Case Study 1: Learning from the field defects in a mature product
案例1：从一个成熟产品的区域缺陷中得到的启示。
第一个案例中的产品，拥有一个成熟的开发过程，而且被认为是一个高质量的产品，它为关键性任务应用程序提供了具有工业化实力的解决方案。但是，仍然有一些缺陷逃逸到外部（即区域缺陷），需要提供服务以修复缺陷。这些逃逸给客户的缺陷所产生的成本源自于缺陷本身的影响和产品的服务成本两个方面。在我们开发组织中，一个区域缺陷（逃逸到外部的缺陷）所产生的成本远远大于测试阶段发现此缺陷的成本，而与设计和编码阶段发现此缺陷的成本相比就更高了。即便不考虑实际的成本节约，也非常明显的是，最好不要在设计或编码的阶段引入缺陷，或者至少尽可能早的发现缺陷。
团队应首先以避免引入缺陷为目标，而许多已有的质量活动都能够减少引入到代码中的缺陷数量。开发过程中使用的度量方法包括缺陷数量和缺陷率（缺陷检测模型）。还有随着开发过程的改进，在每次发布结束时进行的“学习经验教训”的分析。
此产品的开发和测试过程包括以下几个主要阶段：
高层设计，设计文档和检查记录。
低层设计，设计文档和检查记录。
代码检查，或采用同伴检查方式。
功能验证测试（检查测试计划）
系统测试，充当产品的第一个用户（检查测试计划）
打包和发布测试（重复已有的测试用例）
解决方案测试（与其他产品的集成测试）
在前面的发布中，测试人员创建了大量的回归测试序列。这些序列被用于功能验证测试（FVT）和系统测试，以保证新版本的变化不会在现有的代码库中引发问题。此外，对每个逃逸的缺陷进行因果分析，是为了了解这些缺陷是如何逃逸的，以及如何防止未来有类似的缺陷再次逃逸。尽管进行了这些大量的最好的实践，但还是需要更加地关注于改进。在基于客户使用的测试上，ODC能够通过对最大几率区域的识别来提供这些改进。
部署 在做出对产品的最后版本实施ODC的决定之后，由分别来自于开发、功能确认测试、系统测试和解决方案测试的各个人员组成了一个七人团队，随后，他们学习了ODC的使用。这个团队每周都会聚在一起对客户发现的特殊缺陷进行分类。
在对区域缺陷进行分类时，首先基于实际的环境描述选择trigger（触发器），揭示缺陷以及最有可能引发此缺陷的动作，看其是否能在内部发现。 如果我们不知道用户是如何发现缺陷的，即用户的操作是不可知的，那么我们需要记录如何在内部重现此问题。如果在代码执行时出现了缺陷，则可以假定此缺陷是从测试阶段逃逸的。实际上，多数缺陷都是从测试阶段逃逸的。其中的一少部分同样也逃过了文档审核。
评估 在对12个月的ODC数据进行分类后，我们做了一次评估。由于这个产品的生命周期超过了12个月，因此我们需要谨慎对待主要的变更，尽管如此，这次评估还是突出了一些有趣的事实（细节）。
基础代码的重要性 复查的第一个ODC属性是age（码龄）。用户发现的缺陷表明其出自于基代码、重写的、重新修改的代码，还是新代码中？图1为age（码龄）vs.活动图。虽然开发团队的成员希望在新代码中发现大部分的缺陷，因为缺陷通常是由新代码或已更新的代码引入的，但令他们惊讶的是他们在基础和重写的代码中也发现了相当多的缺陷。有两个没有包含任何新功能的功能区域，由于存在着大量的重写（代码），因此其对应的缺陷被分类为“rewritten”（重写）。然而，基代码中的缺陷数量也看似很高的样子。下一步则确定这些基缺陷（基代码中的缺陷）是从哪个测试阶段逃逸的，以及包含了这些缺陷的功能模块是哪些。基缺陷对应的活动vs.模块组合图（图2）表明大部分逃逸到外部的缺陷来自于FVT（功能验证测试），并且有两个模块包含的缺陷数量超过了总数的百分之四十。
ODC评估确定了需要进一步调查的区域。然后，利用因果分析技术对这些具体模块中的基缺陷做进一步的分析。这个评估显示：
q模块需要更多的回归测试，特别是临近测试结束时。在下次发布期内执行此项测试。
b模块中添加了大量的新代码，因此这些缺陷是在新代码运行某些方面的基代码时发现的，在此之前那些基代码并没有被使用。此区域中的缺陷还需要进一步研究，但是有一个明显的改进之处，对受新代码所影响的基础功能模块，要进行更多的功能测试。
很明显，在全部的缺陷中，b模块的缺陷数量最多。在项目期间这个功能区域经历了显著的变化。团队知道由于计划时间的约束，一些变更没有进行完全的文档说明，同时，他们也接受了缺乏文档所带来的风险。但是， ODC评估表明了该决定所造成的影响。在未来的发布中，一定要实施文档的变更（管理）过程。
改进功能测试 理想的情况是，客户所发现的缺陷数量会随时间而减少。图3，显示了随着时间的推移，外部缺陷的trigger（触发器）分类的百分比视图，从中可以看到缺陷的数量实际上是在增加的。尽管我们可以预计到这些增加，是由于licenses（用户的使用许可）的增加而引起的。但是比之观察缺陷总数趋势更为重要的是对用户使用方面的评估。这个评估会指出用户是如何发现这些缺陷的。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
