正交缺陷分类（ODC）流程简介及应用经验分享

2010-04-30 作者：谷珊来源：IBM

正交缺陷分类（ODC）简介

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

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

1. 分类阶段

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

前提条件

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

Activity：表示在做哪种测试时发现的缺陷。比如：UT( 单元测试 )、FVT（功能测试），SVT（系统测试）等；
Trigger；表示采取哪种方式触发的该缺陷，不同的 activity 对应不同的 trigger 类型；
Impact：表示该缺陷的发生会对客户造成的影响；
Target：表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：产品设计、相应的代码和文档等；
Defect Type：缺陷类型；
Qualifier：表示该缺陷是由于丢失相关代码、还是代码不正确造成的。或者是由于第三方提供的代码造成的；
Source：表示该缺陷的来源是由于内部编写的代码引起的问题，还是由外包公司提供的代码引起的等；
Age：表示该缺陷是由新代码产生的还是由于修改其它缺陷而引发的，或是在上一个发布版本中就已经有的问题等；
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。这六个选项是由开发人员，也就是该缺陷的解决者来填写的。由这几个属性可以得知，开发人员做了哪方面的修改用以解决问题？改动大不大？是原来的代码有遗漏？不正确？还是需要被删除一部分？原来的版本中是否存在这个问题？等等。有了这些属性的值，就可以很快的知道产生这个缺陷的根源了。

常见问题及建议

缺陷管理工具对 ODC 的支持不完善

有些 ODC 属性间是有关联关系的。例如：在 ODC Submitter 选项签中，如果在 Activity 属性中选择了“Function Test”，那么 Trigger 属性就只能在“Coverage”，“Sequence”，“Variation”和“Interaction”中进行选择。如果在 Activity 属性中选择了“System Test”，那么可选的 Trigger 属性的值又是截然不同的另外几种选项，分别为：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若对这些属性间的关联关系不做限制，选择每个选项时都会把所有的值列出来供用户选择，这样很容易造成选项间的不匹配。从而导致最后统计 ODC 数据时，结果不合理。

另外，没有对 ODC 属性项进行必填操作的校验，也是缺陷管理工具对 ODC 支持不完善的表现之一。例如：仅填写了 Activity 属性，即表明了该缺陷是在何种类型的测试中发现的，但是不填写 Trigger 属性，也就是说不指明是在哪种触发条件下发现的该缺陷，就会造成信息缺失，从而分析出的结果也不会准确。

因此，我们强烈建议在配置缺陷管理工具用以支持 ODC 时，加上对有关联关系属性的限制，并对必填的 ODC 属性进行强制填写的校验，强制每个人必须填写，否则无法提交成功。从而在工具的层面上，保证 ODC 数据输入的完整性和正确性。

测试或开发人员对各自需要填写的 ODC 属性不熟悉

ODC 这种缺陷分析方法并没有普及到每一个项目中，因此在第一次应用 ODC 的项目中必须在分类阶段前，就要在项目内部做好 ODC 知识的系统培训。不仅仅是简单的了解，而是需要知道每个属性所有可选项的含义。这样就不会在分类阶段开始后，一片茫然。另外，由于 ODC 属性选项众多，不可能靠之前的几次培训就全部记住。建议打印一份类似于 ODC 属性快速参考手册的资料。这样在填写 ODC 数据时，可一边参考手边的文档一边填写。

2. 校验阶段

在第一步中，测试人员和开发人员已经填写了 ODC 数据。那么接下来就需要 ODC 专家对这些数据进行校验。因为填写不正确的 ODC 数据会导致后面的评估和行动两个流程步骤没有意义。因此校验数据的正确性尤为重要。

常见问题及建议

校验结果如何在缺陷管理工具中体现？

校验员在校验完某个缺陷并确认相关人员已经完成修改后，校验工作还并没有结束。为了在下一阶段，即评估阶段中，仅仅对已被校验过的缺陷进行分析，就需要在缺陷管理工具中有地方进行标识，用以过滤掉未校验过的缺陷。

可以在 ODC Responder 选项签中增加一个属性项，叫做“ODC Validated”。如图 3 所示。

图 3. ODC Responder 选项签中新增加属性 ODC Validated:

有四个选项可供选择。

“空”：默认情况下，该属性项为空。表示校验人员还没有开始进行该缺陷的校验工作；
“是”：已被校验过，并且相关人员已经把错误的 ODC 属性进行了修改；
“否”：已被校验过，但是相关人员还没有进行修改；
“N/A”：对于无效的缺陷，是不算在最后的统计数据中的。出现无效缺陷的情况可以包括：由于测试人员的问题，开的无效缺陷（User Error）；所发现的问题并不是一个缺陷，而恰恰在产品设计上就是这样的（As Design）；该缺陷与之前开的另一缺陷重复（duplicate）；

校验小组成员间如何更有效的沟通？

校验小组成员通常会从测试和开发人员中分别挑选。在很多大项目中，测试和开发团队可能并不在一个地区，甚至存在时差。如何增强跨地区小组成员的交流，使得资源共享、沟通及时无误呢？这就需要有一个信息共享平台。从我们的实际经验中来看，wiki 是一个不错的选择。wiki 是一种多人协作的写作工具，每个人都可以在上面发表意见。下面是作者正在参与的一个项目组所采用的 ODC 校验小组 wiki 上的内容，包括如下方面。

目的：明确校验工作的目的；
校验小组人员名单：包括姓名和联系方式；
校验流程说明：针对本项目的特点，制定出适合本项目的校验流程。以作者参与的项目为例，校验流程可以包括：
- 每周一，由 ODC 校验小组负责人分配给每个人这周需要校验的缺陷（分配的方式，会在下面的“每周工作安排”中提到）；
- 校验小组中的每位成员开始逐一校验分配给自己的缺陷。如果发现该缺陷的 ODC 属性有填写不正确的或忘记填的，就需要马上发邮件给该缺陷的发现者或解决者，予以修改。若缺陷本身的描述信息足以令校验员分析出正确的选项，那么在邮件中需要写明校验员的修改意见及原因。若缺陷的描述信息不清晰以至于校验员无法作出准确判断的，也需要在邮件中指明。待测试或开发人员在缺陷中补充了更详细的信息，校验员再重新进行校验。
- 一旦校验完成，校验员需要在缺陷管理工具中对该缺陷进行标识，如前面我们提到的“ODC 是否已被校验”属性项，这时把它的值从默认值“否”修改为“是”。以表明该缺陷已被校验过。校验组长下次再分配待校验的缺陷时，就会把已被校验过的缺陷过滤掉。
- 校验员把在校验过程中发现的问题，例如错误分类趋势等进行反馈；
每周工作安排：
- 可由如下表格进行工作分配和进展跟踪。其中的前两列由 ODC 校验小组负责人在分配工作时填写。后两列由 ODC 校验员在进行校验工作时填写。表 1 列出了一些可能出现的情况。

表 1. ODC 校验工作分配 / 跟踪表

校验者 缺陷编号 是否已被校验 问题

张三 00001 是

00002 否在某某日给相关人员发送了第一封邮件，让其进行修改，在三天之内还没有得到回复。

00003 N/A 该缺陷与 00001 重复，不算做 ODC 数据统计范围内。

00004

李四 00005 否在某某日给相关人员发送了第二封提醒邮件，让其进行修改，在三天之内还没有得到回复。

表中的第三列“是否已被校验”与缺陷管理工具中的“ODC 是否已被校验”属性项相对应，同样有四个选项可供选择：不填表示校验人员还没有开始对该缺陷进行校验；“是”表示该缺陷已经被校验完成，可以作为评估阶段的统计数据；“否”表示该缺陷还处在校验过程中，等待相关人员根据检验员指出的修改意见在缺陷管理工具中进行修改。在校验员发出第一封邮件后的三天之内，若没有得到相关人员的响应，校验员需要发送第二封邮件，同时抄送相关人员的直接经理。以此督促相关人员尽快更改 ODC 属性，以便该缺陷被标识为“已校验”；“N/A”表示该缺陷为无效缺陷。

会议纪要：记录、传达每次例会的情况，便于日后查看和跟踪。下面以作者参与的项目为例，会议纪要内容包括如下方面：
- 参会人员：参会人员名单。
- 公告：通常是上次会议待解决事情的进展或结果的说明。也可是重要的通知。
- 本次会议讨论内容：本次会议讨论内容详情。
- 行动：
  - 根据会议讨论的结果，有些是需要在会后付诸于行动的。这样就需要把每个行动的内容和负责人记录下来，以便下次会议进行跟踪确认。下面举例说明。如果本次会议记录了如下两条行动：
    - 某某去联系缺陷管理工具的管理员，添加一个额外的属性来记录缺陷是否已被校验过；
    - 某某去邀请 ODC 专家 David 来参与我们每周的例会，帮助我们解答校验过程中遇到的问题。
    在下次会议开始的时候，首先要确认上次会议中这两条行动是否已经实施。并把进度或结果在本次会议纪要中的公告部分进行说明。
参考资料的链接：
- 关于 ODC 校验工作和 ODC 分类说明的参考资料链接。

对于校验小组长来说，如何更有效、更直接的分配校验任务？

仅仅在 wiki 中列出工作分配表，虽然也可以进行任务分配和进度跟踪，但由于并没有跟缺陷管理工具相关联，所以需要校验人员根据表 1 中的缺陷编号，逐一在缺陷管理工具中进行查找。显然这样很浪费时间，也难免会在查找过程中发生错误。因此在缺陷管理工具中直接分配任务是更合适的办法，同时利用表 1 中所示的 ODC 校验工作分配 / 跟踪表进行进度跟踪。

在作者从事的项目中，我们采用在缺陷管理工具中增加一个名为 ODC Validator 的属性，如图 4 中所示。来供校验小组长在分配任务时进行选择。这样校验人员在登录缺陷管理工具后，直接查询 ODC Validator 属性为自己名字的缺陷列表即可。

图 4. ODC Responder 选项签中新增加属性 ODC Validator:

3. 评估阶段

在确保输入的 ODC 数据正确性的前提下，就可以对这些缺陷进行分析了。根据 ODC 的不同属性进行分类统计，可得出不同方面的结论。以此来反映测试、开发或产品设计方面的问题，指出潜在的改进的机会。比如：缺陷被发现的如何、产品是否稳定等。下面挑几个典型的评估方法进行说明。

对测试工作的评估

利用不同的 ODC 属性的组合，可以从多方面来评估测试工作的完成情况。例如利用测试阶段和 activity 属性来评估是否应在某一测试阶段中发现的缺陷却被在下一测试阶段中才发现；利用 activity 和 trigger 属性来评估是否每个 activity 都使用了足够多的与之对应的 trigger 来发现缺陷；利用时间和 trigger 属性来评估是否随着时间的推移测试变得更加复杂等。下面就利用第一种评估方法来进行举例。

不同的测试阶段有不同的测试重点。例如在功能测试阶段，所对应的 activity 就是 Function Test( 功能测试 )。而在系统测试阶段，所对应的 activity 就是 System Test（系统测试）。我们可以通过统计在每种测试阶段中发现缺陷的 activity 来判断是否本应在该测试阶段中发现的缺陷被遗留到了下一测试阶段。以此来评估测试工作的完成情况。如图 5 所示。

图 5. 利用测试阶段和 activity 属性得到的评估图

由上图我们可以看出，该项目在系统测试阶段，有近一半缺陷的 activity 是功能测试。这说明本应该在功能测试阶段发现的缺陷，却被遗留到了系统测试阶段才得以发现。可见功能测试阶段的测试工作做得不够全面。

经验和建议

这个评估方法常用于衡量是否本应该在功能测试阶段发现的缺陷没有被发现，而是到了系统测试阶段才被发现。因此该评估方法最好在系统测试开始后使用，因为在此之前的阶段使用没有太大的帮助；
客观上讲，在系统测试阶段发现一些功能测试阶段的缺陷是正常现象，这不会影响系统测试的正常运行。反而如果在系统测试阶段没有任何功能测试阶段的缺陷，就说明有问题了。很可能是由于测试人员对 activity 属性理解不正确导致的错误输入引起的；
上图所表现出来的问题是过多的本应在功能测试阶段发现的缺陷却在系统测试阶段被发现。针对该问题，我们可以通过增加功能测试阶段的测试用例来增加功能测试的覆盖面。或是修改功能测试阶段的退出标准，例如必须发现多少缺陷才能进入系统测试阶段等等。

对产品稳定度的评估

利用 ODC 属性不仅可以评估测试工作的完成情况，同时还可以评估产品的稳定度。例如：随着项目的进展，定期统计 qualifier 属性的变化趋势，以此来评估产品是否变得更加完善；或者定期统计 impact 属性的变化趋势，以此来评估影响产品功能性和可靠性的缺陷是否在减少。下面就以一个实例中的 qualifier 属性为研究对象，来评估一下该实例是否随着项目进展的过程而变得更加完善。如图 6 所示。

图 6. Qualifier 属性趋势图

图 6 显示了 missing 和 incorrect 的百分比随项目进展而发生的变化趋势。对于一个逐渐趋向于稳定的产品来说，Qualifier 为 missing 的缺陷应该逐渐减少。因为任何未经测试过的新代码的加入，都会增加潜在的风险。

但是从图 6 中我们可以看到这个实例的稳定度并不乐观。Qualifier 为 missing 的缺陷并没有随着项目的发展而有减少的趋势。

经验和建议

这个趋势图可以按周或月来定期查看趋势变化；
看这个图时，不能只笼统的看表面所反映的数据，missing 所占的百分比是多少，incorrect 占多少。还应该看到更深层的内容，比如那些 missing 的缺陷到底属于哪个 defect type? 又是发生在哪些 component? 这样才能够发现真正的风险在哪里，以此判断产品是否稳定。而不仅仅只是看到有多少百分比的缺陷的 Qualifier 是 missing；
上图中的纵坐标是百分比。如果某个时间段里仅发现了很少的缺陷时，这种表现方式会造成误解。因此看这种类型的评估图时，既要看用百分比来展现的视图，也要看用缺陷数作为纵坐标来展现的视图。

对产品设计和代码的评估

供开发人员填写的 ODC 属性中有一个属性叫做 target。它表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：design/code、build、information、language 等。为了评估产品在设计和代码方面的完成情况，我们可以分析 target 是 design/code 的缺陷，利用其对应的 defect type 和 qualifier 属性来发现产品在需求、设计和代码阶段的不足，以及在哪个薄弱环节更容易引入缺陷。下面以一个案例来说明如何利用 defect type 和 qualifier 属性来评估。如图 7 所示。

图 7. 利用 Defect type 和 Qualifier 得到的评估图

从图 7 中我们可以看到 defect type 为 algorithm/method 的缺陷，qualifier 是 missing 和 incorrect 的比例及缺陷数量都很高。这说明产品的低层次的细节设计描述不完整，同时没有被开发人员很好的理解；其次是 defect type 为 assignment-initialization 和 checking 的缺陷，它们的 incorrect 比例相对来说比较高，这反映了代码编写上还存在欠缺；最后我们看到 defect type 为 interface/O-O messages、relationship 和 timing/serialization 等的缺陷，其 qualifier 为 incorrect 和 missing 的数量都比较少，这说明产品在高层次的设计上和需求分析、理解上都还做得不错。

经验和建议