穷尽测试是不可能的，这是软件测试的一条基本原则。通过测试并不能发现和修改测试对象中的全部的缺陷和问题，因此，不可避免有一些缺陷会遗漏到客户的使用现场，从而触发软件产品产生令用户不满意的失效或者各种问题。那么，测试人员在面对用户反馈的缺陷的时候，我们能够做些什么？本文将从几个方面来回答该问题。
1）DDP
首先，测试人员可以根据用户反馈的缺陷数目，来判断和分析测试人员在测试过程中的测试有效性。通常来说，在测试过程中判断测试人员的测试有效性是很困难的。但是通过用户反馈的缺陷数目，却可以直观的说明测试人员是否遗漏了比较多的问题，从而反映测试人员的测试有效性。
缺陷检测百分比DDP（Defect Detection Percentage）就是基于这样的目的进行定义的，它可以用来评判软件测试生命周期内某个阶段的测试有效性，它以百分比的形式进行计算[1]。其计算公式为：
DDP = [R1 / (R1 + R2)] * 100%
其中：
°R1指的是被评估阶段发现所发现的缺陷数目；
°R2是被评估阶段之后所发现的所有的缺陷数目；
注意：DDP计算公式的分母并不是发现的总的缺陷数目，而是指该阶段之后所有发现的缺陷数目（包括该阶段的缺陷数目）。另外，采用DDP作为测试有效性的评估指标，存在的一个问题是需要在产品发布一段时间之后才能进行，例如：产品发布之后3个月。
表1是计算DDP的一个例子（主要针对动态测试而言的）：
表1 DDP计算的例子
测试阶段 | 发现的缺陷数目 | DDP |
集成测试 | 376 | 51.58% |
251 | 71.10% | |
验收测试 | 65 | 63.73% |
产品发布（3个月之内） | 37 | NA |
2）过程改进
用户反馈的缺陷，是进行过程改进的重要输入。通过收集和分析从用户使用现场反馈的缺陷，可以回答“为什么这些缺陷会遗漏到用户现场”这样的问题。假如测试人员可以找到这个问题的答案，那么就可以将该分析结果应用到下个项目的测试过程中，以尽量减少此类问题再次遗漏到用户现场，从而达到过程改进的目的。
下面是笔者在对用户反馈的缺陷进行分析过程中，对遗漏到用户现场的原因进行的分类。对用户反馈的缺陷进行分类，可以更好的帮助测试人员查找遗漏该缺陷的原因，从而为过程改进提出更加明确和直接的建议和方案。缺陷遗漏到用户现场的主要原因可以是多样的，例如：
（1）需求的原因
通常来说，软件产品或者系统开发和测试的基础是需求，因此需求定义的质量直接决定了测试对象的质量。而测试人员经常面对的需求是不全的、模糊的，甚至是不正确的。
在分析某个产品用户反馈的缺陷过程中，发现用户针对系统R1.0版本配置的数据库，并不能直接在升级之后的R2.0版本中使用，用户认为这极大的浪费了客户的配置时间，也对该产品的易用性产生了某些怀疑。项目利益相关者对该类型的缺陷分析之后，发现测试人员并没有针对这样的场景进行测试，而更深层次的原因是系统的需求中并没有定义可移植性的非功能特性。
分析了该类用户反馈的缺陷之后，项目团队将可移植性非功能特性作为评审软件工作产品的检查表的一个检查点，以避免在将来的项目开发过程中遗漏该质量特性。
