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