测试工程师为什么要关注研发效能？

研发效能中的“研发”，指的是广义的研发团队，包含开发、测试、和研发团队内部的产品经理。测试工程师身处其中，作为研发团队的一员，对于整体的效能如何提升也应该了然于胸。这篇文章，我们详细聊聊为什么测试工程师需要关注研发效能。

本文经公众号思码逸研发效能授权转载。

测试团队的价值困境

在效能改进方面，测试团队的困境往往是不能很好地自证价值。单纯从本位主义出发、只考虑测试团队自身的效能目标，不一定能给研发团队带来整体效益。

比如，有些测试团队会制定缺陷数量的目标，如果仅仅从测试团队自身角度来考量，这个目标是能够产生一定效用的。可是站在整个团队角度思考，却会产生副作用，这种情况想必很多同行遇到过。

还有一些团队致力于提升测试效率，着手点就是通过大规模开展自动化测试来提升自动化测试比例（自动化测试用例数量/自动化测试用例数量+手工测试用例数量）。通过自动化测试，让机器自动执行过往需要手动执行的重复工作用，理想状态下是提升效率的最佳手段。然而，实际效果有时却没那么理想，当研发总监提出这样的质疑：“自动化测试比例这么高，为什么测试周期没有缩短，测试人员没有减少呢？”，测试团队只能无言以对。

图 1-自动化测试的效能

而研发效能领域，正是测试开发团队突破瓶颈的最优选项。

和朋友聊天，发现关注和从事研发效能领域工作的有几波人，包括敏捷教练、项目经理、质量和测试开发团队、研发 Leader 和架构师，大家的视角略有差异，同时也存在相似性。

引用京东技术专家新栋老师分享过的 PPT 的图片来说明：

图 2-研发效能提升“金三角”（引自：研发效能提升三部曲-王新栋）

这些关注研发效能的角色当中，架构师和测试开发团队侧重工程领域，也就是图中的流程机制和基础设施两部分。随着这几年测试团队转型的潮流，很多测试开发团队负责的领域越来越广，从质量内建、效能工具、SRE 和流程改进等方面都有涉猎，正好切合了研发效能的横跨全生命周期的特点。而测试开发团队在基础设施和架构层面的弱势，可以通过和架构师团队合作，从而达成结果。

提升测试效能就是为研发效能做贡献

现在无论是互联网企业，还是传统 IT 企业，“唯快不破”的理念已经深入人心。而在整个产品交付过程中，测试阶段的时间占比和人力投入都是不容小视的，这种情况下，如何提升测试效能就成了一个关键的问题，提升测试效能不仅仅给测试团队带来收益，还能影响整个研发团队的价值交付效率。

DevOps 的基础实践之一就是通过部署流水线打通整个研发过程，并且通过各个阶段的自动化，实现交付效率的提升。其中自动化技术实践包含自动代码扫描、自动化测试和自动化环境部署等，都是测试开发团队持续关注且擅长的。

图 3-自动化技术实践

提升测试效能可以从回归测试做起。在敏捷和 DevOps 的软件开发方法模式下，提倡把大需求进行拆分，把按季度/月交付的周期切分为两周一个迭代进行交付，从而提升研发团队的需求吞吐率。这给测试工作带来了新的挑战——如果不能精准定位测试范围，而选择每次迭代都进行全量的用例回归的话，其工作量是非常大的。

流量录制回放技术和测试精准化是业界常用的实践。通过流量录制回放来生成回归测试用例集，可以极大减少自动化用例编写和维护的时间成本。而测试精准化实践能够精准化匹配代码变更范围，从而推荐最小有效回归用例集，使回归测试执行效率达到最优。

图 4-提升回归测试效率的技术手段

质量内建是效能提升的关键实践

有时候我们会把测试效率提升作为重点，其实质量内建同样是效能提升中不容忽视的关键实践之一。

质量是效能的一部分，我们应该从开始就认识到，效能包含但不等同于效率，质量同样非常重要。“质量是设计和构建出来的，不是测试出来的”的理念已经逐渐被大家所认识到。因此，在设计和开发阶段就需要引入一些实践，来实现质量的内建。

图 5-质量内建的实践

测试开发团队擅长质量工具和平台的建设，可以通过测试能力平台化和服务化的方法把测试能力赋能给架构师和开发人员。具体包含：

• 通过搭建代码质量平台来实现对静态代码扫描和人工代码评审的支持；

• 通过自动生成单元测试技术来减少单元测试用例编写的工作量，通过单元测试覆盖率工具来衡量单元测试的有效性；

• 通过建设低代码/无代码的接口测试平台，使开发人员能够低成本实现接口级别的测试；

• 把界面测试、接口测试和单元测试等不同类型的测试抽离成为独立的测试服务，组装形成不同类型测试任务的混合编排，并且实现与流水线的集成，从而全面支持质量内建实践。

可靠的内建质量不仅提升了软件品质，也为效率提升打下了基础——一方面减少了缺陷和事故概率，使得研发团队不再四处奔忙于救火；另一方面通过测试能力平台化和服务化，降低架构师和开发人员的精力成本，而能够更专注于他们擅长的工作。

测试开发团队向左和向右的效能边界拓展

由于测试处于研发生命周期偏下游的位置，为了化被动为主动，避免由于前期的进度延期或者质量较差等问题影响测试阶段的正常进行，往往会更加关注流程。

其中，比较典型的实践是实现“提测/送测”流程的线上化，使提测流程标准化和自动化。

图 6-提测流程的线上化

相比起来产研团队中的其他角色，测试开发更关注流程，且具备流程线上化和平台化的实际经验。因此测试开发团队常常会把这种能力扩展到需求和发布运维阶段，从而实现需求全生命周期端到端的流程线上化执行。有不少案例表明，端到端的持续交付平台或者 DevOps 平台都是在此基础上不断完善、演进而来的。

图 7-研发流程线上化

从质量度量走向效能度量

做测试时间比较长的朋友们应该都对缺陷燃尽图比较熟悉了。通过观察缺陷燃尽图是否收敛，可以判断一个软件和系统版本的质量情况——如果临近发版的时候，缺陷数量还在不断发散（新增），那此次发版能够按计划施行的几率就比较小了。

在团队还未实现整个研发流程的线上化和平台化时，往往会最先实现缺陷管理的规范化。因此，基于缺陷数据来进行质量分析是我们常用的手段。缺陷数量、缺陷严重等级、缺陷逃逸率、缺陷燃尽图、缺陷密度和人均缺陷数量等等指标从不同视角刻画了研发的质量表现。

而研发团队中关注度量的其他角色，如项目经理和传统 QA 人员，在工具平台建设方面缺少投入和具体的实践；而测试开发团队从一开始就担负着缺陷管理工具、自动化测试报表和测试报告统计等工具的建设工作。因此我们看到，很多由产研团队内部孵化出来的效能度量工具平台，都是由测试开发团队来推动和建设的。

由产研团队内部演进出来的效能度量工具和平台，一般更聚焦于工程性指标和过程改进，更符合产研团队的具体需求。相比之下，由专门的平台部门建设的效能度量平台，则更擅长于大量数据分析、关联数据分析、数据报表下钻等方面。

正是由于两者互有特长，两个团队可以通过合作实现一举两得，既保证海量数据的分析和处理能力，又在一线团队很好地实现落地改进。

图 8-合作共建效能度量

小结

研发效能提升离不开团队中多个角色的协同。其中，测试工程师逐步转型为测试开发工程师，越来越多的测试同仁具备了全栈的技术能力。也许一个测试开发人员，对需求和业务的理解不如产品经理深刻，对代码和架构的掌握不如开发人员精通，对运维和监控的体系不如 SRE 熟练。但是，由于质量和效率是贯穿全流程的，因此对测试开发人员应具备的知识技能的要求也是全栈的。在研发效能的提升之战中，每一个测试开发工程师都必然是先行者。

作者简介：

熊志男，DevOps 及研发效能专家。曾负责京东行云 DevOps 平台的产品规划和架构设计，平台覆盖万人规模的产研团队；曾作为京东数科一站式自动化测试平台的架构师和负责人，推动集团内部多个质量测试平台的共建；曾推动京东商城代码质量平台建设，并实现业务研发团队规模化持续集成落地。

云上软件工程社区 2022 年度研发效能方向创新技术专家，曾担任 QECon2021 的自动化测试专场出品人，测试窝社区联合创始人。

原文链接：

https://mp.weixin.qq.com/s/z-2tqBLrmawhI9PQPmStBA