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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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