在软件项目中,缺陷是衡量软件质量和测试工作的一个重要参数,而对于缺陷的分析则是度量测试过程是一个很重要的环节。在测试过程中,通过对缺陷的有效分析而得到的度量结果,对于改进测试过程、提高软件质量都有着重大意义。IBM
Rational ClearQuest 作为 IBM Rational 家族的核心产品之一,提供了包括缺陷数据的管理服务在内的强大的软件项目全方位管理平台,并且能够基于数据自动生成多种图表报告,为项目提供全方位、全过程的支持。基于此,本文介绍了如何根据项目需求应用
IBM Rational ClearQuest 创建缺陷报告图表,并通过分析缺陷报告对测试过程进行有效的度量,从而帮助项目和测试过程的管理做出科学的决策和改进。
从当今软件技术的发展趋势来看,软件开发的首要问题更多的集中在管理问题而不是技术问题上,而如何对软件开发进行有效的控制,提高软件的质量很大程度上取决于对其开发和测试过程的度量、分析以及改进。通过软件度量可以改进软件开发过程,促进项目成功,开发高质量的软件产品。度量的取向是软件开发诸多事项的横断面。由于在软件项目中,缺陷是衡量软件质量和测试工作的一个重要参数,因此对于度量软件测试过程而言,缺陷的分析是一个十分关键的度量取向。通过分析缺陷报告对测试过程进行有效的度量,能够很大程度上帮助项目和测试过程的管理做出科学的决策和改进。
由于在测试过程中,通过对缺陷的有效分析而得到的度量结果,对于改进测试过程、提高软件质量都有着重大意义。因此,本文将介绍应用
IBM Rational ClearQuest 生成缺陷数据图表的主要步骤和应用典型的缺陷图表对测试过程进行度量的基本方法。
IBM Rational ClearQuest 作为 IBM Rational 家族的核心产品之一,提供了包括缺陷数据的管理服务在内的强大的软件项目全方位管理平台,并且能够基于数据自动生成多种图表报告,为项目提供全方位、全过程的支持。因此,目前很多软件项目应用
IBM Rational ClearQuest 来管理项目数据并根据选取的特定数据生成图表。本章将着重介绍如何应用
IBM Rational ClearQuest 生成几种典型的缺陷数据图表,包括缺陷模块分布图表 (Defect
by component),缺陷趋势图表 (Defect Submit/Resolve Rate Daily)
和缺陷状态跟踪图表 (Defect Opened Rate Tracking)。
度量图表的分类和选取步骤
缺陷分析报告的分类
有关测试过程中的图表按照作用和映射信息的方式大致能分为以下几类:对比型,状态跟踪型,预言型,信息型和过程型。每种图表有可能涵盖其中一种或者多种类型。如
IBM Rational ClearQuest 支持缺陷的图表共有三种:分布图,趋势图和回顾图。这三类图表的定义和作用如下:
分布图用于查看有多少条记录归于已定义类别或者与指示的值匹配。它表明所指示记录的当前状态。理论上来讲,对于缺陷来说,每种属性字段都能够定义与之相对应的缺陷分布图。例如,基于缺陷的属性如模块,版本,迭代,所属者,提交者,优先级,严重等级等的缺陷分布都属于这一类。在基于每个属性字段的基础上,还可以进行最多两次的属性迭代。那么从定义和作用来看,分布图就能够用来反映并比较属于不同属性的缺陷信息,它就属于信息型和对比型的图表。
趋势图用于需要对一段时间的变更请求活动进行度量的场合。只有基于状态的记录类型才能用于趋势图,其水平轴是以时间作为衡量标准,而用于显示过滤的第一个字段是状态,第二个字段可选。趋势图可以分为两类:累计计数和分散计数。
回顾图又称期龄图,用于显示多少记录处于选定状态已有多久。和趋势图一样,也只有基于状态的记录类型才能用于回顾图,如缺陷具有提交中,等待解决,已解决,已关闭等状态,如果我们想了解有多少缺陷记录处于提交中状态超过一周,或者有多少缺陷处于待测试状态超过
5 天等信息,那么基于缺陷数据的回顾图可以帮助我们得到答案。
缺陷分析报告的选取步骤
缺陷报告的创建主要分为以下几个步骤:
在项目的最初阶段,就应该明确需要获得的对象信息有哪些,以便进行数据的收集。如要生成缺陷报告,在项目测试的整个生命周期中,首先需要正确记录每一个缺陷以及缺陷的必要属性,其次,要实时的监控并更新这些数据以保证数据的及时性和有效性,此外,如
ODC(正交缺陷分析)还提供了设置某些人员和审核流程的方法以保证缺陷数据的有效性。只有这样,才能保证数据能够正确并完整地被记录下来,才能创建出对项目分析和决策有益的报表。
定义报告也是在项目初期就启动的操作。用户首先明确需求,如用户需要按照不同模块报告的缺陷的总数,那么图表报告对象就是缺陷的个数,而缺陷的归属类就是模块。
报告的方式和类型有很多种,如图表,表格,图,列表,文字等。到底选什么样的方式去展示主要取决于哪种方式能够使用户最简单轻松的获取所需信息。图表越复杂,信息的涵盖面就越多,但理解起来也相对晦涩;反之,简单的图表较易理解,但也就不能表现较综合的信息。因此,跟随用户角色和需要选择最适合的就是最好的。
缺陷图表根据自身定义,可以决定其更新和报告的频率。如时间间隔为周的缺陷趋势图需按周进行更新汇报即可,不需要汇报得太频繁,因为频率小于一周报告不会更新任何信息。而某些关键图表便需要更短的汇报周期,以便于及时发现项目中存在的问题。
在分析报告的结果的同时,我们也应考虑:报告结果是不是充足完善,图表定义是否需要改进等。如按照不同模块报告的缺陷个数分布图,当项目过程中,模块的个数发生改变时,图表也应该随之改进,否则就不能够及时准确的报告项目信息。
缺陷分布图的创建
缺陷分布图在项目的应用十分广泛。本节就以按软件模块划分的缺陷模块分布图(Defect by component)为例,介绍应用
IBM Rational ClearQuest for windows client 所提供的创建图表的功能定义并运行图表的步骤。
由于 Rational ClearQuest 提供的分布图支持基于某种属性再进行两次迭代,也就是说一共可以选择三种缺陷的属性。那么,本节的缺陷分布图定义为按模块划分,并且在模块这个属性上进行两次迭代,迭代属性分别为测试迭代号和测试类型。
明确报告对象和确定图表的需求后,就可以开始在 IBM Rational ClearQuest for
windows client 中创建所需的图表了。
首先,选择图表对象的记录类型。在 IBM Rational ClearQuest for windows
client 右边目录树的任一查询项的右键菜单中,选择“创建图表”,在弹出的如图 1 所示的记录类型选择页面选择“TMDefect”。
图 1. 缺陷分布图参数界面 - 选择记录类型
然后,定义图表。在如图 2 所示的“指定图表”界面中,选择图表类型“分布图”。
图 2. 缺陷图表参数界面 - 指定图表
点击下一步后,显示如图 3 所示的分布图参数界面。在垂直轴区段选择“id”,函数选择“Count”,表示垂直轴的数据显示为缺陷的数量。在水平轴区段选择“Component”,并可以选择按照“升序”或者“降序”排序。在图注区段,将字段分别选择为“测试迭代号”(Iteration)和测试类型(Test
type)。
图 3. 缺陷分布图参数界面 - 分布图属性
接着,定义图表的标签,显示类型和样式等,如图 4,5,6 所示。其中,标签包含了图表的标题,页脚,垂直水平轴标值和图注对齐方式等信息。显示类型和样式为用户提供了图表展示形式的定义,使用户能够以最直接明了的方式的获取所需信息。
图 4. 缺陷分布图参数界面 - 标签
图 5. 缺陷分布图参数界面 - 显示类型
图 6. 缺陷分布图参数界面 - 样式
完成以上操作后,点击“完成”,缺陷报告的创建就完成了。运行此报告后,将会有报告的结果集以表和图的形式显示在
ClearQuest 的右部,结果集如图 7 所示。
图 7. 缺陷分布图
最后,根据图表中显示的信息,用户可以接着修改除了记录类型和图表类型以外的参数,如垂直水平轴的字段,标签,样式等。
在图 7 中,上半部分是结果集以表格式列举的具体数据。列名分别是图 3 中设置的垂直水平轴的属性字段,每一行的第一列数据表示在分布某个
component,某个迭代周期中,某种测试类型下的缺陷个数。下半部分是缺陷图表,右边列出了迭代周期和测试类型两种迭代属性相合的图例。依次图例,用户就可以很清晰的看到在每个模块的测试中,在所有迭代周期和测试类型的组合下缺陷的个数。
缺陷趋势图的创建
缺陷趋势图对于度量某段时间缺陷的活动情况十分有帮助。如本节以度量某段时间内,每一天在不同测试类型下提交和解决的缺陷个数(Defect
Submit/Resolve Rate Daily)为例。
创建缺陷趋势图和分布图的步骤类似,首先,选择图表对象的记录类型为“TMDefect”,在图 2 中选择报告类型为“趋势图”。
接着,在趋势图属性界面的水平轴区段,定义水平轴时间的开始结束日期和时间间隔。在图注区段,为字段 1 的状态选择值:Submit
和 resolve。如图 8 所示。为字段 2 选择属性:测试类型。计数方式选择“显示每个时间段的总数”。
图 8. 缺陷趋势图参数界面 - 属性
然后,定义图表的标签,显示类型和样式等。运行此报告后,类似地,将会有结果集以表和图的形式显示,通过以上步骤创建的报告结果集如图
9 所示。
图 9. 缺陷趋势图 - 显示时间段总数
如果在定义报告的计数方式时,即图 8 中,选择“显示每个时间段的过渡状态”并选中“显示累计总数”复选框,运行报告后,图表的垂直坐标将显示每天的累积数据,如图
10 所示。
图 10. 缺陷趋势图 - 显示累计总数
缺陷状态跟踪图的创建
回顾图(期龄图)也常用于项目中以度量多少记录处于选定状态已有多久。本节以缺陷打开状态跟踪图(Defect
Opened Rate Tracking)为例,此图表可以查看某段时间内,不同测试类型有多少缺陷处于打开状态较长。
首先,选择图表对象和报告类型为“期龄图”。在期龄图属性界面的水平轴区段,定义水平轴时间的时间间隔大小,单位,时间间隔数和结束日期。在图注区段,为字段
1 的状态选择值:Opened。如图 11 所示。为字段 2 选择属性:测试类型。和趋势图类似地,期龄图也提供“显示累积计数”的计数方式。
图 11. 缺陷龄期图参数界面 - 参数
通过上述方式定义的期龄图结果集显示如图 12 所示。将鼠标放在图表的任一条形图上,会有一条包含时间,字段
2 的属性信息和计数数据的注释显示出来。
图 12. 缺陷龄期图参数界面 - 龄期图
对图表信息的分析和所反映问题的挖掘,可以为项目决策和执行实施,提供了有益的指导。本章将就第二章介绍的项目常用的三种典型缺陷图表:缺陷模块分布图表
(Defect by component),缺陷趋势图表 (Defect Submit/Resolve
Rate Daily) 和缺陷状态跟踪图表 (Defect Opened Rate Tracking),介绍如何分析缺陷图表和根据分析结果度量测试过程和软件质量。
缺陷模块分布图
解读图表
以第二章的第二节创建的缺陷模块分布图表 (Defect by component) 为例,如图 7。
其分布图的条形图按照水平坐标——模块属性的个数分为 4 部分,每部分条形图的个数取决于两种迭代属性个数的乘积。从图例可看出,迭代属性测试迭代号(Iteration)有两个值:I1
和 I2;测试类型(Test type)有三种值:FVT,SVT 和 Accessibility。因此每部分条形图的个数是
6。如每个组件中黄色条形图代表的就是在第一个迭代周期进行功能测试(FVT)时发现的缺陷总数。
列举现象
通过解读图表,我们就能够发现很多现象,如:
现象 1:模块 4 的缺陷总数最多,模块 1 的最少;
现象 2:在第一个测试迭代周期,模块 1 没有发现缺陷;
现象 3:模块 1,3,4 都是在进行功能测试时的缺陷数量最多,而模块 2 在系统测试时发现的问题最多;
……
分析现象发现问题
看到这些现象,我们就会问:真正的问题是什么?通常地,图表本身只能提供一些现象和事实,并不能告诉我们问题是什么。具体问题的分析还需要借助很多要素和信息。如从现象
1(模块 4 的缺陷总数最多,模块 1 的最少)本身来看,出现这种情况的相关因素有很多:
从模块本身的角度考虑,与模块本身逻辑复杂程度相关;
从开发角度考虑,与模块开发质量,开发人员对需求的熟悉程度相关;
从测试角度考虑,与测试覆盖率,测试人员经验等相关;
从项目管理角度考虑,与开发测试周期长短,资源多少,环境等因素相关。
这就需要结合项目的其他信息,挖掘问题的根源,才能透过现象看到本质。
假设通过对上述元素的相关信息的调研,我们得出下表的分析结果:
|
模块 1 |
模块 2 |
模块逻辑复杂程度 |
简单 |
复杂 |
模块开发质量 |
高 |
中等 |
开发人员对需求的熟悉程度 |
熟悉 |
一般 |
测试覆盖率 |
高 |
较高 |
测试人员经验 |
丰富 |
丰富 |
开发测试周期长短 |
短 |
长 |
开发测试资源 |
充足 |
不充足 |
…… |
|
|
根据上表所示,度量人员就能分析出两模块缺陷数量差异的原因,分析结果也能在一定程度上为处于项目不同角色的人员提供改进过程的依据。
缺陷趋势图
解读图表
以第二章的第三节创建的缺陷趋势图表 (Defect Submit/Resolve Rate Daily)
为例,如图 9,图中折线的个数是状态和测试类型迭代属性值的乘积。从图例可看出,定义状态是所选择的值:提交(submitted)和已解决(resolved);测试类型(Test
type)有三种值:FVT,SVT 和 Accessibility。因此折线的个数是 6。图中蓝色折线表示在指定时间段内,功能测试中每天缺陷的提交数量。
列举现象
通过解读图中蓝色折线,我们就能够发现很多现象,如:
现象 1:缺陷提交的数量在 12 月底,1 月上旬某天,2 月上旬某天出现峰值
现象 2:1 月中旬到 2 月下旬这段时间所有类型的缺陷提交数和解决数都趋于零。
……
分析现象发现问题
针对现象 1,我们可以根据追溯缺陷个数峰值出现当天(12 月 31 日)的历史事件,去解析软件过程度量软件质量。假如通过查找项目日志等发现
12 月 31 日,是第一个用于功能测试的 build 产生。通过查询和总结当天提交的缺陷,发现大部分缺陷都是关于模块
A 的,那么我们就可以将问题定位于这个 build 的模块 A。
针对现象 2,通过追溯项目日志,发现这段时间是春节假期,因此缺陷提交数和解决数都趋于零。
提供指导
根据上述两个现象的问题定位,我们可以提出以下问题并给出建议:
作为开发人员,需要专注在哪里?
当某个 build 产生前,需要更加有效的验证测试。
对于模块 A,也许需要总结一下出现大量缺陷的原因,再进行其他模块的设计和开发作为经验参考。
作为测试人员,需要专注在哪里?
尽可能在较长的假期前验证所有缺陷,以提高测试用例的通过率,加快项目进度,并尽早发现问题和解决问题。
缺陷状态跟踪图
解读图表
以第二章的第三节创建的缺陷状态跟踪图表 (Defect Opened Rate Tracking) 为例,如图
12。
此图表中,横坐标为 0-1 的柱状图表示处于打开状态持续时间在 1 周以内的缺陷个数。不同的颜色表示不同的测试类型(TestType)。
列举现象
通过解读图表,我们就能够发现如下现象:
现象 1:处于打开状态持续时间在 1 周以内的缺陷个数最多
现象 2:测试类型为 Prod 的缺陷处于打开状态持续时间最长。
……
分析现象发现问题
针对现象 1 和现象 2,我们可以判断出来 FVT 阶段的缺陷处理和解决的速度是较快的;而 Prod
测试的缺陷则解决时间较长。
如果迭代的属性是模块,那么我们也可以分析出来哪些模块的缺陷解决速度较快,哪些较慢。
对于这些解决速度较慢的缺陷,我们就能有针对性地进一步分析其原因,根据原因提出解决方案以便于在今后的项目中避免类似问题的发生。
本文主要介绍了应用 IBM Rational ClearQuest 生成缺陷数据图表的步骤和应用典型的缺陷图表对测试过程进行度量的基本方法。通过基于不同缺陷图表所反映出来的各类趋势和现象进行分析总结,挖掘可能引起这些趋势和现象的原因,结合项目执行的实际情况剖析问题的根源,可以使项目组及管理人员获得正确的信息来改进测试过程,减少研发、测试中的重复工作和预测项目风险。
|