ODC(Orthogonal Defect Classification)简介

Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。

Defect 分类帮助改进产品质量

软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。

回页首

几种常见的defect 分类方法

在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。

下面我们来看看几种我们常见的defect 分析方法：

按照defect 严重程度分类

我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图：

在这个图中defects跟据它们的severity属性进行了分类， severity为1的defect是最严重的defect, 它使系统根本不能运转，需要立即进行改正。那severity为 2的defect 是一般功能性的错误，这些错误是需求中所要求的，必须改正才能实现系统完整的功能。Severity 为3的defect是一些细小的错误，它们不影响功能的实现，但可能引起用户的误解或者使用不当。Severity为4 的 的defect是测试人员建议改进的地方，如果时间允许开发人员可以选择性的改正，或者等到下个版本中再改进。从图3中我们可以看到第一个图是在一个项目测试前期的时候，这时候1级的defect很多，整个系统还不能够运转，正需要大量的时间和人力进行测试和改正代码错误。第二个图则显示项目测试已经到了中期，这时候最严重的defect已经很少了，系统已经基本可以运转，然后测试人员发现了大量的功能性的错误和细节上的错误需要改正。第三个图显示了项目测试已经到了末期，这时的产品需求的功能已经实现，只有部分细节和建议需要改进，产品已经可以发布了。在用severity分类的图表中，我们可以了解到以下有关项目的几个方面：

1) 工作的优先级

2) 项目的进展状态

3) 产品的质量

按照component/module分类

对于不同的component或者module，我们也可以有类似的defect分布图来说明另外一些问题：

图4中，对于第一个图，我们能看出C模块中发现的defect明显的比其他模块的少，那么原因可能是C模块的开发人员技术非常的好。第二个图中我们可以看出A和C中发现的defect明显比其他两个模块的多，那么可能这两个模块的难度、大小或者是改动的变化比较大，因此而造成了它们中发现的defect比较多。对于第三个图，C模块的defect明显比其他的多，那么可能是C模块的开发人员太差了，需要管理者的特别关注了。

回页首

Orthogonal Defect Classification简介

下面我们来介绍ODC，什么是ODC（Orthogonal Defect Classification）呢？简单的说，它是另外一种defect分类的方法，它使你能够快速得到每一个问题的信息来帮助你后面做出正确的决定来解决问题。

开发中应用ODC

作为一个开发人员我发现的问题如果按类型（type）分类可能是由如下几种可能：(括号中的英文为缩写图例)

1) 没有正确的初始化 （Init）

2) 代码没有正确的check-in （Chk）

3) 算法问题 （Alg）

4) 功能性的错误，可能是模块内的功能没有被正确实现，也可能是模块与模块之间相联系的部分没有被正确实现。（Fnct Cls）

5) 有可能是有关时间的错误 （Time）

6) 界面相关的错误 （Intf）

7) 代码之间相关联的错误，例如错误的继承关系 （Rel'n）

按照type的分类我们有如下的分布图：

从图5、图6中，我们可以了解到开发过程中哪个环节的错误比较多，例如图6中算法错误和功能性错误是最多的那么应该在单元测试或者code review中着重注意这两个部分的代码质量。另外从上图中我们也可以知道在哪以及如何来改正错误代码。