正交缺陷分类（ODC）简介

正交缺陷分类法，Orthogonal Defect Classification（以下简称 ODC）是一种缺陷分析方法，由 IBM 在 1992 年提出。它通过给每个缺陷添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等各方面的问题。从而得到一些解决办法来进行改进。例如对于测试团队，通过 ODC 可以知道测试工作是否变得更加复杂；每一个测试阶段，是否利用了足够多的触发条件来发现缺陷；退出当前测试阶段有什么风险；哪个测试阶段做得好，哪个测试阶段需要改进等。对于开发团队，利用 ODC 可以知道产品设计和代码编写的质量情况。而给产品用户带来的好处就是提高客户满意度，减小产品投入市场后的维护花费。

ODC 的工作流程分为四部分：“缺陷分类”，“校验已被分类的缺陷”，“评估数据”以及“采取行动来改进工作”。下面我们将逐一进行讲解。

1. 分类阶段

分类，是 ODC 工作流程中的第一步，即需要测试和开发人员分别对每一个缺陷填写 ODC 属性。对于团队成员来说，正确的了解每个属性的值尤为重要，这样才能保证他们在分类时尽量选择正确的选项。

前提条件

有些缺陷管理工具在默认情况下是不支持 ODC 的，这就需要在填写之前，对缺陷管理工具进行改进，配置额外的属性。常用的缺陷管理工具包括 Clear Quest(CQ) 和 Configuration Management Version Control(CMVC) 等。需要增加的 9 个 ODC 相关属性分别是。

1. Activity：表示在做哪种测试时发现的缺陷。比如：UT( 单元测试 )、FVT（功能测试），SVT（系统测试）等；
2. Trigger；表示采取哪种方式触发的该缺陷，不同的 activity 对应不同的 trigger 类型；
3. Impact：表示该缺陷的发生会对客户造成的影响；
4. Target：表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：产品设计、相应的代码和文档等；
5. Defect Type：缺陷类型；
6. Qualifier：表示该缺陷是由于丢失相关代码、还是代码不正确造成的。或者是由于第三方提供的代码造成的；
7. Source：表示该缺陷的来源是由于内部编写的代码引起的问题，还是由外包公司提供的代码引起的等；
8. Age：表示该缺陷是由新代码产生的还是由于修改其它缺陷而引发的，或是在上一个发布版本中就已经有的问题等；
9. Content Type: 表示修复文档的类型。仅对文档类的缺陷有效。

对于 CMVC，自从 1.7 版本后就自带了 ODC 属性，可直接使用。而对于 CQ，需要安装一个 ODC 包即可。关于该 ODC 包可从附件中下载，解压后里面有详细的文档教读者如何在 CQ 中安装该包。

在配置好 ODC 后，CQ 的应用程序窗口中会出现新的选项签：ODC Submitter 和 ODC Responder，如图 1 和图 2 所示。

图 1. CQ 中的 ODC Submitter 选项签

图 2. CQ 中的 ODC Responder 选项签

在缺陷管理工具支持 ODC 后，就需要测试人员和开发人员分别填写 ODC 属性，后面的流程都会用到这些数据。

测试人员进行分类

从图 1 中我们可以看到，ODC Submitter 选项签中有三个选项，分别是 Activity、Trigger 和 Impact。这三个选项是由测试人员，也就是该缺陷的发现者来填写的。由这几个属性可以得知，该缺陷是在进行何种类型测试的时候，由怎样的触发方法来发现的。同时，对用户造成的影响是什么。仅靠这三个 ODC 属性，就可以一目了然。

开发人员进行分类

从图 2 中我们可以看到，ODC Responder 选项签中有六个选项，分别是 Target，Defect Type，Qualifier Source，Age 和 ContentType。这六个选项是由开发人员，也就是该缺陷的解决者来填写的。由这几个属性可以得知，开发人员做了哪方面的修改用以解决问题？改动大不大？是原来的代码有遗漏？不正确？还是需要被删除一部分？原来的版本中是否存在这个问题？等等。有了这些属性的值，就可以很快的知道产生这个缺陷的根源了。

原文转自：http://www.ltesting.net