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

本文介绍了三种从 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