聊聊缺陷收敛率

一位关注我公众号很久的同学后台留言，问了我一些关于质量度量的问题，和他沟通过程中交换了彼此的一些观点，也让我对质量度量有了一些新的理解。这篇文章聊聊在质量度量中，几个很有意思的指标，以及常见的误区。

什么是缺陷收敛率

说到缺陷收敛率，就不得不先聊聊缺陷逃逸率。

我在前面的文章《聊聊缺陷逃逸率》中对缺陷逃逸率是如此描述的：缺陷逃逸率指的是软件产品线上发布后，发生在线上环境的缺陷数量与该版本迭代生命周期内总缺陷数量的比率，缺陷逃逸率也称之为线上BUG逃逸率或者“测试逃逸”。

关于线上缺陷逃逸率，有这样一个计算公式：线上缺陷逃逸率=线上缺陷数/版本周期总缺陷数×100%。这个指标一般除了衡量线上的产品交付质量以外，还可以用来评估测试团队的质量控制水平。

既然是质量控制，那对应的就是要控制线上缺陷的数量，或者尽可能降低线上缺陷对业务和系统稳定性的影响。在这样的背景下，就有了缺陷收敛率这样一个质量度量指标。

缺陷收敛率的作用

所谓缺陷收敛率，反映的是缺陷在软件产品研发过程中的变化趋势和修复的时效性问题。一般来说，软件系统会在测试阶段的前中期(单元测试&集成测试)暴露出大量缺陷，到系统测试和回归测试阶段，缺陷数量会有明显的下降和收敛趋势。

为什么会出现这样一个指标呢？正常来说每轮测试发现的bug，应该在下一轮测试开始之前都尽量修复，且bug的reopen数量应该有大幅度的降低，这样才能从某种角度证明，测试活动是有效的。

单纯以bug数量衡量软件产品质量，是不够全面的，但是bug数量的多寡确实在很大程度上体现了产品的功能正确性。如果在多轮的测试和bug修复后，依然存在很多bug，那只能说质量控制的结果是失败的。与之对应的，无论是测试活动，还是研发规范，或者说编码质量，肯定存在很大的风险。

而缺陷收敛率的作用，则是用来度量这一过程的工作结果，是否符合预期。同时这一指标还可以提醒研发测试同学，避免潜在的风险向下游传递，放大影响范围和修复成本。再进一步来说，通过缺陷收敛率这一指标，来控制和降低产品验收以及线上发布的风险。

如何度量缺陷收敛率

既然缺陷逃逸率可以度量，那么缺陷收敛率同样可以度量。下图是一张缺陷收敛折线图：

（网图侵删，仅供示意参考）

一般来说，从提测到线上发布，再到下一版本线上发布之前，这一阶段可以视为一个完整的缺陷统计度量区间。如果只是简单的进行统计，那么仅需要统计如上图所示的三个指标即可。

如果需要更详细的指标，则可以对这一完整的统计度量区间进行划分。例如：单元测试阶段，集成测试阶段，系统测试阶段，验收灰度阶段，线上运营阶段。

单纯的统计数据和度量其实比较简单，一般来说如果在某个统计阶段内，累计发现缺陷和累积解决缺陷的曲线接近一致，则说明缺陷收敛率数据较为良好。反之，则说明该阶段的质量存在一定的风险。

理论上，累积发现缺陷和累积解决缺陷的曲线应该在完整的统计区间末期接近重合。但在实际工作场景中，这种情况很少见，毕竟影响质量的因素太多了，且总会存在不可控的因素，或者黑天鹅因素。

如何根据缺陷收敛率度量评估质量呢？我的思路是选择某个版本作为对比基线，然后统计后续版本不同阶段和统计区间的数据，进行同比和环比的对比。

当然，所有的质量度量和改进措施，在实际应用实践中应该“量力而为”，因为质量本身就是有成本的。应该在有限的资源条件下提高质量，这也是质量保障和改进应该追求的目标。

之前看过一些分析文章和部分测试团队的质量度量实践案例，他们为了线上质量和系统稳定性，专门针对线上环境制定了度量指标，典型的如线上问题留存率(线上发现的缺陷留存时长，用来评估修复时效和对线上质量的重视程度)。

对此我只能感叹，指标和数据真的被玩出花儿了。

最后，聊聊缺陷逃逸和缺陷收敛的关系。

缺陷逃逸率是阶段性的质量结果，缺陷收敛是对质量进行控制和改进的目标，缺陷收敛率是评估质量控制和改进结果的度量指标。听起来很拗口，简单来说就是因为有逃逸，所以要进行收敛，并对收敛的结果进行评估。

其实无论是质量度量还是什么，都只是解决问题达成目标的手段和工具。有度量指标，从度量结果开始分析如何改进，然后对改进过程和结果继续进行度量分析改进，套娃般的循环往复。

度量指标真要玩起来，能定特别多的指标，但最为重要的是结合团队痛点，真实的去优化改进，不断提升产品交付质量。否则质量度量，最后只会成为KPI和向上管理的画饼工具。