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

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

陈 元, 软件工程师, IBM
夏 丽丽, 软件工程师, IBM
吕 杨清, 软件工程师, IBM

2009 年 4 月 29 日

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

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

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

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

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

回页首

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。

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

回页首

3. 解决方案

3.1 普通方案：从脚本列表生成 CQTM Test Case

方案描述

图 7 说明了 RMT2CQ 工具是如何在普通方案中使用的。在此方案中，测试人员在测试用例准备时仅需编写 RMT 脚本，RMT2CQ 将负责在 CQTM 中生成 Test Case 和 Configured Test Case，生成时会根据 RMT 脚本所在的文件目录结构来组织测试计划（Test Plan）的结构，并以 RMT 脚本的名字作为 Test Case 的标题。

所有需要传入该工具的信息都可以在其用户界面上找到，如图 8 所示。

在“Generation”标签页上，用户需要指定 RMT 脚本所在的路径，以及将 RMT 脚本关联到哪个层级：Test Case 或 Configured Test Case。如果用户指定只关联到 Test Case 层级，则该工具将根据 RMT 脚本创建 Test Case，并把它们相关联，然后停止；如果关联到 Configured Test Case 层级，则工具将继续创建 Configured Test Case 并建立相应关联。

在“Configuration”标签页上，用户需要指定 master schema 的名称，登录所使用的用户名和密码，登录到的数据库名称， configuration 名称，asset registry 名称，file location 名称，以及 test plan 名称。这些信息可以储存为一个配置文件，这样当用户下次启动该工具时，就无需再次输入。

示例代码

本小节包含了对上述方案的详细解释以及部分示例代码，供读者参考。

当 CQ 的 API 第一次在代码中出现时，以粗体标注。

RMT2CQ 工具的基本步骤包括：

• 创建 CQSession 并登录；
• 获取 RMT 脚本的名称；
• 创建 Test Plan；
• 创建 Test Case；
• 创建 Configured Test Case；
• 创建 External File；
• 将脚本与 Test Case 或 Configured Test Case 相关联。

1. 创建 CQSession 并登录。此处需要传入所登录的 schema 和数据库名称，以及登录所使用的用户名和密码。

 CQSession session = new CQSession();
//pass in username, password, dbname and schemaname;
session.UserLogon(username, password, dbname, schemaname);

2. 获取 RMT 脚本的名称。

根据全路径名，可以通过 Java API 获取 RMT 脚本的名称，此处省略具体代码。

3. 创建 Test Plan。

我们沿用前面的例子，“FVT”和“Function1”是 Test Plan，并且前者是后者的父计划。对于“FVT”来说，它没有父计划。如果这些测试计划还未创建，则根据树结构创建它们。顺序是首先创建最上层计划，再创建其下的子计划。在测试计划创建完成后，应当返回其 ID 以用于稍后创建其余的 test plan 或 test case。

 // query to determine if the test plan already exists
 // if query for the top level plan, the sql should be modified 
 String sql = "select distinct T1.id from TMTestPlan T1, TMtestplan T2 " + 
 "where T1.parentplan = T2.dbid and " + 
 "(T1.dbid <> 0 and ((T2.headline = '" + parentPlan + "' and " +
 "T1.headline = '" + headline + "')))";
 CQResultSet resultSet = session.BuildSQLQuery(sql);
 resultSet.EnableRecordCount();
 resultSet.Execute();
 if ( resultSet.GetRecordCount() > 0 ) {
 resultSet.MoveNext();
 return resultSet.GetColumnValue(1); //already exists, no need to create
}

// if the test plan does not exist, create it
// fetch parent plan’s ID; for the top level plan, “parentPlan” is empty
String parentPlanId = "";
if ( !parentPlan.equals("") ) {
 String sql = "select T1.id from TMTestPlan T1 where" +
 " T1.headline='" + parentPlan + "'";
 CQResultSet resultSet = session.BuildSQLQuery(sql);
 resultSet.Execute();
 while ( resultSet.MoveNext() == 1 ) {
 parentPlanId = resultSet.GetColumnValue(1);
 break;
 }
}

// create test plan and return it’s ID
CQEntity entity = session.BuildEntity("TMTestPlan");
entity.SetFieldValue("AssetRegistry", registryName);
entity.SetFieldValue("Headline", headline);
if ( !parentPlan.equals("") ) {
 entity.SetFieldValue("parentplan", parentPlanId);
}
entity.Validate();
entity.Commit();
return entity.GetFieldValue("id").GetValue();

4. 创建 Test Case。
   当测试计划的层次被创建之后，可根据直接父计划的 ID 来创建一个 Test Case，其标题即是在第 2 步中取得的脚本名称。同样，所创建的 Test Case 的 ID 也应被返回以用于 Configured Test Case 的创建和脚本的关联。

// queryto determine if this test case already exists
// the code is similar to the query of test plan, so omit here

// if the test case does not exist, create it
// the creation of Entity is similar to previous code, so only list difference here 
CQEntity entity = session.BuildEntity("TMTestCase");
entity.SetFieldValue("parentplan", parentPlanId);
entity.SetFieldValue("Headline", headline);

5. 创建 Configured Test Case。
   当一个 TC（Test Case）被创建之后，可以在其下创建 CTC（Configured Test Case）。创建时需要 Configuration 域的值，该值是在 RMT2CQ 工具的用户界面上选择的。该 CTC 的 ID 同样应被返回以用于脚本的关联。

// query to determine if this configured test case already exists
// the code is similar to the query of test plan, so omit here

// if the test case does not exist, create it
CQEntity entity = session.BuildEntity("TMConfiguredTestCase");
entity.SetFieldValue("testcase", testcaseId);
entity.SetFieldValue("headline", headline);
entity.SetFieldValue("configuration", configuration);

6. 创建 External File。

External File 实现脚本与 TC 或 CTC 之间的连接，因此在进行关联前必须被创建。下面的示例代码中，“fileLocationName”，“assetRegistry”和“rmtPath”的值是从用户界面上选取的，externalFileName 的值为第 2 步中的脚本名称。External File 的名称被返回以用于脚本关联。

// get the real path corresponding to fileLocationName
// similar to previous code, only change the SQL statement
String sql = "select distinct T1.scriptfileslocation from” +
 " tmfilelocation T1,tmassetregistry T2 where T1.assetregistry = T2.dbid and " +
 "(T1.dbid <> 0 and ((T2.name = '" + assetRegistry + "' and " +
 "T1.name = '" + fileLocationName + "')))";
…
scriptFileLoc = resultSet.GetColumnValue(1);

// get the full path of “rfile”. The naming rule of rfile is defined by CQ.
String rfile;
int index = scriptFileLoc.lastIndexOf("/");
scriptFileLoc = scriptFileLoc.substring(index + 1);
int length = scriptFileLoc.length();
int length2 = rmtPath.length();
if (length2 > length) { //if rmtPath is a sub directory of scriptFileLoc
 rfile = "rfile://" + fileLocationName + "/" + rmtPath.substring(length + 1) 
 + "\\" + externalFileName;
} else { 
 rfile = "rfile://" + fileLocationName + "\\" + externalFileName;
}

// query on this External File. Only need to change the SQL statement
sql = "select T1.fldcolumn from TMExternalFile T1 where T1.fldcolumn = '" + rfile + "'"; 

// if this External File does not exist, create it
session.SetNameValue("ExternalFileCreation", "true");
CQEntity entity = session.BuildEntity("TMExternalFile");
entity.SetFieldValue("File", rfile);
entity.SetFieldValue("FileLocation", assetRegistry + " " + fileLocationName);

7. 将脚本与 Test Case 相关联。

然后，通过 External File 和相应的 TC 的 ID，就可将脚本与 TC 相关联。此处脚本类型被设为“RMT”，它也可被设为其他脚本类型，例如“RFT”。

CQEntity entity = session.GetEntity("TMTestCase", tcId);
entity.EditEntity("modify");
entity.SetFieldValue("DefaultScript", externalFile);
entity.SetFieldValue("DefaultScriptType", "RMT");
entity.Validate();
entity.Commit();

8. 将脚本与 Configured Test Case 相关联。

用同样的方法可以将脚本与 CTC 相关联。

CQEntity entity = session.GetEntity("TMConfiguredTestCase", ctcId);
entity.EditEntity("modify");
entity.SetFieldValue("Script", externalFile);
entity.SetFieldValue("TestType", "RMT");
entity.Validate();
entity.Commit();

3.2 高级方案：从 Checklist 导入信息

方案描述

在 4.1 节中，我们已经解决如何批量的创建 Test Case（TC）和 Configured Test Case（CTC），并与脚本相关联。在本节中，我们将提供一个高级方案，以使得测试的准备更方便，流程更易管理。

在 CQTM 中，除了与测试脚本相关联以外，对于 TMTestCase 和 TMConfiguredTestCase 还有其他一些重要的信息，比如“Description”, “Iterations”, “Points”, “Owner”等，如图 9 所示。

我们当然可以在测试用例 (TC/CTC) 被创建后手动为每个用例输入上述信息，但这样做非常耗时，而且不易于统计所有用例的信息或在同一视图中对它们进行比较。为何不可在同一次创建过程中批量导入这些信息呢？

假定我们有一个关于所有测试用例信息的列表，那么我们就可以在同一视图中修改并管理它们。这会使得测试用例的准备和审查更为容易。更进一步的是，有了这样一个列表，我们就可以在短时间内将这些信息准确无误的导入到 CQTM 中。

这个方案在前述的普通方案的基础上增加了效率——首先创建一个列表，其中包含所有测试用例所需的信息；然后在创建 TC/CTC 时，就可同时将相应的信息导入到 CQTM 中。

Checklist 简介

Checklist 可以是 txt 格式，excel 格式或其他易于通过程序访问（仅需读取权限）的文件格式。

该文件的内容应当以类似表格的形式存在，每一行代表一个测试用例，每一列则代表测试用例的某个域的值。

图 10 是一个 txt 格式的文件示例：

在这种格式中，每个测试用例都从新的一行开始，每个域之间用逗号（，）分隔。如果某个域含有换行符或者逗号，则需要用一对双引号（“”）将其括住。

图 11 是一个 excel 格式的文件示例：

在这种格式中，每行代表一个测试用例，每列代表测试用例的一个域。标题（headline，与测试脚本名称相同）将用于匹配将在 CQTM 中创建的测试用例。

图 12 展示了该表格和 CQTM 之间的域映射 :

示例代码

高级方案中的步骤与普通方案类似，但加入了一些其他功能，以及更复杂的逻辑控制。基本步骤包括：

• 创建 CQSession 并登录；
• 从工作表获取脚本信息；（更多信息，例如 owner，Iteration，description，points 等）
• 创建 Test Plan；
• 创建 Test Case；
• 创建 Configured Test Case；
• 创建 File Location；
• 创建 External File；
• 将脚本与 Test Case 或 Configured Test Case 相关联。

以下示例代码阐述了与普通方案的一些主要不同点：

1. 创建 Iteration。

从工作表可以获取测试用例相关的迭代（Iteration）信息。如果该迭代在 CQTM 中不存在，则可以通过提供 startDate 和 endDate 来创建它。

session.SetNameValue("IterationCreation", "true");
CQEntity entity = session.BuildEntity("TMIteration");
entity.SetFieldValue("Name", iterationName);
entity.SetFieldValue("StartDate", startDate);
entity.SetFieldValue("EndDate", endDate);
entity.SetFieldValue("AssetRegistry", assetRegistry);
entity.Validate();
entity.Commit();

2. 创建 Test Plan/TC/CTC 时加入更多的信息。

由于从工作表中可以取得更多信息，因此可以尽可能的向 CQTM 中自动加入，以减少手动工作。以下列出一些可能添加的信息。
创建 Test Plan：owner 和 Iteration.

创建 Test Case：points, description, owner 和 Iteration.

创建 Configured Test Case：points, owner 和 Iteration.

以创建 Test Plan 为例：

entity.SetFieldValue("AssetRegistry", assetRegistry);
entity.SetFieldValue("Headline", headline);
entity.SetFieldValue("owner", owner); //owner information
entity.SetFieldValue("Iterations", iteration); //Iteration information

3. 创建 File Location。

可以创建 File Location 以供 External File 使用。此处需要定义一定的命名规则来区分不同的 File Location。其名字应被返回以在创建 External File 时使用。

// define fileLocName and fileLocation. The naming rules can be customized
String fileLocName = assetRegistry + "_" + iterationNo + "_" + phase;
String fileLocation = remote_path + "\\" + assetRegistry + "_" 
 + iterationNo + "_" + phase;
String testLogLocation = fileLocation;

// query on the File Location, only change the SQL statement
String sql = …

// if it does not exist, create it
session.SetNameValue("FileLocationCreation", "true");
CQEntity entity = session.BuildEntity("TMFileLocation");
entity.SetFieldValue("AssetRegistry", assetRegistry);
entity.SetFieldValue("Name", fileLocName);
entity.SetFieldValue("ScriptFilesLocation", "rfile://FileLocationURI/" + fileLocation);
entity.SetFieldValue("LogFilesLocation", "rfile://FileLocationURI/" + testLogLocation);
// the following two field values are necessary for a File Location entity
entity.SetFieldValue("AssetRegistryCMManaged", "0");
entity.SetFieldValue("LogsCMManaged", "0");

4. 创建 External File。

此项功能大部分与普通方案中相同，只有一点差异：External File 所用到的 File Location 名称不是直接指定，而是从第 3 步创建来的。因此 rfile 域的值可以直接计算出来：

// the naming rule can be customized
String rfile = "rfile://" + fileLocationName + "/" + component + "\\Scripts\\" 
+ externalFileName;

3.3 综合方案：使用 GenRMT 和 RMT2CQ 工具，从 TestCase 模板到 CQTM

方案描述

如果你只使用 RMT 来执行脚本而不想进行编辑，这个方案会很有帮助，因为它可以自动生成 RMT 脚本。这个方案把所有测试用例相关的信息收集到一个模板中，并基于它生成 RMT 脚本和 CQTM Test Case。除 RMT2CQ 以外，这个方案中还用到另外两个工具：TestCase 模板和 GenRMT。

什么是 TestCase 模板

TestCase 模板既是一个用来规范 TestCase 设计的 excel 规范表格又是一个用来存放 TestCase 的 excel 的表格文档。

在这个文档中，包含了例如测试用例的名称，描述，测试步骤，测试条件，测试属于的阶段，测试优先级等等信息。

在这个模板上完成的测试用例会作为后续工具所使用的数据来源。

本文提到的 TestCase 模板，因为不是本文的重点，在此不加以详细描述。请关注后续文章——《一个通用的测试用例模板》。

什么是 GenRMT

GenRMT 是一个从 TestCase 模板生成 .rmt 文件（RMT 脚本文件）的工具，并会将这些文件保存到一个本地目录中。脚本中的测试步骤即来自于 TestCase 模板。

这个工具的目的是，自动生成脚本，节省人工在 Rational Manual Tester 里面输入的时间并且避免输入错误。

生成的 .rmt 脚本既可以在 Rational Manual Tester 上打开并且执行，又可以作为 RMT2CQ 的输入而导入到 CQTM 中。

对于 GenRMT 的剖析和详细的设计信息，请关注后续文章——《如何实现 Rational Manual Tester 自动脚本生成》。

三个工具间的关系

如图 13 所示，TestCase 模板向 GenRMT 提供信息以生成 RMT 脚本，也向 RMT2CQ 提供信息以生成 CQTM Test Case 并关联 RMT 脚本。

如红色箭头所示，GenRMT 根据模板文件生成 RMT 脚本，RMT2CQ 再根据这些脚本以及模板文件来将脚本及测试用例信息导入到 CQTM 中。

蓝色箭头则表示了普通方案的做法，RMT2CQ 根据 RMT 脚本的路径来找到相应的脚本并在 CQTM 中生成 Test Case。

回页首

4. 未来的构想：CQTM 插件

在以上章节中，我们介绍了批量生成 CQTM Test Case 的三种解决方案。在实际项目中，这些方案以及模板文件、GenRMT 和 RMT2CQ 工具已经被应用并获得了极好的效果，工作完成效率得到了显著提高。经过测试，在局域网内的 CQTM 中创建 Test Case，每个用例大约花费的时间在 3-5 秒之间，相对于以前由测试人员手动添加并编辑测试计划、测试用例，效率提高在 90% 以上。在未来，为了更好的应用这些方案，可以考虑将这些工具可整合为 CQTM 的一个插件，或是其他易于使用的形式，以替代目前的应用程序。这对 CQTM 的测试用例准备方面将是一个有效的改进。

免责声明

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

参考资料

• 参考 IBM Rational ClearQuest 测试管理入门简介，第 1 部分 。
  
  
• 参考 IBM Rational ClearQuest 测试管理入门简介，第 2 部分。
  
  
• 访问 IBM developerWorks 中国网站 Rational 专区 了解更多关于 Rational 产品的信息。

作者简介

		陈元，IBM 软件工程师，在 IBM CDL SaaS (Software as a Service) 部门从事基于通用平台的解决方案的性能测试工作。

		夏丽丽，IBM 资深软件工程师,曾任 Rational 工具开发员,和 MBPS 解决方案测试负责人,现任 IBM CDL TaaS (Test as a Service) 经理。

		吕杨清，IBM 高级软件工程师，曾从事过多个行业的软件设计及开发相关工作多年，目前就职于 IBM CDL SaaS (Software as a Service) 部门，先后从事软件测试及软件售后技术支持工作。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首