背景

最近老有人问我如何成为测试架构师, 或者问如何从零开始构建起来分层测试体系. 我都不知道如何回答.
首先测试架构师只是个虚名, 本质就是个测试开发工程师. 行业里面其实都没这个正式的名分.
要说特别的话, 就是一定是了解研发的技术体系多一些, 在遇到新的体系时知道如何测试. 其他的我就不装逼了.
搭建测试体系需要对公司的架构需要有个了解, 对症下药.
每家公司都有自己的测试方案和测试手段. 我分享下我目前做的一些东西给大家.

这里面的很多选择只是备选. 是为了让大家了解现状. 大家需要根据自己的情况选择适合自己的框架和工具.
这个也只是我初期做的规划, 里面的很多内容还未完成. 仅供参考.

以后有机会我将挨个的分析每个每个测试层次的所用到的细节, 搞个小小测试架构师系列文章.
不过鉴于我一直写文章跳票, 所以大家最好心理准备吧.

思维导图版

文字版本

---+ 测试规划

• 测试技术

  • 云测服务使用
    • mtc
    • testin
    • fir
    • mqc
  • UI 自动化
    • appium
    • capybara
      • selenium
      • phantomjs(推荐)
  • 接口测试
    • 框架选择
      • soapui
      • capybara-json
      • gatling
        • 参考他的集成测试例子
    • fake server
    • 分析工具
      • fiddler(貌似是唯一可自动解码工具)
      • soapui
      • em-proxy
      • 自定义代理
  • 单元测试
    • 研发推进, 仅作支持
    • 持续集成结合
    • 静态扫描
      • findbugs
  • 性能测试
    • 负载测试
      • 加压工具
        • gatling
        • ab
        • jmeter
      • 监控平台
        • influxdb+grafana
        • ELK
        • nmon(不推荐)
    • 性能剖析
      • byteman
      • btrace
      • 火焰图
        • perfj
        • systemtap
  • 测试分析体系
    • 覆盖率
      • jacoco
        • android
        • java
    • 流程建模
      • 根据 byteman 构建思维导图
    • 代码 diff
      • 思维导图红黑线 diff
      • dot 绘图
    • debug 与 trace

• 研发流程

  • jenkins 持续集成
    • 自动构建
      • 发布包构建
      • docker 镜像构建
    • 自动编译
    • 自动静态扫描
    • 单测
    • 部署
    • 性能测试
    • 接口测试
    • UI 测试
    • 报警机制
      • 大 job 收集所有子 job 的结果
      • 邮件提醒为主
  • 手工测试
    • 新功能测试
    • 预发布环境
    • 预演环境
      • testerhome 的引流
  • 开发模式
    • 分支开发主干发布
    • 基于每个分支构建对应的持续集成 job
    • 发布版本从 tag 中获取
    • 持续集成监控 tag

• 测试环境

  • 手工部署
  • 自动化部署
    • docker
      • 基础镜像可以手工构建
      • 给每个容器分配独立的 ip
    • vagrant
    • vmware virtualbox

• 线上环境

  • 接口版本化
  • 灰度发布
  • 流量旁路