在软件开发中，缺陷是衡量软件产品质量的重要指数，同时，它也为评估开发测试团队的工作效率提供了一个非常有效的参考。因此对缺陷的分析，就成为软件开发生命周期中必不可少的工作。IBM Rational ClearQuest作为一个灵活的工作流程以及变更管理的工具，提供了对缺陷的分析报告图制作的无缝集成，开箱即用的操作大大方便了用户的定制和作图。本文将在介绍缺陷分析报告基本制作方法的基础上，结合ClearQuest工具，详细阐述制作缺陷分析报告图的方法和技巧。

1. 缺陷分析报告简介

我们首先通过一个简单的实例，对缺陷分析有个直观的理解。

报告需求：在A产品构建阶段，项目经理想要通过缺陷的严重度和数量来了解目前产品的各个开发模块(a,b,c)的质量水平。

报告分析：

1. 输入数据范围界定：构建阶段的A产品的所有缺陷。可以通过缺陷的字段 “缺陷发现阶段=构建阶段” 过滤提取出输入数据。
2. 分类方式：有两种分类方式—缺陷严重度和缺陷数量。首先将缺陷按照开发模块划分，方法是通过缺陷字段“模块”组织分类。在一个模块内部再按照缺陷严重度划分，方法是通过字段“严重度”来分类。
3. 输出：缺陷数量。

报告结果数据：A 产品构建阶段所有缺陷是470个，其中模块a-120（非常严重30，严重70，不严重20）；模块b-230（略）；模块c-120（略）。

报告表：

报告图：

报告结论：

在构建阶段内，模块b的质量问题较为突出，非常严重的缺陷数量大大超过其它两个组件，而且模块b整体的缺陷数量也最多。因此需要对模块b的质量加强管理与监督。相比之下，模块c的质量问题比较理想，主要集中在不严重的小缺陷上，但也应该提醒相关人员加以改进。

通过这个例子，我们可以看出，缺陷分析就是从一组缺陷数据中，提取具有某些属性的一类或者多类缺陷，利用统计的方法对其数量或者其它特征加以分析和对比，制作出分析表格或者图形，从而得出一定的结论。而这里的表格和图形就是缺陷分析报告的不同形式。

从这个例子我们还可以看出，报告图较表格更为直观，能够一目了然地反映报告结果。也正因如此，报告图在实际工作中更为常用。但是报告图通常是以报告表为数据源，再次加工而成。通常情况下，报告人先生成报告表，然后再利用excel等工具，完成报告图的制作。如果需要频繁大量地生成报告图，这种手工操作无疑增加了相当的工作量。而ClearQuest不仅在缺陷管理方面功能强大，而且集成了报告图的制作功能，用户只需要组织报告分析字段，查询、报告功能就能同时完成。另外ClearQuest还支持报告图的旋转、缩放等动态显示效果。

2. 缺陷分析报告图信息收集

软件开发过程中，我们通常会为项目建立一个缺陷或者包括缺陷在内的所有变更的管理库。在项目的整个生命周期中，该管理库记录项目相关的所有缺陷信息，从提交、分派、修复、验证到关闭。利用它可以追踪缺陷状态，缺陷相关任务分派，同时它也是缺陷分析的数据来源。比如IBM Rational ClearQuest就提供了这样的管理功能。

缺陷分析报告是通过提取缺陷管理库中的数据，进行归纳总结绘制而成的，由于缺陷管理库不仅仅用于缺陷分析，因此我们在开始制作分析报告图以前，就应该对提取什么样的字段数据做好准备工作。

举一个简单的例子，假如我们想了解测试团队中对某个产品组件在某个工作阶段内每个人的工作量（可以是提交缺陷的数量）如何，那么就应该提取出该产品组件在该时间段内所有的缺陷，并且按照提交人加以分类，从而查询出每个人的缺陷提交量绝对值或者百分比。那么这个分析报告的制作，涉及到缺陷的多个属性：所属产品组件，所属开发周期的阶段，以及提交人。所以我们要制定出这个报告图，就必须保证缺陷的这几个属性是存在的，并且不是空值。Rational ClearQuest对于缺陷跟踪的管理，提供了多套样式(schema), 对于很多常用的属性已经默认设置完成，用户可以方便地使用。但是如果用户想要定制更复杂的分析报告，比如对缺陷产生原因的分析，就要自己定义特定字段（在这个例子中可以是“原因”字段），来满足分析的需求。

这里给出一些常用的用于缺陷分析的字段，供参考。除了要保证这些字段的存在外，最好还能通过在一定状态下关键字的形式，保证其值非空。

• 状态(state)：常见的状态有新提交的，修复了的，已经关闭了的。
• 优先级(Business Priority): 用于衡量缺陷对用户使用该产品的影响程度，通常设定值为1-3，数值越低说明对商务的影响越严重。
• 阶段(Iteration): 作为RUP迭代开发的阶段划分，它可以方便地定位缺陷被发现的时期，利于阶段性缺陷分析。
• 原因(Root Cause): 用于标记缺陷被引入的原因，其值可以通过字符串列表的形式加以设定，目的是有的放矢地加以改善，以期达到理想的产品质量。
• 状态改变的日期：包括提交日期，修复日期，关闭日期等等。便于观察缺陷状态演变的行进效率。

3. 常见的几种缺陷分析报告图

由于缺陷分析报告图比报告表更为常用，这里介绍几种常见的ClearQuest支持的报告图。ClearQuest支持3种缺陷分析报告图：分布图(Distribution Chart)、趋势图(Trend Chart)和回顾图(Aging Chart)。ClearQuest的报告图功能通过在windows客户端的图表(chart)创建来实现，目前仅在windows客户端实现了这一功能。

3.1 缺陷分析分布图

分布图在缺陷分析中最为常用，它用于观察有多少缺陷属于用户指定的某类或者满足用户指定的某值。在这类图表中，又有3种比较常见：等级分布图，产品组件分布图以及缺陷产生原因分布图。

等级分布图是指按照严重等级将缺陷分类，比较各种严重等级下缺陷的分布比例，严重等级高的缺陷数量越少越好,以此来衡量某一阶段该产品的健康度，以及指定下一阶段的策略。

产品组件分布图，顾名思义，就是将缺陷数量按照产品的各个组件分类，进行比较。这种方法既可以反映出各个开发模块的难度或者质量，也可以用来评估不同开发模块的测试效果。

缺陷产生原因分布图是缺陷分析中有利于质量控制的最为重要的一类图，它将缺陷按照产生原因分类，各种原因类别需要事先定制，可以是软件工程各阶段中可能引入缺陷的各种因素，而且原因分类越细致，越能够精确定位缺陷产生点。 项目经理或者质量管理人可以据此了解影响软件质量的最为薄弱的环节，并加以干预促进改善。

图1给出了这3种分布图的示例图。

除了以上3种常见的缺陷分布图之外，在开发进程中，项目经理还可以随时通过分布图来掌握工作状态，比如查看一组记录的当前状态；查看谁当前被分配了最多/最少的缺陷；以及查看哪些缺陷具有最高优先级。

3.2 缺陷分析趋势图

趋势图反映一定时期内，缺陷数量在某种状态下的动态分布。可以是累计的缺陷计数，也可以是不累计的。我们常用趋势图来查看新缺陷的增长趋势，以及关闭缺陷的趋势。观察是否新缺陷的数量在逐渐下降？是否缺陷的关闭比较及时？这些结果对于影响相关的进度推进决策有相当的参考价值。

比如图2所示的某产品在发布前的一段测试周期内，新发现缺陷数量的趋势图，随着测试的开展，越来越多的缺陷被发现，随着缺陷的及时修复，发现新缺陷的数量也在一定时间点后逐渐减少。可见，该趋势图反映的产品质量基本符合发布标准。

3.3 缺陷分析回顾图

回顾图是一种特殊类型的缺陷分析报告图。显示在多长时间内有多少缺陷记录处于所选状态。龄期图回答像下面这样的问题： 在不到1周时间内提交了多少个缺陷？ 在3周多的时间内提交了多少个缺陷？ 在2个月多的时间内延迟了多少个缺陷？

图3表示了某时间段内，按优先级(BP)分类的缺陷通常多久被修复。读图可以看出，在这段时间内，缺陷按照优先级归类，分别为13，19，17个，这些缺陷在大于一周内时间的被修复的个数分别为9，10，17；大于两周被修复的分别是6，10，14个，等等。这里曲线下降的快慢反映了修复的速率，从图中可见，大多数的缺陷在5周内得以修复。根据不同优先级对缺陷修复时间的要求，项目经理可以据此判断修复时间是否达到标准，是否需要推进对缺陷的修复进度。

4. 使用ClearQuest制作缺陷分析报告图

在介绍了缺陷分析图表的3种分类后，我们将遵循不同类别，来了解ClearQuest中制作缺陷分析报告图的关键点。

首先，通过主菜单上的“查询”，选择“新建图表”。对于我们想要创建的缺陷这种记录类型的分析图表，选择图表的类型—分布图、趋势图或者回顾图，注意在此窗口清除“运行查询”选项，因为我们将在定制报告图后，手动添加查询条件，并以查询结果为源数据，绘制报告图。

4.1 分布图的制作

以查询测试团队中某些测试人员在某个阶段的各个严重等级的缺陷量为例，在接下来的参数窗口中，我们进行字段的选择，如图4所示，Y轴表示缺陷数量；X轴表示缺陷提交人；同时在图例(lengend)域，增加商业优先级字段，并且指定按照优先级大小排序。图例域提供了1到2个可选的图例来帮助对数据的进一步分类。当用户填写了某个图例字段后，图表数据将按照这个字段的所有值来组织数据显示。比如我们这里选择了商业优先级，那么缺陷记录数将按照这个指标分类给出。

接下来，定制图表的标签，包括标题，脚注，坐标轴标注以及图例所处的位置。然后为图表选择展示类型和风格，展示类型可以在柱状图(bar)，堆叠柱状图(stacked bar)，线状图(line)，区状图(area)，以及饼状图(pie)中进行选择。展示风格包括背景坐标表格的添加，3D效果，彩色或者黑白图等。

至此，图表的定制基本完成，但是用于分析的源数据还没有指定，点击“完成”，将进行缺陷源数据的选取，也就是说分析报告图将在这批数据上进行归纳总结。在查询编辑器中，通过字段值的设定，选取源数据。最终的查询结果如图5所示。

同时该缺陷分析报告图完成。如图6所示，我们可以清晰地查看出各个提交人发现的不同优先级的缺陷的数量。结合测试人员的测试模块，能够据此评估各个测试人员的工作业绩。

如果对报告图的某些设定不太满意，可以返回编辑修订。除此之外，图表右键菜单中还包括了一些有助于更清楚地查看图表的操作，比如缩放，旋转，移动等等，还提供了导出功能。

4.2 趋势图的制作

以某开发阶段内提交的缺陷和修复的缺陷统计为例，我们来了解如何查看缺陷的历史趋势信息。

在选择新建趋势图后，趋势图的参数定制窗口显示出来。如图7所示，起始日期(Start date)和结束日期(End date)定义了在该时间范围内进行趋势分析，时间间隔(interval)可以选择天、周、月、年。状态(state)在本例中选择提交(submitted)和修复(resolved)。统计方式选择显示该时间段内的总量(Show totals in each time period)。

同样，在进行了图表标签定制、展示类型和风格的定制后，通过查询确定源数据，最终的缺陷分析报告图如图8所示。

该图表示在所示时间区间内，每个月提交和修复的缺陷数量趋势变化。红色曲线表示新提交缺陷数量趋势变化，随着该阶段测试工作的开展，新发现的缺陷呈上升趋势，接近迭代周期的后期，由于大多数的缺陷被修复，发现的新缺陷迅速下降。蓝色曲线表示修复缺陷的数量变化趋势，起初由于缺陷修复在时间上滞后于缺陷提交，所以少于缺陷的提交数量，随着修复的进行，越来越多的缺陷得以修复，包括前段时间累积的缺陷，最后，随着新提交缺陷数量的减少，修复缺陷的数量也呈下降趋势。这张趋势图基本符合一个迭代周期内缺陷的理想状态分布，表明该产品的质量以及团队工作效率比较合适。

4.3 回顾图的制作

最后，我们来介绍回顾图的制作。比如我们想查看一批缺陷一般在多长时间内关闭，图9为参数定制界面，选择时间间隔以及间隔数量，并且选定所要查看的状态—关闭。

最终的回顾图如图10所示。

通过图表可见，绝大多数的缺陷通常在1-2个月内关闭，其次在1个月内关闭。项目经理结合缺陷关闭进度标准，可以判断当前的缺陷关闭进度是否满足项目要求。

总结

利用ClearQuest出色的缺陷管理、查询和报告图的功能，不同角色的用户可以根据各自的需求方便地绘制报告图，提取出所需的信息，从而对项目、产品的管理做出科学的决策。

参考资料

• 请访问 IBM developerWorks 中国网站 Rational 专区 能得到更多关于 IBM IBM Rational 产品的文章、教程和其他参考资源。