测试实现的模式
　　记录
　　通过自动化测试工具来执行此模式的测试实现。该工具记录并回放手工测试者的操作。某种程度上，考虑到昂贵的维护成本，这种方式被认为是一个糟糕的实践。
　　脚本化
　　由程序员使用自动化工具的API来执行测试实现（例如Selenium WebDriver API）。
　　实现基础模板（测试模板）
　　该模式将实现基础测试模板类。要实现各种测试的变体，可以通过继承和扩展模板类的功能来创建。
　　数据驱动实现
　　通过测试用例来定义一个基础测试的实现。可以通过一系列不同的输入数据组合，来创建各种测试的变体。
　　在大部分单元测试框架中都实现了这一方法，例如：MSTest以DataContext（键值集合）的方式，提供对测试内部的属性的访问权限。于是，相同的测试方法主体会运行很多次，但DataContext属性所提供的数据各不相同。
　　关键字驱动实现
　　这一测试实现借助了关键字（例如：点击、回车）。测试实现通过特殊的IDE完成，这类IDE可以钩挂到应用的UI上。
　　目前已有数款软件工具，支持借助关键字来实现测试。测试的步骤，以关键字、屏幕上的控制名和输入参数的结合的形式出现。HP QTP和MonkeyTalk是这类IDE中的典型例子
　　模型驱动实现
　　对任何应用来说，在特定的时刻接受特定的输入，都只会有一个特定的状态。根据这样的定义，我们可以将软件程序描绘为有限状态机（有限自动机）。考虑到这一事实，以及状态可用性和转换模型（例如图1），我们可以定义一套特定的页面间转换（工作流）的集合，它将能够覆盖程序的大部分功能。
　　架构模式
　　多层的测试解决方案
　　该模式从逻辑维度将正在测试的系统划分为独立的逻辑层级。
　　将软件系统以架构性方式分为独立的层级是一个广为流传的实践。第一层封装了表述逻辑，第二层则是业务逻辑层，而第三层负责数据存储。使用这一范式，有助于降低应用维护成本，因为更换每层内部的组件对其他层级的影响将被小化。而同样的方法也可以运用到测试系统中。
　　测试代码同样可以分为三层：用来向SUT提供访问的UI自动化工具界面层、功能逻辑层和测试用例层。每一层都肩负特定的责任，而它们都在追求共同的目标——降低测试维护成本，提升创建新测试的便利性。

　　图 3: 架构性原型——测试系统的多层架构