模板
教程
环境
性能
功能
管理
从用例到测试用例的追踪
本文阐述了一种从用例产生功能测试用例的正式方法，包括如何创建一个用例，产生所有场景，并且创建合理的测试用例，以及使用IBM Rational RequisitePro进行从用例到场景和测试用例的追踪。
需求类型概览一个需求被定义成 "系统必须遵从的条件或能力"。
它可以是：
一个顾客或用户所需要的，用以解决一个问题或达成一个目标的能力
一个必须被一个系统所满足和拥有的，用以满足一个合同、标准、规格、规则或其它正式强制文档的能力
一个被涉众所强加的限制
图1显示了带有不同需求级次的需求金字塔
图1. 需求金字塔
最高层的是涉众需求。通常，一个项目包含五到十五个这样的高层需求。较低层次的是特性，用例和补充规约。不同层次的需求有不同的细节。越低的层次需要越多的细节。例如，一个需求可以是："数据必须是持久的"。特性可以将此需求精化为："系统应当使用一个关系数据库"。在补充规约层次，需求会更加详细：" 系统应当使用Oracle 9i数据库"。层次越低，需要越详细的需求。
需求之间的追踪关系
追踪是这样一种技术，在系统中它能为不同层次的需求之间提供关联。这个技术帮助你确定任何需求的起源。图 2 阐述了从高层次到低层次需求是如何被追踪的。每一个需求通常映射到几个特性，然后这几个特性映射到用例和补充需求。
图2. 追踪需求金字塔
用例描述了功能性的需求，补充规约描述了非功能性的项目。另外，每个用例映射到许多场景。映射用例到场景，是一对多的关系。 场景映射到测试用例也是多对一的关系。另一方面，在需要与特性之间，是多对多的映射。
追踪起到了几个重要的作用：
验证一个实现是否完成了所有的需求：用户要求的每一件事情都被实现了验证应用程序只做了所要求的事情：不会去实现用户从未要求的事情
有助于变更管理：当一些需求变更后，我们想知道哪些测试用例应当被重新执行以测试这个变化一个追踪项是一个项目元素，其需要从另一个元素进行追踪。按照IBM Rational RequisitePro，它是一个需求类型的实例所表示的任何事情。在RequisitePro中一些需求类型的例子是涉众需求，特性，用例，参与者，和术语条款。
在RequisitePro中，有一种按照特定视图展示追踪性的便利方法。图3 显示了将特性映射到用例的一个例子。
图3. 在RequisitePro中的追踪关系
这里有一些问题，这些箭头应指向哪里：是从更低的层次到更高的层次，还是从更高的层次到更低的层次。甚至在RequisitePro中的两个例子使用了两个不同的方法。答案是没有关系，只要你在项目中始终如一地使用它们就可以了。
参与者和用例
参与者是与系统交互的某人或某事。用例是根据操作顺序的一个系统描述。它为参与者产生了一个看的见的结果或数据值。以下是用例的一些特征：
被参与者初始化
模拟参与者和系统之间的交互
描述操作的序列
获取功能需求
为参与者提供数据值
表示完整的和有意义的事件流
用例的目的是促使开发者、顾客和用户之间对系统应做些什么达成一致。用例在开发者和顾客之间达成了某种契约。它同时也是用例实现的基础，它在程序设计中起到了非常重要的作用。另外，你可以从用例中产生序列图，协作图和类图。此外，你可以从用例产生用户文档。用例可能还在计划迭代的技术内容方面有帮助，并且使系统开发者更好地了解系统的意图。最后，你可以使用它们作为测试例程的输入。
用例图显示了参与者和用例之间的关系。在本文我们使用一个在线书店作为项目的一个例子。图4 展示了这个项目的用例图。
图4. 用例图
原文转自：http://www.uml.org.cn/Test/200607073.htm
