本文主要介绍如何结合 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 Variation Sequencing Interaction Workload/Stress Recovery/Exception StartUp/Restart Hardware Configuration 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 属性分析客户问题
Component Trigger Impact Type Qualifier Age Defect Leakage Reason from testing Component A
Component B
Component C
...
Coverage
Variation
Sequencing
Interaction
Workload/Stress
Recovery/
Exception
StartUp/Restart
Hardware Configuration
Software Configuration
Installability
Integrity/
Security
Performance
Maintenance
Serviceability
Migration
Documentation
Usability
Standards
Reliability
Accessibility
Capability
New Requirement
Assignment/
Initialization
Checking
Algorithm/
Method
Function/
Class/
Object
Timing/
Serialization
Interface/
Messages
Relationship
Missing
Incorrect
Extraneous New
BASE / Prior Release
Rewritten
Refixed Config/Env difference
Missing in test design
Missing in test execution
Incorrect test case
Incorrect test execution