敏捷开发最佳实践：质量维度实践案例之接口级自动化测试

本次分享我们将继续给大家带来全新的质量维度实践案例：接口级自动化测试。

本实践节选自《2022中国企业敏捷实践白皮书》，分享者为查俊，是来自腾讯的高级研发项目经理。

问题：

版本持续迭代，关键路径上的场景持续增加，导致回归测试时长无法收敛，产品质量难以控制，挤压迭代交付容量。

问题成因：

手工测试占比太高，测试不够高效；过度追求交付速率，对技术架构治理投入不足；过度依赖测试阶段控制质量，上游研发缺乏早期看护。

敏捷实践：

自动化测试体系搭建：减少功能测试人力，置换原人数30%的专职人员进行自动化测试建设，并增加产研自测流程，按迭代T+1实现自动化覆盖。

适配范围：因当前项目轻前端重后台，场景化接口测试为主，单元测试为辅；
工具选型：使用公司内成熟用例编写框架，后期快速接入DevOps做为质量门禁和卡点；
编写规范：考虑测试资源和数据的独立性，便于后期可以快速在多环境执行，真正做到一套自动用例到处运行；
用例维护：用例持续运行数据可视化，底层异常信息标准化错误聚类，大幅减少分析维护成本。

区分特性团队和技术域团队：特性团队面向交付，技术域面向技术架构，提供公共服务、看护架构质量。

人才培养：每个技术域设置专门的值守人（兼职），日常参与迭代交付，纵深看护领域内技术架构；
公共服务：迭代技术方案横向Review，抽象公共服务解决方案，监督研发遵循执行&技术债消除；
稳定性建设：从性能排查、研发规范、灰度策略、监控告警、资损对账等维度，持续搭建质量稳定体系。

实践结果：

通过自动化测试建设，测试人力降低为原来30%左右，结合技术债的消除和对技术域的值守保证了稳定的产品质量；自动化能力的提升，使得冲刺周期中回归测试的时间从3天缩减为1天，提升了需求和价值的实际交付量。

总结：

质量管理是高速持续迭代的基石，通过测试自动化技术体系的搭建，才能规模化提效；测试不应该是质量管理的“保护伞”，质量应该前移到架构规范、服务标准化，从源头就开始治理。

本案例体现了敏捷第七条和第九条原则：“可工作的软件是进度的首要度量标准。”、“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。”

专家观点：主动消除技术欠债，在源头处保证质量

林伟丹

旭势教练深圳合伙人敏捷变革专家

敏捷倡导迭代开发和增量交付，以便更多、更快地支撑产品和服务的尝试性实验，及早获得来自于用户和数据上的反馈，帮助企业在高度不确定的BANI时代和激烈竞争的市场环境中获得成功。

在这种短周期交付的节奏中，测试和验证的周期相当有限，如何保证研发质量和安全、又好又快地交付，面临着巨大的挑战。

解决这个挑战的秘方例如：基于更小的需求粒度进行跨职能协作，拉动需求流动减少阻碍和停滞，提升代码签入后部署价值流的自动化程度，促进敏捷团队内部的技能备份和基于瓶颈的互相补位协作，等等。

在这些方面，在腾讯查俊经理带领的团队案例中，有着良好的实践和成果。

内建质量（Build-in Quality）是当下企业中重要的质量理念，也称为在源头处保证质量（Quality at the Source），与丰田精益五原则中的尽善尽美（Perfection）也有很强关联。

对于软件开发来说，这种理念与以往以“阶段-门径”为特征的软件工程过程有显著不同，对于产品的质量，不再寄望于一个或多个单独的、长周期的后置测试阶段来保证质量，而是更积极的将质量前置（Shift Left），力图在代码写好的那一刻（或在几分钟或几小时之后），就能符合上线的质量标准，达到潜在可交付的程度。DevOps与持续交付相关的各种工程技术实践应运而生，在近些年越来越多地普及开来。

主动消除技术欠债也是持续保证系统质量的另一个重要视角。

技术欠债通过日常非最优的技术选择（迫于项目压力或工程师的能力、惰性因素）而形成，属于看不见而又产生消极影响的一类东西，需要在平时的工作过程中持续“还债”，最好通过有意识的“产能分配”，给技术类的改进留出一定百分比的研发资源；否则会逐步拖累、拖慢研发的步伐，并且对系统质量产生更大的压力。

在查俊的案例中，对于每个技术域的专人值守、对于技术方案的横向review，也都有助于减少欠债、提升效能。