正交缺陷分类法（ODC）是一种用于分析软件缺陷的归类方法。它可以结合软件开发过程的一系列数据分析技术，为测试组织提供了一个强大的针对开发过程和软件产品的评估方法。在本篇文章中，会列举三个案例研究来说明如何使用ODC改善我们的软件测试。 第一个案例描述一个团队如何开发一个高质量的、成熟的产品，并以此来达到他们在测试策略所制定的减少区域缺陷的目标。第二个案例是一个中间件软件项目，他 们通过ODC确定需要加强的系统测试的范围。第三个案例则描述了一个小型团队，在测试策略不够充分的情况下，他们是如何认识到如果按计划的时间发布会产生 的风险，以及通过压后发布时间来获得更为稳定的产品，还有他们添加的那些必需的但很是糟糕的测试场景。所有三个案例都强调了技术团队如何在他们的开发过程 和产品评估中使用ODC，并得到客观的反馈信息。而这些反馈信息会推动组织对（开发和测试等）活动进行确认，以此提高开发和测试的效率和有效性，并最终改 善组织的资源管理水平和软件 量。
软件系统的复杂度和规模都在不断地增加着。而商业需求却在要求更短的开发周期，这就迫使软件开发组织去努力地寻找一个在功能、市场时间和质量之间的折衷方
法。由于缺乏相关的技能，以及面对时间计划带来的压力和有限的资源，加之软件开发的高度手工化，最终导致无论是大型还是小型的团队组织，都会产生同样的问
题。
这些问题包括不完整的设计，无效的测试，低劣的质量，高额的开发和维护费用以及可怜的用户满意度等。而作为一种防止缺陷逃逸的方法，很多公司都在软件测试
上投入了更多的资源。此外，为了改善测试的其他方面（例如测试人员的技能水平，自动化测试，
新工具的开发和测试过程等），需要有一种方法来评估当前测试过程，以了解它的优势和缺点，并强调和揭示现存的风险。尽管大家都很清楚，在过程的早期发现缺
陷，花费也会少的多，而一旦缺陷在外部发生，则势必需要用更多更昂贵的花费来修复它们。然而，测试人员通常并没有意识到他们所面对的是什么样的特殊风险，
以及如何加强测试来达到他们的质量目标。
在本文中，我们会讨论使用正交缺陷分类法（ODC），即一种缺陷分析技术，来评估测试过程。同时为大家列举三个案例研究。前两个案例所讨论的软件产品是在2000年初开始使用ODC的，那时本文的三位作者正一起在IBM Hursley网站上从事ODC部署工作。而在第三个案例中出现的项目经理T. Kratschmer，也是本文的作者之一。
第一个案例中的产品开发人员开始使用ODC来评估区域缺陷。尽管产品质量很高，很成熟，没有产生很多的缺陷，但缺陷还是在外部发生了，而且不得不用非常昂
贵的花费来修复这些缺陷。这个使用了ODC的团队，他们的目标是如何改善测试过程，在内部发现更多的这类（field）缺陷，以此来减少逃逸到外部的缺
陷，并降低售后质保的成本（如果用户在购买产品后一段时间内发现产品缺陷，生产商必须免费修理或更换产品）。第二个案例描述了一个大型的中间件软件项目，
这个项目具有定义良好的开发过程。尽管有成熟的过程，这个团队还是遇到了几个问题，于是决定看看ODC能否给他们一些团队改进上的启发。这个团队对ODC
关于过程所给出的任何重点启示和在产品发布前需要注意的地方都有着浓厚的兴趣。第三个案例展示了一个非常小的项目。而ODC被用来评估产品的稳定性，并指
出在产品发布前，为达到一个可接受的测试标准需要加强的地方。由于对测试的关注不够充分和适当，拥有一个客观的衡量方法就显得非常重要了，这个方法同时也
方便了他们的管理层与开发团队就未来的决定达成一致。
Overview of Orthogonal Defect Classification
正交缺陷分类法（ODC）介绍
有关ODC的介绍性文章一般都会描述ODC的概念，及ODC计划的定义，同时也会讨论ODC各个属性间的关系，并附上一些试验研究的结果。因此，我们在这
篇文章中只对ODC的细节做一些简短的描述。ODC方法提供了一个软件缺陷的分类方案和一系列概念，这些概念为分析这些分类聚合的缺陷数据提供了指导。
“正交”指由缺陷属性和属性值捕捉到的信息具有非冗余的本质，而缺陷属性和属性的值其本身就是用来对缺陷进行分类的。与几何学中的笛卡尔坐标非常的类似，
近十年的研究表明，对于大多数软件开发的问题，这些属性（和它们的值）充分地“填补”了缺陷信息空间中那些有趣的部分。与管理层使用的缺陷分析工具不
同，ODC以技术团队为目标—如开发人员，测试人员及服务人员等。因此，进行缺陷分类的技术团队，应在数据评估中发挥积极的作用，从而决定要实施的活动。
本文最后的附件A和B列出了ODC的属性。附件C则列出了一个ODC缺陷评估中所包含的典型项。
ODC部署过程 在过去的10年间，ODC的部署过程一直在发展。下列的基本步骤是成功部署ODC的关键：
管理层必须承诺进行ODC的部署，并根据ODC评估所产生的结果来实施活动。
缺陷数据必须由技术团队分类，且应保存在一个易于存取的数据库中。
要定期（或经常）地对已分类的缺陷进行确认，以保证分类的一致性和正确性。
一旦开始确认，则必须定期地（或经常）对数据进行评估。通常，由一名熟悉此项目且有数据分析能力和兴趣的技术人员来执行评估。
向技术团队定期地反馈已确认和评估的结果是非常重要的。这样不仅可以改进分类的质量，也为团队提供了必要的信息，据此他们能够决定（或确定）那些需要改进
的活动。对于从技术团队获得必要的承诺而言，反馈也是很重要的。一旦他们看到这些客观的、量化的数据，以及合理的和切实可行的活动，通常团队对ODC过程
的承诺和责任感也会随之增加。
一旦团队获得这些反馈，他们就能确定并优先考虑那些要实施的活动。
当这个ODC过程与组织的过程整合到一起时，就能实现全组织范围内的互利。对开发过程和其生成的产品进行持续地监控和改进，以使我们能够从开发的最初阶段起建立产品的质量。
缺陷分类和确认 缺陷的分类具有两个不同的时间点（提交和应答）。首次发现或提交一个缺陷时，根据ODC的提交者（submittor）属性，activity（活动）、trigger（触发器）以及impact（影响）来分类。
Activity指实际的过程步骤（如代码检查，功能测试等），它们表示发现缺陷时正在执行的活动。
Trigger描述缺陷产生时的环境和条件。
Impact指对用户造成的感觉或实际的影响。
修改或应答一个缺陷时，根据OCD的响应者（responder）属性，target（目标）、defect type（缺陷类型）、qualifier（限定）、source（来源）和age（码龄）来分类。
Target表示被修改的对象所属的高层方位（如设计、代码、文档等），即在哪个高层目标中修改缺陷。
Defect type指缺陷的所固有的性质，即缺陷类型，如算法、初始化等。
Qualifier（适用于Defect type，对缺陷类型的限定说明）说明所作的修改是丢失的、不正确的、还是无关的代码或信息所引起的。
Source指缺陷的来源，是源自内部代码、对某个库的重用、平台之间的移植，还是源自第三方的外包代码。
Age指缺陷对应的码龄（代码的龄期），说明缺陷是出现在新代码中、老代码（基础代码，还是重写的或重新修改的代码中。
有关属性的定义和更多的详细内容可在下列网址中找到：
http://www.research.ibm.com/softeng/.
通常，捕捉ODC属性的工具与用来收集其他缺陷信息的工具是相同的。这里，有两种确认数据的方法。其中之一是由具备适当技能的人对已逐个分类的缺陷进行复
查（是否有分类错误）。这种方法也许需要等到团队成员对分类类别和用途非常适应的时候才能适用。其二是使用总体的数据分析来帮助确认。尽管这个确认方法更
为快速，但是它要求的技能超出了分类法所要求的技能范围。为了执行使用了此方法的数据确认，确认者需要复查缺陷属性的分布状态。如果数据或过程内部包含了
不一致的信息，则表明数据质量具有潜在问题，我们需要保持疑问的心态，并通过对一个缺陷子集进行更为详细的复查，从而找到这些问题的所在。虽然在某些情况
下，个人对分类法的步骤存在着误解，但一般只限于一个或两个特定的方面，而它们也是容易被澄清的。一旦团队明白了基础概念和它们的用法，数据本身的质量就不再是个问题了。
数据评估
对数据进行确认后，开始准备评估这些数据。在进行评估时，关注点不能只放在单个的缺陷上，还要进行因果分析。准确地说就是对总体数据的趋势和模式进行研
究。对ODC分类的数据进行数据评估基于ODC各个属性之间，以及与非ODC属性之间的相互关系，其中非ODC属性包括component（模
块），severity（严重性）和缺陷open日期。例如，要评估产品的稳定性，我们要考虑—defect
type（缺陷类型）、qualifier（限定）、open日期和defect
severity（缺陷严重性）等属性之间的关系。缺陷类型为“功能缺失”或严重等级高的缺陷，如果有一个增长的趋势，则表示产品的稳定性正在下降。
接下来的三个案例研究，都使用了ODC来度量测试的有效性。同时，每个案例的那些需要注意的测试过程，OCD都给与了重点说明。而评估则为ODC过程的最 后一个步骤—选择适当的改进活动，提供了必要的信息。案例研究包括了产品的背景信息，以及他们如何实现ODC过程和评估的具体细节，最后包括与之对应的改 进活动。
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（用户的使用许可）的增加而引起的。但是比之观察缺陷总数趋势更为重要的
是对用户使用方面的评估。这个评估会指出用户是如何发现这些缺陷的。
图3表明在最初的几个月中，主要的缺陷出现于执行某个单独的功能时，正如图中的trigger（触发器）--coverage（覆盖）和 variation（变量）所指出的那样。随后，在9月里，通过更为复杂的测试场景所发现的缺陷在增多，图中的trigger（触发器）-- interaction（交互）、sequencing（连续）和software configuration（软件配置）可以说明这一点。 但是在大多数月份里variation是占主导地位的trigger（触发器）。Variation表示通过改变单个功能的输入参数所发现的缺陷。图 2--活动和模块图，表明很多缺陷是从FVT（功能验证测试）中逃逸的，正如图中的trigger-- coverage（覆盖）、variation（变量）、interaction（交互）和sequencing（连续）所表现出来的那样。这些观测结果 表明，我们必须对FVT（功能验证测试）过程进行改进，以确保逃逸的缺陷少之又少。具体点说，测试计划中必须包括更多的变量（variation）测试。 通过对测试人员的培训，以及检查测试计划时对这一点的强调，我们可以实现上述的改进。
小结 ODC帮助我们在过程中找出下列不足和改进措施
多数缺陷是从FVT（功能验证测试）逃逸的。Variation（变量）是最普遍的trigger（触发器）。因此，团队需要对测试人员进行有关
FVT（功能验证测试）中各种测试类型的培训，确保FVT（功能验证测试）的测试计划中有足够的变量（variation）测试用例。
q模块中有太多的基缺陷。团队必须针对此模块区域增加回归测试的次数。
大多数缺陷都在b模块中。团队要保证所有的变更都具备清晰的文档说明，同时保证一旦有代码发生变化，受其影响的基代码应被作为测试中的重点对象来对待。
未来的计划
团队会继续对外部（发现的）缺陷进行分类，并利用此信息改进他们的开发和测试过程。ODC外部缺陷为定义用户惯用法的简档提供了基础，而简档可以帮助测试
团队来复查缺陷。在新版本的开发周期中，这个团队也开始对“过程中”发现的缺陷进行分类，并与外部缺陷的分类进行了对比。这样的对比会为当前的测试过程提
供更加准确的信息，并为将来的测试工作提供关注点。
Case Study 2: A large middleware project
案例2：一个大型的中间件软件项目
这个案例中包含了一些隶属于IBM系列的中间件产品，这些产品可用于大部分的操作系统平台。它们都是由几百人的团队开发的成果，开发过程遵循典型的瀑布过程，通过各个阶段的判定检查点评估产品是否可以进入到下一个阶段。
产品团队中最先开始使用ODC的是测试组。而测试组正处于重组的过程中，以期通过此来解决一些问题。他们需要一套度量规则，使他们可以客观的评估他们的进度，并面对一些他们自己的问题，这些问题是：
单元测试阶段，功能验证（FV）阶段和系统测试阶段，三个阶段互相叠加进行。理论上讲，这些阶段都是假定为有序的阶段，但是它们会经常叠加，有时是完全地
叠加进行。系统测试的入口检查点的目的是判断前一个测试阶段的进度，测试是否充分，是否可以进入到系统测试的阶段中。而他们需要的度量规则能够为这一判断
提供可度量的、客观的数据，而不是个人的（主观）意见。
测试组开发了大量的测试序列，但是他们并不知道这些序列的有效性如何。他们只有两个度量方法：（1）缺陷--上升和关闭率 （2）测试用例--执行率和测试用例结果，如成功或失败。
这些度量方法度量了测试进度，却不能说明测试的有效性如何。而ODC可以提供客观的、可量化的数据，对组织寻找的判断依据而言是非常必要的。
ODC过程
分别由两个项目组对ODC过程展开实验，并以一系列的培训讲座为开始。团队成员参加的培训内容包括1小时的概貌介绍，以及2小时的关于如何分类缺陷的详细
培训。其中的一部分测试人员和开发人员还要参加一个2小时的关于如何确认数据的课程。一个月后，很多人都接受了2小时的评估培训，学习如何复查数据，以及
如何开始使用这些数据。
数据由确认小组每周进行一次确认，以保证分类的正确性，并纠正每个错误。随后，由评估小组对数据进行复审，并评估项目的状态，决定是否需要采取某些特定的行动。对于个别项目，可以选择合适的时机进行评估。
评估 在评估期间，他们决定是否可以开始系统测试，以及需要对系统测试和功能测试做哪些改进。
提早进入系统测试的一个案例.
在这个产品的FV（功能验证）阶段进行到大约四分之三时，项目组开始使用ODC。七周内，项目到达了系统测试入口的判断检查点处。虽然ODC数据在那个时
候还没有被正式地纳入到决策的过程范围内，但项目组还是饶有兴趣地复查了这些数据。为项目组启动系统测试提供的支持，证明这些数据是非常有用的。
进入系统测试的（判断）标准之一是“FV（功能验证）的覆盖度超过百分之八十，而且完成了不少于百分之五十的功能验证”。在这个案例中，FV并没有达到百
分之八十的覆盖度目标，但是有超过百分之七十的功能验证都完成了–非常高的通过率。此外，FV团队相信代码已经非常稳定了。图4则展现了
activities（活动）和triggers（触发器），说明：
功能测试的范围已经很大了，达到了ODC
triggers（触发器）的范围。Coverage（覆盖）、variation（变量）、sequence（顺序）和interaction（交互）
测试包含了所有已暴露的缺陷。实际上，在使用更复杂的系统测试的triggers（触发器）时，如recovery/exception（恢复/异常）和
startup/restart（开始/重起），项目组已经让缺陷完全地暴露了。
功能测试进入到更为复杂的triggers（触发器），意味着产品的基本功能已经稳固，准备进入系统测试阶段。这个暗示为FV团队的“直觉”提供了支持。
尽管没有达到FV的正式标准，但ODC提供的信息让团队相信项目已可以开始系统测试了。随后，系统测试团队取得了快速地进展。
分析外部缺陷，改进系统测试.?
图4也说明系统测试的大部分关注点都在workload/stress（工作量/压力）上。有超过百分之五十的缺陷是通过workload
/stress（工作量/压力）测试发现的。图5展现了对前一版本的外部缺陷进行后续分析所产生的结果。图中的activities和triggers清
晰的显示了用户暴露的缺陷较之内部测试所发现的，其对应的系统triggers（触发器）的范围更为广泛，特别是在software
configuration（软件配置）上表现的尤为明显。因此，系统测试团队会复查他们的测试，以扩充他们的测试场景，特别是software
configuration（软件配置）的区域。 
通过对外部和内部缺陷的分析，改进功能测试.? 随着FVT（功能验证测试）的完成，测试团队复查了ODC数据以寻找潜在的改进区域。图6、7和8突出了在未检查的情况下可能出现的潜在问题。 
图6展现了产品前一个版本的外部缺陷对应的defect
type（缺陷类型）和qualifier（限定）。虽然checking类的缺陷并不是最大的一组，但其中有相当大的一部分是由missing（缺失）
的代码引起的。图7展现了一个相同的表，但显示的是当前版本在内部发现的缺陷。这次，checking（检查）类的缺陷是最大的一组，而且其中的大部分同
样是由于代码missing（缺失）引起的。图8则展现了qualifier（限定）均为missing的内部缺陷，以及它们的defect
type（缺陷类型）和triggers（触发器），同时表明大部分因missing（缺失）检查造成的缺陷是由variation（变量）和
sequencing（顺序）测试发现的。这说明低层设计的稳定性存在问题。
根据这次评估的结果，FV（功能验证）团队的成员们决定以提高发现“缺失检查”的能力为目标，重新复查他们的测试序列，特别是：
使用代码覆盖工具度量由功能测试序列获得的语句和分支覆盖率。测试人员在开发人员的帮助下利用输出的结果，来确定测试序列中的缺口和重复。
ODC的triggers（触发器）是良好覆盖率的保证，因此，可以根据它们对功能测试用例进行分类和分析。为了向2000年的悉尼奥运会提供最好的产
品，IBM团队使用了这种技术作为一种确定方式，事先确定测试序列能否使用大范围的triggers（触发器）。获得此产品FV（功能验证）的测试序列的
有效性评估是至关重要的，特别是随着时间的发展，测试用例的数量会明显地增加。
由评估引出的改进.?
几项致力于改进过程的措施都来自于ODC评估结果。在一个典型的发布周期内，仅仅在最后的几周或几个月里，才尝试对缺陷的修复进行优先级划分，往往会导致
测试工作长期停滞不前，并超出实际需要的时间。图表9里面的数据指出，很多缺陷的严重等级都是3级，而通常会认为它们已足够严重，需要修复，但实际上它们
还没有严重到让用户的系统崩溃的地步。尽管这些缺陷占了已提交缺陷总数的百分之八十，但是不可能把它们放在优先的位置。因此，我们在在缺陷描述中添加了一
个新的属性“importance”（重要性）。基于对有多少工作会受此缺陷影响的考虑，提交人可以指定缺陷的重要性，以使这个缺陷能够得到快速的修复。
“重要性”有：
- 高重要性：阻碍了大量的测试工作，需要立即修复的—紧急。
- ?中等重要：阻碍了一部分测试工作，但同时还可以进行其他的工作，需要尽可能快的修复。
- 低重要性：最多阻碍了一到两个测试工作，可以继续进行工作，有时间的时候修改。
这个属性字段能让团队把重点放在对整个进程影响最大的缺陷上。 
另一处由ODC评估结果引出的改进是让缺陷包含更多的信息，以便于对ODC分类的缺陷进行确认。这处改进对分类缺陷的团队也同样有用。提供更清晰的解释和说明，能够有效地对缺陷进行处理。
小结 这个项目使用ODC的时间刚好超过了一年。事实证明它是有价值的，当未达到传统的标准时，它能够帮助我们评估通过一个判断检查点时所产生的风险。
这个团队能够客观地查看他们的数据，而且很快就能确定出针对他们的过程和最终产品的改进措施。这些改进是合理的，不需要投入大量的时间、金钱或人力。通过
对ODC的使用，测试团队达到了他们提高测试效率的目标。这项技术的价值在这个团队得到了证明，因此， ODC的使用范围也扩大到了其他的项目上。
Case Study 3: A small team project
案例3：一个小型团队项目
这个案例属于一个小型项目，由几个开发人员开发一个基于Java**的软件工具，其用途是让用户把与软件开发相关的数据进行可视化。这个工具支持ODC分
析。这个产品的基本用户是整个IBM软件开发试验室中的测试人员、开发人员和服务人员。这个开发团队面临的挑战是：
缺少开发资源且经验有限 -- 这个团队缺乏面向对象编程和Java语言的开发经验，也没有工具开发方面的经验。此外，他们只有一点测试经验。团队成员们依靠一个功能检查表和他们自己的感觉来制定测试的内容。
时间进度上的压力 -- 他们经常要修复bug和增加功能，导致进度表越来越紧张。
客户需求 -- 用户要求这个工具必须能够大规模且成功地部署ODC。因此，为了最大限度地成功实现这项功能，它必须是一个高质量且稳定的产品。
ODC是有效管理资源、度量产品稳定性，以及指导团队进行高效测试的关键。
ODC过程
自产品的第一个版本发布以来，ODC已经得到了实践，但本文的关注点是产品在1.3版本中所做出的改进。到此版本可用时，团队已经有了ODC分类的经验。
由于项目经理曾在过去的五年里做过ODC的顾问，在执行确认和评估方面有着丰富的经验，因此在执行评估的时候没有遇到“学习曲线”的问题。
评估
最初，他们计划在2000年的八月至九月间发布1.3版本。此版本的发布主要是解决一个软件bug，并没有增加新的功能。在计划发布的一个月前，团队成员
们表达了他们的信心，产品已经为发布做好了准备。他们相信这次只是因为要修改bug，基本的功能都不会发生变化。他们已经花了几个星期的时间测试了新的代
码，所以他们觉得时间进度不会在发生意外的变故了，产品能够按照原定的计划发布。然而，在他们进行了ODC评估后，却证明产品并没有做好发布的准备。
图10展现了相关的activity（活动）和triggers（触发器）。需要注意的第一点是只有15个缺陷。即使对于这个小型项目而言，功能和系统测
试仍然会发现更多的缺陷。第二点，在功能测试中发现的缺陷数量和在用户界面检查中发现的缺陷数量一样多。但在产品的历史记录中，功能测试中发现的缺陷数量
明显比GUI检查中的多很多。第三点，由coverage（覆盖）和variation（变量）可以证明，在功能测试中暴露的缺陷只是通过执行单个的功能
发现的。通过点击按钮或执行简单的命令就可以很容易的发现这些缺陷。然而，在通常情况下，当每个活动上的缺陷都是通过大范围的triggers（触发器）
发现的时，产品才是经过良好测试的产品。虽然在界面检查时发现的缺陷是通过各种不同的triggers（触发器）发现的，但功能和系统测试则没有。
Coverage（覆盖）和variation（变量）只代表了此活动上的4个可用triggers（触发器）中的2个而已。在产品发布之前，还需要通过
更复杂的triggers（触发器）进行测试。特别是，通过功能测试中的sequencing测试和系统测试中的workload/stress、
software configuration测试发现更多的缺陷。 
图11展现的是ODC属性为age（码龄）的缺陷数量，进一步支持了产品还没有准备好发布的结论。其中有9个缺陷（占总数的60%）是在基础代码中发现的
–
缺陷在之前的版本中就已经存在了。这些是被隐藏的缺陷。本应该在之前的版本中发现却没有发现。因此，不仅通过执行单个的功能发现了缺陷，而且还有很大一部
分的缺陷是在老代码（基代码）中发现的，并非在新代码中。此信息更进一步地支持了团队关于对代码没有进行充分测试的怀疑。所以依照情况，团队采取了唯一可
能接受的措施。增加测试工作，推迟发布日期。 
为了提高测试效率，在variation、sequencing、interaction、software
configuration和workload/stress区域里，添加了几个测试用例。图12展现了新增测试用例的测试结果，以及对应的ODC活动。
到12月时，除了之前的15个缺陷，他们又发现了138个缺陷。新增的测试工作得到了回报。接下来，对triggers（触发器）图表进行复查。在此之 前，单个的功能triggers（触发器）构成了整个测试的全部（百分之百）。虽然计划的时间被延长了，但由多功能triggers（触发器）-- sequencing和interaction暴露的缺陷增长到了总数的37%。此外，我们通过系统测试的triggers（触发器）— recovery/exception（恢复/异常），发现了7个缺陷。测试场景由简单场景发展为更复杂的场景，从而发现了更多的缺陷。
在workload/stress和software configuration上还需要说明两点。由于测试执行方面的限制，没有发现新的缺陷。同时，由于缺少资源，这个结果被认为是可以接受的。
小结
在已延长的测试周期临近结束时，产品比8月份表现出了更强的稳定性。大部分的缺陷都已被发现，当然可以预计得到还会有很少量的缺陷逃逸到外部。事实上，它
们还是被这个团队发现了。1月份报告了4个缺陷，其中的一个是build（构建）问题。然而，如果在8月份他们并没有做ODC评估，产品照原计划发布，那
么九月和十月的测试所发现的缺陷很显然会对用户产生影响。用户满意度势必会降低，对团队开发高质量产品的能力失去信心。此外，开发团队还会变成“救火员”
的角色。相反，这个团队利用了ODC的分类缺陷数据，评估了测试的有效性。在随后创建的测试计划中明确了目标，在之前缺少的sequencing测试中使
用多功能场景。这些步骤都可能提高测试效率，同时降低弱点，让开发团队向用户交付一个稳定的、高质量的产品。
正如前面所提到的一个重要的方面，ODC提供的是基于数据的判断的支持。这个评估花去了一个小时的时间，随后决定扩大测试的范围，而这个决定是在客观的数
据基础上做出的。一旦团队复查了图表中列出的ODC属性，有关产品是否准备就绪的争议就不会再有了。团队有了下一步的决定，有了要采取的应对措施，经理就
不会再被两个对立的观点搅得痛苦不堪了。这些图表清晰地表现出了软件的状态，以及采取的措施，对团队来说，它们都是显而易见的。
这次的经历使开发团队相信，在测试期间不用花太多的时间和精力去精确地度量过程和强调风险。尽管是个小型团队，但对分类缺陷的数据评估可以很快就完成了，
并采取相应的措施以避免潜在的灾难性的情况发生。最重要的是，从用户那里收集到的反馈表明这个版本是最稳定的版本！
Conclusion
总结
我们描述了三个不同产品的项目团队使用ODC的经历。通过使用ODC，每个团队都达到了提高测试效率的目标，同时对组织资源造成的影响也是非常小的。在所
有三个项目中，他们在采用ODC之前已经收集并使用了缺陷相关的信息，而ODC能够让这些团队利用丰富的缺陷信息集，以一种客观的方式，来改进各自的产品
质量。
第一个案例是一个高质量的产品，其目的是减少客户报告的缺陷，以此提高客户的满意度，同时降低质保的费用。通过对这些引起客户报告的潜在问
题的确定，测试的有效性得到了提高。来自于逃逸缺陷的分类triggers（触发器），为测试和开发的某个具体区域的改进提供了必要的依据。这个团队所采
取的措施其重点是加强测试计划，改进FVT培训，增加对已确定模块的回归测试，以及提高文档的质量。
第二个案例使用了在功能和系统测试数据中发现的缺陷来提高测试的有效性。这个研究列举了一个减轻进度压力的例子，通过ODC的分类缺陷，表明产品的进度充
分，足以进入到下一步测试中。团队能够早于计划的时间开始系统测试，得益于ODC评估提供的信息，它表明团队已经达到了早期活动的退出标准。与第一个案例
相似，这个团队也确定了一些薄弱的测试区域。随后，他们针对这些区域采取了具体的措施。他们实施的措施包括使用代码覆盖工具和功能测试用例的ODC分类，
来确保他们所需的测试场景有足够的覆盖范围。
第三个案例描述了一个拥有很少资源的小团队，他们对测试存在的具体不足进行确定，并从中受益。这个团队使用的缺陷信息是在项目发布前不久在内部发现的。产
品发布前，他们针对需要改进的功能测试，使用了ODC来确定多功能的测试场景。这样，团队能够快速地评估测试的效果并实施正确的措施来加强他们的目标
triggers（触发器）。
ODC数据收集可以在软件开发过程中的任意点开始。所有的三个案例都提供了这样的例子，他们分别在软件生命周期中不同的时间点上对ODC分类的缺陷进行分
析，并从中获益。而他们实施的改进措施都是合理且可行的，也不需要为实现提高测试有效性的目标投入大量的资源。
除了此处所表现的ODC的积极影响外，还有很多不容易度量的结果，但尽管如此，我们还是从中得到了很多的收益。我们的测试人员和开发人员身上产生了微妙的
变化，比如他们的技能都提高了，因为现在他们能看到自己的工作是以一种新的客观的方式进行的。测试人员学会了用复杂的triggers（触发器）来考虑测
试用例。他们会根据预定计划的阶段查看当前进度的趋势，也更加警觉于这些趋势里出现的任何偏差。他们变成了缺陷triggers（触发器）的比较能手，而
这些triggers分别暴露了用户发现的和他们自己的测试所发现的缺陷。测试人员增加了测试有效性方面的知识水平，从而带来了更好的产品质量和更强壮的
过程。最终，这些增长的知识生产出了质量更高的且开发费用更少的软件 -- 一个所有的软件组织想努力达到的目标。
Appendix A: Scheme version 5.11 for design and code
附录A：针对设计和编码活动的分类表 版本5.11
更多的信息和例子请参阅http://www.research.ibm.com/softeng。
提交缺陷时的分类属性：
Activity（活动）—指实际（软件开发过程）的活动。例如，在系统测试阶段，当你点击一个“选择打印机”的按钮时，出现了一个缺陷。虽然处于系统测试阶段，但对应的活动应为功能测试，这是由于此缺陷是通过执行一个“功能测试类型”的活动发现的。
Triggers（触发器）—触发缺陷出现的环境或条件。它的定义更类似于一种“测试类型”。
Impact（影响）—逃逸到外部的缺陷对用户产生的影响或开发过程中未发现此缺陷的影响。
表1为活动到触发器的映射表。
| Table 1 Attributes identified when a defect is uncovered |
修改缺陷时可用的属性：
Target（目标）—在哪里修改缺陷，如设计、代码、文档等。
Defect type（缺陷类型）—实际的修改类型。
Defect qualifier（缺陷限定：适用于缺陷类型）—捕捉的不存在、错误或无关的实施元素。
Source（来源）—缺陷的起源，一般如内部开发的代码、重用的代码、外包的代码或端口等。
Age（码龄）—缺陷对应的代码历史。
The attributes identified when a design or code defect is fixed are shown in Table 2.
Table 2 Attributes identified when a design or code defect is fixed
在软件工程中，验证(Verification)和确认(Validation)的区别：
“确认”是要证明所提供的（或将要提供的）产品适合其预计的用途，而“验证”则是要查明工作产品是否恰当地反映了规定的要求。换句话说，验证要保证“做得正确”，而确认则要保证“做的东西正确”。
验证注重“过程”，确认注重“结果”
简单一点说：
验证我们是不是正确的做了软件（实现和需求规格一致）
确认我们是不是做了正确的软件（实现和用户需求一致）
Review & Inspection
复查（审核）&检查
复查（审核）—指到达软件生命周期的各个阶段，所进行的确认活动，主要以会议的形式对各个阶段的产物进行评审。一般会组成评审委员会，组织对各种产物的评审（复查）活动。
检查—指对产品或产物进行一步一步的详细检查。目的是发现被检查物中的错误。实施检查的组织由开发、测试和质量保证等同级人员组成。
转载：http://www.51testing.com/html/22/n-66022.html