ODC(Orthogonal Defect Classification)简介
|
 |
冯涛 , IBM中国开发中心软件工程师 2005 年 11 月 Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。 Defect 分类帮助改进产品质量 软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。 图1
几种常见的defect 分类方法 在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。 图2 下面我们来看看几种我们常见的defect 分析方法： 按照defect 严重程度分类 我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图： 图3  在这个图中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  图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  从图5、图6中，我们可以了解到开发过程中哪个环节的错误比较多，例如图6中算法错误和功能性错误是最多的那么应该在单元测试或者code review中着重注意这两个部分的代码质量。另外从上图中我们也可以知道在哪以及如何来改正错误代码。 功能测试中应用ODC 下面我们来看看测试，在FVT（功能测试）中，一个主要的帮助FVT做得更好的指标是trigger, 在ODC中trigger可以简单的理解为是什么样的测试发现了这个defect。在FVT中我们定义了一下4个trigger：Coverage (这里的coverage不是我一般意义上理解的测试覆盖面的意思，它是指normal function, 是任何用户都会用到的功能，基本的、简单的功能)，Variation （对于有些对产品比较熟悉的用户，有可能会愿意用不常用的有创造性方法或者输入来完成同一种动作或者功能，或者单单就是为了挑错，在这些尝试中往往会发现很多漏掉的defect，例如'边界限制'），Sequencing (用和以前不同的操作流程来完成一种任务功能)，Interaction （当两个或者多个功能模块互相交互时可能会发生一些错误，例如同时启动一些功能时可能会造成系统死机）。 下面我们举例来看看FVT中按trigger分类的defect分布图： 图7 在图7中我们可以看到，这个产品中在一般的功能Coverage和改变操作顺序Sequencing的测试中发现了比较多的defect, 这说明了代码还需要作更多的单元测试来减少错误，从而我们可以了解到产品的基本质量水平。 图8  在图8中我们可以看到Coverage的错误很少，产品的基本质量是可以保证的；Variation的错误很多（看来测试组做了大量的这方面的测试），Sequencing 和 Interaction的错误也不少，那么后面的测试中应该加大这两块儿的测试。这里我们可以清楚地知道我们测了什么还有哪块需要加大测试力度。 图9  在图9中我们可以看到Variation的错误很多，那么加大单元测试的力度可以很好的解决这个问题，例如增加更多的边界检查。 系统测试中应用ODC 下面再让我们来看看SVT(系统测试)， 在系统测试中，ODC定义了另外一组trigger, 它们是：Blocked （有哪些defect阻止了SVT的执行， 最常见的是FVT的defect），Stress （压力测试的结果很可能是客户最关心的数据），Recovery (对于数据恢复和出错处理)，Restart (x系统的启动和重启)，Hardware configuration (硬件配置)，Software configuration (软件配置)。 下面我们举例来看看SVT中按trigger分类的defect分布图： 图10  在图10中我们看到了Blocked的defect太多了，显然这个时候进行大量的SVT测试是不明智的，那么应该让产品继续的进行功能测试，直到Blocked的问题减少到可以接受为止。 图11 在图11中，我们同样可以了解到SVT中进行了哪些测试，在这里软件配置测试和压力测试是需要加强的。 图12 在图12中，我们可以了解到硬件配置的defect比较多，那么我们应该要求开发人员更关注这部分的代码。 从上面的分析中我们看到了ODC中trigger告诉了我们哪里发现了问题，应该去做些什么。 ODC对于客户影响的应用 那么下面我们再来看看ODC怎么样的来影响客户。软件产品对于客户的影响有哪些方面呢？在ODC中定义了如下方面： 1. Installability 图13  这里图13是一个产品的defect 影响分布图, 我们可以看到这个产品有非常多的问题出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那么这样的产品如果卖给客户将是可怕的，那么我们就应该采取相应的动作来完善这几个方面的问题。 在ODC中，还定义了其他的元素来组合使用以帮助我们更好的了解问题出在哪里，同时帮助我们做出正确的决定。 在测试人员发现一个问题并且开一个defect时，需要给defect定义下面的属性： 1) Activity, 它是指在哪种测试中发现的defect, 例如：UT、FVT、SVT 等等。 2) Trigger, 问题出现的情况 3) Impact，影响客户的方面 当开发人员接到一个defect并且开始修改代码时，他需要定义下面的属性： 1) Target, 将要在哪里改正错误，例如：design、code 等等 2) Defect Type, defect的类型，例如：算法、初始化 等等 3) Qualifier: 只有三个，他们是missing、incorrect 和extraneous 4) Source: defect 的来源，例如：内部代码、outsource的代码等等 5) Age: defect是新代码还是重写的代码 具体可以参考下图： 图14 
结束语 在项目和产品开发中，我们经常会想到这样的问题：我们的测试有多有效？单元测试、功能测试、系统测试都做得正确吗？我们怎样在需求、设计、开发阶段来减少潜在的defect呢？我们的代码已经完成并且准备好了进入到下一个阶段了吗？我们发现的defect有哪些是属于上一个版本的？客户将会感觉我们的产品质量怎么样呢？这些都是很关键的问题，需要我们改进开发和测试流程，使它们更加有效，从而进一步增强我们产品的质量。那么怎么样改进呢？通过ODC我们可以知道我们采用的哪种测试方法正在帮助我们找出更多的defect（是基本功能测试，还是边界条件测试或者压力测试），还有defect是由哪种错误造成的（是初始化的问题或者界面的问题，还是其他的原因），错误是由于代码缺失还是代码错误造成的，defect是在老代码还是新代码中发现的, defect对于客户的影响有哪些有多大。找出了这些问题的答案，我们就可以改进我们开发和测试的有效性，增强产品模块的稳定性，更早的发现那些高风险的模块，最后使产品的每个版本都比上一个版本质量更好。
参考资料
|
|
|
冯涛 , IBM中国开发中心软件工程师 2005 年 11 月 Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。 Defect 分类帮助改进产品质量 软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。 图1
几种常见的defect 分类方法 在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。 图2 下面我们来看看几种我们常见的defect 分析方法： 按照defect 严重程度分类 我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图： 图3 在这个图中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 图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 从图5、图6中，我们可以了解到开发过程中哪个环节的错误比较多，例如图6中算法错误和功能性错误是最多的那么应该在单元测试或者code review中着重注意这两个部分的代码质量。另外从上图中我们也可以知道在哪以及如何来改正错误代码。 功能测试中应用ODC 下面我们来看看测试，在FVT（功能测试）中，一个主要的帮助FVT做得更好的指标是trigger, 在ODC中trigger可以简单的理解为是什么样的测试发现了这个defect。在FVT中我们定义了一下4个trigger：Coverage (这里的coverage不是我一般意义上理解的测试覆盖面的意思，它是指normal function, 是任何用户都会用到的功能，基本的、简单的功能)，Variation （对于有些对产品比较熟悉的用户，有可能会愿意用不常用的有创造性方法或者输入来完成同一种动作或者功能，或者单单就是为了挑错，在这些尝试中往往会发现很多漏掉的defect，例如'边界限制'），Sequencing (用和以前不同的操作流程来完成一种任务功能)，Interaction （当两个或者多个功能模块互相交互时可能会发生一些错误，例如同时启动一些功能时可能会造成系统死机）。 下面我们举例来看看FVT中按trigger分类的defect分布图： 图7 在图7中我们可以看到，这个产品中在一般的功能Coverage和改变操作顺序Sequencing的测试中发现了比较多的defect, 这说明了代码还需要作更多的单元测试来减少错误，从而我们可以了解到产品的基本质量水平。 图8 在图8中我们可以看到Coverage的错误很少，产品的基本质量是可以保证的；Variation的错误很多（看来测试组做了大量的这方面的测试），Sequencing 和 Interaction的错误也不少，那么后面的测试中应该加大这两块儿的测试。这里我们可以清楚地知道我们测了什么还有哪块需要加大测试力度。 图9 在图9中我们可以看到Variation的错误很多，那么加大单元测试的力度可以很好的解决这个问题，例如增加更多的边界检查。 系统测试中应用ODC 下面再让我们来看看SVT(系统测试)， 在系统测试中，ODC定义了另外一组trigger, 它们是：Blocked （有哪些defect阻止了SVT的执行， 最常见的是FVT的defect），Stress （压力测试的结果很可能是客户最关心的数据），Recovery (对于数据恢复和出错处理)，Restart (x系统的启动和重启)，Hardware configuration (硬件配置)，Software configuration (软件配置)。 下面我们举例来看看SVT中按trigger分类的defect分布图： 图10 在图10中我们看到了Blocked的defect太多了，显然这个时候进行大量的SVT测试是不明智的，那么应该让产品继续的进行功能测试，直到Blocked的问题减少到可以接受为止。 图11 在图11中，我们同样可以了解到SVT中进行了哪些测试，在这里软件配置测试和压力测试是需要加强的。 图12 在图12中，我们可以了解到硬件配置的defect比较多，那么我们应该要求开发人员更关注这部分的代码。 从上面的分析中我们看到了ODC中trigger告诉了我们哪里发现了问题，应该去做些什么。 ODC对于客户影响的应用 那么下面我们再来看看ODC怎么样的来影响客户。软件产品对于客户的影响有哪些方面呢？在ODC中定义了如下方面： 1. Installability 图13 这里图13是一个产品的defect 影响分布图, 我们可以看到这个产品有非常多的问题出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那么这样的产品如果卖给客户将是可怕的，那么我们就应该采取相应的动作来完善这几个方面的问题。 在ODC中，还定义了其他的元素来组合使用以帮助我们更好的了解问题出在哪里，同时帮助我们做出正确的决定。 在测试人员发现一个问题并且开一个defect时，需要给defect定义下面的属性： 1) Activity, 它是指在哪种测试中发现的defect, 例如：UT、FVT、SVT 等等。 2) Trigger, 问题出现的情况 3) Impact，影响客户的方面 当开发人员接到一个defect并且开始修改代码时，他需要定义下面的属性： 1) Target, 将要在哪里改正错误，例如：design、code 等等 2) Defect Type, defect的类型，例如：算法、初始化 等等 3) Qualifier: 只有三个，他们是missing、incorrect 和extraneous 4) Source: defect 的来源，例如：内部代码、outsource的代码等等 5) Age: defect是新代码还是重写的代码 具体可以参考下图： 图14
结束语 在项目和产品开发中，我们经常会想到这样的问题：我们的测试有多有效？单元测试、功能测试、系统测试都做得正确吗？我们怎样在需求、设计、开发阶段来减少潜在的defect呢？我们的代码已经完成并且准备好了进入到下一个阶段了吗？我们发现的defect有哪些是属于上一个版本的？客户将会感觉我们的产品质量怎么样呢？这些都是很关键的问题，需要我们改进开发和测试流程，使它们更加有效，从而进一步增强我们产品的质量。那么怎么样改进呢？通过ODC我们可以知道我们采用的哪种测试方法正在帮助我们找出更多的defect（是基本功能测试，还是边界条件测试或者压力测试），还有defect是由哪种错误造成的（是初始化的问题或者界面的问题，还是其他的原因），错误是由于代码缺失还是代码错误造成的，defect是在老代码还是新代码中发现的, defect对于客户的影响有哪些有多大。找出了这些问题的答案，我们就可以改进我们开发和测试的有效性，增强产品模块的稳定性，更早的发现那些高风险的模块，最后使产品的每个版本都比上一个版本质量更好。
参考资料
|