今天收到一个测试任务，测试总监让我关注一下平时每次迭代中的缺陷逃逸率和溢出率，从网上找了一些文章，转载一下

笔者近年主要从事基于TMMi的软件测试过程改进咨询，接触到一些案例，且正好前段时间在“论道TMMi（39）如何评估测试的有效性”中也谈到了一个与缺陷逃逸率高度相关的指标——缺陷检测率（DDP），对此略微了解一些，故来谈谈缺陷逃逸率这个话题。

“缺陷逃逸率”，Defect Escape Percentage，简称DEP，是指软件产品发布后发现的缺陷数量与该软件产品在整个生命周期发现的所有缺陷数量的比率，通常用来衡量软件开发团队与测试团队对软件质量控制的水平。

缺陷逃逸率的计算公式一般是：

缺陷逃逸率（DEP）= [R2 / (R1 + R2)] * 100%

其中：

R1指的是产品发布前发现的缺陷数；

R2是产品发布之后所发现的缺陷数。

大家还记得笔者在“论道TMMi（39）如何评估测试的有效性”中谈到的缺陷检测率（DDP）的计算公式吧：

缺陷检测率（DDP） = [R1 / (R1 + R2)] * 100%。

没错，缺陷逃逸率和缺陷检测率高度相关，理论上，它们二者之和应该是1，即：

缺陷逃逸率（DEP）=1-缺陷检测率（DDP）

因为软件测试不可能做到穷尽测试，且软件测试可以发现系统存在的问题，但是不可能证明系统中不存在问题，因此，即便是产品发布之后，我们也不可能在有限的时间内把产品中所有的逃逸缺陷都发现出来，因此，缺陷逃逸率（或缺陷检测率）的值可能会随着统计时间周期的增加而动态的发生变化。

在实际应用中，通常选定一定的时间周期对缺陷逃逸率（DEP）进行统计。这儿的时间周期通常是考核周期，例如1个月、3个月、半年或一年等。

在该统计周期中：

缺陷逃逸率（DEP）=考核周期发现的生产缺陷数/(产品发布前发现的缺陷数+考核周期发现的生产缺陷数）×100%

根据行业中一些同行们披露的数据：

逃逸缺陷率如果在7%至10%，软件研发团队对软件质量控制的水平算作一般；

如果小于7%，软件质量控制水平算优秀；

如果大于10%，质量控制水平就比较差了。

当然，这个数值仅供参考，具体应用时，需根据自己组织的实际情况（例如不同类型的项目、不同质量等级要求的系统等）来进行统计、评估和分析。

例如，

笔者接触到的一家大型金融机构，他们今年（2021年）的平均逃逸率到目前为止，都控制在0.6%以内。而一家新能源汽车公司，他们的缺陷逃逸率则在3%左右。

从笔者对他们的了解，其实这二家企业的这个数据也并不具有可比性。

在上述的大型金融机构组织中，他们去年（2020年）通过了TMMi3级认证，期间曾经对度量进行了改进和提升。今年（2021年）又专门发布了度量指标库，对缺陷逃逸率（DEP）的计算标准做了严格定义和说明，比如投产前的缺陷计算哪些类型，投产后的缺陷以什么来源为准认定，哪些算缺陷类等等。在规范的制度和体系下，严格收集数据和度量，获得了0.6%的缺陷逃逸率（DEP）的度量值，在整个组织中都得到了认可。

而在汽车制造行业，实际情况会比较的复杂。例如，整个流程中测试参与者很多，有的团队流程不规范，测试过程中没有留下缺陷的记录，缺陷数据无法统计（数据有缺漏）；有的产品问题会集中爆发在上市的前6个月，但有的产品问题则要等车卖出去好几年才会报出，因为这部分的问题是在零部件老化后才会出现。

上述某新能源汽车公司的缺陷逃逸率（DEP）统计中，事先没有在整个组织内对缺陷逃逸率（DEP）进行完整（或清晰）的定义，3%的缺陷逃逸率数值也只是针对于一辆整车的情况，且是把所有市场表现不好的后续变更都算成了软件缺陷，而部分零部件测试发现的问题却没有被统计进去。如果是单独一个控制器，他们的缺陷逃逸率（DEP）则大约是在1%到2%。

故以上数据，在二家企业之间，并不具有可比性。

再如，据海通证券参与的中国信息通信研究院组织的DevOps能力成熟度模型评估相关报告显示，海通证券的e 海通财资讯中心-数据应用服务系统近3个月生产缺陷逃逸率则均保持为0。该系统是海通证券依托30余年行业经验自主研发的一站式综合理财投资服务软件，在质量保障上属于重点“投资”的项目。

质量是有成本的！

缺陷逃逸率的实践应用，也应“量力而为”，过度追求“零缺陷”逃逸是不经济的，也是不现实的。

在有限的资源条件下，应尽可能降低缺陷逃逸率，才是我们做过程改进应该追求的目标。

根据诸多案例的分析，造成缺陷逃逸的主要原因可能包括：

1）需求不够明确，开发、测试人员对需求理解不到位，测试设计不够全面;

2）需求变更频繁，开发、测试人员获取到的需求不够及时、准确，测试用例不足以覆盖变更后的需求；

3）测试计划安排不够合理，测试时间过于紧张，测试人员没有充足的时间设计用例和执行测试；

4）测试设计人员对需求不够熟悉或设计能力有限，测试用例设计不全面，覆盖度不够高导致缺陷遗漏；

5）测试执行过程存在疏漏，例如测试执行人员与测试设计人员不同，测试执行人员不能全面理解测试用例的测试要点，导致一些显而易见的软件缺陷或本来应该发现的软件缺陷没有被测试出来；

6）测试环境或版本与生产环境有差异，某些缺陷难以在测试环境被发现；

7）某些特殊数据才会出现的缺陷，因测试数据不足而难以发现。

如何降低缺陷逃逸率？建议可以考虑尝试以下一些改进措施。

1） 测试尽早介入

测试人员在需求阶段就参与进来，加强需求的分析、确认和评审等工作，使测试人员可以充分理解需求以便设计准确而全面的测试用例。

2） 合理安排测试计划

或做好测试与开发的协调，为测试保留相对合理的设计和执行时间，避免开发时间延后从而挤占测试时间。

3） 专业的人做专业的事

安排熟悉系统需求并掌握测试用例设计方法的人员设计测试用例，或提升测试人员的设计能力，并加强对测试用例的评审。

4）加强特殊场景（特殊数据）测试

多使用存量和特殊数据进行测试，并适当进行破坏性测试，挖掘可能隐藏的问题。

5） 加强测试环境和测试版本管理

测试环境应尽量与生产环境保持一致，至少是逻辑上的一致。

当然，导致测试逃逸的原因可能是多方面的，不同的项目可能有各自不同的原因。

测试管理人员要善于定期对缺陷逃逸情况进行总结，分析可能的原因，采取相应的措施，以更好的改进测试过程，降低测试缺陷逃逸率。