持续交付2.0-读书笔记
持续交付2.0：业务引领的DevOps精要（增订本）
持续集成实践对自动化测试建设的四个基本衡量维度
快速
- 指自动化测试用例的执行速度要快。
- 建议大量端到端自动化测试用例的团队，建议持续集成的要求“最好在10分钟之内，不要超过15分钟”。
便捷
- 指团队中的每名工程师都能够随时随地很方便地执行自动化测试用例，而且不需要他人帮助，也不会影响到他人。
及时
- 指一旦功能发生了改变，就能够通过自动化测试用例的运行，告知本次代码变更对软件质量的影响，包括对原有功能的影响，以及新增功能的质量情况。
- 目前中小公司都无法做到新功能完成的同时有新的自动化用例验证新功能，所以反馈速度会降低。
可信
- 指自动化测试用例运行后的结果可以信赖，不存在随机失败（或成功）的现象。
- 测试用例运行需要稳定。
- 持续集成实践要求一旦自动化测试用例失败，必须立即修复。
自动化测试的实施策略
增加自动化测试用例的着手点
- 针对代码热区补充自动化测试用例
- 最好能跟随新功能开发的进度
- 从测试金字塔的中间层向上下两端扩展
- 自动化测试用例的质量比数量重要
要在实现成本最低的测试层级上进行相应业务逻辑的测试。
提高自动化测试的执行次数
- 共享自动化测试用例
- 开发人员是自动化测试的第一用户
良好自动化测试的特征
- 用例之间必须相互独立
- 测试用例的运行结果必须稳定
- 测试用例的运行速度必须快
应对方式
1）将一个测试用例分解成多个独立的测试用例，每个用例测试原有测试用例的一部分，这样就可以并行执行
2）将“等待”改为“轮训”，即以很小的时间间隔来不断查询是否到达下一步执行的状态。 - 测试环境应该统一
这样这些已编写好的自动化测试用例才能被多人复用，才能最大化自动化测试的收益
共享自动化测试的维护职责
- 如果自动化测试用例没有得到及时更新，这个测试用例一定会执行失败。
- 当这种情况发生较多的实话，开发人员很容易对自动化测试的结果视而不见，这样自动化测试用例集也就失去了更大的作用，也会导致越来越多的额自动化测试用例失败，却没有人关注，从而产生“破窗效应”。
最好的同步方式就是开发人员运行自动化测试失败后，就可以自己动手修改对于的测试代码——但是一般中小公司还是无法信任，开发人员只能运行测试，测试人员才能修改测试代码。
代码测试覆盖率
自动化测试的语句覆盖率——单元测试框架编写自动化测试所达到的覆盖率
谷歌公司对测试覆盖率的建议性标准，即单元测试覆盖率达到85%
写自动化测试不是为了测试覆盖率的数值，而是运行这些自动化测试以后，对自己正在开发的软件质量到底有多少信心。
用户验收自动化测试要点
先搭建分层框架
- 测试用例的描述层——测试目的与内容
- 测试用例的实现层——自动化测试用例本身
- 测试用例的接口层——自动化测试库，对底层通用工具的封装
验收测试用例数应保持低位
验证软件应用或服务的核心工作流程，验证端到端的行为，而非具体实现细节。
为自动化测试用例预留API
- 可以增加必要的API，只是不对外开放这类API。
- 在生产环境上发布时，可以通过技术手段隐藏或去除这些API。
为调试做好准备
- 提供完整的日志文件
- 记录常见的测试失败模式
- 保留所有相关的系统状态信息，如自动化截屏、出错时的现场镜像保存等
测试数据的准备
常用的方法有下面4种
- 通过一些规则，编写程序自动生成数据
- 通过录制手工测试时产生的数据
- 将生产环境的非敏感数据克隆一份，或者截取数据片段。
- 进行生产环境数据的自动化录制、保存并备份。
其他质量检查方法
差异批准测试方法
差异批准测试（diff-approval testing）是一种半自动化测试方法。
代码规范检查与代码动静态检测
代码风格规范检查
- Checkstyle
- PMD
- SonarQube
静态扫描
- Coverity
- Klocwork
动态分析
- Valgrind
- Purify
AI在测试领域的应用
- Appdiff
- DiffBlue
- BugDojo
- 微软AI安全风险检测工具
- Facebook Sapienz
总结
对自动化测试的实践管理来说，希望大家能够记住5条重要原则。
- 自动化测试用例运行次数越多，平均成本越低，收益就越大。
- 自动化测试用例之间应该尽可能相互独立，互不影响。
- 在质量有保障的前提下，自动化测试用例的数量越少越好。
- 遗留代码的自动化测试编写应该从代码热区开始。
- 自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高。