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

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


图 2：用例的流程图

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

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

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

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

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


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

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

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

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

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

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

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

为功能验证测试创建测试用例

在功能验证测试阶段中，不明显的功能块也会被仔细地验证。功能验证测试通常被认为是针对详细需求以及外部和内部设计 文档的功能组成的测试。内部和外部的界面可能是利用残断的数据输入和截留的数据输出来测试的。

不像系统集成测试，它更多关注的是应用软件影响其它软件和系统的能力，功能验证测试则分步对它本身的应用软件进行检测，包括测试单个组分和过程，界限和极限，以及其它外部技术细节。对于功能验证测试，用例与测试用例的比率将是一对多。功能测试团队将对组成基奔流，可选流，以及例外流的组分感兴趣，而且这些流稍后将由系统集成和用户验收测试团队进行测试。

为了在这个粒度达到佳的结果，功能验证测试团队可以从一些更详细的 UML 图中获取利益，比如类和序列图。Copeland 将一个类图定义为“描述构成系统以及它们之间静态关系的类。类是按照它们的名称、属性（或者数据），以及行为（或者方法）来定义的。” 36 序列图提供了目标之间按照序列顺序生成交互的信息。每个交互都将生成一些想要的结果。 37 这些图的类型，有文本描述的补充说明，应该为功能验证测试团队在这个项目周期中工件测试用例提供充分的信息。

图 4 显示了一个来自 IBM DeveloperWorks 的 Rational UML 序列图，描述了进入和出来的消息（交互）。


图4： 一个来自 IBM DeveloperWorks 的 Rational UML 序列图，表述了进入和出去的消息

如果一个项目在类和序列图中不使用 UML 或者不继续使用用例文档到一定的程度，Function 测试人员要一直等到构建测试用例所需的具体的外部和内部设计文档完成之后。另外，用例还不覆盖非功能需求，这对功能验证测试阶段来说是非常普通的。

创建单元测试

我们后讨论单元测试，是因为这个水平的测试的输入需要以后的文档由这个项目团队创建。单元测试是模块中新代码和变更代码初进行的测试。大多数这种类型的测试利用白盒测试方法。这是软件测试的低水平，也是动态测试中寻找软件缺陷的第一道防线。在这个阶段，缺陷可以很容易且经济地被识别和修正。只有一少部分地实际用例被直接输入道单元测试用例中。单元测试的量取决于以这些用例为基础的低水平工件。

由于用例可以通过黑盒访问这个系统，所以它们成为单元测试人员的关键性驱动。然而，它们可以在单元测试人员利用局部的黑盒方法执行测试时提供有意义的价值。用例可以为用户如何期望系统工作提供深刻的见解；而且，如果有完备的文件，他们不但识别这个应用软件的基奔流，还会将可选流，可能的分支流与可选流，例外或者错误流相联系起来。黑盒测试依赖于这个测试，因为这个测试了解系统所输出的将成为一个特定系统输入。这些在用例中被识别的过程流信息对进行单元测试的开发人员有很大的帮助，因为它让他们很容易能理解用户期望信息如何被输入这个系统，以及他们所希望的输出是基于特殊的输入的。

如果这个项目组织利用 UML 来建模，那么单元测试将需要序列图，类图，可能还会需要活动图。类图交付单元测试所需的构架信息。序列图，在功能验证中有很重要的价值，提供交互的信息。他们显示了“参与者在做什么，他正与那些部分发生交互，以及有哪些参数正被通过，” 38 以及他们对测试人员开发单元测试用例有特别重要的作用。因此，这个负责单元测试的开发团队应该确保这个类和序列图包含在项目交付产品中。

单元测试人员访问实际用例之外的，与被分解的信息相沟通的工件是十分重要的。这个水平的信息能够创建可靠的单元测试用例和覆盖范围。如果这个组织不使用 UML，这个开发团队将很可能要等到具体的设计文档被创建以后，而且这个文档是在他们需要这些信息创建测试用例之前创建的。

弥补测试覆盖的空缺
用例驱动测试过程，但是它们不直接处理各种类型的测试用例。非功能性需求并不包含在用例中，主要是因为方法、指导方针，可能是由一个有效的驱动触发的。但是，实际上，为这样的属性创建一个外部列表，或者行式项目需求，远比创建一个用例要有效得多。照这样说，这个覆盖空缺增加了这样一个缺陷进入未被发觉的产品中的可能性。

当为下面的测试步骤构建测试用例时，测试人员需要从其它工件中拉取：

性能/负载/压力/竞争条件
硬件兼容性
安装
内部的审计和控制
可靠性
安全性
软件兼容性
迁移
用户界面
这种接触没有干涉单元或者验收测试目标。单元水平测试人员是由低水平文档驱动的。验收测试则由用例的高形式触发的。而且没有从发现非功能性相关缺陷中直接排除测试人员。我们甚至找到一个这个限制是优先权形式的理由，因为当在类似产品环境中执行时，这些限制条件下发现的非功能性缺陷似乎影响了更多的终端用户。

要为非功能性需求的构建测试用例，测试人员要依赖于附加的文档，因此也称作需求补充说明。 39 Bittner 和 Spence 曾经写到，可以将具体的需求（并不运用到整个系统的需求）置于一个用例中，这样对高水平测试用例的编者来说也更容易接近。 40 但是一般说来，这种类型的信息，以及这样有关联的测试用例，开发过程中信息的生成应该晚于由那些测试用例驱动的生成的。

确认用例
从用例中生成测试用例过程的局面将会停止。在这种情形下，识别驱动因素是十分重要的。常见的驱动有：

测试用例编者需要太多具体细节。
用例十分复杂。
用例已经被分解。
编者缺乏对业务问题的基本理解。
测试用例与这个水平的测试不相称。
上面的大多数情况都可以通过在循环早期提前操作而避免。因为它们有太多处于危险状态，测试组织必须安置来影响用例的质量构建。正如 Leffingwell 和 Widrig 指出的那样，“用例技术构建了一套可以直接驱动测试过程的资产。” 41 但是在测试开发时期修正一个薄弱且错误的用例十分困难而且成本很高，尤其是当使用一个基于瀑式开发方法的时候。这样，我们建议一种双交叉的方法来确保这个用例对测试人员来说还具有功能上的价值。首先，包含在用例创建中的一个测试代表应该使团队远离用例编写的常见陷阱。其次，团队应该始终执行用例的静态测试。

首先要避免的陷阱是功能分解，一个源自行为多样化的问题。分解抽象化的形式是将用例分解成更小的部分。 42 在这个用例中，当低水平信息被一个用户或者系统代替时会发生这样的情况。发生的方式之一是将数据流图和用例图混淆在一起。 43 从根本上说，用例编写者会根据设计而不是功能来查看这些目标。结果是用例不能独立存在来创建可测试的场景。

一个相关的陷阱是在这个用例中将需求和设计混淆在一起。在这种情况下，用例可以用来创建可测试场景，但是隐藏信息所包含的内容 44 与维持测试用例穿越任何设计变更的能力相冲突。

太多或者太少的信息是另一种常见的陷阱，但是在决策方面它包含的艺术多于科学。如果没有足够的信息，对测试人员来说创建一个坚固的测试用例组合是十分困难的。如果信息太多，又会使识别测试路径和优先化测试的过程变得很困难。一开始了解正确的平横关系，需要拥有用例以及个人在项目中的历史支持组合方面的经验。

要避免的一个单纯的陷阱是，用团队的失败来加强设计原理、方法，以及过程。 45 这包含编写风格以及内容。尽管这是一个广泛的话题，有一致的过程跨越这个项目团队的功能区域，测试团队可以很容易地避免这个陷阱。

尽管有一个有经验且受过良好训练的团队，但是仍然有风险，用例可能有缺陷，从而影响终创建一个功能强大的测试用例的能力。第二个确保用例是一个测试所需的可靠的而有用的输入的机会是，对测试用例进行静态测试。团队甚至可以将用例的静态测试作为一个闸门机制。当静态测试被看作是为了这个活动的成功实现，其项目计划依存关系中的一个被识别的风险时，测试人员要保证这些用例对于他们的交付结果是可靠的输入。用例的静态测试可以由检查表驱动，安全的各种水平也应该包含测试人员。

有很多静态测试项目用例的方法。对无领域专家尤其有用，Copeland 建议将用例分解成三个部分：语法、领域专家测试，以及可追溯性。 46 用这种方法，每个用例都要测试。NASA 建议只对精选的用例进行分析。 47 分析诸如边界、元素命名，以及被执行的发起。Alistair Cockburn 推荐了一个问题列表来考虑何时读取用例。 48 这些问题对识别缺口很有帮助，但是遗漏其它颗粒元素没有被公开，它们可能阻碍成功地使用用例来驱动测试用例的行为。这种处理用例检验的方法可以变化，但是很明显，这些用例在测试用例的创建种有重要的价值，团队必须从形式上关注这些用例的质量。

用例的工作空间
对于用例何时以及怎样被开发有很多种理论。在有些组织中，具体的团队，比如系统工程或者架构，都要对用例的创建负责。 他们在几乎是真空的环境中创建用例，用他们自己的判定，使用他们所能聚集的所有信息。他们可能会访问利益关系者和开发人员来收集需要的信息，或者他们实际上是基于发布的需求来创建用例的。开发过程的“下游的”团队，比如测试和 文档，可能不会被考虑。实际上他们是设计和开发过程的下游，可能对增加需求讨论还有一定的价值。这样降低了用例的真实价值。

Bittner 和 Spence 提出了一个不同凡响的开发用例的方法。 49 他们建议在这个项目生命周期的早期开始，保持一个用多种参与者团队的用例工作空间，这些参与者有多种技术和知识。他们指出工作空间中参与者的混搭包括项目中每个主要利益关系团队懂得代表。这种方法提供了许多潜在的利益。包括用户代表，开发人员，测试人员，构架师，以及/或者其他主要利益关系减少机会关键问题将会被忽略，因为每个团队都将他们自己对应用软件的观点提到表格上来。它还给每个团队代表提供了确保他们团队的需求能够被满足的机会。这个工作空间提供了一个在成员和每个利益关系团队之间建立良好工作关系的机会；而且它还能保证每个参会的人员对需求都有相同的理解。

根据这个团队的动态，规格，以及所有的努力，可以为三个独立的工作空间建立良好的变量。应该有一个初的工作空间作为用例的生成之地。第二个工作空间应该包括所有的测试用例为用例验证所用。后，序列和类图，或者类似的交付产品，从而构成了第三个工作空间的建议。

某些利益关系团队参与这样的工作空间从而获得了辅助的利益??他们获得在这个项目生命周期早期完成有生产价值工作的机会。测试团队是一个特别好的例子。通常情况下，测试人员不会被带进项目中，直到这个开发周期的晚期。因此，他们基本上都依赖于其它团队向他们提供需求信息，外部和内部的设计文档，以及其它相关信息。一旦他们接受了这个信息，他们必须将它与在没有参加任何早期股东会议情况下进行比较。通过将测试编者包含于用例工作空间，这个团队可以开发股东对相关项目需求的前期理解。测试用例编者可以获得这个项目的范围以及技术复杂性的理解，这样他们可以在这个项目生命周期的早期提供更准确的测试估计。他们能够按照测试策略进行工作，并可以比按照通常的方法提前几个星期甚至几个月完成。如果将这种方法与变更控制紧密联合，将在测试质量上生成相当大的提升。

要获得这个工作空间所有的利益，包含正确的测试资源是十分重要的。团队应该包含一个技术测试领导或者其他测试项目专家，他们对这个应用软件有熟练的经验，而不是依赖于一个键盘输入水平的测试人员或者测试项目的管理人员。每个测试团队派遣到会议的代表都应该为提前完成制定自己的目标。参加这个会议，团队代表都应该有一个他们团队在工作空间所必须的交付产品的列表。

结论
当用例不能覆盖所有的测试类型时，他们可以为几个主要的测试阶段提供重要的价值，包括用户验收测试，系统集成测试，功能验证测试，以及单元测试。要大化这个价值，每个测试所有者都必须是一个活跃的参与者，从而确保在他们特殊的测试阶段能创建高质量和高水平的用例。

如果创建了结构良好、高质量的用例，它们可以为测试组织提供许多利益。他们有助于确保在这个项目的生命周期的早期创建更准确的测试估计。它们可以帮助开发人员更好地理解这个系统希望做什么，帮助构建正确地解决方案。开发循环中的改善意味着一个更高质量的产品被传递到这个测试团队，他们终帮助将它交付给利益关系者。用例对证明被测试和交付方案需求跟踪性能力有很大的贡献。创建的各种工件都是用例建模的一部分，为测试组织提供了有价值的必需的信息，这些信息在开发测试用例中被利用到。在建模过程中构建的流图在帮助测试人员识别关键路径，优化测试用例执行时十分有用，并且为特定的测试阶段提供了更有效的测试覆盖率。后，当利用全球方案团队是，用例甚至可以通过减小需求到执行的“转换”风险帮助减轻全球化资源的压力。

要实现测试中使用用例的大价值，这个项目应该调解用例工作空间的需求。在这个项目生命周期的早期投资一个用例工作空间必须包含所有的必需资源和必需的技术，从而使用例建模顺利到达项目的适当水平。测试人员必须能够清楚地识别为每个测试阶段更彻底地创建适当地测试而附加文档和图。所有这些关键路径交付产品应该在项目水平被跟踪。这些步骤将使得用例能够有效地利用，从而提高这个方案地总体测试质量。