简介：

正交缺陷分类法（Orthogonal Defect Classification，ODC）是一种软件缺陷分析方法，它给每一个软件缺陷定义了 8 个属性，从不同维度分析软件缺陷，评估产品质量，开发测试水平。而客户报告的问题尤其是最后被定位到软件缺陷的客户问题通常是开发测试团队都比较关心的。本文主要介绍如何结合 ODC 理论分析客户上报的软件缺陷，从而找到当前开发测试流程当中存在的问题，提出改进方案，提高产品质量。

正交缺陷分类法（Orthogonal Defect Classification，ODC）简介

Defect（软件缺陷）分析是软件开发和测试中一个重要的环节。传统的使用严重等级，重要性等分类方法无法帮助开发人员快速定位问题，也无法准确评估测试人员的效率。 正交缺陷分类法（Orthogonal Defect Classification，ODC）介绍了一种不同于大家常用的非常有效的软件缺陷分类及分析方法，它定义了八个正交的缺陷属性用于对缺陷的分类。所谓正交性是指缺陷属之间不存在关联性，各自独立，没有重叠的冗余信息。对于缺陷提交者，他需要给这个缺陷分配“活动（Activity）”、“触发（Trigger）”、“影响（Impact）”这三个属性。当一个开发人员关闭一个缺陷时，他可以分配“阶段（Age）”、“来源（Source）”、“限定符（Qualifier）”、“类型（Type）”以及“目标（Target）”这些属性。下面将介绍这些不同的属性的含义：

Activity：就是当缺陷被发现时实际的处理步骤。比如单元测试，功能测试，系统测试等等。

Trigger：描述了暴露缺陷时存在的环境或者条件。针对不同的 Activity，会对应有不同的 Trigger。

Impact：是指缺陷可能对用户造成的影响。

Target：将要在哪里改正错误，例如：design、code 等等。

Type：表示所进行的实际修正的种类，比如算法，接口，初始化等等。针对不同的 Target，也会定义不同的 Type。

Qualifier：指明了所进行的修复应归于缺失，错误或者还是外来的代码或者信息。

Source：指明了发现的缺陷的来源，是出现在内部代码编写中，重用自一个程序库中，从一个平台转移到另一个平台上的，或者是外包一个软件销售商的。

Age：确定这个缺陷是新代码还是旧代码，或者是重写的代码。

客户问题的特征

客户报过来的问题，通常有两种。一部分问题可能是由于客户自己操作不当，环境配置不当或者是对软件功能的理解有误引起的，这个不同于我们所说的缺陷，不需要代码改动，只需要技术人员的支持就可以解决的。另外一部分问题是被定位到软件缺陷，需要开发人员进行代码改动才能解决的。这个是我们今天分析的重点。这部分缺陷是本来应该在开发测试流程当中发现，而却没有发现，给客户带来不良影响的问题。修复这些软件缺陷需要付出高昂的代价，因而也是我们今天分析的重点。

定义分析模型

ODC 理论里边定义的 8 个属性涵盖的面较为广泛，比如根据不同的 Activity 和 Target 都会对应有不同的 Trigger 和 Type，全部都分析的话需要耗费大量时间。对于我们今天要分析的客户报告过来的被定为软件缺陷，并且有代码改动的问题，并不是 ODC 的每一个属性都有必要进行分析。下面我们通过逐个分析 ODC 属性的意义来选取能给我们带来比较大价值的属性。

首先，我们来看 Activity，当客户发现软件缺陷时，他们的实际处理步骤只有 Function Test 和 System Test，所以 Activity 只有这两种值，我们就不需要做深入分析了。

确定 Activity 只有 Function Test 和 System Test 这两种时，那我们的 Trigger 也就是只针对这两种的了，所以包含有这些值：

• Coverage
• Sequencing
• Interaction
• Workload/Stress
• StartUp/Restart
• Software Configuration

Impact: 涉及到这个缺陷对于用户的实际感受或影响，通过对 impact 的分析可以得到客户关注焦点和客户满意度，是我们需要分析的。
Target: 因为我们分析的都是被确定为是软件缺陷的有代码改动的问题，所以 Target 都是在 code 范围内，这里 Target 就不做深入分析了。

Type: 确定 Target 是 code 之后，那么对于 Type 的属性值就是这些：

• Assignment/Initialization
• Checking
• Algorithm/Method
• Function/Class/Object
• Timing/Serialization
• Interface/Messages
• Relationship

Qualifier: 能够定位这个 defect 产生是由于缺失，错误或者还是外来的代码。结合 Type 的分析还能指导如何预防这个 Defect 的产生，所以是我们需要分析的。

Source: 由于大部分问题都是内部代码产生的，不在我们分析重点。

Age: 可以分析出流露到客户那里的问题有多少是新代码的问题，有多少是一直存在着的问题等等。

另外，这些被客户发现的 defect 都是测试遗漏的，从测试的角度我们还可以分析一下如何从测试当中遗漏的。还有以及常用的根据模块的分析。

所以，我们重点分析的是如表 1 展示的这些属性：

表 1. 利用 ODC 属性分析客户问题

ODC 分析案例

下面我们会通过一些具体的例子来介绍如何利用 ODC 来分析客户提交的软件缺陷，从而评估和指导开发测试工作。

利用 ODC 来评估设计和代码中的问题

我们对软件缺陷进行 Type 和 Qualifier 的分析，可以得到下图。从这个图中可以看出来，最多的缺陷类型是 Checking 和 Function/Class/Object 相关的。

图 1. Defect Type 和 Qualifier 的分析

而对 Type 和 Qualifier 进行进一步的深入分析，ODC 里边 Type 和 Qualifier 的属性值映射到具体开发设计的流程有如下表的关系：

表 2. ODC 缺陷类型与开发设计流程的映射关系

因而我们就有了下面图 2 来表明在开发设计中哪个阶段存在着问题。

图 2. 可以避免 Defect 产生的阶段

发现的问题：从图 2 中可以看到 52% 的问题存在于代码的编写和检查当中，而且主要是由不正确的检查（Incorrect Checking）导致的（如图 1）。另外有 31% 的问题存在于高层次的设计中。而在整个软件开发过程中如果要重新改动高层次的设计往往会带来比较大的代码改动量，因此所带来的风险也是巨大的。

改进意见：对于大量的代码错误，在今后的开发过程中应该加强代码检查，单元测试工作，开发组应该创建和维护一些常见的代码检查点以供代码检查使用。尤其对一些复杂功能，应该考虑到各种不同条件下的检查点。另外高层次的设计也存在很大问题，今后对于每一个需求一定要在项目初期就提供详细的设计文档，并且要经过相关开发，测试，需求分析人员一起讨论审查通过之后才能进行下一步的工作。

分析造成缺陷的代码是何时开发的

除了分析出设计代码中存在的问题，我们有时候还想知道造成缺陷的这些代码都是何时开发的，这个就可以通过对 ODC 中 Age 属性进行分析。

图 3. 对 Defect Age 的分析

发现的问题和改进意见：通过对 Age 属性进行分析，我们发现大部分软件缺陷都是在开发新的代码时候引入的，说明我们在开发新功能的时候测试的不够充分。另外 Refixed（修复之前的一个软件缺陷引入的问题）的缺陷数量也相对较高，说明开发在修复缺陷的时候引入新问题比较多，这样给测试就会造成比较大的压力。图中基础代码引起的缺陷相对较少，说明旧版本还是比较稳定的。

改进意见：在新功能的开发测试流程中，需要重新审核测试计划，测试策略，测试用例设计和执行的各个过程，看看到底是哪个环节中存在问题。开发团队在修复缺陷的时候要考虑到对周边区域的影响，并且要通知相关区域的专家加强代码审查。当然测试团队也要尽可能多的在相关区域做一些回归测试。

对 ODC Trigger 的分析来指导测试

对于 ODC 中 Trigger 的分析可以用来评估测试用例的设计水平，指导测试用例设计过程中需要改进的地方。比如我们对某一项目分析的结果如图 4：

图 4. 对于 Trigger 的分析

发现的问题：38% 的问题是由 Interaction 引起的，模块之间的交互测试涵盖的比较少。另外还有 25% 是 coverage 的问题，也就是基本的功能点没有涵盖，以至于流露到了客户环境中了，这个是正常情况下不应该出现的。

改进意见：由于存在大量 Interaction 的问题，说明我们需要设计更加复杂的测试用例，加强模块之间的交互测试。各个功能模块的开发测试需要一起评审一下哪些模块之间互相有依赖性，互相交流，覆盖到模块之间交互的测试用例。而 Coverage 缺陷的百分比如此之高是应当引起测试团队警惕的，找到覆盖率不够的功能点，所以我们要对 Coverage 的缺陷进一步进行按照模块的分析，如图 5。另外在正常测试用例设计的流程中，就可以根据 ODC 的各种 Trigger 去设计用例，这样可以覆盖到边界值，特殊顺序，反向测试的各种复杂情况。

图 5. 对于 Coverage Trigger 的模块分析

发现的问题：通过进一步对 Trigger 为 Coverage 的软件缺陷进行分析，我们发现大部分 Coverage 的权限都发生在 Component C 上。说明我们对这个模块的测试还远远不够。

改进意见：重新研究 Component C 相关的需求文档，审查测试用例，增加这部分测试用例覆盖率，并且对这个模块进行回归测试，以避免后续让客户发现更多问题。同时开发团队也可以重新审查下模块 C 相关的代码，通过代码审查找到缺陷问题。

分析软件缺陷从测试中遗漏的原因

除了 ODC 里边明确定义的这些属性之外，对于客户报告的问题，我们还需关心的是为什么这些问题会从测试当中遗漏掉。如图 6 就是这样一个分析。

图 6. 分析软件缺陷从测试中遗漏的原因

发现的问题：53% 的问题是由于在设计测试用例中遗漏掉了。测试用例设计是我们测试流程中的一个薄弱环节。另外还有 20% 是由于测试执行中某些操作步骤不正确引起的，说明测试人员对功能本身不够熟悉。

改进意见：在设计测试用例时，应该加强审查过程，让需求分析和开发人员以及项目经理共同参与到用例的审查流程中。另外还应该加强对测试人员进行测试理论和测试方法的培训。对于已经遗漏的测试用例，应该及时的弥补，以备后续版本的测试之用。对于测试执行操作不正确的问题，应该加强测试人员对软件产品本身的培训。另外对于设计的不正确的用例也要及时更正过来。另外对于设计用例时遗漏掉的这部分问题还可以进行进一步的按照 Trigger 的分析（如图 7），这样可以评估出哪一方面的测试用例不够，比如这个项目中就要加强 Interaction 和 Variation 这种 Trigger 的用例设计。

图 7. 进一步分析用例设计中遗漏的软件缺陷

利用 ODC 分析客户关注点

ODC 的 impact 属性可以帮助我们收集客户满意度，分析客户的关注焦点。

图 8. 对 customer impact 的分析

发现的问题：从图 8 中，我们看到客户关注的焦点在可用性（usability）上，有 43% 的软件缺陷都是跟 usability 相关的。而 Reliability 相关的软件缺陷很少，说明这个产品在客户环境当中还是比较稳定的。

改进意见：在今后的开发测试中我们应该更加关注可用性。从设计阶段就要加强跟客户之间的沟通，把客户的反馈意见及时的更新到产品设计中，在产品发布前要加强客户体验，改进在其中发现的不利于使用的地方。

RTC 对 ODC 的支持

目前在 IBM Rational Concert（RTC）3.0 中也可以添加 ODC 属性，实施对 ODC 数据的分类和采集，然后生成分析报告。如图 9 就是在 RTC 的 Defect 中添加了 ODC 属性。这样在提交和关闭 Defect 的时候，开发测试人员就可以在 RTC 中给这个 Defect 分配 ODC 属性，以便于后续分析。

图 9. RTC 对 ODC 的支持

关于如何在 RTC 中添加 ODC 属性，请参考参考文献《使用 Rational Team Concert 3.0 及 ODC 改进项目的质量》。

总结

本文通过具体实例介绍了如何利用 ODC 理论来分析客户提交的软件缺陷。从不同角度阐述了 ODC 各个属性的分析对于开发测试的指导意义，从而减少流露到客户环境中的问题，提高产品质量和客户满意度。需要注意的是，在进行 ODC 分析之前，一定要加强对开发测试人员的 ODC 培训，以保证数据的准确性。同时在分析过程中，开发和测试人员也要加强沟通以达到大家理解的一致性。只有保证大家理解的一致和数据的准确性，我们才能确保 ODC 的指导意义是有效的。

参考资料

查看 developerWorks 文章“使用 Rational Team Concert 3.0 及 ODC 改进项目的质量”。

访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。

订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。