聊聊持续测试的进阶

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

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

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

这篇继续聊聊持续测试建设的ROI分析，思考未来的成熟度进阶，以及其他要注意的。

前一篇：聊聊持续测试

持续测试的成熟度进阶

鼎叔经常对团队描绘持续测试建设发展的三大阶段，看看怎么和行业的高水平逐步对齐。

第一阶段，跑起来，形成纪律。

只要有代码提交，必然触发流水线测试的结果。团队在第一阶段实践好了就能看到以往没有的自动化收益。

有些工程师以往不愿意投入自动化建设，理由就是业务需求安排的太满，没有时间搞自动化建设。

这里有一个误解，自动化测试不是额外的工作，它就是业务测试的一部分，如果自动化测试不能让业务测试更高效，那就说明自动化选择策略出了问题。

当我们要求全员把第一阶段跑起来，那些业务测试压力很大的同学很快就适应了，做得很不错，甚至开始依赖持续测试的回归拦截网，它让新需求的测试更加安心。

以往的业务测试压力大，往往是怕大量的历史业务逻辑没有被验证，所以测试计划时间拖得很长，进一步增加了交付压力。在持续测试背景下，员工只需要聚焦新功能验证即可。

第二阶段，成熟的流水线部署，能够应对大团队的持续测试需求，并做好精细化管理。支持常见的流水线构建机制，如并发构建（缩短大量用例执行时间），次级构建（让耗时长的用例异步处理，或者让不太重要的用例集异步处理）。

在这个阶段，用例可以分为不同的批次，有些在代码变更时就触发执行（执行时间短，维护成本低），有些在主干发版前才触发执行（执行时间长，维护成本高）。比如APP适配质量标准的测试属于后者。

这个阶段的持续测试看板建设也成熟起来了。各个团队、各个项目的流水线执行健康情况和趋势一目了然，低效指标会很快暴露出来。

第三阶段，流水线的智能化+精准化，以及不稳定测试集的隔离。

前者要达到的水平是，让大量项目的海量自动化用例能够被智能的挑选，缩短执行的总时长，挑选出尽量少的用例集覆盖尽量多的代码执行路径；系统能主动识别出要汰换的过期或低效用例集，并提示应该补充的新用例。

后者要建设的目标是，把偶然失败的用例（随机性失败）挑选出来，单独在隔离区中集中运行，研究概率失败模式，挖掘更有深度的质量缺陷。这块的用例数量大约占总用例数的1%-2%。隔离区对于持续测试用例的整体执行稳定性也有很大助力。

第三阶段能实现大规模团队的持续测试管理，把算法分析的价值在测试执行分析上发挥到最大，把最新的测试智能工具进行中心化部署，让业界的好东西快速传播到所有一线团队。这就是鼎叔心目中的行业一流水准。

DevOps和持续测试实践的ROI

在持续交付DevOps实践中，频繁的持续测试自动化占据着非常重要的一席之地。只有快速验证每次代码提交的质量，持续集成才能健康地顺利进行。理论上所有自动化测试建设成果都可以纳入每日持续测试的范畴，但是出于快速响应及验收的目的，持续测试中的自动化一定是小批量的精华测试用例，其产生的ROI理应也是最高的。

基于此逻辑，稳定的单元测试和主要链路的接口测试用例会成为每次代码提交的必测用例集，执行时间很短（几秒到一分钟以内）。

那么，其他层次的自动化测试建设成果是否就应该隔绝于DevOps之外了？非也。以下是作者基于项目实践总结的例子。

1 更多非主链路的接口测试用例，如边界场景，超时场景，异常处理场景，可以安排并行构建队列，同步执行，缩短等待接口测试结果的时间。

2 稳定的很少量UI层验收自动化用例，可以作为可选测试集合，在版本提测给专职测试人员之前触发运行，代表着基本的用户视角场景验收完成。

3 更为耗时的系统级测试，如性能测试，稳定性测试和系统兼容测试，可以安排在次级构建队列中，下班后自动运行，第二天上班看测试报告。次级构建不会影响白天的代码提交入库门禁，但是发现问题也要尽快处理，必要的话需要回滚代码部署。

4 对于实践持续集成的研发团队，每日构建的健康度和团队纪律至关重要，其相关纪律指标可以考虑下面这些。

1)是否每天都有提交？如日构建次数，人均checkin代码次数，每日自动化测试的执行次数和范围等。

2)每天提交代码的测试质量如何？如每日测试自动化回归通过率，单元测试门禁95%以上通过率，其他自动化测试集通过率90%以上，发现crash/ANR次数等。

3)代码健康度指标。如代码扫描通过率，圈复杂度，重复代码率，扇入扇出数量等。

4)自动化缺陷前置率。有多少有效缺陷是在测试人工介入之前，由持续测试平台已经发现的？在总共的有效缺陷中占比多少？这个指标说明了持续自动化测试平台的建设收益。

5)关注构建成功率（主干分支的构建成功次数/构建总次数），健康构建天数（每天都保障有可供尝鲜和众测的版本），构建平均时长（从代码拉取到所有任务完成，包含编译，代码扫描，单测和自动化测试）和构建失败的平均恢复时长。

所有流水线的平均构建时间应在15分钟以内。平均构建失败的恢复时间应小于4小时。

6)关注版本发布健康度。成功发布成功率足够高，灰度发布次数符合预期，尽量减少不必要的紧急版本发布。

如果要对持续集成和持续测试的成熟度进行评价，我们可以依据哪些团队典型表现来判断？以下这些问题可以供大家自评参考，进而锚定改进措施。

1)团队是否利用了静态代码分析工具，对发现的不良问题立即进行修改，不遗留到正式提交代码前？不良问题包括严重级别以上的问题，高重复率和高复杂度的坏味道代码。越早关注坏味道代码并加以杜绝，评级越高。

2)开发人员是否为新增或修改代码创建了单元测试，并通过流水线门禁来频繁执行和保证持续生效？开发人员越能在实现代码的同期提交单元测试代码，评级越高。

3)功能和接口自动化测试是否有效，且能够通过持续集成频繁执行？遵循金字塔原则，不同层级的自动化测试的覆盖范围（投入）是合理的。

4)团队能否基于单主干开发，以便测试人员进行快速灵活的测试策略？基于单主干开发，测试人员可以每天完成功能验证，无须针对代码合并主干再做集中验证。

5)非功能性测试能否在发布前足够短的时间完成？团队可以利用工具模拟对被测系统的性能、安全、并发稳定性、系统适配性、版本兼容性等质量情况进行自动化验证，频繁执行。因为有成熟的自动化基础设施，大部分非功能性测试已经在迭代内验证过了，发布前很短时间（比如一天内）就可以集中完成。

6)所有构建、测试和发布是否都使用流水线自动完成且验证内容完整：

流水线可以自动打通全部发布渠道（自由渠道，应用商店，内部灰度渠道等）。不同分支的流水线选用不同的覆盖策略并行推进。特性分支只做快速验证，发布分支的流水线则进行全面扫描、测试和发布打包。静态扫描以及自动化测试如果耗时过长，则应该增加独立流水线进行验证。

7)每个开发人员能够及时将代码合并回主干（从新的编码开始计算，最好三天内合并回主干）。

8)构建/测试成功或者失败能立刻通知团队，团队立刻关注并尝试解决错误或者回滚代码，让构建或测试通过。

9)团队是否利用了多种可视化提醒方式，让持续构建和持续测试的不健康状态传递给责任人及影响团队，比如IM弹窗、告警声音、亮灯和监控罗盘。

最终，从DevOps平台视角来看，能否可视化地呈现整个研发过程中各阶段的阻塞时间？包括待评审、待开发、待测试和待发布这四个主要阶段，能从中看到“被迫等待”的严重情况，便于团队得出下个迭代如何改进的建议。每一个DevOps工程的状态扭转都会作为研发过程的元数据自动生成相关指标数据。

相应的，DevOps平台也应该显示各个时间的WIP（在制品数量），以便团队及时停下来进行针对性干预，避免后面的整体交付效率下降。

此外，DevOps本身作为一个toB的产品，它的可视化看板和操作台可以请产品经理进行易用性设计，不断提高团队的使用效能。

持续测试的文化建设

真正优秀的持续测试标杆员工，有哪些特点？鼎叔会点赞甚至广泛传播这样的实践效果。

一，非常复杂但是很稳定的大系统，基于持续测试，让质量保障游刃有余，只需要一个QA员工轻松搞定。

二，让开发依赖流水线的持续测试应用。开发每次提交代码后都关注持续测试的结果，没问题才离开岗位。

三，让外包积极参与持续测试流水线用例的建设，效果稳定。持续测试不应限制测试框架的选取，只看效果，总有适合本外包团队的自动化测试框架，用心实践会得到超出预期的效益。

还有什么要聊的

持续测试想要健康运行的两大基石，就是测试环境治理和测试数据构造，这两块可以作为专项建设来展开，值得深入挖掘。

持续测试的环境

首先要能透明化问题，不要停留在时常的团队抱怨状态中。

手段并不难，我们可以监控所有测试机器的在线率，并触发告警，统计可用率。

针对频繁掉线的服务和设备，具体分析原因，定期广而告之。

测试环境需要一整个链条的支持，包括服务器、手机终端、配置平台、网关证书、鉴权工具，批处理工具、恢复缺省状态的工具，均能正常工作。背后就是要耐心磕细节，收益有可能非常大，因为测试环境可能服务了数百上千的工程师，多投入治理精力是值得的。

测试数据构造市场

对于一个复杂大型业务，参与自动化测试的人员众多，花费在构造测试数据的成本会显得很庞大。

业务逻辑链条越长，测试数据的调用和验证就更复杂。

封装一个核心测试数据的自动构造工具（函数），对于缩短测试用例生成时间非常有帮助。我们把可能用上的核心数据工具列在工具市场上，供各团队选用，使用热度越高的工具越排在前面。