关于版本质量的思考V2.0

在《关于版本质量的思考V1.0》文章中，我罗列了5个版本质量相关的量化指标：线上问题数量及问题级别、需求缺陷密度、缺陷关闭率、缺陷关闭时长、缺陷逃逸率。

本文来聊一下缺陷逃逸率，上线后发现缺陷数 / 有效缺陷总数，也就是漏测分析。

分析漏测，可以发现测试过程中的问题，优化测试策略，提高测试团队的能力，提高测试覆盖率，更加全面的验证需求。

什么样的问题算漏测？

只要测试能够发现的问题就算漏测。

举2个例子，第1个例子是回归测试，研发改动代码影响了老功能，不管测试是否知道，就算漏测，为什么没有做全量回归。第2个例子是测试物料，数据不好造，没有做验证，出了问题也是算漏测，为什么不协调上下游。

我们可能会觉得不公平，从测试人员的情感来说，是有一点难以接受。但是从老板的利益来看，是非常合理的。测试存在的价值，就是尽可能多的发现问题。测试能够发现的问题，不管什么原因，最终结果没有发现，以结果为导向，就需要让测试做出改进和提升。

缺陷逃逸率反映了测试团队的工作结果，如果缺陷逃逸率很低，线上问题却不断发生，很可能是计算出现了偏差，要让更多的问题算做测试漏测。

现在的测试，就是这样被卷起来的。我们接受漏测的同时，也要防止产品和研发甩锅给测试，测试不是保姆，有些问题跟测试没有关系。

出问题很正常，哪个系统没有问题呢，禁止低级漏测，防止严重问题，尽量发现更多问题，持续改进测试方法。

我最近发现缺陷的数据是21/71，71是总缺陷数，21是提测前发现缺陷数，其中设计评审4个，代码评审17个，分析每行代码改动，是我个人总结出来的有效测试方法。

更多通用的、体系的测试方法，待时间沉淀后，再进行分享。

欢迎大家讨论提高质量的测试方法。