为功能验证测试创建测试用例
在功能验证测试阶段中，不明显的功能块也会被仔细地验证。功能验证测试通常被认为是针对详细需求以及外部和内部设计 文档的功能组成的测试。内部和外部的界面可能是利用残断的数据输入和截留的数据输出来测试的。
不像系统集成测试，它更多关注的是应用软件影响其它软件和系统的能力，功能验证测试则分步对它本身的应用软件进行检测，包括测试单个组分和过程，界限和极限，以及其它外部技术细节。对于功能验证测试，用例与测试用例的比率将是一对多。功能测试团队将对组成基奔流，可选流，以及例外流的组分感兴趣，而且这些流稍后将由系统集成和用户验收测试团队进行测试。
为了在这个粒度达到最佳的结果，功能验证测试团队可以从一些更详细的 UML 图中获取利益，比如类和序列图。Copeland 将一个类图定义为“描述构成系统以及它们之间静态关系的类。类是按照它们的名称、属性（或者数据），以及行为（或者方法）来定义的。” 36 序列图提供了目标之间按照序列顺序生成交互的信息。每个交互都将生成一些想要的结果。 37 这些图的类型，有文本描述的补充说明，应该为功能验证测试团队在这个项目周期中工件测试用例提供充分的信息。
图 4 显示了一个来自 IBM DeveloperWorks 的 Rational UML 序列图，描述了进入和出来的消息（交互）。
图4： 一个来自 IBM DeveloperWorks 的 Rational UML 序列图，表述了进入和出去的消息
如果一个项目在类和序列图中不使用 UML 或者不继续使用用例文档到一定的程度，Function 测试人员就要一直等到构建测试用例所需的具体的外部和内部设计文档完成之后。另外，用例还不覆盖非功能需求，这对功能验证测试阶段来说是非常普通的。
创建单元测试
我们最后讨论单元测试，是因为这个水平的测试的输入需要以后的文档由这个项目团队创建。单元测试是模块中新代码和变更代码最初进行的测试。大多数这种类型的测试利用白盒测试方法。这是软件测试的最低水平，也是动态测试中寻找软件缺陷的第一道防线。在这个阶段，缺陷可以很容易且经济地被识别和修正。只有一少部分地实际用例被直接输入道单元测试用例中。单元测试的量取决于以这些用例为基础的低水平工件。
由于用例可以通过黑盒访问这个系统，所以它们成为单元测试人员的关键性驱动。然而，它们可以在单元测试人员利用局部的黑盒方法执行测试时提供有意义的价值。用例可以为用户如何期望系统工作提供深刻的见解；而且，如果有完备的文件，他们不但识别这个应用软件的基奔流，还会将可选流，可能的分支流与可选流，例外或者错误流相联系起来。黑盒测试依赖于这个测试，因为这个测试了解系统所输出的将成为一个特定系统输入。这些在用例中被识别的过程流信息对进行单元测试的开发人员有很大的帮助，因为它让他们很容易就能理解用户期望信息如何被输入这个系统，以及他们所希望的输出是基于特殊的输入的。
如果这个项目组织利用 UML 来建模，那么单元测试将需要序列图，类图，可能还会需要活动图。类图交付单元测试所需的构架信息。序列图，在功能验证中有很重要的价值，提供交互的信息。他们显示了“参与者在做什么，他正与那些部分发生交互，以及有哪些参数正被通过，” 38 以及他们对测试人员开发单元测试用例有特别重要的作用。因此，这个负责单元测试的开发团队应该确保这个类和序列图包含在项目交付产品中。
单元测试人员访问实际用例之外的，与被分解的信息相沟通的工件是十分重要的。这个水平的信息能够创建可靠的单元测试用例和覆盖范围。如果这个组织不使用 UML，这个开发团队将很可能要等到具体的设计文档被创建以后，而且这个文档是在他们需要这些信息创建测试用例之前创建的。
弥补测试覆盖的空缺
用例驱动测试过程，但是它们不直接处理各种类型的测试用例。非功能性需求并不包含在用例中，主要是因为方法、指导方针，可能是由一个有效的驱动触发的。但是，实际上，为这样的属性创建一个外部列表，或者行式项目需求，远比创建一个用例要有效得多。照这样说，这个覆盖空缺增加了这样一个缺陷进入未被发觉的产品中的可能性。
当为下面的测试步骤构建测试用例时，测试人员需要从其它工件中拉取：
性能/负载/压力/竞争条件
硬件兼容性
安装
内部的审计和控制
可靠性
安全性
软件兼容性
迁移
用户界面
这种接触没有干涉单元或者验收测试目标。单元水平测试人员是由最低水平文档驱动的。验收测试则由用例的最高形式触发的。而且没有从发现非功能性相关缺陷中直接排除测试人员。我们甚至找到一个这个限制是优先权形式的理由，因为当在类似产品环境中执行时，这些限制条件下发现的非功能性缺陷似乎影响了更多的终端用户。
要为非功能性需求的构建测试用例，测试人员要依赖于附加的文档，因此也称作需求补充说明。 39 Bittner 和 Spence 曾经写到，可以将具体的需求（并不运用到整个系统的需求）置于一个用例中，这样对高水平测试用例的编者来说也更容易接近。 40 但是一般说来，这种类型的信息，以及这样有关联的测试用例，开发过程中信息的生成应该晚于由那些测试用例驱动的生成的。
