|
|
如何使用 ClearQuest 中所包含的测试管理特性[3]本文关键字 ClearQuest 测试用例和配置测试用例 测试用例记录的作用是使您识别与一个特定测试相关的信息。关于最重要的测试用例的信息就是标题和描述，标题将显示在文件夹中（树形），而描述将识别测试用例的目的。 测试用例是测试计划的子结点。每一个测试用例记录必须只属于一个父测试计划记录。被配置的测试用例是由测试用例产生的。被配置的测试用例是在您将一个特定的配置关联到一个特定的测试用例时被创建的。你可以通过在树形视图中选择一个测试用例，并且选中 Add configuration 选项来完成这项操作。如果您愿意的话，您还可以打开一个测试用例记录并且将其关联到配置。当您执行这些操作时，树形视图将会立即被加载上测试用例特定的被配置的版本。 如果您使用测试脚本的话，并且您期望同一个脚本能够被测试用例的每一个被配置的版本所使用，那么最好在添加配置之前，将脚本添加到父测试用例中。这样的话，被配置的测试用例将会继承定义在父测试用例中的脚本。这就在构建您的测试用例的集合过程中节省了大量的时间。如果您需要为属于同一个父测试用例的每一个被配置的测试用例建立不同的脚本的话，那么这些脚本将在您创建被配置的测试用例之后被关联起来。 重组测试资产 随着您的测试周期的发展，您可能需要将测试用例从一个测试计划移动到另一个测试计划。如果要这样做的话，您只需重新指定父测试用例即可： 同时选择若干个测试用例； 复制一个测试用例既不需要保留任何到原始版本的引用，也不需要将引用复制到测试日志中。测试日志仅仅能够同一个测试用例相关联。因此，假如您拥有为一个给定的发布被执行的测试用例，那么如果您将这个测试用例复制到一个新的发布的文件夹下的话，它将不会保留任何日志信息。您将不能够回答那个测试用例是否在以前被运行过，以及以前的结果是什么等问题。正如本文最开始所提到的，当您移动到一个新的发布或者迭代的时候，您最好不要使用 Duplicate 特性来复制一组测试计划和测试用例。更好的办法是为您的项目保留一组测试计划和测试用例，并且为每一次迭代对它们进行标记，正如前一小节所描述的那样，有效地使用迭代。这样的话，您只需要打开一个被配置的测试用例，并且查看相关联的日志文件，就可以看到所有发布的执行结果。 测试资产的复制是一个十分便利的特性，例如，您为组织测试计划创建一个目录结构，您希望将其作为同一个项目中或者同一个资产注册下不同项目中的其他测试计划的分类模板。您能够创建一次占位符，然后将其复制到每一个测试计划中（当计划被实际实施时，标题和其他元数据将将被修改）。 测试资产的所有权 测试计划、测试用例，以及被配置的测试用例（CTC）记录都拥有一个 Owner 域。默认情况下，创建该资产的人就是所有者。如果您使用所有权域的话，将很容易创建允许您跟踪状态的查询。由于被配置的测试用例才是您将要实际运行的，所以一个好的实践就是适当的在 CTC 上设置所有权。用户能够轻易的创建查询来查看他们自己的 CTC，因此他们能够轻易的看到哪些需要被执行。同样地，管理人员能够通过整个团队的所有者运行查询和报告来核对状态。如果在资源方面发生变化的话，也很容易从查询结果中多选几个记录，并且将若干 CTC 的所有权成批的改变为一个新的所有者。 测试资产的状态 每一个测试计划、测试用例、以及被配置的测试用例都拥有一个 State 域。根据资产得不同，它们所提供的状态也有所区别。 对于测试计划来说，有以下三种可能的状态： Draft（默认值） 对于测试实例来说，有以下两种可能的状态： Draft（默认值） 被配置的测试用例具有以下三种可能的状态： Draft（默认值） 对于给定的测试资产只能设定一种状态，理解这一点非常重要。这是测试管理模型的一个限制。您不能够在每一次迭代中为一个资产定义不同的状态。如果您一次只工作在一个迭代上的话，就不存在这个问题了。然而，如果您交叠或者并行测试的话，您可能在计划下一次迭代的同时为这一次迭代执行一个被认可的测试，那么您可能希望拥有一种能够识别一种以上状态的方法。如果您的计划要求您修改 CTC 来满足新的功能性的话，您可能希望将 CTC 的状态从 Implemented 变回 Draft。如果您这样做的话，测试将会显示为 Draft，即使它已经被前一个迭代执行。 请注意： 如果您希望将一组测试用例识别为闭塞的的话，状态域就将变得很便利。如果存在闭塞的测试，那么您就能够同时选择若干个 CTC 并且将它们一同标注为闭塞的。随后，您就能够使用 Blocked（闭塞的）域来轻易的在当前闭塞的 CTC 上进行查询。 (未完待续) |
|
|
||