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

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），文末有链接。

我们继续聊聊在整个软件生命周期中，以及各个主要阶段，我们选取哪些关键拆解指标做好研发过程的提效治理。

一 需求分析阶段

基于测试左移到需求阶段的知识 ，聊聊测试左移到需求阶段，https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484386&idx=1&sn=219bd680bdd83246517871b47da0a7a8&scene=21#wechat_redirect
我们如何通过度量手段，保障高效的需求分析措施能落地？

完成需求评审后，推荐在研发管理平台录入以下度量指标，方便团队迭代回顾和改进。

需求评审的问题拦截数，或拦截率（需求评审阶段发现的问题，占整个研发周期发现问题的比重）：在需求研讨阶段发现的问题越多越好，这意味着大量的无效开发和测试会被节省下来，同时这也标志着技术和产品的研讨是非常高效的。
需求验收测试用例数和覆盖率：在需求评审阶段，如果团队将每个需求都明确了验收标准和合适数量的验收用例，就对驱动开发进行高质量的代码实践提供了保障（这个保障是有团队共识的），避免开发目标的跑偏，同时保障了交付的最基本质量。既然有验收测试用例，证明需求的可测性就不是问题。
需求平均大小（颗粒度）：每个需求的平均大小（故事点）处于合适的值，按照经验，小批量需求的平均开发量最好为 2-3 理想人日，测试验证就会非常及时。
需求评审效率，即需求开发预估时长/需求评审时长。注意，效率太高或太低都不是好事，都值得改进。如果太高，可能反映了需求评审会的讨论不充分，有悖于 “磨刀不误砍柴工” 的质量左移原则。如果太低，可能反映了需求逻辑没有经过事先的充分思考，需要先小范围交流和打磨，再进入团队集体评审，节约团队时间。相似的指标还有需求评审通过率，我们同样不追求需求评审要一次通过，而是更多地关注需求评审不通过是否因为缺乏可测性描述。
需求文档完整度。我们可以在需求规格文档（PRD）的模版中加入 “可测性分析” 需要的关键技术信息（具体可以参考内容聊聊需求评审与验收测试），这样有利于开发和测试提高设计质量，尽可能减少后期返工和浪费。因此技术团队可以针对哪些关键信息的缺失来给出 PRD 的 “完整度” 分数，常见的关键信息有：需求背景，市场和竞品分析，业务目标/价值，业务流程图，需求功能清单和描述，性能/安全/数据要求，对外依赖关系，需求限制说明等等。

注意，敏捷不追求重文档，对于大家都清楚的信息，即使 PRD 文档没有说明，也可以认为是完整的。

二 开发设计与编码阶段

开发团队的管理者理应重视工程实践中的质量和速度，尽可能降低工程师操作的繁琐程度，提高编码阶段和单元测试阶段的发现问题效率，尽可能让工程师处于 “心流” 之中（即沉浸式研发）。那么如下的指标就凸显了其重要性。

开发中断时长和次数：在整个开发周期，开发被迭代无关事项打扰的次数和时间。管理者或者教练应该尽可能让开发有持续的思考和编码时间，进入高效率的工作状态。
需求测试验收一次通过率：有多少个需求开发提测后，是一次性通过测试的？这个比例越高，说明开发和测试互相流转缺陷状态和回归任务的消耗成本是越低的，也说明开发侧质量很靠谱。
单元测试代码覆盖率：对于单测，应该追求核心代码的被覆盖率到一定比例，新增和存量覆盖率可以有一定差别，比如增量代码覆盖率 80% 以上，存量代码覆盖率 50% 以上（仅供参考）。此外，持续测试中的单测通过率应该要求 90% 以上甚至 100%。
代码评审通过率：默认提交主干的代码都需要通过代码评审，有明确的签署人，评审改进意见入库。代码评审的基础除了对业务要有深刻理解，也需要大家对代码规范的共识，这一块 QA 可以做较多的推动培训和审计工作。
代码扫描阻塞（Block）问题数量及解决率：针对有效的代码扫描问题（非误报），开发团队可以设置门禁规则，提高扫描出阻塞型问题的解决率，追求尽量短的处理时长，避免人员经常忽视，导致技术债越来越多。相似的指标还有代码扫描重要（Major）问题的数量及解决率。
代码圈复杂度和代码重复率：这两项指标是有潜在高收益的可改进项，圈复杂度会带来可测性的极速下降，以及逻辑理解难度的快速增加，相对于代码缺陷密度更有指向性。代码缺陷密度和测试能力及业务结构都有密切关系，难以横向对比判断。代码重复率说明代码重构方面有不足，可以借此进行简洁代码的改造。
Crash 率和 ANR（Application Not Responding 响应超时）率：挑选这两个质量指标作为开发改进的重点，原因是它具有通用性（所有业务都不能容忍这个值过大），明示了代码质量的严重显性问题（用户的感知非常强烈），自动监控工具和分析定位工具也高度成熟。从经验上说，开发团队的基础素养在对 crash 率的修复态度上可以体现出来。
联调人力成本：如果接口定义和异常设计的水平高，联调的成本就会大幅下降。对于复杂的软件系统，调用链路的长度、跨域响应的数量、基础服务的稳定性、单个微服务的质量，都会影响联调的成本。因此，缩短该成本的努力，也是完善架构设计细节的过程，其回报也是值得的。

三 测试阶段

测试管理者首先要关注测试环境的可用性，方便、稳定、随时可以进入测试，其次是对自动化框架的强大整合能力，对于手工测试的提效和复盘也不可或缺。敏捷测试需要的 “测试左移” 实践则是管理者应该修炼的方向。下面这些关键指标有利于测试管理者始终把控关注重心。

测试环境准备时长和测试环境恢复时长：测试环境是阻碍测试效率提升的老大难问题，耗时多的地方在于：一、环境准备时间通常很烦人，耗时占比惊人。二、环境不稳定，经常需要停下来重启或者寻找故障所在。如果这块度量数据总是不理想，技术团队就需要停下来进行专项治理了。高效能的团队，环境的分配、准备和恢复都应该是高度自动化的，无需使用者操心。
重复执行手工用例占比：虽然我们并不追求测试自动化率越高越好，但是手工测试的 “完全” 重复执行是值得警惕的效能洼地。当我们识别出这一块用例集，就需要思考自动化它们的成本是否值得，未来是否仍然会频繁地执行它（比如用例场景是否高度确定）。
测试独占周期：有些公司把这个指标定义为从开发提测到收到首次测试完成报告的时间。还有些公司把它定义为从开发提测到测试阶段彻底完成的时间。不管如何定义，这个时间都指示了测试阶段应如何缩短给开发的 “反馈” 周期，也驱动测试人员尽量的 “左移” 质量准备工作，并充分利用好自动化工具。从经验上判断，如果迭代中的测试独占时间超过了开发独占时间的一半，那我们就需要关注哪些环节存在效率改进或 “左移” 的空间，比如测试设计耗时过长，或者多种测试任务可以并行。
系统测试缺陷占比：系统测试是迭代用户故事均完成测试后，整个产品进行的全面测试，以通过上线前的所有质量保障环节。如果每个用户故事都提前进行了充分测试和修复，到系统测试阶段能发现的问题就会大幅下降。显然，这个比例越低，代表着产品发布的风险越低，测试左移越成功。当然，我们也可以只度量严重级别以上的缺陷。我看到不少公司都拿系统测试缺陷总数来考核测试人员绩效，发现缺陷越多代表绩效越高，这显然是违反敏捷价值观的。
平均缺陷发现耗时：缺陷被发现的时间减去缺陷被引入的时间，缺陷发现时间越短，说明测试敏捷度越高，左移效果越佳。从这个耗时分析 “为什么问题没有被尽早发现”，可以提炼出不少针对性的敏捷改善动作。同理，还有平均缺陷解决耗时（从缺陷报告到缺陷确认修复的时间），可以用来推动开发提高解决问题的速度。缺陷的整个生命周期在研发管理系统中都有状态变更的时间记录，只要及时更新状态，我们就可以审视这个最关键质量处理过程的效率。
版本遗留缺陷 DI 值：完成测试时，还有多少有效缺陷没有被修复，DI 值是否可控（即缺陷按优先级加权后的总数，比如阻塞缺陷算 10 分，严重缺陷 3 分，普通缺陷 1 分，轻微缺陷 0.1 分）。正常情况下，阻塞缺陷一定要修复，或者被缓解（即部分修复以致降低严重等级），才能进入待发布阶段。

四 迭代整体指标

敏捷研发以迭代为周期进行，我们可以根据业务形态和发布成本，决定是只完成用户故事，还是将其发布上线。因此，从迭代的角度来看效能指标，可以重点关注下面这些。

迭代实际交付需求总点数和偏差率：迭代完成的所有需求的点数大小，与迭代计划评审时估算的本迭代应完成故事点数进行对比，看看有多少需求没能完成。分析没有完成的原因，以及团队估算在哪里出现了误判。
迭代无关活动时长占比：回顾本迭代中，那些活动是和迭代计划需求无关的，一定比例内是正常的，总有一些外部事件要处理，但是活动占比高的话可以分析其 “干扰” 所在。敏捷研发的要求是每个人的工作应专注在特性团队内。
迭代等待时长：可以拆解为，需求待评审时长，需求（已完成评审）待开发时长，需求（已完成单元测试）待联调时长，需求（已完成联调和开发自测）待测试时长，需求（已完成测试）待发布时长。如果能够度量出各个阶段的 “等待” 时长，就可以知道哪里存在拖延的现象，进而能针对性的优化。
持续部署效率（耗时和成功率）。为了确保迭代成果能随时可测或可发布，就需要将其（联同配置脚本）自动化部署到测试环境，预发布环境或正式环境。关注部署自动化流水线的效率，解决部署过程中出现的阻塞错误，可以保障研发迭代的交付效率。

五 发布和运营阶段

在发布和运营阶段，出现任何问题，应对法则都是 “唯快不破”，尽量预防故障，尽早识别故障，尽快恢复服务，降低损失。以下指标是关键的指示器。

MTBF（Mean Time Between Failures ）：让连续稳定工作时间最大化。
MTTR（Mean Time To Recover）：让故障恢复时间最小化。
发布活动健康指标，包括：
发布频率是否健康，发布成功的频率应该符合应对市场竞争的预期。
发布异常次数和发布回滚次数，分析异常原因和改进措施，这个考核非常关键。
发布过程耗时，这一块可以尽可能缩短，降低发布成本。
灰度发布相关指标：是否满足灰度计划，及时发布到了正确的灰度用户范围，采集到了反馈数据。
故障响应时间：针对线上故障的应急响应能力，是否达到标准要求。
业务线上监控指标。针对业务的每个核心服务，都可以监控调用总量，调用成功率，QPS。针对调用异常情况，可以进一步的监控错误码 TopN，围绕主要错误发生的数量和频率发起告警和处理。围绕业务健康度的核心指标，可以放到线上监控的实时仪表盘上，如订单量和交易金额，以便团队可以共同关注业务的异常波动。关键数据（尤其是资金数据）正确性监控，其重要性不亚于核心服务健康度的监控。

六 最后，全面复盘

当需求真正发布上线后，我们如何通过复盘，度量需求是否达成设计预期？

我们可以定期组织对已上线需求进行复盘，在研发管理系统中及时填入相应度量数据，方便团队对需求 “是否实现了预期目标（价值）” 进行反思和改进，SM、PO 和技术 leader 都应参加。参考聊聊需求的价值如何度量。https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484491&idx=1&sn=76f02238329258c22755eedf310c0482&scene=21#wechat_redirect