| UML软件工程组织 | |||
| |
|||
|
|||
如何使用 ClearQuest 中所包含的测试管理特性
2008-03-10 作者：Susan Manupelli 来源：IBM
获得使用 IBM® Rational® ClearQuest® 测试管理特性的经验，并且学习如何在考虑到测试的组织结构的情况下最大程度的利用这些测试管理特性。 IBM® Rational® ClearQuest® 的测试管理特性为您提供一种计划、组织和定义某一组特定测试的工具，其中包括改变需要在一个给定的测试周期中被运行的配置信息。这使得您能够紧紧跟踪测试过程，以便管理资源和进度。这一特性还提供了一种根据横跨若干关键区域所报告的组织结构来进行质量测量的机制。 如果您通过 Enterprise 模型设置 ClearQuest，那么 ClearQuest 测试管理将被包括进来。如果您通过任何其他的模型或者是一个定制的模型来设置 ClearQuest，那么您就能够将 ClearQuest 测试管理包应用到本文所描述的特性之中。 在本文的第 1 部分中，我们将学习 ClearQuest 测试管理的主要特性，并且为将测试团队的结构和组织考虑进来的执行提供指导。 在本文的 第 2 部分 中，我们将逐步学习 ClearQuest 测试管理在一个实际环境中的执行。请注意，本文将不会介绍产品的安装，而是介绍在 ClearQuest 测试管理安装之后的测试资产的创建和组织。它将为读者呈现从 Asset Registry（资产注册） 的创建到 Test Logs（测试日值） 的回顾的一个完整的测试周期。 开始在配置 ClearQuest 测试管理之前，首先思考如何回答以下这些问题：
在您阅读本文的过程中，如何组织您的 ClearQuest 测试管理配置将依赖于您对这些问题的回答。 ClearQuest 客户端软件选项ClearQuest 提供了若干种不同的客户端软件选项。并不是所有的 ClearQuest 测试管理特性都会出现在所有的客户端中；因此，用户的角色就是决定哪一款客户端是自己最佳的选择。下面是可供选择的 ClearQuest 客户端，旁边伴有该 ClearQuest 测试管理的使用注释： 提示：
组织 ClearQuest 测试管理资产当决定如何组织您的测试资产的时候（更明确地说，即测试计划和测试用例的集合），首先应当考虑对它们进行分类和分组的方式。您能够想象出许多种不同的测试资产分类方法——例如，可以是通过产品或者项目进行分类，通过测试人员进行分类，或者是通过测试的类型进行分类。对于这一点并没有什么限制。因此，问题转变为什么将能够使您最大程度的利用 ClearQuest 测试管理中所提供的各种特性，并且确保测试尽可能的被有效的管理？下一小节将描述一个运转良好的模型，在您构造测试层级的同时也伴随着避免常见缺陷的警报。 资产注册对于分组 ClearQuest 测试管理中的测试资产来说是一个最大的容器。该模型是已经被证明过的，它基于由 IBM 测试团队所进行的 ClearQuest 测试管理的内部使用，其目的是将 Asset Registry 作为一个用于同指定项目或者产品相关的所有测试资产的容器。对于一个特定的项目或者产品，一些测试产品和测试资源是共享的，它们是：
在 ClearQuest 测试管理中有一些用于跟踪上述每一个产品或者资源的特定的特性。在下一小节中，您将看到如何使用现已存在的记录类型来覆盖这些公共区域。 一个应该避免的公共缺陷就是为同一个产品的不同发布分别创建资产注册。如果您这样做的话，那么您将立即设置一个分级，它要求您将测试资产从一个资产注册中复制到另一个资产注册中，当您从同一个产品的一个发布移动到另一个发布的时候，将会分离资产注册。当测试资产的每一个新版本都成指数趋势增长的时候，你将陷入到 ClearQuest 测试管理的环境之中。您将无法利用一个指定测试用例经历若干个发布之后的跟踪执行历史，这是因为当一个测试用例被复制的时候，执行日志文件的结果并不被复制。最终，您将损失 ClearQuest 测试管理为从一个发布到另一个发布对测试资产进行复用而提供的功效。 提示： 另一个要避免的缺陷就是为每一位用户都分别创建一个资产注册。除非用户按照各自的发布进度独立操作各自的项目，否则不应当为每位用户都建立一个不同的资产注册。标准的 ClearQuest 测试管理形式允许您将每位拥有者分配到每一个测试资产的类型中。这是一种跟踪哪一个测试属于哪一位所有者，以及所有者的全部测试过程的好方法。 ClearQuest 测试管理中的一个迭代允许您识别一个指定的测试周期，以及开始和结束日期。当迭代被适当的管理和使用的时候，您将从 ClearQuest 测试管理中获得最大的利益。迭代使得您能够跟踪同一产品在并行开发和测试周期中运行的多个测试阶段的进度。迭代还能够使您最大程度的对测试用例进行复用。 迭代记录的目的就是允许您以一种同一个指定的测试周期相关联的方式“标记”其他测试资产。测试计划、测试用例、以及被配置的测试用例都能够被一个或者多个迭代进行标记。然后，您能够生成报告来显示哪一个测试资产被用于（或者将被用于）一个给定的测试周期。在一个给定的资产注册下被创建的迭代只能在同一个注册内适用。 如果您使用结构化的命名约定的话，那么您就能够更加强有力的使用迭代。一个意味深长的命名约定不仅能够辨别指定的测试周期，而且能够根据组织结构报告辨别出该测试周期所属于的最大和最小发布。下面我们来看一个如何发展命名约定的例子：
提示：
这一约定，在您的产品或者项目属于一次性定制开发努力的情况下，可能已经足够了。然而，如果您希望您将要测试的产品拥有新的最大或者最小维护发布的话，那么您需要复用尽可能多的测试资产。
结果是，迭代名称将同这个类似，它指出最大的是 Release 4、Version 2、Transition System Verification Test 周期二：Rel4_V2_TSVT2。 这样一来，您就拥有了一个能够被标注的测试用例，并且它因此能够被更多的发布所跟踪，即使这些发布是并行运行的也没有问题。它还使您能够打开一个被配制的测试用例记录，并且查看测试用例横跨若干版本和发布的测试运行结果历史。 我们说，您拥有不止一个资产注册来跟踪不止一个产品，而且这些产品都参与到了一个指定的主要发布之中。使用一个命名约定包括主要发布允许您跨越多个资产注册来为一个给定的主要发布查询测试结果。 重要提示： 迭代尤其是指创建它们的资产注册。您能够让一个迭代属于一个资产注册，而名称相同的另一个迭代属于另一个不同的资产注册。当浏览迭代名称时，ClearQuest 自动地将资产注册的名称添加到迭代名称前面，从而在彼此之间以示区别。 文件位置就是保持外部文件路径的记录，其中包括测试脚本。文件位置指向网络共享，它们可以包括：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 中按照字母顺序被排列整理。这使得您能够按照名称的数字前缀进行插入，以一种逻辑顺序组织测试计划、子计划和测试用例。举例说明，您能够创建一个计划的层级，如下所示：
一个诸如此类的层级能够使您报告属于一个指定计划的测试用例的状态，以及属于该计划的子计划的测试用例的状态。 如果测试计划和测试用例的顺序不是那么重要的话，那么使用编号方式的系统就显得太过麻烦了，另一种用于报告属于一个计划及其子计划的所有测试用例的方法就是，使用 Legacy 标签下的一个定制区域来制定能够被用来查询测试用例的关键词。例如，您可以将所有在 Security Plan 下被配置的测试用例以及那些在 Security Plan 的子计划下被配置的测试用例加以标注，在被配置的测试用例记录（在 Legacy 标签下）的定制区域中使用标签 SP。 测试用例记录的作用是使您识别与一个特定测试相关的信息。关于最重要的测试用例的信息就是标题和描述，标题将显示在文件夹中（树形），而描述将识别测试用例的目的。 测试用例是测试计划的子结点。每一个测试用例记录必须只属于一个父测试计划记录。被配置的测试用例是由测试用例产生的。被配置的测试用例是在您将一个特定的配置关联到一个特定的测试用例时被创建的。你可以通过在树形视图中选择一个测试用例，并且选中 Add configuration 选项来完成这项操作。如果您愿意的话，您还可以打开一个测试用例记录并且将其关联到配置。当您执行这些操作时，树形视图将会立即被加载上测试用例特定的被配置的版本。 如果您使用测试脚本的话，并且您期望同一个脚本能够被测试用例的每一个被配置的版本所使用，那么最好在添加配置之前，将脚本添加到父测试用例中。这样的话，被配置的测试用例将会继承定义在父测试用例中的脚本。这就在构建您的测试用例的集合过程中节省了大量的时间。如果您需要为属于同一个父测试用例的每一个被配置的测试用例建立不同的脚本的话，那么这些脚本将在您创建被配置的测试用例之后被关联起来。 随着您的测试周期的发展，您可能需要将测试用例从一个测试计划移动到另一个测试计划。如果要这样做的话，您只需重新指定父测试用例即可：
这样做将会把测试用例的双亲改变为被选中的新计划。唯一改变的事情就是测试用例记录的双亲的关系。并没有新的记录被创建出来。现在，测试用例将会在树形视图中出现在它们的新双亲的下面。这一操作既不移动任何相关联的脚本，也不移动任何相关联的外部文档。
复制一个测试用例既不需要保留任何到原始版本的引用，也不需要将引用复制到测试日志中。测试日志仅仅能够同一个测试用例相关联。因此，假如您拥有为一个给定的发布被执行的测试用例，那么如果您将这个测试用例复制到一个新的发布的文件夹下的话，它将不会保留任何日志信息。您将不能够回答那个测试用例是否在以前被运行过，以及以前的结果是什么等问题。正如本文最开始所提到的，当您移动到一个新的发布或者迭代的时候，您最好不要使用 Duplicate 特性来复制一组测试计划和测试用例。更好的办法是为您的项目保留一组测试计划和测试用例，并且为每一次迭代对它们进行标记，正如前一小节所描述的那样，有效地使用迭代。这样的话，您只需要打开一个被配置的测试用例，并且查看相关联的日志文件，就可以看到所有发布的执行结果。 测试资产的复制是一个十分便利的特性，例如，您为组织测试计划创建一个目录结构，您希望将其作为同一个项目中或者同一个资产注册下不同项目中的其他测试计划的分类模板。您能够创建一次占位符，然后将其复制到每一个测试计划中（当计划被实际实施时，标题和其他元数据将将被修改）。 测试计划、测试用例，以及被配置的测试用例（CTC）记录都拥有一个 Owner 域。默认情况下，创建该资产的人就是所有者。如果您使用所有权域的话，将很容易创建允许您跟踪状态的查询。由于被配置的测试用例才是您将要实际运行的，所以一个好的实践就是适当的在 CTC 上设置所有权。用户能够轻易的创建查询来查看他们自己的 CTC，因此他们能够轻易的看到哪些需要被执行。同样地，管理人员能够通过整个团队的所有者运行查询和报告来核对状态。如果在资源方面发生变化的话，也很容易从查询结果中多选几个记录，并且将若干 CTC 的所有权成批的改变为一个新的所有者。 每一个测试计划、测试用例、以及被配置的测试用例都拥有一个 State 域。根据资产得不同，它们所提供的状态也有所区别。 对于测试计划来说，有以下三种可能的状态：
对于测试实例来说，有以下两种可能的状态：
被配置的测试用例具有以下三种可能的状态：
对于给定的测试资产只能设定一种状态，理解这一点非常重要。这是测试管理模型的一个限制。您不能够在每一次迭代中为一个资产定义不同的状态。如果您一次只工作在一个迭代上的话，就不存在这个问题了。然而，如果您交叠或者并行测试的话，您可能在计划下一次迭代的同时为这一次迭代执行一个被认可的测试，那么您可能希望拥有一种能够识别一种以上状态的方法。如果您的计划要求您修改 CTC 来满足新的功能性的话，您可能希望将 CTC 的状态从 Implemented 变回 Draft。如果您这样做的话，测试将会显示为 Draft，即使它已经被前一个迭代执行。 请注意： 如果您希望将一组测试用例识别为闭塞的的话，状态域就将变得很便利。如果存在闭塞的测试，那么您就能够同时选择若干个 CTC 并且将它们一同标注为闭塞的。随后，您就能够使用 Blocked（闭塞的）域来轻易的在当前闭塞的 CTC 上进行查询。 正如前面所描述的，ClearQuest 测试管理允许您将多个迭代同一个被配置的测试用例关联起来。当您运行测试和记录结果的时候，您识别出该结果应当被应用到哪一个迭代中。在一个迭代的过程期间，您可能多次返回一个 CTC 的不同结果。为了跟踪最终的裁决，测试日志记录拥有一个被称作 Latest 的域，其值可以为“真”或者“假”。当您将一个新的测试日志提交到数据库的时候，ClearQuest 就会通过运行一个搜索来决定是否存在一个用于同一个被配置的测试用例和同一个迭代的日志文件。如果找到的话，它就将旧的测试日志记录中的 Latest 域设置为“假”，并且将新的测试日志记录中的 Latest 设置为“真”。对于一个给定的 CTC 和迭代，在 Latest 标记中应该只有一个被设置为“真”。同样地，每一次迭代都拥有一个给定 CTC 的裁决。 正如您将在 第 2 部分 中的报告一节中所看到的，理解 Latest 标记非常重要。当您报告结果时，您需要确保测试日志中只有一个 Latest 域被设置为“真”，以便您总是能够获得您所报告的迭代的最近的测试结果。 结束一个测试周期同时开始另一个新的测试周期第 2 部分 将向您介绍一支测试团队如何使用标准的模型来配置 ClearQuest 测试管理，并且完成一个从计划到执行的完整的测试周期。通过适当的基础结构、层级和命名约束，移动到下一次迭代或者测试阶段将变得非常顺利。
正如您所能看到的，从一个迭代移动到下一个是非常简单的。通过仔细的思考和计划您的 ClearQuest 配置，包括建立有意义的命名约定，您将真正能够完全释放出 ClearQuest 测试管理的巨大能量。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
