使用IBM Rational ClearQuest 创建缺陷分析报告图.doc

使用 IBM Rational ClearQuest 创建缺陷分析报告图 在软件开发中，缺陷是衡量软件产品质量的重要指数，同时，它也为评估开发测试团队的工作效率提供了一个非常有效的参考。因此对缺陷的分析，就成为软件开发生命周期中必不可少的工作。IBM Rational ClearQuest作为一个灵活的工作流程以及变更管理的工具，提供了对缺陷的分析报告图制作的无缝集成，开箱即用的操作大大方便了用户的定制和作图。本文将在介绍缺陷分析报告基本制作方法的基础上，结合ClearQuest工具，详细阐述制作缺陷分析报告图的方法和技巧。 1. 缺陷分析报告简介 我们首先通过一个简单的实例，对缺陷分析有个直观的理解。 报告需求：在A产品构建阶段，项目经理想要通过缺陷的严重度和数量来了解目前产品的各个开发模块(a,b,c)的质量水平。 报告分析： 输入数据范围界定：构建阶段的A产品的所有缺陷。可以通过缺陷的字段 “缺陷发现阶段=构建阶段” 过滤提取出输入数据。 分类方式：有两种分类方式—缺陷严重度和缺陷数量。首先将缺陷按照开发模块划分，方法是通过缺陷字段“模块”组织分类。在一个模块内部再按照缺陷严重度划分，方法是通过字段“严重度”来分类。 输出：缺陷数量。 报告结果数据：A 产品构建阶段所有缺陷是470个，其中模块a-120（非常严重30，严重70，不严重20）；模块b-230（略）；模块c-120（略）。 报告表： A 产品构建阶段缺陷数量报告表 模块 a 模块 b 模块 c 总共 非常严重 30 50 10 90 严重 70 80 60 210 不严重 20 100 50 170 总共 120 230 120 470 报告图： A 产品构建阶段缺陷报告图 报告结论： 在构建阶段内，模块b的质量问题较为突出，非常严重的缺陷数量大大超过其它两个组件，而且模块b整体的缺陷数量也最多。因此需要对模块b的质量加强管理与监督。相比之下，模块c的质量问题比较理想，主要集中在不严重的小缺陷上，但也应该提醒相关人员加以改进。 通过这个例子，我们可以看出，缺陷分析就是从一组缺陷数据中，提取具有某些属性的一类或者多类缺陷，利用统计的方法对其数量或者其它特征加以分析和对比，制作出分析表格或者图形，从而得出一定的结论。而这里的表格和图形就是缺陷分析报告的不同形式。 从这个例子我们还可以看出，报告图较表格更为直观，能够一目了然地反映报告结果。也正因如此，报告图在实际工作中更为常用。但是报告图通常是以报告表为数据源，再次加工而成。通常情况下，报告人先生成报告表，然后再利用excel等工具，完成报告图的制作。如果需要频繁大量地生成报告图，这种手工操作无疑增加了相当的工作量。而ClearQuest不仅在缺陷管理方面功能强大，而且集成了报告图的制作功能，用户只需要组织报告分析字段，查询、报告功能就能同时完成。另外ClearQuest还支持报告图的旋转、缩放等动态显示效果。 2. 缺陷分析报告图信息收集 软件开发过程中，我们通常会为项目建立一个缺陷或者包括缺陷在内的所有变更的管理库。在项目的整个生命周期中，该管理库记录项目相关的所有缺陷信息，从提交、分派、修复、验证到关闭。利用它可以追踪缺陷状态，缺陷相关任务分派，同时它也是缺陷分析的数据来源。比如IBM Rational ClearQuest就提供了这样的管理功能。 缺陷分析报告是通过提取缺陷管理库中的数据，进行归纳总结绘制而成的，由于缺陷管理库不仅仅用于缺陷分析，因此我们在开始制作分析报告图以前，就应该对提取什么样的字段数据做好准备工作。 举一个简单的例子，假如我们想了解测试团队中对某个产品组件在某个工作阶段内每个人的工作量（可以是提交缺陷的数量）如何，那么就应该提取出该产品组件在该时间段内所有的缺陷，并且按照提交人加以分类，从而查询出每个人的缺陷提交量绝对值或者百分比。那么这个分析报告的制作，涉及到缺陷的多个属性：所属产品组件，所属开发周期的阶段，以及提交人。所以我们要制定出这个报告图，就必须保证缺陷的这几个属性是存在的，并且不是空值。Rational ClearQuest对于缺陷跟踪的管理，提供了多套样式(schema), 对于很多常用的属性已经默认设置完成，用户可以方便地使用。但是如果用户想要定制更复杂的分析报告，比如对缺陷产生原因的分析，就要自己定义特定字段（在这个例子中可以是“原因”字段），来满足分析的需求。 这里给出一些常用的用于缺陷分析的字段，供参考。除了要保证这些字段的存在外，最好还能通过在一定状态下关键字的形式，保证其值非空。 状态(state)：常见的状态有新提交的，修复了的，已经关闭了的。 优先级(Business Priority): 用于衡量缺陷对用户使用该产品的影响程度，通