采用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）”这些属性。下面将介绍这些不同的属性。

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

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

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

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

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

我们的案例项目的背景

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

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

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

你如何采用ODC？

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

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

图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为评估产生一些图表。当在图表中发现不正常的现象时，我们可以设法从不同的方面来对它作出解释。下面我将展示一些这种评估工作的例子。