从测试用例列表批量生成 CQTM Test Case 的三种解决方案

发表于:2009-05-24来源:作者:点击数: 标签:CQTM批量CaseTESTCASE
本文介绍了三种从 Test Case 列表批量生成 IBM Rational ClearQuest TestManager(CQTM)Test Case 的 解决方案 ,通过本文所提供的解决方案,可以节省测试人员在CQTM中手动创建 Test Case 的大量重复性工作,提高生产力。 IBM Rational CQTM(ClearQuest Tes
本文介绍了三种从 Test Case 列表批量生成 IBM Rational ClearQuest TestManager(CQTM)Test Case 的解决方案,通过本文所提供的解决方案,可以节省测试人员在CQTM中手动创建 Test Case 的大量重复性工作,提高生产力。

IBM Rational CQTM(ClearQuest TestManager)可以与 RMT(Rational Manual Tester)或 RFT (Rational Functional Tester)集成。通常,测试人员需要先在 RMT 或 RFT 中编写脚本,然后在 CQTM 中,将此脚本关联到一个 TMTestCase 或 TMConfiguredTestCase。在很多情况下(例如测试用例数量众多,或是迭代次数较多),这样的工作会很耗时,并且往往有大量重复性劳动。本文介绍了三种从 Test Case 列表批量生成 CQTM Test Case 的解决方案,其核心思想是通过使用 CQ(ClearQuest)所提供的 API 来实现自动化的批量生成 TMTestCase 并将相应的脚本与之关联起来。通过本文所提供的解决方案 , 可以节省测试人员在 CQTM 中手动创建 Test Case 的大量重复性工作,提高生产力。经过测试,在局域网内的 CQTM 中创建 Test Case,每个用例大约花费的时间在 3-5 秒之间,相对于以前由测试人员手动添加并编辑测试计划、测试用例,效率提高在 90% 以上。

我们已成功实现了 RMT 和 CQTM 的这种整合,因此本文主要讨论根据 RMT 的脚本列表如何批量生成,但文中所描述的方案同样适用于 RFT。本文中,我们结合我们的思路提供了部分示例代码,读者可以根据具体的应用需求来实现和定制自己的代码。

注 : 文中有关 IBM Rational ClearQuest TestManager 的示例代码为非官方代码,IBM 不对其提供支持。使用示例代码需自行承担风险。作者强烈建议在使用前先在虚拟项目中对代码进行测试。

1. 通常的使用场景

图 1 展示了结合使用 CQTM 和 RMT 的通常场景。测试主管(Test Lead)在 CQTM 中创建 Asset Registry,Test Plan,Configuration 和 Iteration。测试人员(Testers)在 RMT/RFT 中编写脚本,然后在 CQTM 中创建 Test Case,并将相应的脚本与之关联。测试人员根据 Test Case, Configuration 和 Iteration 生成 Configured Test Case。在测试执行过程中,测试人员为每个 Configured Test Case 创建 Test Log。


图 1. 通常的使用场景
 

现在我们深入分析一下测试人员如何创建 RMT 脚本和 CQTM Test Case,即图 1 中红框所包含的部分。

首先,测试人员在 RMT 中编写一些脚本并将它们放在某个共享目录下,例如,\\SharedMachine\SampleProject。为了更好的组织这些脚本,测试人员在此目录下创建了一个名为“FVT”的子目录,以标识这些脚本是用于 FVT 的;然后在“FVT”目录下再创建一个子目录“Function1_Scripts”用于存放关于组件“Function1”的脚本。对于每个 RMT 脚本,使用一些描述性的命名以表示其功能,例如“TestCase3.rmt”。如图 2 所示。


图 2. 创建 RMT 脚本
 

接下来,在 CQTM 中,测试人员需要先定义 Asset Registry 和 File Location,才能开始添加 Test Case 并与 RMT 脚本相关联。图 3 展示了在这个场景中所定义的 File Location。


图 3. 创建 File Location
 

当 Asset Registry 和 File Locations 都准备好之后,测试主管创建一个名为“FVT”的 Test Plan, 并在其下创建一个名为“Function1”的子计划。然后测试人员就可以开始在“Function1”下创建 TMTestCase。测试人员需要把每个 TMTestCase 与一个 RMT 脚本相关联,为了保持一致性,TMTestCase 的标题与 RMT 脚本的名字一样。如图 4 所示。


图 4. 创建 CQTM Test Case
 




回页首

2. 上述场景中的问题

通过观察图 2 和图 4,可以发现其树结构和命名规则都是极其类似的。因此在 CQTM 中所做的工作其实是一种重复性劳动。我们为何不能寻求一种自动完成这些工作的方法呢?

基于以上考虑,我们通过编程的方法,根据 CQTM 提供的 API 与之进行交互,开发了一个工具来实现自动化,以消除这些重复工作。

假定将 ClearQuest 安装在 C:\Program Files\Rational\ClearQuest 目录,则可以在 C:\Program Files\Raitonal\ClearQuest\doc\books 目录下找到 cq_api.pdf 文件。在这个文件中,所有的 API 都采用 Basic 语言和 Perl 语言进行了描述,但这些 API 也提供对 Java 语言的支持。基本上,使用 ClearQuest 客户端所能进行的所有操作,都能通过这些 API 来编程实现。这为 CQ 用户实现工作的自动化提供了充分的可能。

在以下章节中,我们针对上述场景中 CQTM 用户所面临的问题,提出了三种解决方案。3.1 节是一个普通方案,可以节省测试人员在 CQTM 中创建 Test Case 和 Configured Test Case 所需的工作。3.2 节是一个高级方案,将测试准备和测试用例(test case)的生成更彻底的结合在一起。3.3 节是一个更为综合的方案,它提供了一个包含所有相关信息的模板以用于测试准备和审查,并且除批量生成 CQTM 测试用例以外,还会批量生成相应的 RMT 脚本。

在实际使用中,我们在不同的项目的测试中已经实践了这三种解决方案。对于普通方案,我们开发了一款名为 RMT2CQ 的工具。对于高级方案,我们往 RMT2CQ 工具中增加了一些特性。对于综合方案,我们设计了一个模板,并开发了另一款名为 GenRMT 的工具与 RMT2CQ 结合起来使用。

在本文中,我们以 RMT2CQ 的一些示例代码来阐述我们的思路。读者可以根据自己的项目情况来定制代码。对于第三种方案中所涉及的模板和 GenRMT 工具,将会有其他的文章进行更详细的描述。

注:示例中所使用的是 CQTM 7.0.0.0 和 Common Schema CQTMCS_V1。

使用 API 建立查询的技巧:通过 API 在 CQTM 中创建新的实体(entity)之前,必须进行查询(query)以防止重复。在建立查询时,可以使用 session.BuildSQLQuery() 或 session.BuildQuery()。

如果使用 BuildSQLQuery(),当前会话(session)的登录用户应当具有“SQL Editor”特权,这是由于用户需要传入正确的 SQL 语句。如果用户对于 SQL 语句的语法不太确定,可以通过 CQ 的 Eclipse 客户端得到提示。用户可以在客户端中创建类似的查询,并右键单击该查询,选择“SQL”,然后选择“View SQL”,如图 5 所示。该查询相应的 SQL 语句将会显示出来,如图 6 所示。在我们的工具以及本文的示例代码中,我们使用的是这个 API。


图 5. 查看 SQL
 

图 6. 显示 SQL
 

如果使用 Buildquery(),其代码非常类似于用户从客户端创建查询的过程。可以使用 BuildField() 来指定要显示的域,并使用 BuildFilterOperator() 和 BuildFilter() 来指定查询标准。




原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)