本文通过实际的操作流程，介绍了如何利用 Rational ClearQuest 的特性进行灵活项目测试管理的完整过程，其中包括测试需求及变更管理、测试用例管理及测试进度管理和结果管理。

Rational ClearQuest 项目测试管理流程

对于软件项目而言，测试是整个生命周期中的重要部分。软件的测试周期包括有测试评估和计划阶段（Test Assess and Planning）、测试设计阶段（Test Design）、测试执行阶段（Test Execution）和测试的结束阶段（Test Close）。

测试人员（Tester）在测试设计阶段需要深入了解项目的需求和设计文档，设计测试用例；在测试的执行阶段，测试人员执行测试用例，完成对项目需求所要求实现的系统功能的测试，这个阶段通常会发生需求变更，这个时候就需要增加、删除或修改测试用例，实现对需求变更的测试。在测试的结束阶段，测试组长（Test Leader）生成测试结果报告。

在整个测试过程中，由于测试的复杂性和需求的变更情况存在不确定因素，因此，有效的测试管理是不可或缺的部分，也可以说是项目按时并保质完成的关键。在设计阶段需要管理测试需求，建立需求和测试用例的映射关系，形成初始的测试用例和需求的可追溯性（traceability）；在测试的执行阶段，管理测试需求变更，保证测试用例和需求的实时映射关系，并通过监控测试用例执行情况、缺陷的修复验证状态实现测试的进度管理；在测试结束阶段，生成项目测试结果报告，同时也为今后的项目提供真实的参考数据。

IBM Rational ClearQuest 是一个缺陷和变更跟踪（Defect and Change Tracking）系统，提供灵活的缺陷和变更跟踪、过程自动化、报告和生命周期的可追溯性管理，并提供良好的开发和测试生命周期的可视性及控制。利用 Rational ClearQuest，可以方便的实现测试设计、测试执行和测试结束阶段的测试管理工作。

ClearQuest 在项目的设计阶段可以通过规划功能（Planning）管理需求和测试用例，并建立起二者的映射关系，也就是可追溯性关系。当进入测试执行阶段时，利用 ClearQuest 的查询（Query）功能，查询并生成测试用例的执行状态结果，缺陷（Defects）的修复验证结果。分析这个结果就可以了解目前的测试进度，一旦发现测试进度滞后，就可以及时采取措施进行弥补，保证项目测试进度按计划顺利进行。在项目结束时，通过从 ClearQuest 中导出相应的数据，就可以得到项目实际的测试用例和需求的可追溯性和验证（Verification）信息，提高了测试管理的效率，保证了测试项目的顺利进行。

图 1 说明了 Rational ClearQuest 在测试周期中的测试管理流程。在下面的章节将详细介绍 Rational ClearQuest 如何实现测试需求管理、测试变更管理，测试用例管理，测试进度管理和测试结果管理。

图 1.Rational ClearQuest 在测试过程中的测试管理流程

测试需求管理

测试需求是测试工作的重要部分，不仅直接确定了测试范围和测试任务，而且对测试计划的制定也至关重要，因此测试需求的管理是项目测试管理的首要任务。在项目初期首先要明确项目的需求，编写项目的需求规格说明书。在项目的需求规格说明书中，每个需求有相应的编号（Req#），标题（Headlines）和详细的描述（Description）。表 1 是项目需求列表，第一列 Req# 是需求的编号，如 BRS1 就是这个需求的编号，SRS1.1 是 BRS1 的子需求编号。第二列 Headlines 是对需求的简短描述。Description 是需求的详细描述。

项目通过使用 Rational ClearQuest 的规划功能来实现测试范围的管理。根据上面的需求信息，在 Rational ClearQuest 的 Test Manager Planning 窗口，先为项目创建一个总的测试计划，可以以项目名称命名，这里命名为 Test。 然后为所有的需求创建相应的测试计划，用来管理测试范围。创建名为 BRS1、BRS2 的测试计划。同时把相应的子需求创建为子测试计划，在 BRS1 的测试计划下面创建子测试计划 SRS1.1、SRS1.2。在 BRS2 的测试计划下面创建 SRS2.1 的子测试计划，并将这个需求的 Description 部分拷贝到相应测试计划的 Description 域里，这样在 ClearnQuest 中就把需求范围通过树状的测试计划管理起来了，并且测试计划直接和 BRS 需求编号一一对应，简单高效，如图 2。

测试需求的变更管理

尽管在项目初期确定了项目的需求，但是在项目进行当中，由于多种原因，需求或设计经常会发生变化，而这种变化直接影响了测试的范围和测试计划的执行，因此测试需求变更的有效管理直接影响了测试计划顺利执行。

我们可以利用 Rational ClearQuest 的规划功能来管理这些需求变更。首先创建需求变更列表。每个需求变更，确定一个变更号（Change#），标题和详细描述，并确定这个变更是属于哪个需求的变更（Req#）。变更号可以采用变更的日期来表示，方便以后及时定位。变更信息如表 2：

接下来在 Rational ClearQuest 的 Test Manager Planning 窗口，为每个变更创建相应的测试计划来进行需求的变更管理。如图 3 所示。

在图 3 中，SRS1.1-change20090601 这个测试计划对应 2009 年 6 月 1 日的针对子需求 SRS1.1 的变更。同理，SRS2.1-change20090609 这个测试计划对应 2009 年 6 月 8 日针对子需求 SRS2.1 的变更。同样把变更的 Description 信息也写入测试计划的 Description 中，方便以后查询。

测试用例管理

测试用例是软件测试过程的核心内容，测试用例完成的情况也就是测试计划的执行情况，因此测试用例的管理是测试执行过程中的重要内容。

我们利用 Rational ClearQuest 的规划功能和查询功能实现测试用例的管理。在 Rational ClearQuest 的 Test Manager Planning 的窗口，选择一个测试计划，然后右键选择 New Test Case，填写相应信息，这样就为这个测试计划创建了一个测试用例。然后为这个测试用例增加相应的配置和迭代信息生成已配置的测试用例 ----CTC（Configured Test Case）。依照这样的方法，项目所有的测试计划都创建相应的 CTC，如图 4。这样就在 Rational ClearQuest 中通过测试计划和测试用例的关系生成了测试需求和测试用例的映射关系，简单而且直接。

接下来在 ClearQuest Navigator 窗口，创建一个项目目录，可以以项目名字命名，这里创建的项目名为 Test。并创建一个 TMConfiguratedTestCase 的 Query，这个 Query 名字和一个测试计划相同，由于测试计划和需求一一对应，因此每个 Query 和一个需求对应。根据相应的测试计划 ID 过滤（Filter），这就可以通过 ClearQuest Query Results 很容易查到每个需求对应的所有 CTC。

图 5 右面的 Query Results 是所有需求对应的 CTC 的 Query 结果。第一列是是需求的编号，并已经按照需求编号排序。第二列是子需求的编号，第三列是 CTC 在 CQ 中的 ID 号，第四列是 CTC 的标题。这就形成了需求和测试用例的关系矩阵，需求变更和测试用例的对应关系一目了然。

图 6 是 BRS1 需求对应的 CTC。

图 7 是 BRS2 需求对应的 CTC。

这种方式非常方便而有效的维护并管理了测试需求及变更和相应的测试用例的对应关系。在测试过程中，如果需要得到某一时刻的测试用例和需求及变更的可追溯性关系信息，只需要导出查询结果即可以得到。

测试进度的管理

为了保证项目按计划执行，在项目的执行过程中，需要及时管理测试的进度，获得目前测试用例执行情况，缺陷提交、修复及验证情况，将项目测试状态提交项目管理小组，并保证测试进度的按计划完成。

使用 Rational ClearQuest 的查询功能，就能够实现测试的进度管理。 在 ClearQuest Navigator 窗口，在所有需求的 CTC Query 中（ BRS-All）设置如下的显示内容（Display Fields）如图 8：

然后刷新 ClearQuest Query Result, 窗口，就可以得到每个 CTC 的实际执行状态。如图 9：

在图中，列出所有需求及变更对应的 CTC 测试状态，

1. 第一列是需求号
2. 第二列是子需求号
3. 第三列是 CTC ID 号
4. 第四列是 CTC 的标题
5. 第五列是每个 CTC 的执行状态
6. 第六列是 CTC 关联的 Defects ID 号
7. 第七列是 CTC 关联的 Defect 状态

对于需求 BRS1：

1. 根据图 10 分析，已经测试了子需求 SRS1.1 的所有 CTC。 有两个 CTC 失败（failed），两个通过（passed）, 失败的 CTC 中，一个缺陷 是 Opened 状态，表示开发人员正在修复 ; 一个缺陷是 Closed 状态，表示这个缺陷已经修复验证通过，测试人员应该去重新测试这个 CTC。

2. 根据图 11 分析，已经测试了子需求 SRS1.1 变更的所有 CTC。两个 CTC, 一个失败，一个通过 , 有一个缺陷已经修复，正等待测试人员去验证。

3. 目前 BRS1 测试了 100%，需要做的工作是开发人员修复缺陷 00004732; 测试人员验证修复的缺陷 00004734; 测试人员重新测试失败的 CTC 00004714。

对于需求 BRS2：

1. 根据图 12 分析，执行通过了子需求 SRS2.1 的 3 个 CTC，还有一个没有执行。

2. 根据图 13 分析，SRS2.1 的变更的测试还没有开始执行。

3. 目前需求 BRS2 的执行还没有完成，需要进行原因分析，确定测试进度是否按计划进行。

测试结果的管理

在测试的结束阶段，需要生成测试结果报告，包括所有测试用例和需求的可追溯性及验证报告，测试总体进度等。

使用 Rational ClearQuest 导出（Export）功能就可以直接生成这些报告。执行所有 CTC 的 Query，也就是 BRS-All 的 Query，将 ClearQuest Query Results 从 CQ 中导出，这样就直接得到了实际的测试用例和需求的可追溯性和验证结果。

以图 14 为例可以看出所有需求对应的测试用例执行情况，测试 100%，15 个测试用例中测试通过 14 个，失败 1 个，这个测试用例失败的原因是有一个缺陷被确定为延后修复（Postponed）。

如果需要得到通过或失败的测试点数（Test Point）信息，可以在 BRS-All 的 Query 中的增加 CTC PassedPoint, 和 FailedPoint 的显示内容，导出结果并形成相应的统计结果，以图 15 为例，一共通过 145 个点，失败了 5 个点，通过率 是 97%。

结论

在整个测试的过程中，利用 IBM Rational ClearQuest 进行灵活项目的测试管理。在测试的设计阶段，利用 CQ，我们把测试的需求进行了管理，便于合理安排测试任务；在测试的执行过程中，通过 CQ，我们能够及时跟踪测试的进展，当需求发生变更时，可以及时管理变更和测试用例，便于调整计划安排，最大效率的完成测试任务；在测试的结束之后，通过 CQ，我们可以非常方便的总结整个测试过程，并对项目管理小组出具详细的测试报告。利用 CQ，我们实现了测试过程的有效管理及过程可视化，极大地提高了项目测试管理的效率，保证测试按计划顺利进行。

参考资料

• 访问 developerWorks 中国网站的 Jazz 技术空间，这里汇集了丰富的 Jazz 平台中文技术资源。 您可以通过这里了解更多关于 Jazz 平台和 Jazz 技术发展趋势的最新信息。
• 访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
• 阅读 Rational Edge 中文版，获取软件开发领域的最佳实践。
• 订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
• 学习 Hello World 系列教程，这是学习 IBM 软件工具的快速通道。在每一篇教程中，都会有快速入门产品演示动画。您可以通过其中的动画演示快速浏览如何使用 IBM 软件完成开发任务。

• 访问 IBM Rational ClearQuest 产品专题，了解最新的 IBM Rational ClearQuest (CQ) 产品文档和产品信息，获得关于 IBM Rational ClearQuest 的技术文档和参考资源，可以查阅产品概览、产品手册、产品技术支持、试用版下载，以及相关文章、教程、多媒体课堂和产品演示等信息。
• 下载免费的 IBM Rational ClearQuest 试用版。
• 访问 IBM Rational 软件交付平台 V7 专题，了解 Rational V7 产品的方方面面。
• 获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
• 下载免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
• 获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

• 查看 developerWorks 博客 并加入 developerWorks 社区。