UML软件工程组织

 

 

如何在测试管理中应用 IBM Rational ClearQuest TestManager
 
作者:梁禹,傅晓静,张彦 来源:IBM
 
本文内容包括:
本文将结合“计划阶段”、“管理阶段”和“执行阶段”这三个阶段向大家解释 ClearQuest TestManager 的各种角色,各种记录以及 ClearQuest TestManager 在测试管理中的基本应用,和 ClearQuest TestManager 同 Rational 其他产品的集成带来的测试管理的改进。

1. 综述

Rational ClearQuest TestManager(简称 CQTM)是 IBM Rational ClearQuest 产品(简称 CQ)中的一个特性,属于集成到 IBM Rational ClearQuest 中的一个应用包。它继承了作为对立产品的 Rational TestManager 的测试管理的特性,同时更有效的结合 ClearQuest 的特性,为测试管理提供了更佳的解决方案。 CQTM 定义了测试管理中的测试资产,其中包括:测试计划、测试用例、测试需求、测试配置环境、测试脚本和测试结果等。在这些文件夹、文件和数据之间的层次关系是用 ClearQuest 数据库中的记录来表示的。数据库中的记录是按照 CQTM 定义的层次结构来组织的。

在层次结构的贯彻执行中包括三个阶段:计划阶段,在该阶段,首先创建资产注册表,再创建测试计划、测试用例、配置的测试用例等记录类型,用以形成测试层次结构;管理阶段,在该阶段创建测试脚本,并与测试用例和配置的测试用例相关联,进行对整个测试的管理,尤其是对测试脚本,测试结果;执行阶段执行配置的测试用例或测试套件,评审测试结果,结果如果适当则提交到 CQ 数据库中形成测试日志或者测试套件日志,完成对测试的执行并配合记录结果从而进行结果分析。

本文将结合这三个阶段向大家解释 CQTM 的各种角色,各种记录以及 CQTM 在测试管理中的基本应用和 CQTM 同 Rational 其他产品的集成带来的测试管理的改进。

2. CQTM 的安装

2.1 使用 Enterprise Schema

CQTM 软件包已经集成在 Enterprise 模式中,属于开箱即用的模式,用户只要创建属于 Enterprise 模式的数据库,即可获得 CQTM 的特性。

2.2 应用 CQTM 软件包

在没有集成 CQTM 的模式里,可以应用 CQTM 软件包来获取 CQTM 的特性。登录 ClearQuest Designer,检出模式,该模式应该是非 Enterprise 的 OOTB 模式。点击 CQ Designer 中的菜单,软件包/软件升级,选中 CQTM 的软件包,如图 1 所示。并点击完成。

检入模式,然后升级用户数据库。则对 CQTM 的软件包的应用已经完成。用户可以在使用该模式的时候,获得 CQTM 的特性。

图 1: 升级软件包

图 1: 升级软件包

3. CQTM术语

3.1 记录类型解释

CQTM 的将各种测试资产用 CQ 的记录类型进行表示,存储在 CQ 的用户数据库中。在随后的介绍中,我们将使用 CQTM 记录类型的英文名字进行介绍。

CQTM 记录类型 解释
TMAssetRegistry
资产注册表是无状态记录,用作测试计划、测试用例、配置的测试用例、测试套件、文件位置和迭代记录关联文件的所有位置信息的容器。
TMIteration
迭代是包含迭代信息的无状态记录。迭代记录代表开发正在接受测试的系统期间的特定里程碑。
TMTestPlan
测试计划是主要的有状态记录,表示预计要执行的测试的主要分组。它可包含对关联的子测试用例记录的引用,或对进一步指定相关测试区域的其他测试计划的引用。测试计划记录提供项目中其他测试资产的组织结构。
TMTestCase
测试用例记录代表需要在受测试系统中进行验证的行为单元。

注:如果对模式应用 Rational RequisitePro 集成 V1.8 软件包,并且测试用例是选定的记录类型,则测试用例记录也将包含需求页面。

测试用例记录始终保持至少与一个测试计划记录相关。

TMConfigurationAttribute
配置属性是无状态记录,它可以定义由任何配置记录使用的属性。
TMConfigurationValue
配置值是无状态记录,定义由配置属性使用的值。配置值记录与配置属性记录相关联。
TMConfiguration
配置是无状态记录,定义受测试的系统配置。配置记录与配置的测试用例及测试套件记录相关联。
TMConfiguredTestCase
配置的测试用例是有状态记录。已配置的测试用例记录是具有关联配置和迭代记录的测试用例的可执行格式。每个已配置的测试用例记录都与父测试用例记录相关联。单个测试用例记录可与多个已配置的测试用例记录关联,其中每个已配置的测试用例记录都将用于测试不同的配置。
TMTestLog
测试日志是无状态记录,显示执行的已配置测试用例记录的摘要结果。
TMTestSuite
测试套件是有状态记录,表示可按顺序执行的已配置测试用例记录的有序列表。
TMSuiteLog
套件日志是无状态记录,表示在关联测试套件中所有执行的已配置测试用例记录的摘要结果。

表 1: CQTM 记录类型

3.2 各个记录类型的关系

上节所介绍的各种 CQTM 的记录类型,它们之间有着一定的架构关系,图 2 介绍的是 CQTM 中 TMAssetRegistry,TMIteration,TMTestPlan 以及 TMTestCase 记录类型之间的可能的一种架构关系。Product 1 相关的测试资产“Asset Registry for Product 1”对应 CQTM 中的 TMAssetRegistry 记录。而对 Product 1 进行的测试会分为几个迭代,包括 Iteration 1,Iteration 2 和Iteration 3,在 CQTM 中以 TMIteration 记录来表示。所有的测试计划和测试用例都会存在于指定的 Product 1 的测试资产中,分别用 TMTestPlan 和 TMTestCase 记录类型来存储。而且不同的测试计划和测试用例也可以单独关联不同的迭代记录。如图上 Test Plan 1 与 Iteration 1 关联,Test Case 2 和 Test Case 3 则与 Iteration 3 关联。

图 2: CQTM 记录类型关系图

图 2: CQTM 记录类型关系图

图 3 介绍的是 TMTestPlan,TMTestCase,TMConfiguration 和 TMConfiguredTestCase 记录类型之间的架构关系。由图所述,已经定义了 Configuration 1 和 Configuration 2 等四个配置,在 CQTM 中以相应的 TMConfiguration 记录来标示。可以将一个 TMTestCase 记录与这些 TMConfiguration 记录进行绑定,从而形成一个可配置的测试用例,也即是 TMConfiguredTestCase 记录。一个 TMTestCase 记录可以与多个 TMConfiguration 记录关联而形成不同的 TMConfiguredTestCase 记录。当然这些 TMConfiguredTestCase 也与 TMTestPlan 和 TMTestCase 一样,存储在测试资产注册表中。

图 3: CQTM 记录类型关系图

图 3: CQTM 记录类型关系图

图 4 介绍的是 TMConfiguration,TMConfigurationAttribute 和 TMConfigurationValue 的关系。TMConfiguration 类型的记录创建需要两个元素,包括配置属性和配置值,这两个元素在 CQTM 中分别以 TMConfigurationAttribute 和 TMConfigurationValue 两种记录来标示。通过这些可重用的 TMConfigurationAttribute 和 TMConfigurationValue 记录,就可以很容易地指定一个 TMConfiguration 记录的细节信息。

图 4: CQTM 记录类型关系图

图 4: CQTM 记录类型关系图

4. 基本测试管理应用 CQTM

4.1 CQTM 所涉及的角色

CQTM 的使用涉及到以下的用户角色。

模式开发者:模式开发者把 CQTM 应用包,应用到一个已存在的 CQ 模式中,也可以自定义 CQTM 的记录类型在实际中所需要的其他各种字段,为实际测试环境进行在 CQ 以及 CQTM 中定制相应的设计。

项目组长:模式开发者会指定某个产品发布所涉及的测试 Build 和迭代阶段。

测试组长:测试组长的职责定义测试工作的范围,创建定义测试计划所需的测试资产。测试组长还创建各个测试计划来覆盖所测产品特性,以及包含测试脚本和测试激发因素文档的文件地址。在执行已配置的测试用例或者测试套件后,测试组长可以分析测试结果、对应需求的测试覆盖率及与测试用例相关的缺陷。测试组长通过查询、报告和图表来评估测试覆盖率、测试者的工作量以及测试总体进程。

测试者:测试者创建测试用例、配置环境、已配置的测试用例和测试套件等记录。测试者还可以使用受支持的 Rational 测试工具来为每一个测试用例开发测试脚本。测试者还会执行已配置的测试用例和测试套件,审查测试结果,并提交测试结果到 CQ 数据库中。

ClearQuest 管理者:如果测试项目以前使用 Rational TestManager 来管理测试资产,ClearQueat 管理者可以使用 CQTM 提供的迁移工具来迁移数据,ClearQueat 管理者必须安装IBM Rational ClearQuest 7。0版本,包括 ClearQuest 客户端或包含 Test Management 插件的 ClearQuest Eclipse 客户端。

4.2 角色分工

测试开始之前的准备工作,由模式开发者来进行。根据测试的需求,模式开发者设计在测试管理中的所需要的 CQ 记录类型、记录类型的各个字段定义以及记录操作的表单。而 CQ 管理者需要对 CQ 所使用数据库进行管理,包括数据的备份,使用的软件的升级等等, CQ 管理者的工作将在测试的各个过程中持续,直到测试结束。模式开发者和 CQ 管理者对整个测试过程的作用在于前期的准备和测试过程中的维护。

在实际测试进行中,项目组长需要指定测试产品的开发的迭代阶段以及测试需要使用 Build。而测试组长则需要创建 TMAssetRegistry,TMTestPlan 和 TMTestCase 记录,从而可以使测试者可以根据这些记录进行测试。测试者则创建 TMConfiguratedTestCase 和 TMTestSuite 记录,在测试后提交测试结果。测试组长在测试完成后根据测试结果生成报告和图表,从而完成测试工作。在随后的介绍中,将具体介绍在测试的过程中,不同角色发挥的作用,即基本的测试管理的应用。

图 5: 角色

图 5: 角色

4.3 CQTM 在测试管理的生命周期中的具体应用

在测试的过程中,主要参与的角色包括项目组长,测试组长和测试者,我们将主要讨论这三个角色在测试过程中如何利用 CQTM 进行测试管理,从而完成整个测试管理的生命周期。本章节将讨论的是基本的应用,所有图例都是在 IBM ClearQuest Eclipse 简体中文版客户端中截取。关于与其他产品的集成所产生的高级应用,将在随后的章节详细介绍。

首先,项目组长需要对整个项目进行分析与估计,制定并且设计好测试的整体资产。项目组长需要创建测试中的资产注册表,将所有的测试资源指定在该资产注册表下,同时需要指定测试的迭代过程,从而为整个测试的进度做规划。其中对 TMAssetRegistry 和 TMIteration 的创建,可以通过正常的向导生成,如图 6 所示。

图 6: 创建 TMAssetRegistry

图 6: 创建 TMAssetRegistry

其次,测试组长的工作主要集中在具体的测试计划,测试用例方面,完整的搭建一套测试体系架构,因此测试组长需要创建 TMTestPlan,TMTestCase,TMConfiguration,TMConfigurationAttribute 和 TMConfigurationValue 记录,从而规划测试者的测试,图 7 是由 ClearQuest RCP(Rich Client Platform)客户端中“TestManager – 规划”视图看到的各种类型的记录的层次关系,是对 CQTM 中所有的记录类型之间关系的总结。

图 7: 各个记录类型的层次结构

图 7: 各个记录类型的层次结构

TMTestPlan,TMTestCase,TMConfiguration,TMConfigurationAttribute 和 TMConfigurationValue 记录的创建,可以根据向导进行,与图 6 的创建过程相仿。也可以在“TestManager – 规划”视图中相应的记录使用右键点击弹出菜单中进行快速创建。需要注意的方面是创建的顺序,如 TMTestCase 记录的创建必须在 TMTestPlan 记录之后,各种记录创建顺序如下表所示。

产生顺序
测试计划/测试用例 配置
TMTestPlan TMConfigurationAttribute
TMTestCase TMConfigurationValue
  TMConfiguration

表 2 创建顺序

测试者需要根据测试组长已经创建的 TMTestPlan,TMTestCase,TMConfiguration,TMConfigurationAttribute 和 TMConfigurationValue 的记录,创建 TMConfiguratedTestCase 和 TMTestSuite 记录,然后在完成测试后提交测试结果。TMConfiguratedTestCase 记录的创建前提是存在相应的 TMTestCase 和 TMConfiguration 记录。图 8 中就是根据 TMTestCase 记录来添加已配置的测试记录。然后在图 9 中选择相应的配置记录从而形成 TMConfiguratedTestCase 记录。

图 8: 创建 CTC

图 8: 创建 CTC

图 9: 绑定配置

图 9: 绑定配置

如果测试者并不使用其他 Rational 测试工具: Rational Functional Tester, Rational Manual Tester 以及 Rational Performance Tester 编写测试脚本,并将 TMTestCase 或 TMConfiguratedTestCase 与测试脚本绑定,而只是进行手工测试。则需要测试者自行创建测试日志也即 TMTestLog 记录,从而在 CQTM 中记录测试结果。如果测试者使用其他 Rational 测试工具,则在测试工具执行脚本后,由测试工具自动产生测试日志。图 10 演示了如何通过 TMConfiguratedTestCase 记录创建 TMTestLog 记录。图 11 演示了创建 TMTestLog 记录所需要填写的内容。

图 10: 创建 TMTestLog 记录

图 10: 创建 TMTestLog 记录

图 11: 填写 TMTestLog 内容

图 11: 填写 TMTestLog 内容

对于测试者,如果当前的 TMConfiguratedTestCase 记录的测试结果是失败的,则需要使用到 ClearQuest 的缺陷管理的功能,完成提交缺陷的功能。这一提交的功能需要手工的操作,无论 TMConfiguratedTestCase 记录是否与其他 Rational 的测试工具的脚本绑定,对缺陷的提交和添加都如图 12 所示。

图 12: 创建缺陷

图 12: 创建缺陷

测试组长在测试者进行测试之后根据结果生成报告和图表提交给项目组长,从而完成测试工作。如图 13 所示,CQTM 提供了很多缺省的报告图表,方便了总结测试工作。

图 13: 图表

图 13: 图表

5. 集成自动化测试工具 - Rational Functional Tester;Rational Performance Tester;Rational Mannual Tester

5.1 与 Rational 测试工具集成的优势

前文介绍的是如何使用 CQTM 来管理测试过程中所涉及的测试资产,在自动化测试工具应用越来越广泛的今天, CQTM 也提供了与自动化测试工具的无缝集成。Rational Functional Tester(RFT)是一款先进的、完全面向对象的和跨平台的基于图形化用户界面的自动化测试和回归测试工具,其支持 Java 和 VB.Net 编程语言,支持 Windows 和 Linux 平台,并且为 Java 和 Web 测试人员提供了和开发人员同样的基于 Eclipse 的集成操作平台;Rational Performance Tester(RPT) 是一款强大的基于 http 或 SAP 的图形化自动性能测试工具;Rational Manual Tester(RMT)为用户提供强大的手工测试脚本编写和执行功能。CQTM 也提供了与这三种广泛应用的测试工具的无缝集成,将测试工具完美集成到 IBM Rational 整个测试生命周期中,真正实现测试自动化和过程管理的统一平台,极大地提高整个软件开发团队的能力。集成使我们可以在完全统一的平台中进行测试用例记录的编写,以及测试脚本的开发、管理和执行,还可以很方便地从测试用例定位到相应的测试脚本以及运行,然后产生脚本的测试日志,最后对测试日志进行分析并提交缺陷。

5.2 集成的功能

CQTM 为测试工具的集成提供了 TMTestCase 记录和 TMConfiguratedTestCase 记录与实际的测试脚本相关联的功能。当 TMTestCase 记录与脚本关联后,由 TMTestCase 记录所配置得到的 TMConfiguratedTestCase 记录会自动关联上其所关联的脚本,当然我们也可以对从 TMConfiguratedTestCase 记录单独关联测试脚本。

CQTM 还为测试工具的集成提供在统一的平台中定位和执行 TMConfiguratedTestCase 记录所关联测试脚本的能力,并且可以对测试脚本执行所产生的测试日志进行分析和处理。

其集成功能可以分成三个部分:测试脚本与 TMTestCase 记录和 TMConfiguratedTestCase 记录的关联;通过 TMConfiguratedTestCase 记录来执行测试脚本;测试脚本执行结果的处理。这三个部分根据 CQ 的客户端软件的不同在使用方法上有所不同。

CQTM 可以单独以 RCP 客户端方式启动,但是为了得到与测试工具的集成能力,我们建议将 CQTM 以插件的方式安装在测试工具中。这样所有的操作就可以统一的 IDE 中进行。如果需要将以上所说的三个测试工具和 CQTM 一起进行集成,我们需要将 RFT,RMT 和 RPT 安装到统一的 IBM Rational 软件开发平台(RSDP)中,而 CQTM 以插件的方式安装在 RSDP 中。以下的介绍也将基于这个平台来进行。

5.2.1 测试脚本与测试用例记录的关联

在 CQTM 中,在测试用例记录和测试脚本相关联前,首先需要在测试用例记录所在的 TMAssetRegistry 记录下建立相应的文件位置记录,也即是关联测试脚本在网络上所存放的共享路径。在实际操作中,由于测试脚本有可能存在于不同的项目中,我们的建议是建立一个共享目录,然后将所有的测试脚本项目都统一集中放在该共享目录下以便于执行和管理。在关联脚本之前先在RSDP中连接上所需要涉及到的测试脚本项目。

启动 RSDP,切换到 ClearQuest 透视图下,连接一个 CQ 的用户数据库,该用户数据库应该已经应用了上文所说的升级了 CQTM 软件包的模式,界面会出现标题为“TestManager – 规划”的视图。切换到“TestManager – 规划”视图中,展开相应的 TMAssetRegistry 记录,用右键点击 TMAssetRegistry 记录下的文件位置目录,在弹出菜单中点击“新建文件位置”选项。在新建文件位置向导窗口中保持“测试资产在 Eclipse 项目…”选项被钩上,然后点击“下一步”按钮。

图 14: 创建文件位置

图 14: 创建文件位置

根据提示,选择一个 Eclipse 项目以及相对应的测试日志位置,然后点击“完成”按钮,一个文件位置记录就被创建了。接下来我们就可以进行测试用例记录和自动测试脚本的关联。

在“TestManager – 规划”视图中,导航到相应的 TMTestCase 记录和 TMConfiguratedTestCase 记录,在记录上点击右键,在弹出菜单中点击“关联测试脚本”选项。

图 15: 关联测试脚本

图 15: 关联测试脚本

如果我们需要关联的是 RFT 脚本,我们需要在“测试脚本关联”窗口中选择 Rational Functional Tester 作为测试类型,在相应的项目中选择相应的测试脚本,然后点击“完成”按钮。这样我们就将测试用例记录和测试脚本关联上了。而对于 RPT 和 RMT 的脚本,我们需要分别选择 Rational Performance Tester 和 Rational Manual Tester 作为测试类型。

图 16: 测试脚本关联

图 16: 测试脚本关联

5.2.2 通过 TMConfiguratedTestCase 记录来执行 RFT 自动测试脚本

由于 RFT,RMT 和 RPT 的测试脚本运行会产生测试日志,当前的用户对共享目录应该有修改的权限。

在“TestManager – 规划”视图中,导航到相应的 TMConfiguratedTestCase 记录,在记录上点击右键,在弹出菜单中点击“执行”选项。

在执行测试窗口中选择迭代记录以及输入工作版本信息,然后点击完成按钮。

图 17: 执行测试

图 17: 执行测试

RSDP 将会弹出测试脚本执行窗口来显示当前的脚本运行状态和进度,并开始执行 TMConfiguratedTestCase 记录所关联的脚本。如果是 RMT 脚本,我们需要手工进行脚本的运行。

图 18: 测试脚本执行

图 18: 测试脚本执行

在脚本运行完毕后,RSDP 会关闭测试脚本执行窗口,生成测试日志,并关联到一个处于未提交状态的 TMTestLog 记录上。这些 TMTestLog 记录我们可以在测试结果视图中看到。除了运行 TMConfiguratedTestCase 记录来执行测试脚本外,我们还可以通过运行 TMTestSuite 记录来定制运行多个测试脚本。首先为 TMTestSuite 记录配置一个或多个 TMConfiguredTestCase 记录,然后右键点击该 TMTestSuite 记录,在弹出菜单中点击 Execute 选项。这样相应的 TMConfiguredTestCase 记录所关联的脚本会顺序运行。

5.3 测试脚本执行结果的处理

在脚本运行完毕后,测试日志记录将会显示在测试结果视图的未提交分类中。同时最近提交到数据库中的测试日志记录也将显示在测试结果视图中。该记录会显示运行结果,测试用例的描述信息,运行的测试脚本类型,运行的测试脚本和生成的测试日志所在位置。我们可以根据这些信息分析测试脚本运行情况,并且将该记录提交到数据库中甚至根据测试结果直接提交 Defect。在测试结果视图中用右键点击“提交 Defect”选项:

图 19: 测试结果

图 19: 测试结果

RSDP 会弹出创建(Defect)窗口,并将测试日志有关的信息自动填入,我们可以在创建(Defect)窗口中修改需要的信息,然后提交即可。同时该测试日志会自动提交到 CQ 数据库中。

图 20: 关联 Defect

图 20: 关联 Defect

除了上章所说的 Rational 自动测试工具外,CQTM 还可以与 IBM Rational RequisitePro(以下简称 ReqPro)进行集成,使测试的计划与内容可以和软件的需求进行关联,提供互相可追溯的功能。为测试的计划制定提供了依据。在需求变更的时候,更容易保持需求与测试计划和内容的一致性,完成了测试和软件需求之间的集成,让测试工作可以贯穿到整个软件的开发生命周期中,为软件的开发生命周期的协同工作提供了良好的统一平台。

6. 集成需求软件 - Rational RequisitePro

6.1 与 ReqPro 集成的优势

通过 ReqPro 和 CQTM 的集成,用户可以将 ReqPro 中的需求记录与 CQTM 中的测试相关记录关联起来。

例如,用户可以将 CQTM 中的改进请求、缺陷、测试计划、测试用例、已配置的测试用例等记录类型与 ReqPro 中的需求记录相关联。

用户也可以根据 ReqPro 中的需求记录来创建 CQTM 的需求记录。这些记录作为 ReqPro 需求的代表或者“代理”,并将需求标记、名称、文本、类型、修订版以及更改日期设置为只读数据。从而使用这些 CQTM 需求记录(可以通过 ReqPro 和 CQTM 两种工具创建)与其他 CQTM 记录(例如测试计划、测试用例等)进行关联。用户可以进一步地使用 CQ 客户端中的查询和报告工具查看需求关联。

除了通过 CQ 客户端,用户还可以通过 ReqPro 来查看“属性矩阵”中的关联,并从 ReqPro 需求浏览至 CQTM 需求或其他关联的记录。也就说用户既可以从 ReqPro 客户端,也可以从 CQ 客户端中通过这些关联进行记录间的浏览。通过 ReqPro 属性矩阵和 CQTM 查询结果,用户还能够查看测试覆盖率。

6.2 集成的步骤

CQTM 和 ReqPro 的集成需要通过 Rational Administrator 建立的项目,使用 Rational Administrator可以使 ReqPro 项目与 CQTM 用户数据库相关联。用户首先需要使用 CQTM 集成属性来配置 ReqPro 需求类型,CQTM 记录必须配置为引用 Rational Administrator的项目和需求。

在 ReqPro 里创建或使用现有的一个项目,我们使用安装后的例子:Learning Project。然后在项目属性设置中,把 CQTM 的记录类型,例如 TMTestPlan、TMTestCase、TMConfiguredTestCase 和 CQTM _Requirements等作为属性加到 ReqPro 里某种需求类型的属性中里。需要注意的是,在添加需求属性时,Label处填写 CQTM 里相应记录类型的名字,Type 处选择 ClearQuest integration,并勾选 Change affects suspect 选项,如图 21 所示,在 Requirement Type 处选择的是 FEAT: Product Feature。

图 21: 选择 FEAT

图 21: 选择 FEAT

在所创建的项目里创建 View 和 Requirement 并保存,如图 22 所示。

图 22: 创建视图和需求

图 22: 创建视图和需求

关闭 ReqPro,然后通过 Rational Administrator 创建一个 RA 项目,使 ReqPro 里的需求记录的属性能够跟 CQTM 中相应的记录类型进行关联。但是需要注意:为了网络环境的其他用户能够访问该 RA 项目,Project location 处需要使用 UNC 格式填写一个共享的路径;如果想使该 RA 项目也与 ClearCase 进行集成,则需要勾选“Use ClearCase and Unified Change Management to baseline project assets.”选项,如图 23 所示。

图 23: 创建 RA Project

图 23: 创建 RA Project

然后如图 24 所示,对 RA 项目进行配置,关连上 ReqPro 中的项目以及 CQTM 中的模式库。Requirements Assets 处选择刚才配置好的 ReqPro 项目所在路径。Test Assets 处是存放关联的测试数据池。在 Change Requests 处点击 select 按钮,选择用于关联的 CQTM 模式库进行连接,该模式库应该在 CQ 维护工具中先行配置。然后点击 OK 按钮,保存该 RA 项目的配置。

图 24: 配置项目

图 24: 配置项目

通过 Rational Administrator 完成创建及配置 RA 项目后,需要进行 ReqPro 和 CQTM 的集成配置。把前面在 ReqPro 新增加的 FEAT 类型需求属性和 CQTM 里相应的记录类型关联起来,如图 25 所示。由此 ReqPro 和 CQTM 的集成配置就完成了。

图 25: 集成向导

图 25: 集成向导

6.3 集成后 CQTM 在测试管理中增加的特性

CQTM 和 ReqPro 集成后所增加的新功能,是可以在 CQ 客户端中对记录关联上响应的需求。比如测试计划、测试用例、已配置的测试用例等,此功能都包含“Requirements”附签中。下面以测试计划为例。

如 图 26 所示,在提交测试计划记录时,选择“Requirements”附签,在 RA Project 处选择刚才建立的 RA 项目,然后点击“RequisitePro”按钮,可以把 ReqPro 里相应的需求添加进来。如果需要,用户还可以直接在 CQ 客户端中直接创建需求记录。在“Associate Requirement”窗口中点击“Create”按钮,就可以直接进入 ReqPro 的需求创建窗口,在窗口中填写相应内容后,即可以将新建的需求与 CQTM 记录关联起来。

图 26: 关联需求记录

图 26: 关联需求记录

在 CQ 客户端中关联 CQTM 记录和 ReqPro 需求后,用户也可以通过 ReqPro 客户端从需求记录追溯到其关联的 CQTM 记录。

在 ReqPro 客户端中,双击需求记录,在“Requirement Properties”窗口中选择“Attributes”附签,就可以看到刚才关联的测试计划记录,如图 27 所示。

图 27: 属性显示

图 27: 属性显示

通过右边的浏览按钮,用户也可以直接在 ReqPro 客户端中对需求记录关联 CQTM 的记录,如图 28 所示,用户可以查询并选择关联需要的 CQTM 记录。用户甚至可以通过“New Record”按钮直接创建 CQTM 记录。

图 28: 关联 CQTM 记录

图 28: 关联 CQTM 记录

7 总结

本文详细介绍了 Rational ClearQuest TestManager对测试管理的定义,对测试过程中各种测试资产的运用,并且通过介绍 CQTM 同其他 Rational 产品的集成,更加完善了在自动化测试中对 CQTM 的应用以及对测试脚本的版本管理。

8.致谢

感谢在 CSDL 工作的 IBM Rational Testing 项目组同事的支持。

参考资料

学习
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号