从用例到测试用例的追踪(5)

　　测试用例的分配可以在测试用例分配表格中描绘，如表 4所示。

　　表 4 描述了图11中每列包含不同的测试用例。每一行相应的是用户输入的变量。

　　步骤 4：为变量赋值

　　在此步中，你替换如"一个非常长的名字" 或"扩展很长的电话号码"这样的占位符为像"Georgiamitsopolis" 和 "011-48 (242) 425-3456 ext. 1234"这样实际有价值的东西。在此步，你还可以分裂表 4所示的表格中的测试用例，为每个测试用例创建独立的表格。

　　如书籍订购使用用例的测试用例 1，你就可以创建一个像表 5这样的表格。这就给你的测试者创建一个文档。测试者将跟随总队2和3的方向，并且记录纵队5，6，7的结果。

　　表 5：最终的测试用例

　　RequisitePro再一次帮助你创建追踪关系。在产生了全部的测试用例以后，你可以设置从场景到测试用例的追踪。

　　图 12显示了全部的场景：从不同的可选流程合并中产生21个场景。

　　图12 ：追踪矩阵

　　在设置了场景和测试用例之间的追踪关系后，我们可以创建一个显示从用例到测试用例全部追踪方法的追踪树。

　　这里有两个选项。第一个选项——如图 13显示——用于追踪到用例外，用来显示上层的用例并且追踪场景和测试用例。

　　图 13：用例的追踪树

　　第二个方法是测试用例中的追踪，如图14所示。在此种情况下，追踪树看起来会有不同：你从测试用例开始，然后追踪场景和用例。

　　图 14：测试用例的追踪树

　　进行这种追踪的一个最主要的原因--并且花费时间将其加入到RequisitePro中--是为了让你知道当一些事情发生变更时需要重新测试什么。追踪和所谓的可疑关联，如图 15所示，为你显示了由于先前的场景和用例发生了变化，哪些测试用例也要随之改变。

　　图 15：可疑关联

　　映射到IBM Rational统一过程

　　如何映射到IBM Rational统一过程(RUP)呢?它们大多数发生在过程中的先启和精化阶段。只要你有了用例之后，我们就可以开始建立场景和测试用例。图 16描述了这些活动对应于RUP方法论中的哪些地方。

　　图 16：映射到RUP阶段的追踪活动

　　当建立场景和测试用例时，你可以给用例设计者反馈并且精炼一下需求。这有助于在过程中尽早改变一些任务，并且最终为团队尽快完成任务做出贡献。在整个精化阶段以及几乎是整个构造阶段中都会使用测试用例。

　　总结

　　本文介绍了一种从用例中产生功能测试用例的方法。这是使用此方法的一些益处：

　　用更自动化的方法产生测试用例

　　避免重复测试

　　更好的测试覆盖

　　简化了测试进度的监控

　　简化了测试人员之间的工作负载平衡

　　简化了回归测试

　　通过把一些任务从构造阶段移到精化阶段来缩短项目时间

　　能够帮助尽早地发现缺失的需求

　　你创建的测试用例能够用于人工测试，也可以用于像IBM Rational Robot这样的自动化测试。这种方法已经在许多项目中获得了成功。

原文转自：http://www.uml.org.cn/Test/200607073.htm