UML软件工程组织

 
更多技术资源 文章，讲座 ,培训，咨询 请访问 www.uml.org.cn

 
采用ODC改善软件质量：一个案例研究
 
作者:Yang Gu 出处:IBM
 
本文内容包括:
本文来自于 Rational Edge：通过测试人员在软件开发整个生命周期中揭示的一些缺陷，向测试团队提供更加详细的缺陷信息，看看正交缺陷分类或者ODC是如何提高软件质量的。

高性能软件通常是很难产生的，现在的迭代化开发实践对瀑布式方法有了巨大的改善，然而当通过测试工具分析代码时，许多相当好的测试方法却只产生了一些缺陷记录。通过这些简单的记录，很难确定软件的适用性、设计文档的适宜性、代码的效率以及顾客的满意度。

在过去的几年里，我已经通过在Rational环境中加入一种额外的测试技术改善了这种情况：ODC，其表示“正交缺陷分类”。它是缺陷分析一个革命性的方法，在充实了记录的内容同时提供了一个系统的分析方法，可以追溯到缺陷的开发阶段。ODC能够提高测试的效率，监控质量状态，向开发者提供改进的线索，同时有助于评估顾客的满意程度。

在这篇文章中，我将和大家一起分享我在一个使用Rational开发环境的软件项目中采用ODC方法的经验。我们将看到ODC可以给我们带来的许多好处，同时我将向大家提出一些关于实现ODC的建议。

软件开发中典型的质量问题

究竟有多少缺陷？我们怎样才能区分这些缺陷？通常情况下，我们可以收集尽可能多 的缺陷并将它们按照“严重程度”和“优先级”进行分类。因此我们可能在相同的严重程度和优先级发现几百个缺陷情况，对于相同的缺陷我们的测试可能产生一百个实例。这些过于简单的缺陷属性不足于进行高质量的分析，原因有以下几点：

  • 首先，我们不知道每个缺陷引起的原因。术语“严重级别”和“优先级”的描述性并不很强，因此它们对开发团队的帮助并不是很大。这里并没有帮助开发者来理解缺陷原因的方法，他们只能通过手工搜索这些缺陷的脚本来给他们定位。
  • 第二，我们无法评估这些员工的工作效率。在一天内发现100多个严重程度为1的缺陷的人就是这个团队最优秀的测试员吗？即使这些缺陷都代表相同的问题。
  • 第三，一个迭代或者阶段的退出标准不完全。也就是说，因为我们不清楚每个缺陷的“类型”每个阶段退出标准只能建立在全面通过率的基础上。当然 ，如果我们不知道关于这些缺陷更多的属性，我们可以在适当的时间查看合适的缺陷。
  • 第四，这里并没有描述用户感情的缺陷，因此开发者根本不知道顾客的满意水平，一直到发布以后。

事实上，我们需要更多的属性来描述缺陷，并且需要一个相应的方法来分析这些额外的属性。这些属性与开发者和测试人员相关，与开发阶段相关，与顾客的满意程度也相关。通过分析这些属性的结果可以提高软件的质量，这是ODC的承诺。

什么是ODC？

ODC在高层次上，是帮助获取缺陷信息的一个缺陷分类方案。但是它不仅仅是一个分类方案，ODC是一个软件过程的度量系统，它是建立在包含于缺陷流中的语义信息基础上的。它可以帮助我们评估测试的效力和效率，可以进行错误跟踪，通过方案背后的分析机制评估顾客的满意度。

在这个简单的术语中，ODC为测试人员的记录定义了一组缺陷属性。同时为分析这些缺陷提供了一组经验性的规则。然后，可以根据这些分析，对提高软件质量采取正确的措施。

在以下一个或者多个条件下，ODC是十分有用的：

  • 开发生命周期相对来说是一个很漫长的过程，包括后续的改进工作。例如，这个项目包括多个软件版本或者一个版本有多次迭代。
  • 潜在的缺陷数目是相当大的。缺陷数目越多，客观的分析结果也越多，对我们了解软件质量越有好处。
  • 这个项目已经将“高质量”设定为它的主要目标之一。

ODC通过搜集有用的信息丰富了缺陷的属性。ODC一共有8个属性，如图1所示。当一个测试人员发现并提交一个缺陷时，他可以给这个缺陷分配“活动（Activity）”、“触发（Trigger）”、“影响（Impact）”这三个属性。当一个开发人员修复或者回应了一个缺陷时，他可以分配“阶段（Age）”、“来源（Source）”、“限定符（Qualifier）”、“类型（Type）”以及“目标（Target）”这些属性。下面将介绍这些不同的属性。

figure 1

图1：ODC的八个属性.来源： ODC v5.11, IBM 软件工程中心, www.research.ibm.com/softeng.

在ODC活动中，这个测试人员就是“ODC提交者”或者“ODC打开者”，我们称呼开发人员为“ODC回应者”或者“ODC关闭者”。对这八个属性的分别介绍如下所示：

  • 活动就是当缺陷被发现时实际的处理步骤（代码审查，功能测试等等）。
  • 触发 描述了暴露缺陷时存在的环境或者条件。
  • 影响 就是对用户或者是认识到的，或者是实际的影响。
  • 目标 表示被修复实体的高层特性（例如，设计，代码，ID，等等）。
  • 类型 表示所进行的实际修正的种类。
  • 限定符 指明了所进行的修复应归于缺失，错误或者还是外来的代码或者信息。
  • 来源 指明了发现的缺陷是出现在内部代码编写中，重用自一个程序库中，从一个平台转移到另一个平台上的，或者是外包一个软件销售商的。
  • 阶段 确定可拥有这个缺陷目标（比如设计，代码，ID等等）历史。

现在，ODC是由IBM Rational ClearQuest (RCQ)和Jmystiq支持的。2 我们可以将特殊的ODC属性合并到RCQ 窗口和制表符中去。图2显示了我们将ODC用户化以后的一个RCQ窗口。“ODC Submitter”和“ODC Responder”是两个集成ODC八个属性信息的标签。与ODC中独创的属性一起，我们同时可以获得大量需要通过Jmystiq分析的资源，这些资源可以使ODC的分析变得更容易。

figure 2

图2：一个在定制ODC后的Rational ClearQuest窗口。“ODC Submitter”和“ODC Responder”是收集ODC八个属性信息的两个页签

我们的案例项目的背景

我们的项目是一个典型的基于J2EE portal 技术的Web应用。这个项目属于中等规模，大约由86,000行Java代码和14,000行Java Server Pages代码组成。这个项目使用了典型的迭代开发模式，并在最终版本之前包含多个迭代，如图3所示。在这个项目上我们已经设置了相当高的质量目标。

figure 3

图3：案例项目中使用的迭代模式

这个项目包括十五个开发人员和测试人员，各自分成两个团队。在每一个开发阶段，主要的角色要承担的主要的责任也不相同。表1中显示了这个项目开发的阶段和相应的责任人，同时也包括最初在采取ODC方法之前的退出标准。

Table 1: Activities, owners, and exit criteria for stages of an iteration in a typical software development project.
活动 负责人 产生缺陷 退出标准
需求管理 负责人 No 　
代码实现 开发者 No 　
单元测试 开发者 Yes (ClearQuest) 所有单元测试用例都通过。
代码审查 开发者 Yes （ClearQuest） 所有代码评审检查单中的规则都通过。
功能测试 测试者 Yes （ClearQuest） 95% 测试用例通过。没有严重程度级别 1 和 级别 2 未被修复的缺陷存在。
系统测试 测试者 Yes （ClearQuest） 95% 测试用例通过。没有严重程度级别 1 和 级别 2 未被修复的缺陷存在。
用户验收测试 用户 Yes （ClearQuest 和 Notes 数据库） 没有严重程度级别 1 和 级别 2 未被修复的缺陷存在。

你如何采用ODC？

ODC有它自己的生命周期，我们可以将它整合到迭代软件开发的生命周期中去。随着迭代的进行，我们可以监控每个开发阶段的软件质量状况。如果在我们的ODC分析结果中发现异常情况，我们可以采取纠正或者预防措施。

如图4所示，ODC的生命周期包括六个步骤，由三个可能的角色，三个循环来实施，这将取决于所需的ODC步骤的数量。我将详细阐述下面的这些概念。

Figure 4

图4：通过三个不同颜色标明的角色实现六个ODC步骤

三个角色

ODC生命周期包括三个不同的角色：

  • 团队成员：这是ODC中最普通的角色。团队成员就是开发者，测试人员或者用户，他们负责输入数据。
  • ODC核心：这个角色是一个ODC专家，其熟悉ODC的执行，并且可以帮助项目团队进行正确的计划和分析工作。ODC核心人物可以来自项目团队的外部。
  • ODC的特殊团体：ODC的特殊团体负责活动计划的创建、确认以及评估。这个团体是由来自不同团队的人员组成的团队。

三个循环

根据ODC所需的步骤的数量，它有三个可能的循环:

  • 大循环：除了预备步骤，这个循环本身含有五个步骤。IDC计划步骤与ODC的评估是相关联的，并且它可以使评估更加有效。
  • 中等循环：它包含四个步骤，这几个步骤是ODC生命周期中的核心组成部分。尽管完整的ODC评估在这个循环中是不能得到的，一些有用的评估是可以被执行的。
  • 小循环：这个循环包含两个步骤。也就是说只要找到一定数量的缺陷，随时可能发生确认的活动。

ODC的实现：六个步骤

这篇文章中我将阐述一个完整的大循环。通常循环中的一个步骤被看作是下一个步骤的基础，上一个步骤的输出是当前步骤的输入。除了预备步骤，其他四个步骤形成一个支持迭代软件开发的循环。

步骤1：预备阶段

第一个步骤是十分重要的，对于那些以前没有采用ODC的团队来说尤其关键。在这个步骤中，我们需要做的事包括：

  • 获得采取ODC方法操作的批准和支持
  • 采取ODC，要获得开发团队和测试团队的允许
  • 找到一个ODC的中心人物，邀请他/她提供一些ODC培训和指导。
  • 调查项目当前的状况。比如，当前的开发生命周期是什么？用什么工具来进行缺陷跟踪？如果这不是一个新项目。你应该考虑使用历史数据的方法
  • 给开发人员和测试人员指派ODC角色。这将有助于决定谁来负责计划，执行确认，执行评估以及制作活动计划。注意这些人应该包含ODC特殊团队的成员。
  • 在一个缺陷跟踪工具上部署ODC计划，比如Rational ClearQuest
  • 指导两轮内部培训：一轮是关于ODC基本概念的培训，另一轮是数据输入和确认标准的培训。在我们的案例项目中，我被邀请作为ODC的核心人物，同时也是开发团队的成员。两个ODC特殊团队的人，一个来自开发团队，另一个来自测试团队。我们请我们Clear Quest团队来帮我们部署ODC计划。两轮内部培训之后，我们的ODC开发就正是开始了。

步骤2：计划

计划步骤的主要任务是定义“来源”，它在随后的数据输入步骤中将会用到。这个步骤中产生的信号对评估退出标准是十分关键的。

在这个步骤中我们需要做的事包括以下几个方面：

  • 确定阶段属性：“阶段（Age）”缺陷属性有三点：新的（New）、基础（Base）、重写（Rewritten）。“新的”表示最近增加的代码。“基础”表示来自最后一个版本或者最后一次迭代的旧代码。“重写”表示已经被测试但是修改过的代码。如果是一个全新的项目，那么所有部分的代码都是新的。
  • 将项目分成组件：为了分析缺陷以及跟踪到开发阶段，我们应该将这个项目划分成几个组件。然后我们可以跟踪缺陷到一些组件而不是整个程序阶段。所有的资源包括代码，文档和配置文档都应该划分成几个组件。你可以根据功能名称，物理位置或者逻辑关系来创建这些组件。
  • 为ODC的评估决定项目检查点：在项目整个生命周期中的所有阶段中，你应该计划做两次或者三次评估。比如，你可以在功能测试之后做评估，或者在UAT（用户接受测试）后做。你执行ODC评估的检查点和检查时间将影响软件质量的提高和效率。
  • 确定你正在使用的开发模式：你当前所使用的开发模式将决定所需要的识别标志的数量。例如，如果你使用的是迭代开发模式，那么识别标志就会被两种方式其中的一种所控制。一种识别标志代表完整的过程，另一种表示每一次迭代。
  • 创建计划文档: 一个ODC计划应该包括记录资源分配，工作进度以及评估步骤。
  • 评审ODC计划：在你正式开始之前，了解每个步骤资源分配是否平衡是十分重要的。更好的平衡就会得到更好的质量提高。

在我们的案例项目中，我们确定使用30％的阶段属性是基础代码，70％的是新代码。我们将项目按照功能中的逻辑关系划分为十二个组件，并使用ODC信号模板编辑ODC计划文档。对这个文档进行几次评审以后，我们准备进入下一个步骤，数据输入和确认。

步骤3和4：数据输入和确认

我们可以将这两个步骤合并成一个步骤。这里的主要目的是提供一套可靠而且准确的缺陷数据记录。

以下几点是这两个步骤中要特别注意的事项：

  • 在数据输入之前，确保所有的开发人员和测试人员都清楚地了解每个属性的含义。
  • 在数据输入过程中，数据的格式应该由工具来控制。这些程序应该与缺陷状态的转换保持一致。
  • 数据输入以后，需要一个完全的确认。这个确认过程可以由人工的方法来实现，也可以由自动操作来完成。过程内的 人工数据的有效性对于输入数据的正确性十分关键。

在我们的案例项目中，我们使用Rational ClearQuest来采集数据输入，并通过创建一些逻辑关系使用Jmystiq来实现自动确认。另外我们还创建一个特殊的指导方针确保所有的开发人员和测试人员理解这些属性的意义。

步骤5：评估

这是一个收获的步骤，收集到如此多优良的数据以后，你可以生成一个结果用来以下几种方法来分析:

  • 选项1：利用Jmystiq生成一个分析序列
  • 选项2：生成一个ODC“退出评估报告”，并从它开始分析
  • 选项3：为这个项目生成并选择一些有意义的图表

在开发生命周期的任何时候都可以进行评估。我们利用Jmystiq为评估产生一些图表。当在图表中发现不正常的现象时，我们可以设法从不同的方面来对它作出解释。下面我将展示一些这种评估工作的例子。

样例1：Opendate里的触发

在我们的案例项目中，当绘制“Opendate内部触发的总次数”图表（参见图5）时，我们可以发现在功能测试阶段之后出现了一些覆盖缺陷。造成这种缺陷可能有两种原因。原因之一是测试效率不够高，原因之二是重新修复或重写代码不够理想。因此接下来在我们不得不研究“触发与组件”以及“限定符与组件”的图表，从而找出真正的原因。

figure 5

图5：我们可以看到一些覆盖缺陷（灰色标明的）是在功能测试之后发生的

样例2：阶段中的触发

当我们绘制“阶段（Age） 内部触发的总次数”的图表(图6)时，发现基础缺陷的比例相当大。另外两张图表“组件与活动”和“组件与阶段”是确定相关原因的。如果我们在同一个组件同时发现了有新代码的缺陷和有基础代码的缺陷，那么这些缺陷反映的是最近附加代码。这是造成这种现象最常见的原因。否则，这个问题就可能属于无效的测试用例。

figure 6

图6：大量的基本缺陷应当进行进一步的调查研究。

样例3：活动内部的触发（Trigger）

当我们检查“活动内部的触发完全次数”图表（图7）时，发现在功能测试阶段，覆盖与变体占主要地位。这可能标明单元测试或者详细的计划不够充分，或者原计划的综合测试用例不够充分，测试人员仅仅关注于基本功能要点

figure 7

图7：在功能测试阶段，覆盖和变体占主导地位。

步骤6：活动

活动是最后一个步骤，这个时候应该设计一个正式的活动计划，这个计划能够帮助我们不断地提高软件质量。这个活动计划包括来自设计文档的材料，特殊代码组件，开发步骤或者测试方法。但是最重要的部分是下一次迭代或者下一次发布所要采取的活动。这些活动的目标必须清楚而且是可度量的。紧记下一个阶段中出现的问题往往是先前步骤中的错误导致的。

ODC分析案例

我们的项目有三个质量目标：及时递交产品，确保发布之前没有我们没有发现的缺陷以及达到顾客的高度满意。在这个部分我将展示几个真实的案例，它们可以证明ODC是如何帮助我们实现这些目标并提高软件质量的。

使用ODC提供更好的退出标准

我们的开发生命周期包含了几个连续的阶段。每个阶段有它自己的退出点，它们是根据预先确定的退出标准来评估的。为每个阶段设置准确而详细的退出标准对于管理整个开发进度表是十分重要的。在采用ODC之前，我们每个阶段的退出标准仅仅是根据测试用例的通过率来决定的。这虽然合理，但是并没有更详细的颗粒度。

有了ODC，我们可以根据不同的情形为每一个阶段编制退出标准，它允许我们在适当的时候查看更详细的缺陷情况。这样做，我们可以为以前的阶段增加附助的标准，比如，“严重级别为1和2 的未确定缺陷是集中的或者是复杂的缺陷，我们就可以退出。”

利用ODC来评估设计和代码的充分性

当我们遇到一个质量问题，我们需要了解这个问题存在于设计中还是编码中。ODC在缺陷的记录中提供了两个属性，我们可以根据这个记录跟踪原因一直到高水平的设计，低水平设计或者代码中。

第一个属性是“缺陷类型（Defect Type）”，它详细说明了这个问题是否是与设计相关的。在图8中，它用图说明了缺陷类型与时间的关系，我们可以看到缺陷的不同类型，比如分配、校验、运算法则以及打包。但是我们看不到任何带有类型功能的缺陷。从ODC的原则看，这意味着高水平的设计是充分的。我们也可以看到有太多 Algorithm 类型的缺陷，这意味着低水平的设计还需要改进。

figure 8

图8：太多 Algorithm 类型的缺陷意味着低水平的设计需要改进。

另一个有用属性是“限定符（Qualifier）”，图9的图表详细标明了“缺陷类型中限定符的总次数”。它表明这个问题是否由代码造成的。在图9中我们找到几个限定符：错误的（incorrect）、丢失的（missing）以及外来的（extraneous）。丢失的表明代码本应在那现在却不在。错误的表明代码存在，但是编写得不正确。在这个案例中，由于我们已经找到了很多带有分配类型和运算法则类型的不正确的代码，我们得知这个代码编写得很糟糕。大量带有类型运算法则的丢失的缺陷反映了对详细设计的误解的问题。（我们会在下一个缺陷类型与组件图表中获得更多的详细情况）

figure 9

图9：大量的带有分配类型和运算法则类型的错误代码表明这个代码编写得很糟糕。

用ODC评估测试的效率

测试效率对于确保产品质量是十分重要的。采用ODC之前，我们只是简单的依赖执行的测试用例来评估这个测试效率，但是这并不是一个很客观的度量。ODC提供了触发和阶段两个属性来帮助我们跟踪这个目标一直到开发生命周期不同的测试阶段。

每个触发都归属于某个特定的活动。缺少任何触发意味着在相关活动中的测试不够充分。在图10中，我们可以看到在GUI评审活动中丢失了两个触发：输入设备和Widget/GUI行为。由于我们的项目提供了一个用户界面，这两个触发是必需的。

figure 10

图10：我们观察到在GUI 评审活动中丢失了两个触发：输入设备和Widget/GUI行为

我们重新看一下图4，由于原计划是由计划编制阶段的识别标志而产生的。在图11中，我们可以看到原计划与实际过程中存在的重大差异。首先，在实际过程中相互作用的比例比原计划中的要少。这意味着我们在集成测试用例中要花费更多的精力。其次，变体现象在实际过程中占着主要的地位。由于当前阶段不正常的现象反映了先前阶段缺陷的问题，因此我们要通过单元测试来检查其过程。最后，我们发现分界线和二者选一的单元测试是不够充分的，同时我们还发现基本输入类型的确认不够完善。

figure 11

图11：原计划方案与实际过程中存在着差异

在前面我对基础（Base）和新的（New）的概念做过解释。在图12中我们可以看到基础缺陷的百分比比新缺陷的高。这种现象可能表明先前的版本的测试不够充分，我们应该对基础代码进行回归测试。在图12中我们还看到一些重写和重新修复的缺陷。这可能表明重写和重新修复的过程完成地不够好。

figure 12

图12：基础缺陷的百分比比新缺陷的高，这种现象可能表明先前的版本的测试不够充分，我们应该对基础代码进行回归测试。

用ODC评估缺陷修复的效率

有时候我们发现测试时间表会被延迟。我们可以通过严重级别的属性来找到原因。

严重程度较大的缺陷需要分配更高的优先权。在图13中，我们可以看到一些严重程度高的缺陷需要花费很多时间来关闭。

figure 13

图13：通过描绘缺陷“严重级别”与关闭“时间”关系的图表，我们可以看到一些严重水平为1 的缺陷已经花时间解决了

ODC可被作为一种控制产品状态的途径

在使用ODC之前，我们根据缺陷严重水平来评估产品的质量，而且只能近似估计产品总体质量。使用ODC以后我们可以针对详细的质量相关特征做出可靠的定量分析，从而推断我们产品质量的状况。这些结果是十分客观的。

图14图示是一个典型的“Opendate内的限制符总次数”的图表。根据经验我们估计丢失缺陷的比例应该在30％和40％之间，我们看到图示显示的丢失缺陷的百分比是35％，恰好在我们预计范围之内。但是在后来的阶段中仍然发现一些丢失的缺陷，因此我们应该找出此原因。

figure 14

图14：在后来的阶段中仍然发现一些丢失的缺陷

使用ODC突出显示涉众关注点中的不匹配

我们质量的目标是给顾客很高的满意度。在采用ODC之前我们不能清楚地确定开发者与顾客之间关注点的不匹配。ODC的属性影响力可以帮助我们收集关于用户满意度的信息，并找出顾客真正关注的焦点。

在图15中，我们可以看到我们顾客关注的焦点是可用性。但是在图16中，它反映开发生命周期中的状况，我们发现我们并没有充分关注可用性的测试。我们还看到大量的请求缺陷。这可能导致进度的延迟，因为新的请求必须进入测试阶段。

figure 15

图15：很明显，顾客关注度最高的是可用性

figure 16

图16：但是事实上，我们关注更多的是性能，而对于需求的关注几乎忽略了。

行动计划以及ODC各阶段的建议

从ODC的分析，可以发现我们开发生命周期中的优势和难点，然后采取活动并改进。

行动计划

我们的行动计划有十二个具体的步骤，如下所示：

  1. 进行培训来提高JavaServer Faces (JSF)/JSP技巧，因为绝大多数缺陷都位于UI组件。（请看图8）
  2. 为具体的设计做一个模板，使其具有更多相关可选择的通道（请看图8和图9）。
  3. 设计并执行关于的输入设备和 Widget/GUI 行为测试用例（请看图10）。
  4. 制定一个输入确认的清单，它包括对精确数值、浮标、文本、数据等的确认（请看图11）。
  5. 精心处理“单元测试执行”过程来确保单元测试的效率（请看图12）。
  6. 对测试用例进行分类和分析，确保良好触发的范围，尤其是集成测试用例（请看图11）。
  7. 通知测试团队及时改写代码（请看图12）。
  8. 精心处理“缺陷修复”过程从而避免重新修复的缺陷（请看图12）。
  9. 对组件进行回归测试，它是重写缺陷和基础缺陷集合而成的（请看图13）。
  10. 更多得关注严重级别高的缺陷，无论我们对缺陷进行修复还是核查（请看图13）。
  11. 将功能测试阶段延长一周，因为在随后的阶段发现的遗失缺陷位于一些重要的功能区域（请看图14）。
  12. 草拟一个提高产品在页面设计、页面流程、功能性、重新组织等等方面可用性的计划（请看图15和图16）。

采用ODC的建议

这里我将对 ODC使用过程的各个阶段提一些建议。

计划编制阶段

  • 识别标志正确但是并不精确。我们可以求助一个对每个活动（触发）都很熟悉的人来帮助完成分配的任务。
  • 我们应该清楚地了解该采取哪种活动以及活动的顺序是什么，因为它并不反映报告结果。

数据输入阶段

  • 一个新的需求通常是来自于市场，用以寻求他们认为顾客想要的一个新功能。我们通常不提交可用性的需求。
  • 我们带着特殊的使命来执行单个的活动。比如，当我们在功能测试阶段发现一些UI问题时，我们怎样来为这个缺陷选择具体的活动呢？如果要想那个功能测试包含GUI测试，我们依然要对这些活动像功能测试一样进行分类并。重要的是打开并对这个缺陷进行分类的人需要考虑分是，当他们没有发现这个缺陷时他们实际上想要执行的是什么活动。
  • 如果有一个与我们工作相关的活动，我们应该将它与其他活动区分开来。比如，恰巧在功能测试阶段发现了GUI活动，我们将会对GUI进行测试。这个在GUI测试中发现的缺陷活动被看作是GUI。
  • 怎样区别作用范围和变体？这取决于发现这个缺陷在一个测试用例中还是两个测试用例中？如果功能点在一个测试用例中是好的，而在另一个测试用例中失败了，那么关于这些功能要点的缺陷将被看作变体缺陷而提交。
  • 当一个测试人员提交了一个缺陷，他或她应该输入清楚的、详细的而且正确的描述字段。同样当一个开发人员解决了一个缺陷，他/她应该输入清楚的、详细的而且正确的字符字段。因此ODC集中要点，基于输入的数据做出正确的确认。
  • 当提交一个顾客缺陷时，这个输入顺序可能就域缺陷处理顺序不一样了。触发属性将在活动属性之前输入。
  • Web应用的一些输入提示仅仅是：当Web King发现了缺陷，这个活动就是Code Inspector，触发是Design Conformance，影响是Standard。如果Home Page Reader这个缺陷，活动是GUI Review，触发是Design Conformance，影响是Accessibility。如果这个缺陷出现在联机帮助、错误信息或者屏幕信息，那么活动就是Documentation Review。

确认阶段

  • 所有关于数据输入的提示都是合适的。
  • 任何单个属性值的主导地位都可能引起更深入的研究.

评估阶段

  • 评估的主要观点来自于随后的分析阶段发现的任何属性的主要字段，异常的百分比或数量的趋势和一些种类的缺陷（比如丢失的、覆盖等等）。
  • 如果这个综合缺陷的百分比不是这样高，或许是件好事。我们只要提前开始采取活动。我们可以比较其它触发之间的比率来决定这个现象。
  • 我们可以查看无效的缺陷，它们可以帮助我们确定将来可能发生在培训或者理解中的差距。
  • 覆盖和变体是很简单的，单个的功能测试；先后顺序，交互关系，以及系统测试触发都是复杂的测试场景。
  • 缺陷的分配很大程度上受到顺序、范围和执行活动的精确度的影响。

总结

我一直专注于ODC实现方法来提高软件质量。除此之外，以上给出的一些指导方针，几个具体的要点需要关注：

  • 开始阶段的培训活动对成功执行ODC是十分重要的。错误理解ODC概念将导致偏差。
  • ODC的目标不仅仅是收集数据而是找到发展趋势。
  • ODC本身是一个迭代过程可以帮助你不断提高软件质量。

就我的经验而论，ODC能够帮助开发人员和测试人员更好的合作。更重要的是，ODC可以帮助我们提高开发和测试的效率和效力。这些对质量的提高都十分关键。

这里展示的范例是用来论证怎样将ODC整合到软件项目中的。无论你的项目是什么类型，无论你当前面临的是哪个开发阶段，你都可以立即开始使用ODC。我相信只要你按照这篇文章中的指导方针来制定具体的数据，就可以看到很大的改进。

注释

1 Ram Chillarege 等人。“正交缺陷分类－－一个过程中测量的概念”，软件工程的IEEE会报，1992年11月，编号11，第18卷。

2 JMYSTIQ （Java－－管理你的软件并提高质量）是一个来自软件开发和服务，用来进行分析缺陷数据的用户友好的Java工具。它是组织使用ODC（正交缺陷分类）和OPC（正交问题分类）方法所必需的工具，用来获取缺陷信息。查看 https://www.ibm.com/ibm/cas/archives/2004/demos/ 获得更多的信息

参考资料

  • ODC基本概念：http://w3.research.ibm.com/softeng/ODC/DETODC.HTM

    Jmystiq的帮助系统。

    M. Butcher，H. Munro，T. Kratschmer，“通过ODC改进软件测试：三个案例研究”。IBM 系统刊物，2002年，编号1，第41卷。

    Ram Chillarege 和 Kothanda Ram Prasad，“测试与开发过程的回顾―――使用ODC触发的个例研究”

    Kathryn Bassin，“软件开发中的监测与评估”。

    Ram Chillarege，Inderpal S. Bhandari，Jarir K.Chaar，Michael J. Halliday，Diane S. Moebus，Bonnie K. Ray，Man-Yuen Wong，“正交缺陷分类－－一个过程中度量的概念”软件工程的IEEE会报，1992年11月，编号11，第18卷。

    Ram Chillarege 和 Shriram Biyani，“使用ODC基础增长模式鉴定风险”

    Diane Kelly 和 Terry Shepard，“缺陷分类与审查中的一个案例研究”

  • 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  • 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号