前有《微软的软件测试之道》和《Google 软件测试之道》，后有《阿里测试之道》，都在尝试提升软件质量和交付效率。

测试的本质

提升软件系统的质量和效能，阿里主要通过三个维度的提升来改进：

缩短反射弧（时间）：测试用例向“测试金字塔”的下层迁移；提高测试并发执行的能力；通过精准测试能够自动准确地剔除无关的用例；通过测试用例有效性、代码覆盖率和业务覆盖率的准确度量帮助我们更好地进行等价类分析，对测试用例集进行持续瘦身，避免用例集不断膨胀。
降低反馈成本：测试用例向“测试金字塔”的下层迁移；将更多的测试用更快、更省资源的“小型测试”；精简测试用例、只运行相关的用例，通过缩短测试执行时间来减少对资源的占用；从“硬隔离”向“软隔离”转变，用更多的逻辑隔离替代实例隔离；
提高反馈可信度：提高测试的稳定性，降低测试结果的噪声；提高测试的代码覆盖率和业务覆盖率；提高测试的有效性；自动生成测试用例，减少人工进行测试分析和罗列测试用例产生的测试遗漏。

缩短反射弧

度量对于改进的作用是给出反馈，但光有度量还不够，还要度量得足够频繁、度量得足够快，这样才能更有效地改进。
和测血糖类似，原来需要去医院开单检测，现在在家通过仪器就可以检测，这样就缩短了反馈时间。
要缩短反射弧，就要建设持续集成，通过集成测试来给出快速反馈。

高频：通过高频来倒逼问题的发生和能力建设。高频打包、发布、证书更新、容灾演练。通过高频测试可以：缩短反馈弧；变主动验证为“消极等待”，减少测试人员的工作量；识别和确认小概率问题；暴露基建层的不稳定因素；倒闭人工环节自动化；为分析提供更多的数据；
隔离：通过隔离让不同的测试活动之间要尽可能做到不相互影响。团队和系统规模较小时可以考虑硬隔离，当团队和系统规模变大后，同时成本问题也日趋凸显时，就可以逐渐建设起软隔离；软隔离的终极形态是 Testing in Production（TiP），依靠完善的隔离机制，直接复用生产环境的资源和服务搭建测试环境。

阿里有团队不仅在门禁处做单元测试，也会在主干分支上高频运行所有单元测试和接口测试以确保小概率出现问题能暴露出来。

通过变异测试向应用代码中注入一个Bug，看看测试代码能否发现这个变异，以此来验证测试代码发现 Bug 的能力。

用例自动生成、业务覆盖率度量。

防错设计、代码扫描。

测试迭代决策依据：精益测试；
精益测试三个维度的判断：
- 时间短
  - 自动化：集成自动化、测试自动化、监控等来缩短反馈时间；
  - 测试内容：精准测试、并发测试、高频测试等；
  - 度量和迭代：测试数据模型（分层管理，多层互通消费）+可视化呈现（分层）；
- 成本低：测试左移（通过软/硬隔离使得测试能不依赖环境快速执行）、AIGC等；
- 效果好：
  - 对测试进行测试（用例有效性）：变异测试、运维规则测试等；
  - 测试不测试：运维监控、巡检扫描、测试右移（通过现网复杂场景和流量进行回归验证）等；
测试优化手段：测试左移，测试右移；
能力边界：SDET和SDE无能力边界范围区别，SDET的能力栈和SDE能力相同；
文化建设：测试左移和右移不仅是自动化技术方面的改变，还有组织和文化需要配合发生转变，研发是质量的第一责任人：质量内建；谷歌的工程生产力团队仅聚焦自动化能力构建，不对最终产品用例和质量负责；

Q: 是不是一定要有度量，什么时候应该要开始有度量？ A: 流量决定一切，没有流量可以随便重构演进，但有流量的时候就需要开始建度量；
Q：如何来建设度量体系，是正向建设还是反向改进？ A：. 测试数据本应该就是（微）服务的核心属性之一，通过FST分析缺陷流出率等和服务测试数据应该是相互补充促进的关系；举个例子：人肯定要有心跳，并且能用心率监控器检测心跳，发现胸闷可以用心率监控器来检测心跳，但不能等发现胸闷的时候去造心率监控器；当然也有可能发现胸闷不是心脏导致的，但也不能说不需要心率监控器；当然心率监控器不好用，那还是要根据实际遇到的问题来改进；