对于某个特定程序，为其开发自动化功能测试解决方案的过程，与创建该程序的过程，二者相较并没有很悬殊的差别。自动化测试是一个非常年轻的领域，它正在不断经历大量的进步、提升和标准化进程。在这个领域中，涌现了许多与“被测系统”（SUT，System Under Test）互动的新工具。
　　现在，软件开发方面有大量可供选择的方法论和途径，例如：面向对象编程、函数式编程、领域驱动设计、测试驱动设计、行为驱动设计等等。它们拥有明确的声明性概念和理论，并简化了对初始系统架构的定义过程、对系统的理解以及开发者之间的知识交换等方面的工作。
　　本文将主要针对GUI（图形用户界面）应用的测试自动化进行讨论——从自动化开发人员的角度看，在这种情况下被测系统（SUT）表现为一个黑箱（被测系统，是指一个正在测试是否能够正确操作的系统。对于桌面应用来说，它是应用本身，而对浏览器系统来说——则代表了网站/Web项目等含义）。在公司的遗留系统占很高比例的环境里，或是在新开发的系统没有考虑可检测质量属性时，这一现象非常常见。
　　对佳实践的准备和定义，是开发自动化的测试的关键部分。下图展示了被测系统和测试者之间的传统交互：

　　测试者与SUT之间的交互
　　位于该系统中心的，是一个扮演测试者角色的人类个体。测试者使用手动交互和应用的视觉化分析，以及特定的SUT非可视化界面访问工具，将测试用例中所描绘的场景进行复制。如果失败或是遇到系统意外行为，测试者便将错误行为的有关信息输入到默认的追踪系统中。
　　自动化测试的主要目的，是消除（或者至少小化）人类与SUT之间的交互。在持续交付产品开发周期中，这是非常常见的问题。一份文献来源的研究表明，现在自动化测试系统的数量非常多。商业产品一般会公布一系列详细的要求和推荐，特别适用于其产品。但是这些厂家往往不会公布适合与任何自动工具一起使用的一系列工具诊断实践。
　　此外，这些自动工具软件提供商往往还会运用营销手段，基于小量功能测试来描绘其系统的优势。但是随着自动化测试数量的增长，维护现有测试将成为系统工作流程中昂贵的部分。
　　自动化测试框架旨在帮忙解决这些问题。他们定义了基本的系统可复用组件，公布了佳实践和统一自动方法——为了正确地开发自动化测试框架，我们需要得到独立佳实践的指导。
　　自动化功能测试的模式
　　让我们检查以下Web应用程序自动化方面的问题（图1），这是一个自动化解决方案装置的例子。该应用包含了一幅登录页面，而每项测试都必须经过该页面，才能进行更进一步的测试。

　　图1：示例——拥有少页面和功能集的简单Web应用
　　分类体系（图2）为我们带来了全部功能测试模式的整体视角，本文稍后会对各个模式展开描述。

　　图2：自动化功能测试模式的分类