本系列的第 2 部分将向您介绍一个测试团队如何设置和定制测试管理工具、运行测试、然后使用报告功能。在 第 1 部分 中，我们已经学习了 IBM® Rational® ClearQuest® 测试管理的主要特性，并且为将测试团队的结构和组织考虑进来的执行提供了指导。

通过 第 1 部分 的背景知识的积累，我们已经对 IBM Rational ClearQuest 测试管理有了基本的认识，下面我们就使用 IBM® Rational® ClearQuest® 测试管理的特性来计划一个典型的测试。

为测试制定计划

场景：XYZ 公司拥有八个在建的软件项目。他们在 ClearQuest 测试管理中设置了八个资产注册。他们使用著名岛屿的名字作为项目的代号，于是资产注册也因此而的名（请参见图1）。其中两个项目（Aruba 和 Bermuda）拥有地理上分散的团队，所以 ClearQuest 管理员设置了 IBM® Rational® ClearQuest® MultiSite 使得远程团队能够对 ClearQuest 进行访问。

配置的标准化和命名的规范化

测试之下的所有软件产品都得到了三款最主要的平台的支持：Microsoft® Windows®、UNIX® 和 Linux®。由于配置是在所有资产注册中被共享的，所以项目管理者要共同决定能够适合所有项目的配置的集合。他们为这些全球配置使用一个前缀，用以指出全部的优先级。然而，其中两个项目要求唯一的配置。出于这个原因，除了将配置的全球集合统一用

图3显示了这个配置。

迭代名称的协调使用

项目管理者的下一项任务就是协调迭代名称的使用。对命名约定进行标准化将使得横跨多个项目的报告成为可能，特别是被包括在同一个发布中的项目更是如此。在被管理的八个项目之中，有四个是在同一个软件发布中的，另外四个则是独立的产品。所有项目都遵循相似的过程；因此，管理者设计一个命名约定，它包括主要的发布版本和次要的发布版本，以及开发和测试阶段。由于迭代是针对一个特定的资产注册的，所以它们需要在每一个资产注册中创建必要的迭代。

前面四个项目（Aruba、Bermuda、Fiji 和 Hawaii）是发布4、版本2的全部组成部分。Aruba 和 Bermuda 仍处于建造阶段，正在进行功能性确认测试。Fiji 和 Hawaii 正处于系统确认测试阶段。因此它们将为这些项目创建以下迭代：

• Aruba： Rel4_V2_C1FVT. Rel4_V2_C2FVT；
• Bermuda： Rel4_V2_C1FVT. Rel4_V2_C2FVT；
• Fiji： Rel4_V2_TSVT1；
• Hawaii： Rel4_V2_TSVT1；

当这些团队在发布周期中前行的时候，他们能够通过遵守相同的命名约定添加迭代。通过这样做，他们将能够运行或者基于测试阶段或者基于横跨特定版本的更高层级的报告。请注意，在不同的资产注册中拥有相同名称的迭代没有问题。在这个场景的后面，ClearQuest 测试管理将自动将资产注册名称作为前缀添加到迭代名称中，所以 XYZ 团队总是能够区分出彼此。

其余的项目均是独立的产品，他们分散在不同的发布进度之上。然而，处于一贯性的考虑，管理者也应当遵循相同的命名约定。用于这些项目的迭代设置如下：

• Iceland： Rel8_V1_C1FVT；
• Maui: Rel5_V7_C1FVT；
• Nantucket: Rel3_V6_TSVT1
• Puerto Rico: Rel3_V2_TSVT1

决定将脚本保存到哪里

当项目管理者调整配置和迭代的时候，ClearQuest 管理员正在同测试领导者一起决定存储测试脚本的需求。大多数团队使用 IBM® Rational® Manual Tester 作为脚本的端到端的系统级测试。这些团队需要建立一个本地服务器来保存他们的 Rational Manual Tester 脚本。在他们的资产注册中，他们建立一个指向包括脚本的服务器的文件位置

对于 Aruba 项目来说，测试团队是地理上分散的，但是每一个团队都负责他们各自脚本的创建和执行。脚本并不需要被跨位置的分享。在这张情况下，他们在 Aruba 资产注册中建立了两个文件位置。一个位于 Location 1，另一个位于 Location 2。

Bermuda 项目团队也是地理上分散的，他们使用 IBM® Rational® Functional Tester。然而，对于这支团队来说，一个站点开发 Rational Functional Tester 脚本，另一个远程站点负责运行测试。在这种情况下，两个站点都需要访问同一个脚本：因此，他们使用 IBM® Rational® ClearCase® 并且将 Rational Functional Tester 脚本保存在一个多站点的 ClearCase 版本对象库（VOB）中。在他们的环境下，一个文件位置需要被建立指向一个 ClearCase VOB。

建立测试计划的层级

与此同时，随着配置、迭代和文件位置被最终确定下来，测试领导者开始将他们即将发布的计划放到 ClearQuest 测试管理之中。用于功能性测试的测试计划根据特性区域被分类。有些团队还需要进行系统级的测试，所以他们将端对端测试组织到一个测试计划文件夹中。性能团队负责若干项目的测试计划，所以他们有规律的让用户访问不止一个的资产注册。由于测试团队希望将同一个测试计划层级保持在所有被他们所使用的资产注册中，所以他们在资产注册中创建了一个层级，然后使用 Duplicate（复制）特性将该层级拷贝到其他的资产注册中。

用于 Fiji 资产注册的测试计划的层级如图4所示。

请注意性能测试计划下面的子计划：

• Performance（性能）
  • 01_Optimum Env
  • 02_Stress
  • 03_Load

测试领导者希望这些能够以某种逻辑顺序被排列出来。ClearQuest 测试管理按照字母顺序列出了各个资产。因此，当这些测试计划被创建的时候，它们将被添加上两个阿拉伯数字作为前缀，以便显示在一个以特定顺序排列的列表中。

添加测试用例

在测试计划层级被建立之后，测试设计者就能够开始添加测试用例了。在他们创建测试用例的过程中，如果他们知道某个测试用例的所有被配置的版本都将完全共享同一个测试脚本的话，那么他们将开发这个测试脚本，并且将测试脚本同测试用例相关联。通过完成这写操作，被配置的测试用例将会继承脚本的关联。这样就能够节省大量的时间。

请注意：
当测试设计人员处于这个阶段的时候，如果您使用 Rational Manual Tester 或者 Rational Functional Tester 编写脚本，将会对从 Rational Manual Tester 或者 Rational Functional Tester 界面中运行 ClearQuest 测试管理具有特别的意义。这样的话，您就能够在 ClearQuest 测试管理中无缝地从设计和编写移动到测试用例开发。当然，您能够完成目前为止来自 Rational Manual Tester 或者 Rational Functional Tester 界面中的所有这些被讨论的测试计划。然而，ClearQuest 测试管理的一个最佳的特性就是，如果您的刚层级计划是由一个项目管理者完成的，或者团队领导者并没有安装脚本工具，那么他或者她无需安装脚本工具就能够使用 ClearQuest 测试管理为编写脚本之前的所有步骤而提供的丰富的客户端版本。在事情的另一方面，测试设计者能够享受到 ClearQuest 测试管理从与测试脚本工具相同的界面中运行所带来的便利。

创建配置测试用例

在测试用例被设置之后，团队就能够开始通过配置来标记他们的测试用例，并且创建被配置过的测试用例（CTC）。如果他们拥有多个将要运行在同一个平台上的测试用例的话，那么他们能够同时选择多个配置，并且将这些配置批量应用到平台上。这样做可以节省大量的时间。

图 5 显示了属于已经被配置到两个特定平台上的场景辅助计划的测试用例。请注意，这个屏幕捕获显示了一幅来自 Rational Manual Tester 中的 ClearQuest 测试管理的视图。

在测试计划中，团队的最后一个步骤涉及到通过迭代“标注”他们的被配置的测试用例。这是他们能够轻易的成批选择若干个 CTC 并且将其同一个或者多个迭代相关联的另一个步骤。在完成这个操作之后，他们就能够创建查询和报告，显示他们所计划的被配置的测试用例。（详细内容将在下一小节中介绍。）

创建查询来显示被计划的测试

当他们完成您的计划之后，团队希望看到他们为迭代所计划的所有的 CTC。他们能够创建一个查询来显示关于 CTC 的如下重要信息：

1. 他们需要查询的记录类型是 TMConfiguredTestCase。
2. 最小化时，他们将基于迭代进行过滤，但是他们能够从各种不同的重要域中选择将哪些内容显示在查询中。

图6显示了一个例子查询，它返回为迭代而计划的 CTC，但是显示双亲测试用例和双亲测试计划。所使用的显示域如下所示：

TestCase.ParentPlan.PlarentPlan.Headline 
TestCase.ParentPlan.Headline
TestCase.Headline
ID
Headline
Configuration
Owner
TestType
Script

前三个域名称以及 Headline 域按照升序进行排序，即从1到4。其他的域则是无序的。

运行这一测试域，结果如图7中所示。

您能够从这一查询中指出21个计划的测试中有9个没有同测试脚本相关联。这提示我们还需要完成一些额外的计划。

提示：
ClearQuest 的另外一个特性就是从 Query Results 视图中批量修改记录的能力。根据图7中的屏幕捕获，您能够看到，当前所有被配置的测试用例都被指派为 Admin。在批量模式中，您现在能够选择查询结果中的多个行，并且修改 CTC，将它们指派到其合法的拥有者。如果资源被搅乱或者测试用例需要被指派到新的所有者的话，这将是一个非常有用的特性。

运行测试

当团队已经完成了测试、通过合适的迭代标注测试、并且将它们指派到适当的所有者等操作之后，就可以开始进行测试了。管理员能够对前一小节中所使用的查询进行修改，从而为当前用户显示被计划的测试用例。每一个测试人员能够导入并且运行该查询，显示他们拥有的为迭代而被指派的测试。查询在测试下的迭代进行过滤，并且将所有者设置为 [当前用户]。这样，当前登录的用户就能够运行该查询，并且看到哪些计划的测试被指派。

我们举例来说明，Jane 正在 Microsoft Windows 上为 Fiji 项目进行 Rel4_V2_TSVT1 迭代的系统测试。她的查询将返回图8所示的内容。

现在，Jane 能够轻易的看到她所负责运行的完整列表。请注意，她正在查看来自 Rational Manual Tester 中的所有的 ClearQuest 数据。她能够从这个查询中直接执行，也可以返回到属性图表中从那里运行她的测试。她决定从她的 My Planned Tests - ClearQuest Query Results 视图中执行。

1. 她选中一行，并且在下拉菜单中选择 Execute。
2. Execute Test 将会立刻显示出来。

由于 CTC 同不止一个的迭代相关联，所以 Jane 需要选择一个正确的迭代同测试日志关联起来。她还需要识别建造编号。

3. 如果以前已经完成了对建造的创建，那么她就能够从列表中进行选择。否则，她就要在运行时创建它。

建造记录也需要遵守某种命名约束以保证一致性。Jane 不希望用特定的迭代或者测试阶段来识别一个建造，这是因为还有其他的团队使用同一个建造流，但是他们由于测试进度的不同而运行不同的迭代。

4. 因此，她根据建造编号来命名，并且将主要发布和版本标识符 Rel4_V2_B2353 作为它的前缀（请参见图9）。

5. Jane 点击 Execute test 窗口中的 Finish，Rational Manual Tester 脚本将会被显示出来。
6. 她录制了她的确认点，并且完成了此次测试。

结果将被显示在 Test Results 视图中。此处，Jane 需要决定结果是否有效，以及这是否是她希望提交到数据库中的结果。在本例中的情况下，测试是失败的。Jane 决定不将失败的结果提交到测试日志中，并且她还希望记录这个缺陷。

7. 从 Test Results 视图中，她使用下拉菜单点击 Submit Defect。

启动 New Defect 窗口。在新的缺陷被保存之后，它还要提交测试日志记录。测试日志记录将被与新的被创建的缺陷相关联。

8. 从这个视图中，她能够选择打开其中一个日志。
9. 在测试日志中，她能够直接定位到脚本的日志文件，并且从测试日志中查看任何相关联的缺陷。

提示：
您还能够从测试工具中直接运行测试脚本，然后将其结果导入到 ClearQuest 测试管理之中。这种方法将使您能够通过导入一个脚本日志，创建并且提交一个测试日志。这是将 ClearQuest 同可能远程执行它的测试团队集成起来的另一种方法。

在团队中的所有测试人员都要完成执行测试的这些过程，然后将结果和测试日志记录提交到给定迭代的数据库之中。

通过 ClearQuest 测试管理的有用的报告

至此，XYZ 公司团队已经开始了对测试的运行，他们希望能够报告进度。测试领导者希望看到所有已经被执行的 CTC 的完整列表，以及它们的执行结果。ClearQuest 测试管理包括一个 Public Folders 区域下的 TM Queries 文件夹下的查询，它可以作为一个起始点。它被称作“Configured Test Cases —— 测试结果历史记录”，该查询如图11所示。

如果团队不做任何修改的运行这个查询，那么它将使得测试领导者能够选择一个或者多个资产注册，并且看到在被选中的资产注册中曾经被执行的所有的测试的结果历史。图12显示了用于 Fiji 资产注册的默认查询的结果。

请注意上图显示了横跨一个以上迭代的结果历史。尽管这一查询非常有用，但是测试领导者真正希望看到的是测试下的当前迭代的结果历史。为了完成这一操作，测试领导者可以通过两种方式对查询进行修改：

• 改变过滤器，从而总是专门查询 Fiji 资产注册；
• 改变过滤器，为被指派到测试日志（TestLogs.Iteration）中的迭代添加一个校对。

新的查询如图13所示。

新的查询返回的结果如图14所示。

至此，测试领导者能够只查看到两个为 Fiji 项目而运行的 Rel4_V2_TSVT1 迭代的场景。假定查询包括一个用于 TestLogs.Latest=True 的过滤器，那么它将只返回最近被提交到给定迭代的每个测试的那个结果。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 查看本系列第 1 部分：IBM Rational ClearQuest 测试管理入门简介，第 1 部分: 如何使用 ClearQuest 中所包含的测试管理特性。
• 如果希望得到关于 IBM Rational ClearQuest 的更多测试管理功能，请您访问教程： 使用 Rational ClearQuest TestManager 运行并分析软件测试，它是由 Brian Bryson 于 2007 年 8 月撰写的一份 IBM® developerWorks® 教程。
• 常见问题解答：FAQ: 使用 IBM Rational ClearQuest 版本 7 进行企业测试管理
• 请您访问： developerWorks 上的 Rational 软件专区，获得 Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
• 通过 Rational 测试解决方案专题，了解 Rational 的软件测试解决方案。
• IBM Rational 测试工具包：了解并下载 ClearQuest 测试管理工具。
• 请您浏览： 技术书店 获得这方面以及其他技术主题的书籍。

• ClearQuest 用户和管理员能够在 developerWorks Rational ClearQuest 产品专题 中的 ClearQuest 小节中获得更多的资源，其中包括 hooks、Eclipse 插件程序、产品文档、文章和白皮书。
• 请您点击此处下载： IBM Rational 软件的试用版。

• 参与论坛讨论。
• 请您点击此处参与： Rational ClearQuest 论坛。 在这个 developerWorks 上 的 ClearQuest 社区中，您能够从其他的 ClearQuest 使用者那里获得解答、建议或者意见。如果您想通过电子邮件参与其中的话，那么请您发送邮件到 clearquest-subscribe@lists.ca.ibm.com。订阅用户可以发送邮件到 clearquest@lists.ca.ibm.com。
• 请您点击此处加入： Test Management 论坛。 在这个论坛中，您可以就管理测试资产和 Rational TestManager 的各方面问题进行讨论。可以提出问题，也可以分享经验。如果您想通过电子邮件参与其中的话，那么请您首先发送邮件到 tm-subscribe@lists.ca.ibm.com。订阅用户可以发送邮件到 tm@lists.ca.ibm.com。

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

京公海网安备110108001071号