如何使用 ClearQuest 中所包含的测试管理特性[2]

建立文件位置

　　文件位置就是保持外部文件路径的记录，其中包括测试脚本。文件位置指向网络共享，它们可以包括：IBM® Rational® ClearCase® 版本化的对象基础(VOBs)。　　　ClearQuest 测试管理所使用的外部文件的格式有如下两种类型：

测试激发因素
测试脚本

　　在设置文件位置之前，请您考虑如下这些因素，这是因为这些问题的答案将会对您如何建立文件位置产生影响。

　　使用什么脚本工具？
　　环境是否是地理分散的？
　　脚本的描述是一项必备的条件么？

　　测试激发因素是和测试努力相关的文档，例如一个项目进度表、一个需求文档、或者一个项目计划。如果您希望通过这些“项目驱动器”链接到 Test Plan Records 或者其他的测试资产，那么您应当为您的测试激发因素建立一个文件位置。这确实是一个可选的特性，而且 ClearQuest 测试管理能够在没有为测试激发因素建立文件位置的情况下被成功的配置。

　　ClearQuest 测试管理支持从 IBM® Rational® Manual Tester、Rational Functional Tester、Rational Performance Tester 以及 Eclipse TPTP 测试中生成的测试脚本的直接执行。如果您计划使用任何一种脚本格式的话，那么你将需要建立文件位置。

　　如果您的环境并不是地理上分散的，那么您能够使用一个本地的网络共享驱动或者位置来保存您的脚本。如果您的环境是地理上分散的，但是责任的划分是各个站点分别开发和执行它们自己的脚本，那么您能够通过为每一个站点建立分离的文件位置来解决这个问题。您应当为它们命名来指出位置。例如，在一个给定的资产注册中，您已经将一个文件位置取名为 Lexington RFT Scripts，为另一个文件位置取名为 Bangalore RFT Scripts。只要 Lexington 中的人员不需要访问 Bangalore 中的运行脚本，那么它们就会运作的很好。

　　如果您的环境是地理上分散的，并且远程站点需要访问同一组脚本或者激发因素文件，那么您就需要将这些文件保存在一个多站点的 ClearCase VOB 之中。这个文件位置将指向一个 ClearCase VOB，并且该单一文件位置将被所有访问这个特定资产注册的站点使用。

　　如果脚本的描述是一项必备条件的话，那么您必须将您的测试脚本保存到一个 ClearCase VOB 之中。ClearQuest 测试管理保持一个当您执行脚本时所使用的视图剖面的记录。并且它还同迭代紧密相联。如果脚本从一个迭代到下一次迭代发生变化的话，那么你能够打开被执行脚本的特定版本，从而得到一个特定的迭代。这样的话，特定测试用例的被执行的历史就被精确的保存了下来。如果审计是一项重点关注的内容的话，那么请您考虑将 Rational ClearCase 同 ClearQuest 测试管理联合使用。

　　文件位置尤其是指它们所属于的资产注册。这是它对于基于项目来构建资产注册具有重要意义的另一个原因，这是由于您希望用于指定项目的脚本文件能够位于一个共享的资源中。否则的话，您已经在每一个资产注册中建立相同的文件位置了，而不是仅仅对它指定一次。

配置

　　配置记录允许您识别构成给定测试环境下的唯一实例的变量的集合。在创建配置记录之前，您必须首先建立一组环境属性，并且为这些属性定义可能的值。例如，如果您知道您需要在一个变化语言的操作系统上进行测试，那么您就可能需要定义一个 Language 属性。然后您可能还需要创建诸如英语、德语、简体中文等的值。如果测试所横跨的操作系统的类型很重要的话，那么您就可能要创建一个 OS 属性，然后创建诸如 Windows、Linux 和 UNIX 等的值。这些操作系统的特定版本能够被构建进现已存在的值中，或者您可以定义另一个被称作 OS Version 的属性来捕获每一个操作系统的更多变异。在您使用属性和值捕获到可能的变化之后，您就能够选择它们的联合来创建一个配置记录。

　　您可以认为，您能够使用配置记录来捕获非常基本的系统属性，例如操作系统的类型、版本或者内存。您还能够使用它来定义更加复杂的环境，其中包括客户端浏览器类型和版本、服务器系统、Web 服务器、数据库类型、数据库版本，以及同其他应用程序的集成等等。仔细思考如何建立您的配置信息确实十分重要。如果您拥有过多的属性，并且您过细的定义它们的话，那么您将会被如此数量庞大的配置信息所困扰，而且维护工作也会相当的麻烦。如果您的资产注册中的每一个测试用例都被指派到不同的配置中的话，您还可以通过配置信息区分不同类别测试的效用。

　　如果测试下的应用程序仅仅在一个特定约束环境下运行的话，那么您就不需要建立不同的配置。相反，您能够通过一个默认的配置来使用 ClearQuest 测试管理。

　　关于配置，另外一件需要注意的重要的事情就是它们是被所有资产注册所共享的。如果您是在产品或者项目的基础上建立您的资产注册的话，那么这些项目将共享一个相似的配置集合，然后拥有一个能够被全球使用的公共集合，它是 ClearQuest 测试管理的一个非常方便的特性。无论如何，如果配置需要支持的资产注册差异非常巨大的话，那么您就需要提出一套命名约束，以便您能够区分哪一个配置应用到哪一个资产注册。您可以将这些配置的名称的前缀设定为它们所属的资产注册的缩写。

组织测试计划和测试用例

　　测试计划记录使您能够对相关的测试用例加以分类和分组。测试计划能够包含测试用例或者其他的子计划。假定您的资产注册是根据产品或者项目来命名的，那么一个好的对测试计划进行分类的模型就是根据产品组件或者特性区域来命名它们。如果您的测试跨越若干个特性区域的话，另一个分级建议就是根据测试的类型来命名它们（例如系统测试、性能测试、安装测试等等）。这些模型可以被一同使用，其中一些根据特性区域进行命名，另一些根据测试类型进行命名。这确实取决于组织。如同资产注册一样，避免创建那些根据特定发布而命名的测试计划。

测试计划

　　正如前面所提到的，测试计划能够包含测试用例或者其他测试计划。对于如何安排测试计划并没有特别的指导。如果您能够有效的把相关联的测试分组到子计划之中，那么这样做就是了。然而，要避免过度的嵌套，这是因为那样做将使得报告变得非常困难，并且还会使得在树形视图中的浏览变得非常麻烦。

　　ClearQuest 测试管理的最近版本在 Asset Browser 中按照字母顺序被排列整理。这使得您能够按照名称的数字前缀进行插入，以一种逻辑顺序组织测试计划、子计划和测试用例。举例说明，您能够创建一个计划的层级，如下所示：

01_Install Plan
02_Security Plan
02_01 Login Child Plan 1
02_02 Users Group Priv Plan 2 等等
03_Editor Plan 等等
　　一个诸如此类的层级能够使您报告属于一个指定计划的测试用例的状态，以及属于该计划的子计划的测试用例的状态。

　　如果测试计划和测试用例的顺序不是那么重要的话，那么使用编号方式的系统就显得太过麻烦了，另一种用于报告属于一个计划及其子计划的所有测试用例的方法就是，使用 Legacy 标签下的一个定制区域来制定能够被用来查询测试用例的关键词。例如，您可以将所有在 Security Plan 下被配置的测试用例以及那些在 Security Plan 的子计划下被配置的测试用例加以标注，在被配置的测试用例记录（在 Legacy 标签下）的定制区域中使用标签 SP。

(未完待续)