当前位置:首页 >> 信息与通信 >>

5.1 IBM ODC


高性能软件通常是很难产生的,现在的迭代化开发实践对瀑布式方法有了巨大的改善,然而当通过测试工具分析代码时,许多相当好的 测试方法却只产生了一些缺陷记录。通过这些简单的记录,很难确定软件的适用性、设计文档的适宜性、代码的效率以及顾客的满意度。
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 支持的。2 我们可以将特殊的 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 方法之前的退出标准。 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 步骤的数量。我将详细阐 述下面的这些概念。

图 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)时,我们可以发现在功能测试阶段之后出现了一些覆盖缺 陷。造成这种缺陷可能有两种原因。原因之一是测试效率不够高,原因之二是重新修复或重写代码不够理想。因此接下来在我们不得不 研究“触发与组件”以及“限定符与组件”的图表,从而找出真正的原因。

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

图 6:大量的基本缺陷应当进行进一步的调查研究。 样例 3:活动内部的触发(Trigger) 当我们检查“活动内部的触发完全次数”图表(图 7)时,发现在功能测试阶段,覆盖与变体占主要地位。这可能标明单元测试或者详细的 计划不够充分,或者原计划的综合测试用例不够充分,测试人员仅仅关注于基本功能要点

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

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

使用 ODC 提供更好的退出标准
我们的开发生命周期包含了几个连续的阶段。每个阶段有它自己的退出点,它们是根据预先确定的退出标准来评估的。为每个阶段设置 准确而详细的退出标准对于管理整个开发进度表是十分重要的。 在采用 ODC 之前,我们每个阶段的退出标准仅仅是根据测试用例的通过 率来决定的。这虽然合理,但是并没有更详细的颗粒度。 有了 ODC,我们可以根据不同的情形为每一个阶段编制退出标准,它允许我们在适当的时候查看更详细的缺陷情况。这样做,我们可以 为以前的阶段增加附助的标准,比如,“严重级别为 1 和 2 的未确定缺陷是集中的或者是复杂的缺陷,我们就可以退出。”

利用 ODC 来评估设计和代码的充分性
当我们遇到一个质量问题,我们需要了解这个问题存在于设计中还是编码中。ODC 在缺陷的记录中提供了两个属性,我们可以根据这个 记录跟踪原因一直到高水平的设计,低水平设计或者代码中。 第一个属性是“缺陷类型(Defect Type)”,它详细说明了这个问题是否是与设计相关的。在图 8 中,它用图说明了缺陷类型与时间的关 系,我们可以看到缺陷的不同类型,比如分配、校验、运算法则以及打包。但是我们看不到任何带有类型功能的缺陷。从 ODC 的原则看, 这意味着高水平的设计是充分的。我们也可以看到有太多 Algorithm 类型的缺陷,这意味着低水平的设计还需要改进。

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

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

用 ODC 评估测试的效率
测试效率对于确保产品质量是十分重要的。采用 ODC 之前,我们只是简单的依赖执行的测试用例来评估这个测试效率,但是这并不是一 个很客观的度量。ODC 提供了触发和阶段两个属性来帮助我们跟踪这个目标一直到开发生命周期不同的测试阶段。 每个触发都归属于某个特定的活动。缺少任何触发意味着在相关活动中的测试不够充分。在图 10 中,我们可以看到在 GUI 评审活动中 丢失了两个触发:输入设备和 Widget/GUI 行为。由于我们的项目提供了一个用户界面,这两个触发是必需的。

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

图 11:原计划方案与实际过程中存在着差异 在前面我对基础(Base)和新的(New)的概念做过解释。在图 12 中我们可以看到基础缺陷的百分比比新缺陷的高。这种现象可能表 明先前的版本的测试不够充分,我们应该对基础代码进行回归测试。在图 12 中我们还看到一些重写和重新修复的缺陷。这可能表明重写 和重新修复的过程完成地不够好。

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

用 ODC 评估缺陷修复的效率
有时候我们发现测试时间表会被延迟。我们可以通过严重级别的属性来找到原因。 严重程度较大的缺陷需要分配更高的优先权。在图 13 中,我们可以看到一些严重程度高的缺陷需要花费很多时间来关闭。

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

ODC 可被作为一种控制产品状态的途径
在使用 ODC 之前,我们根据缺陷严重水平来评估产品的质量,而且只能近似估计产品总体质量。使用 ODC 以后我们可以针对详细的质 量相关特征做出可靠的定量分析,从而推断我们产品质量的状况。这些结果是十分客观的。 图 14 图示是一个典型的“Opendate 内的限制符总次数”的图表。根据经验我们估计丢失缺陷的比例应该在 30%和 40%之间,我们看到图 示显示的丢失缺陷的百分比是 35%,恰好在我们预计范围之内。但是在后来的阶段中仍然发现一些丢失的缺陷,因此我们应该找出此原 因。

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

使用 ODC 突出显示涉众关注点中的不匹配
我们质量的目标是给顾客很高的满意度。在采用 ODC 之前我们不能清楚地确定开发者与顾客之间关注点的不匹配。ODC 的属性影响力 可以帮助我们收集关于用户满意度的信息,并找出顾客真正关注的焦点。 在图 15 中,我们可以看到我们顾客关注的焦点是可用性。但是在图 16 中,它反映开发生命周期中的状况,我们发现我们并没有充分关 注可用性的测试。我们还看到大量的请求缺陷。这可能导致进度的延迟,因为新的请求必须进入测试阶段。

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

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

行动计划以及 ODC 各阶段的建议
从 ODC 的分析,可以发现我们开发生命周期中的优势和难点,然后采取活动并改进。

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

1.

进行培训来提高 JavaServer Faces (JSF)/JSP 技巧,因为绝大多数缺陷都位于 UI 组件。(请看 图 8) 为具体的设计做一个模板,使其具有更多相关可选择的通道(请看图 8 和图 9)。 设计并执行关于的输入设备和 Widget/GUI 行为测试用例(请看图 10)。 制定一个输入确认的清单,它包括对精确数值、浮标、文本、数据等的确认(请看图 11)。 精心处理“单元测试执行”过程来确保单元测试的效率(请看图 12)。 对测试用例进行分类和分析,确保良好触发的范围,尤其是集成测试用例(请看图 11)。 通知测试团队及时改写代码(请看图 12)。 精心处理“缺陷修复”过程从而避免重新修复的缺陷(请看图 12)。 对组件进行回归测试,它是重写缺陷和基础缺陷集合而成的(请看图 13)。

2. 3. 4. 5. 6. 7. 8. 9.

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。我相信只要你按照这篇文章中的指导方针来制定具体的数据,就可以看到很大的改进。

ODC(Orthogonal Defect Classification)简介

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 2. Security 3. Performance 4. Maintenance 5. Serviceability 6. Migration 7. Documentation 8. Usability 9. Standards 10. Reliability 11. Requirements 12. Capability

图 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 对于客户的影响有哪些有多大。找出

了这些问题的答案,我们就可以改进我们开发和测试的有效性,增强产品模块的稳定性,更早的发现那些高风险的模块,最后使产品的 每个版本都比上一个版本质量更好。

参考资料
? ?
ODC official website:http://www.research.ibm.com/softeng/ODC/ODC.HTM A Comparison of IBM's Orthogonal Defect Classification to Hewlett Packard's Defect Origins, Types, and Modes. Jon T. Huber, 1999.

?

Improving software testing via ODC: Three case studies. M. Butcher, H. Munro, T. Kratschmer. IBM SYSTEMS JOURNAL, VOL 41, NO 1, 2002

?

Orthogonal Defect Classification: A Concept for In-Process Measurements. Ram Chillarege,etc. IEEE Transactions on Software Engineering, Vol 18, No. 11, Nov 1992.


相关文章:
更多相关标签: