创建单元测试
我们最后讨论单元测试，是因为这个水平的测试的输入需要以后的文档由这个项目团队创建。单元测试是模块中新代码和变更代码最初进行的测试。大多数这种类型的测试利用白盒测试方法。这是软件测试的最低水平，也是动态测试中寻找软件缺陷的第一道防线。在这个阶段，缺陷可以很容易且经济地被识别和修正。只有一少部分地实际用例被直接输入道单元测试用例中。单元测试的量取决于以这些用例为基础的低水平工件。
由于用例可以通过黑盒访问这个系统，所以它们成为单元测试人员的关键性驱动。然而，它们可以在单元测试人员利用局部的黑盒方法执行测试时提供有意义的价值。用例可以为用户如何期望系统工作提供深刻的见解；而且，如果有完备的文件，他们不但识别这个应用软件的基奔流，还会将可选流，可能的分支流与可选流，例外或者错误流相联系起来。黑盒测试依赖于这个测试，因为这个测试了解系统所输出的将成为一个特定系统输入。这些在用例中被识别的过程流信息对进行单元测试的开发人员有很大的帮助，因为它让他们很容易就能理解用户期望信息如何被输入这个系统，以及他们所希望的输出是基于特殊的输入的。
如果这个项目组织利用 UML 来建模，那么单元测试将需要序列图，类图，可能还会需要活动图。类图交付单元测试所需的构架信息。序列图，在功能验证中有很重要的价值，提供交互的信息。他们显示了“参与者在做什么，他正与那些部分发生交互，以及有哪些参数正被通过，”以及他们对测试人员开发单元测试用例有特别重要的作用。因此，这个负责单元测试的开发团队应该确保这个类和序列图包含在项目交付产品中。
单元测试人员访问实际用例之外的，与被分解的信息相沟通的工件是十分重要的。这个水平的信息能够创建可靠的单元测试用例和覆盖范围。如果这个组织不使用 UML，这个开发团队将很可能要等到具体的设计文档被创建以后，而且这个文档是在他们需要这些信息创建测试用例之前创建的。
弥补测试覆盖的空缺
用例驱动测试过程，但是它们不直接处理各种类型的测试用例。非功能性需求并不包含在用例中，主要是因为方法、指导方针，可能是由一个有效的驱动触发的。但是，实际上，为这样的属性创建一个外部列表，或者行式项目需求，远比创建一个用例要有效得多。照这样说，这个覆盖空缺增加了这样一个缺陷进入未被发觉的产品中的可能性。
当为下面的测试步骤构建测试用例时，测试人员需要从其它工件中拉取：
性能/负载/压力/竞争条件
硬件兼容性
安装
内部的审计和控制
可靠性
安全性
软件兼容性
迁移
用户界面
这种接触没有干涉单元或者验收测试目标。单元水平测试人员是由最低水平文档驱动的。验收测试则由用例的最高形式触发的。而且没有从发现非功能性相关缺陷中直接排除测试人员。我们甚至找到一个这个限制是优先权形式的理由，因为当在类似产品环境中执行时，这些限制条件下发现的非功能性缺陷似乎影响了更多的终端用户。
要为非功能性需求的构建测试用例，测试人员要依赖于附加的文档，因此也称作需求补充说明。Bittner 和 Spence 曾经写到，可以将具体的需求（并不运用到整个系统的需求）置于一个用例中，这样对高水平测试用例的编者来说也更容易接近。但是一般说来，这种类型的信息，以及这样有关联的测试用例，开发过程中信息的生成应该晚于由那些测试用例驱动的生成的。
确认用例
从用例中生成测试用例过程的局面将会停止。在这种情形下，识别驱动因素是十分重要的。常见的驱动有：
测试用例编者需要太多具体细节。
用例十分复杂。
用例已经被分解。
编者缺乏对业务问题的基本理解。
测试用例与这个水平的测试不相称。
上面的大多数情况都可以通过在循环早期提前操作而避免。因为它们有太多处于危险状态，测试组织必须安置来影响用例的质量构建。正如 Leffingwell 和 Widrig 指出的那样，“用例技术构建了一套可以直接驱动测试过程的资产。”但是在测试开发时期修正一个薄弱且错误的用例十分困难而且成本很高，尤其是当使用一个基于瀑式开发方法的时候。这样，我们建议一种双交叉的方法来确保这个用例对测试人员来说还具有功能上的价值。首先，包含在用例创建中的一个测试代表应该使团队远离用例编写的常见陷阱。其次，团队应该始终执行用例的静态测试。
首先要避免的陷阱是功能分解，一个源自行为多样化的问题。分解抽象化的形式是将用例分解成更小的部分。在这个用例中，当低水平信息被一个用户或者系统代替时就会发生这样的情况。发生的方式之一是将数据流图和用例图混淆在一起。从根本上说，用例编写者会根据设计而不是功能来查看这些目标。结果是用例不能独立存在来创建可测试的场景。
一个相关的陷阱是在这个用例中将需求和设计混淆在一起。在这种情况下，用例可以用来创建可测试场景，但是隐藏信息所包含的内容与维持测试用例穿越任何设计变更的能力相冲突。
太多或者太少的信息是另一种常见的陷阱，但是在决策方面它包含的艺术多于科学。如果没有足够的信息，对测试人员来说创建一个坚固的测试用例组合是十分困难的。如果信息太多，又会使识别测试路径和优先化测试的过程变得很困难。一开始就了解正确的平横关系，需要拥有用例以及个人在项目中的历史支持组合方面的经验。
要避免的一个单纯的陷阱是，用团队的失败来加强设计原理、方法，以及过程。这包含编写风格以及内容。尽管这是一个广泛的话题，有一致的过程跨越这个项目团队的功能区域，测试团队可以很容易地避免这个陷阱。
尽管有一个有经验且受过良好训练的团队，但是仍然有风险，用例可能有缺陷，从而影响最终创建一个功能强大的测试用例的能力。第二个确保用例是一个测试所需的可靠的而有用的输入的机会是，对测试用例进行静态测试。团队甚至可以将用例的静态测试作为一个闸门机制。当静态测试被看作是为了这个活动的成功实现，其项目计划依存关系中的一个被识别的风险时，测试人员就要保证这些用例对于他们的交付结果是可靠的输入。用例的静态测试可以由检查表驱动，安全的各种水平也应该包含测试人员。
有很多静态测试项目用例的方法。对无领域专家尤其有用，Copeland 建议将用例分解成三个部分：语法、领域专家测试，以及可追溯性。 用这种方法，每个用例都要测试。NASA 建议只对精选的用例进行分析。分析诸如边界、元素命名，以及被执行的发起。Alistair Cockburn 推荐了一个问题列表来考虑何时读取用例。这些问题对识别缺口很有帮助，但是遗漏其它颗粒元素没有被公开，它们可能阻碍成功地使用用例来驱动测试用例的行为。这种处理用例检验的方法可以变化，但是很明显，这些用例在测试用例的创建种有重要的价值，团队必须从形式上关注这些用例的质量。
用例的工作空间
对于用例何时以及怎样被开发有很多种理论。在有些组织中，具体的团队，比如系统工程或者架构，都要对用例的创建负责。 他们在几乎是真空的环境中创建用例，用他们自己的判定，使用他们所能聚集的所有信息。他们可能会访问利益关系者和开发人员来收集需要的信息，或者他们实际上是基于发布的需求来创建用例的。开发过程的“下游的”团队，比如测试和 文档，可能不会被考虑。实际上他们是设计和开发过程的下游，可能对增加需求讨论还有一定的价值。这样降低了用例的真实价值。
Bittner 和 Spence 提出了一个不同凡响的开发用例的方法。他们建议在这个项目生命周期的早期开始，保持一个用多种参与者团队的用例工作空间，这些参与者有多种技术和知识。他们指出工作空间中参与者的混搭包括项目中每个主要利益关系团队懂得代表。这种方法提供了许多潜在的利益。包括用户代表，开发人员，测试人员，构架师，以及/或者其他主要利益关系减少机会关键问题将会被忽略，因为每个团队都将他们自己对应用软件唯一的观点提到表格上来。它还给每个团队代表提供了确保他们团队的需求能够被满足的机会。这个工作空间提供了一个在成员和每个利益关系团队之间建立良好工作关系的机会；而且它还能保证每个参会的人员对需求都有相同的理解。
根据这个团队的动态，规格，以及所有的努力，可以为三个独立的工作空间建立良好的变量。应该有一个最初的工作空间作为用例的生成之地。第二个工作空间应该包括所有的测试用例为用例验证所用。最后，序列和类图，或者类似的交付产品，从而构成了第三个工作空间的建议。
某些利益关系团队参与这样的工作空间从而获得了辅助的利益——他们获得在这个项目生命周期早期完成有生产价值工作的机会。测试团队是一个特别好的例子。通常情况下，测试人员不会被带进项目中，直到这个开发周期的晚期。因此，他们基本上都依赖于其它团队向他们提供需求信息，外部和内部的设计文档，以及其它相关信息。一旦他们接受了这个信息，他们必须将它与在没有参加任何早期股东会议情况下进行比较。通过将测试编者包含于用例工作空间，这个团队可以开发股东对相关项目需求的前期理解。测试用例编者可以获得这个项目的范围以及技术复杂性的理解，这样他们就可以在这个项目生命周期的早期提供更准确的测试估计。他们能够按照测试策略进行工作，并可以比按照通常的方法提前几个星期甚至几个月完成。如果将这种方法与变更控制紧密联合，将在测试质量上生成相当大的提升。
要获得这个工作空间所有的利益，包含正确的测试资源是十分重要的。团队应该包含一个技术测试领导或者其他测试项目专家，他们对这个应用软件有熟练的经验，而不是依赖于一个键盘输入水平的测试人员或者测试项目的管理人员。每个测试团队派遣到会议的代表都应该为提前完成制定自己的目标。参加这个会议，团队代表都应该有一个他们团队在工作空间所必须的交付产品的列表。
