这是鼎叔的第九十六篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

如果在测试部门只能推行一个技术建设项目，那鼎叔就会选择 “持续测试”。

持续测试（Continuous Test，CT），也有公司称为每日测试（Daily Test），就是每天都有新版本生成并完成相应的测试活动，绝大部分测试都是自动化测试，但是也可以推送新生成的安装包到成员的终端上进行人工 dogfood（内部探索测试）。尽可能在当天就发现是否有基本功能被新代码破坏掉，缩短解决问题的闭环，并让大团队对新代码提交保持信心，这样的实践契合 “频繁测试”、“集体对质量负责” 的敏捷原则。

持续测试的健康度指标

带领团队全力投入持续测试之前，鼎叔会不厌其烦地强调：持续测试不是普通的自动化测试，健康度比覆盖率更重要。

以往测试团队在设立自动化测试目标时，都把重心放在自动化覆盖率上，比如所有测试用例被自动化的比率，或者接口/代码行的覆盖率。只看这一类指标很容易带来临时抱佛脚，有不少 QA 会在考核末期把自动化率提上去，用例没有通过也不去深究原因，整个自动化下来累计发现的问题非常有限。

鼎叔推荐以下几个健康度指标：

1 持续测试卡点失败的恢复时长（MTBF）

持续测试的卡点就像安灯绳，指定的基础功能一失败就应该停下来检查。

为了保障持续测试能顺利开启，团队首先要确保持续构建的成功率，必要时督促开发立刻处理失败，建立对健康构建的重视态度比完善工具更重要。

有一部分不太稳定的，优先级也不高的持续测试用例集可以不设置卡点，或者设置低阈值卡点，以免经常失败导致人员精力的过度耗费。但这种用例集数量应该尽量控制，可以放在员工本地运行，稳定后再放在团队流水线中。

2 测试还需要关注项目的构建和执行速度，通常应在几分钟以内。在实践中发现，导致构建耗时太长的原因经常来自于测试，比如包含了远程服务（如数据库）。

3 度量团队和项目持续测试的前置缺陷发现率，就是持续测试回归自动化过程中累计发现的所有有效问题。这个指标不管用什么自动化框架，不管黑猫白猫，只要发现尽量多的问题就是好猫。

这个指标主要看遗留测试资产（回归自动化）的效果，包括利用各种无需 QA 人工投入的自动化能力，能在人工测试之前拦截多少有效问题。

持续测试人员可以用各种手段客观记录有效缺陷，不一定要录入缺陷管理系统，更多是度量持续测试的产出价值。

持续测试实践的成效是，后期的系统测试阶段发现的缺陷数量大幅下降了。没错，在测试左移中，系统测试中发现的缺陷占比越少，越有可能是件好事。

4 测试用例通过率。有的流水线卡点会设置为 100% 通过，也有设置为 90% 通过的。关键是只要有失败就要快速排查，是脚本问题、产品沟通问题、环境问题，还是缺陷。

通过率的治理可以倒逼 QA 优化用例集，剔除不稳定的，或没想清楚的用例，避免 “用例越多越好” 的误区。

5 测试人员除了参与验收标准和验收用例的评审，还可以在开发完成单个需求（用户故事）自测后，马上开始针对性的验收测试（如果产品经理能先行做用户验收测试则更佳），快速反馈该单个需求的质量情况（最好当天完成），降低迭代版本测试或系统级测试的风险。反馈周期越短，开发修复的效率越高，而传统的等待版本提测模式，会拉长开发的等待时间，加大切换任务的注意力耗费。

持续测试的技术栈

产品和项目质量交付是一个整体，包括客户端/前端，和后端的代码测试与发布。但是从自动化技术层面，客户端和服务端的测试框架和执行速度还是有很大差异。

所以持续测试建设团队需要从两套技术栈去分头建设流水线，一套是客户端，一套是服务端，分头掌握不同的自动化能力，但最终的质量标准和指标看板要整合为一个结果，面向产品的整体来输出。

客户端持续测试流水线

客户端的自动化测试成本在很多时候是高于服务端的，可以借用的行业技术成果也更加的丰富多彩。

一，因为客户端面向用户体验视角，所以具备 AI 图像识别能力的 UI 自动化测试框架有不错的潜力。

二，三端合一测试技术，即用一套脚本在 Android，iOS，PC/Website 上同时完成自动化测试，这是客户端测试的热点，在持续测试中非常有价值潜力。

三，真机集群适配自动化测试，这个将来有机会可以专题分享。不同机型的 APP 适配质量是很多开发团队的噩梦，行业已经有很多针对性的解决方案。因为真机适配 UI 自动化通常速度慢，失败率较高，所以更适合作为非卡点异步任务。

服务端持续测试流水线

服务端持续测试肯定以协议测试/接口测试为主要形式，但是接口测试的框架也是五花八门。对于电商等复杂的线上流量业务，流量录制回放工具占据了越来越重要的比重。持续测试平台可以同时接入流量录制回放型自动化测试框架，和常规的人工创建型自动化测试框架。

持续测试看的是疗效，不追求执行框架越单一越好，只要能显著提升前面的健康指标，引入外部开源的或商业工具都行，甚至友商工具也可以拿来用。

持续测试流水线的分层（五层）

持续测试中的自动化测试是分层进行的，因为不同层次的自动化测试耗费的时间不同，修复成本不同。参考 HamVocke 的测试金字塔理论，自动化测试可以分为下面几个主要层次。

1）静态测试。即静态代码扫描，包括代码普通质量问题和代码安全问题，针对扫描结果，我们会关注扫描出来 Block 问题和 Major 问题，设立修复率目标，推动开发把精力放在前期。

2）单元测试。之前文章已有介绍。

3）接口测试。

4）跨链路测试或集成测试。在很多公司，集成测试被称之为联调测试，通常由开发人员负责，但是测试人员也可以共同建设。

集成测试可以分为狭义集成测试和广义集成测试。狭义集成测试聚焦被测对象的服务边界，触发本对象和外部（另一个服务，或数据库，或文件系统）的集成动作。而广义集成测试则是通过网络和外部服务进行集成，但是速度更慢，测试更脆弱。依托测试环境稳定的基础设施服务，集成测试通常按照从小到大的顺序联调，逐步提高服务的可用性。

从敏捷角度理解，联调意味着跨特性团队的协作，虽然难以避免，但也属于浪费的成本，应该尽可能降低联调的投入和时间。如果参与联调的各方都有非常清晰完备的接口定义，充分考虑了可能的错误场景，那么联调就可以在最短时间完成，甚至借助事先做好的自动化用例全自动完成。

因此，在微服务产品中，契约测试（作为一种特殊的集成测试）就流行开来，所有微服务的接口测试都根据定义好的接口契约，设计完整的稳定的测试用例套件，确保数据的生产者模块和消费者模块遵循契约。基于该套件的每天持续测试把关，研发团队便向自治团队迈出了一大步。

5）UI 测试/端到端测试。注意，UI 测试是端到端测试的一部分，即从交互界面上验证结果。端到端测试还有不少其他层面的验收标准，比如没有界面的功能，系统性能，安全性检查，日志正确性，交付规范的文档等。对于微服务架构的产品，需要有人面向整个系统，跨越多个服务来编写端到端测试用例。

这些自动化测试层次使用的测试框架各不相同，但持续集成平台都可以纳入，并行执行，根据团队的效能度量要求进行任务配置和结果治理。

哪怕不完美的自动化测试，只要能够频繁执行，也比很少执行的完美测试更有价值。

而前文提到的验收测试，和测试金字塔的各个层次是正交的，你可以依托单元测试来验收，也可以从接口验收，当然也可以在 UI 层验收。

如果一个功能验收可以同时在低层次和高层次自动化实现，那就应该保留低层次测试用例，而放弃高层次用例，以减少用例重复。但是，如果高层次的用例能够提高我们对于产品发布的信心，那就应该保留它。

这也就是我认为，单元测试及集成测试，不太可能完全替代端到端测试的原因。

持续测试与测试右移

持续测试贯穿产品研发生命周期，它的价值不仅限于左边，也适用于右边的质量活动。

持续测试就是要把前期积攒的测试资产在灰度、发布、上线后反复利用，测试框架设施不变，收益最大化。

具体实践可以包括：

埋点验证自动化测试。产品的关键指标埋点是一类对产品发展很重要的功能，除了在常规测试中验证，也可以在预发环境和线上环境进行测试和监控。

线上巡检自动化。出于商业目标的保障（如重大营销时期的价格风险检查），线上的关键页面处于不断变化中，老板对此关注力度大，甚至还需要和竞品对比，这就不是简单的指标监控就能保障的。测试自动化可以梳理出 UI 层面巡检的场景和脚本，把它拓展到正式环境进行采样巡检。

业务逻辑拨测。普通的接口可用性监控，对于运营团队和网络服务公司来说很容易，但是具体业务逻辑是否在现网保持正常，仍然没有确定答案。既然测试团队有各种核心业务场景的自动化脚本，就可以挑选少量场景，用很小的流量进行拨测，尽早发现问题。

下一篇我们聊聊持续测试实践的进阶思考。

↙↙↙阅读原文可查看相关链接，并与作者交流