测试体系分解概要
一· 按属性划分
1.1 软件公共运行环境
1.1.1硬件性能环境
- cpu
- 内存
- 硬盘
- 机房
- cdn
1.1.2软件运行环境
- 操作系统
- 语言版本
- 公共组件
- 运行配置
- 络耗时
- 各软件兼容
1.1.3软件自身
- 后台服务
- 客户端
- web
- 接口
1.1.4 软件部署
- 可操作性
- 可恢复性
- 操作时间
- 架构完备
- 容灾
待sre读完后补齐
二· 按研发过程划分
2.1 本地编码阶段
- Local test
- Presubmit test
- code anaysis tools
- unit test
2.2 代码走读阶段
- code review queue test (regression test / monkey test /diff test)
- code anaysis tools
- auto build&deploy and test(regression test / monkey test)
2.3 持续集成阶段
- health check
- regression test /monkey test / diff test
- trunk onebox test
- unit test
2.4 测试阶段
- system test/union test
- func test
- api test
- test case development / diff test
2.5 预发布测试阶段
- 线上数据模拟验证
2.6 灰度
- AB test
- 灰度流量 or 数据
2.7 线上运维
- 具体业务自动化监控
- 服务稳定性监控
- 络top结构监控
- 路由/机器/ 络联通监控
三· 按测试类型分
- Functional Test
- Ui automation /Client automation /backend automation test
- E2E automation test
- Diff test
- regression test(Automation or manual)
- onebox test
- Monkey test
- Performance test
- Security Test
- presubmit test
- system test /union test /module test/ api test
- ai test
- 持续集成/持续测试
- 大数据测试
- 大型测试，中型测试，小型测试
- 探索性测试
- 精准测试
四· 按被测产品形态
1 toB /toC
2.web /终端 /后台服务
五· 常见测试体系建设
按被测产品，当前研发团队痛点，体量进行不同考虑。比如对于大型研发团队（超过100人）更关注协同，及整体效能，则以devops工程师文化的能力特别需要。 当研发团队人数不多，产品快速进入市场时，质量上可能先是功能测试，探索测试，冒烟测试为主。产品进入第一个稳定周期，更新和发布注重质量时，回归测试进入，自动化测试能力逐步要加大投入。同时按前面提到的产品形态，选取最好的自动化测试手段。比如重前端交互，内部架构不复杂的产品， 终端类的自动化要更多。
他山之石
以google这类公司有标准的test centralfy， 生产力团队会制定测试标准，评估每个项目团队和产品所达到的质量标准。按照标准，其实就可以补齐现在测试团队的能力。推荐阅读： how google test software
google内部生产力团队按大型测试，中型测试，小型测试区分测试开发类人员，同样是一个对测试体系可以建设的方式。 将被测产品按模块类型来这样分类。
分层测试
- 按被测系统架构分层
- 按研发过程分层，业界提的测试左移，测试右移
- 按组织形态
Devops文化
- 按devops概念来构建测试体系，持续集成，持续测试，持续交付是外在表现。频繁多次提交，快速发布，快速反馈。
- 内在自动化测试，环境管理，研发模式，规范标准统一，工具化是基础。
未完待续 –
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！