最简单的处理测试用例优先权的方法是关键路径的识别。关键路径是为了解决方案对最终的用户有价值而使面向用户的功能按照一定的顺序进行操作的需求。关键路径在回归测试和其它有严格时间控制的测试中十分有用。然而识别关键路径，尤其是对于有许多需求的大量释放，可以说是一项令人敬畏的任务。证明用例（尤其是用例图）十分有利是另一个区域的讨论范围。由于用例图开始识别正面的，或者“令人愉快的”，路径，然后分支显示可选的流程和例外条件，它们提供了一种识别整个应用软件中大多数直接路径的方法。这个技术还提供了允许快速决策的信息，这些信息是关于哪些可选流程和例外最重要的。

        用例实现打开了一扇通往更精细更有潜在可能性的有效优先权测试方法的门。例如，ranTest initiative for Software Engineering 2006 利用加权特殊标准的用例。 21 ranTest 技术针对发布版本完全使用了用例，并静态地对它们进行优先权排序。然后测试组织就按照那个顺序来执行测试用例。预算或者时间表如果没有覆盖整个测试单元，那个就会省略一些关键的用例。 此外，这个技术还支持动态的优先排序。当在基于静态的优先级团队执行识别的测试时，风险区域也会被识别。这样，测试用例优先权的第二层也被创建，它重点是证明最关键的功能是与最高可靠性并存的。最终的产品是一种有效的测试方法，提供了确保解决方案能够满足消费者目标需求具体水平的有效测试方法。

        用例还提高了缺陷优先处理的精确度。当一个测试失败了，基于用例的方法可以迅速确定问题的分类和优先权，因为这个用例的整体重要性已经被建立。测试人员可以直接依赖发起者在制定需求规范时赋予这个具体用例的值，而不是对缺陷进行主观地评估。缺陷优先排序几乎变成瞬间而且无可争议了。而且，在缺陷发现和它的优先权确定的时间也大大减少了。

应对全球化资源挑战

        在一个特定的市场，业务往来发生在文化和法律框架之中。法定的市场行为证明，最接近的文化之外的最佳成功机会是在类似的文化或者文化体系中。 22 这个行为与当前从全球外包开发和测试的软件交付模式是相冲突的，并经常导致用户和开发者之间的误解。这种继续向更复杂和过程驱动解决方案移动的行为将增加用户和开发者之间“断开”的风险。这些条件联合起来使保证这个方案能适合目标市场的风险变得更加复杂。

        正如 Bittner 和 Spence 指出那样，“用例通过让我们从视觉上明白这个系统将要做什么以及如何利用它来进行操作。” 23 通过使用用例，全球的测试资源挽回一些在跨越文化边境的过程中可能丢失的文化。它们对业务目标有更充分的认识，从而促进应用软件将要被投放的具体市场的需求。

        用例使用户在需求过程中操作，并允许他们与测试人员进行清楚地沟通，了解这个方案是否准确地针对目标市场。 24 这种理解与传统表达需求的方式在不同的个体之间有很大的差别。因为反映具体结果的用例早就被交付，一个全球测试团队有足够的时间来开拓对这个用户目标良好的理解。前面额外的时间允许测试人员来验证他们对实现和想要的结果的理解。当出现这样的挑战因素时，如不能可视化地与需求所有者沟通， 25 不同的时间区域，以及产品将要服务的市场确保功能和性能的挑战，所测试的内容和所交付的内容以及业务真正所需要的时间空缺将十分引人注目。当利用全球性资源团队来交付方案时，用例会提供降低这种需求到实现“转换”风险的动力。

创建测试用例
        用例实现对测试组织最大的影响是在测试用例的创建过程中。用例创建直接输入到一些高水平测试中去。对于验收测试，当被适当地执行时，用例缩小了测试人员 概念化和用户目标现实之间的距离。尽管最初可交付成果对于单元测试人员是临界值，但是缺乏细节迫使这个方案交付团队随后创建包含低水平测试所必须的输入的支持性工件，比如单元测试。实际上，每个测试阶段都有权输入此阶段或者其它阶段明晰目标所需的合适且完整的信息。此外，由于他们特殊的本质，这些输入十分清晰，而且这些信息很容易就可以转化成适当的测试阶段的测试用例。测试人员不会因为为他们特定的测试阶段而在整个较大的，包括所有类型的文件中搜寻而心烦意乱。这些结果是拥有更好的代码和更好目标的测试。

        一般来说，从一个用例驱动方法来创建测试用例包括以下四个基本步骤：

识别场景
识别变量
为效率和完整性调整适当的覆盖率
分配数据输入
并不是所有的测试水平都以相同的方式来达到以上的步骤的。下面的部分描述了怎样为用例模型驱动的项目的测试阶段创建合适的测试用例

为用户验收测试创建测试用例

        因为用例包括参与者真实语言的目标信息，用户验收的测试用例可以在为其它测试阶段创建测试之前编写。用例是从用户的角度来定义的，而不是系统的内部活动，因此验收测试可以直接从用例中创建。 26 此外，用例非常适合于用户验收测试，因为需要验收测试用例来模拟最初从系统涉众中抽取的情景。 27 就像 Lee Copeland 指出的，用例最适合端到端的黑盒测试——更准确地说，是在用户验收测试被执行的条件下。 28

        验收测试的测试用例的生成在不同的测试阶段是不同的，这是由于这个和其它测试水平潜在的前提之间存在一些明显偏差所导致的。验收测试存在于生命周期的这样一个点上，技术测试团队已经得出此应用软件已经完整且准备交付给消费者了。单个的测试用例是由用例驱动的，而不是附加的，非功能性需求规格。测试用例是上游测试的不同子集。另一个区别是验收团队是通过将最终的结果看作方案完整性来达到获取测试结果的。最后，这个测试人员很像一个“非技术的”普通涉众，并不期望了解潜在的构架，但是要十分熟悉测试中转换描述的目的。

        由于用例是透明且独立于系统，所以对于测试阶段，他们将丢失一些关键的细节信息。用户验收测试用例编写者并不希望用例中有具体的数据。然而，当 Copeland 清楚地被识别时，处理测试，一个验收测试之下的类别失败了，很显然它是依靠数据的。 29 Boris Beizer 支持数据的临界性，规定其生成、捕获，以及用百分之三十到四十的工作来提取数据帐户。 30 这样引导出这样的问题：验收测试到底需要多少具体的数据和脚本。我们的立场是，附有具体数据输入的具体脚本和违反直觉运行用户验收测试总体目标的用户界面步骤是测试用例脚本不需要的。Cem Kaner 和 James Bach 宣称“如果一个脚本的工作是可重复性的，我们可以将这些工作委托给廉价的劳动力。” 31 有了由超级用户，顶级装备或者其它主要领域专家组成的验收团队，用户验收测试用例将不需要低水平用户界面或者类细节。根据这个用例的目标，在测试用例的前置条件或者设置中还需要一些数据输入。

        要开始创建测试用例，用户验收测试资源将需要查看这个用例的流程图。在图 2中，这个基本流程，或者快乐路径，径直穿过这个图。这个可选的流程将被取消。这些代表了额外的测试用例。