正交缺陷分类法（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（缺陷严重性）等属性之间的关系。缺陷类型为“功能缺失”或严重等级高的缺陷，如果有一个增长的趋势，则表示产品的稳定性正在下降。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
