图 2：用例的流程图

        当从一个带有少量路径的用例开始工作时，您可以合情合理地期望用户验收测试执行所有地路径。对于包含许多可选情景和变量，或者对于那些连接到其它用例的用例来说，为每一个路径进行测试几乎是不可能的。尤其是对非关键的应用软件，这样的路径就好像不被业务用例所支持。 32 此外，这些路径中很多可能是多余的或者甚至是无效的。

        McGregor 和 Major 提供了一种对测试用例筛选可管理的方法，这对用户验收测试社区有格外的吸引力。 33 作者描绘了不用种类的用户，创建了可操作的配置文件。一般采取操作剖面图来筛选路径的方法实际上是优化验收水平测试最好的方法。为了使适合那些操作剖面图的用户执行，测试用例的合成子集将向发起者提供这样的保证：所有的用户社区都可以利用这种方案来达到定期的目标。同时，操作剖面图是一种优化或者减少测试筛选的工具。根据这个测试阶段的目标来看，循环和例外的路径并不是需要的覆盖范围，除非这样的路径通常是由用户社区中一些人执行的。

为系统集成测试创建测试用例

        系统集成测试阶段验证一个类似生产环境中所有应用软件(包括组织内部和外部的界面)以及它们的硬件、软件，以及组成组件的集成。

        这种将用例转变成测试用例的方法与系统集成测试对用户验收测试的方法十分相似；不同的是系统集成测试比用户验收测试在范围上更广更深。由于用户验收测试团队可能主要关心的是快乐路径以及可能是为特定用例定义的一个或者两个可选择路径，如图 3所示，系统集成测试团队将很可能需要执行这个快乐路径以及大多数可选路径和例外路径(尤其是那些与错误条件有关联的路径).
               

图 3：系统集成测试的例外路径

        正如上面所讨论的，对于有许多路径的较大的而且比较复杂的过程来说，测试人员可能需要仔细分析，确保能够测试关键的路径功能以及这种测试效率能够维持下去。

        系统集成测试要求有获得一个比验收测试所得的更详细的系统视图。除了在较低水平仔细验证这个体统的功能方面的情况之外，系统集成测试还完成了非功能性的测试。此外，这个系统集成测试团队比验收团队更关注数据测试，尤其是在关于数据已被传递或者从其它系统接受方面。因此，用户验收测试团队实际上是可以使用例对测试用例成为一对一的比率，对于系统集成测试用例对测试用例的比率也可以是以对多。

        要充分并有效地测试这些区域，系统集成测试团队需要的不仅仅是用例。系统集成从一些更详细的 UML 图，比如活动或者流量图中获得利益。Dean Leffingwell 和 Don Widrig 将活动图定义为一种“合理熟悉程度的优势。” 34 这些流程图甚至连非技术资源也可以容易地读懂，它们主要识别业务过程和规则。它们允许这个场景有一个视觉参考。另一个工件，一系列的图，提供了关于目标之间按顺序发生的相互交互的信息。 35 这些图，有文本描述的补充说明，应该为系统集成测试提供足够的信息，从而可以是这个项目在其生命周期的早期开始构建功能的类型。利用变量表格和数据表格或者文档的决策树可以完成这些测试用例。

        有些组织可能不支持 UML 或者不使用任何类型的标准用例建模工具。如果这些用例仅仅是基于文本的，它们对为测试和生成测试用例而计划的系统集成测试 团队来说仍然有十分重要的价值，但是系统集成测试团队需要参与到用例的工作空间，从而确保这些用例被压低到足够的水平来支持他们的测试需求。然而，在这种情景下，这个团队很可能依靠于那些直到在项目生命周期的晚期才生成的外部设计文档。

        所有的用例方法，正式的或者非正式的，都需要附加文档来完成测试用例的创建过程。系统集成测试人员能够通过提取与非功能集成测试用例相关的信息来完成测试用例的程序库。测试用例的安全性、性能、可用性、转化，等等都是由这些类型的文档所驱动的。一般情况下，只有等到用例良好地创建完成之后，这些文档才可以利用。设定这些文档类型交付的时间风险是环境获得的潜在延迟，具体的细节在这篇文章有详细描述。测试组织应该通过计划来减轻这种独立的风险。

        尽快掌握生成大多数测试用例和脚本的能力对系统集成测试团队来说有很多好处。对利用 UML 使用用例建模工具也是一个很好的理由。 早期测试用例开发允许测试团队有足够的时间来处理同等的检验并保持涉众的评论。事实上，团队甚至有充分的时间来进行迭代检验，这样他们可以完善这些 测试用例，从而满足技术上和用户的需求。