目前比较常见的自动化测试框架主要有3种：数据驱动框架、关键字驱动框架和混合型框架。

　　1、数据驱动框架（Data Driven Framework）

　　数据驱动最适合测试的业务逻辑固定不变的应用程序，只有测试数据会变化。通常测试数据会被配置在外部文件或数据库中。

　　2、关键字驱动框架（Keyword Driven Framework）

　　关键字驱动顾名思义，它提供了一系列通用的关键字，用户通过调用这些关键字并输入一些参数可以实现单个操作，比如，打开浏览器、打开某个网页、点击某个链接等等，然后通过组织这些关键字形成一个完整的测试流程。

　　3、混合型框架（Hybrid Framework）

　　混合型框架就是把数据驱动和关键字驱动整合起来，同时具备了两者的优点。与关键字框架不同的是，这种框架通常会提供一些针对于特定应用程序的关键字，比如登录、登出等。然后在完整测试流程的基础上，再应用一层数据驱动，这样就能使测试逻辑和测试数据更加灵活和可配置。

一、自动化测试管理

自动化测试用例的执行机制一般包括管理端和执行端，由管理端发出信号通知执行端开始执行相应的测试任务，从而执行相应的脚本进行测试，并将测试结果报告管理端。

1．管理端

管理端主要完成以下任务：运行控制的决策系统，负责建立并维护运行队列，控制运行策略和信号灯；在管理端还必须维护一个测试任务的队列，每个测试任务的开始执行的时间可能不同，状态也不一样，管理端根据这些标志对其进行控制。

2．执行端

执行端根据管理端的决策系统，来执行运行队列中的测试脚本，其中运行控制的执行系统，负责分配测试脚本，并按照指定策略启动脚本等也是执行端的功能。

二、自动化测试脚本开发

1．测试驱动

测试驱动是一个自动化测试框架的核心，其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动，使用不同的测试驱动，关系到脚本重用率，以及后期的可维护性。

（１）数据驱动

基于数据驱动的自动化测试框架是指测试驱动引擎从数据源获取测试数据，然后将将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。一般数据源与测试结果存储在、Excel文件、Csv文件等。数据驱动主要优点是：测试脚本与测试数据的分离，当应用功能变更时，只需要修改该功能部分的脚本；执行测试用例的人员不需要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的，测试人员可以有选择的执行测试用例。数据库

（２）关键字驱动

关键字驱动的自动化测试框架是在数据驱动的基础上进行改进，数据源里包含的不只是数据，还有关键字，一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑，例如，登录、注销等。数据表通过关键字，查找映射表，执行相关的脚本。

（３）驱动引擎

驱动引擎是对数据表的数据进行分析，根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断，以及测试报告的处理等。

2．测试脚本开发

　　测试脚本开发必须通过详细、合理的设计，要对脚本代码进行划分，脚本文件或数据文件分层管理。这样有利于自动化脚本的开发与维护，从而节省自动化测试的投入成本，也使得不同测试人员或开发人员可以协调开发脚本。

（１）脚本规范

　　测试脚本的开发也要遵循编程的规则与标准，应该统一规划，所有开发脚本的人员按照统一的规定进行编码。除了编程本身规范，还考虑测试用例与库函数名的命名，测试用例需要加上项目名称，但公共的库函数却不需要，因为公共的库函数是独立于项目的。例如，项目M4.1客户端登录测试用例可命名为：TC_M4.1_client_login；读取excel表的函数可命名为：read_excel。

（２）脚本划分

测试脚本的划分，如何定义公共的脚本库，不同模块特有的脚本库，以及直接构建测试用例的脚本。为了方便以后脚本的维护问题，必须对脚本进行有效的分层，同时，提高了脚本的复用率。

① 公共类库

公共类库包括所有模块都可能用户的操作方法，其抽象了不同模块同性，比如操作excel表的方法、读写测试报告、驱动引擎等。

② 模块特定类库

在模块内部将可以为该模块共享使用的方法抽象出来，作为一个公共类。它可以是一个单的逻辑操作，也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。

③ 测试用例脚本

测试用例脚在最上层，它根据测试点进行设计，面向具体的应用。它可直接调用公共类库或模块特定类库的方法，即调单个逻辑操作。它是单个或多个逻辑操作的集合，即一个测试用户脚本。比如，在客户端访问资源的测试用例，它调用了客户端登录方法和访问资源方法。

（３）测试用例

① 测试用例粒度

测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。应该根据每个系统的具体情况来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大，这样一旦出执行测试用例出错，不利于定位问题；但也不能太细化，太小则不方便执行。

② 测试用例与测试套件

一个大型的项目有许功能模块，必然会产生大量的测试用例，怎样才能有效的管理这些测试用例呢？这就需要创建测试套件，通过测试套件将测试某一个模块或功能点的测试用例集合起来，方便运行与管理。例如，只验证“用户管理”模块功能，则只需要执行“用户管理”模块套件即可。

（４）脚本与html标记分离

脚本与html标记分离使得在一定程度上脚本独立于WEB页面，脚本没有直接的处理html标记，脚本代码通过html映射表获取赋有WEB页面标记值的变量。WEB页面标记包括html标记和页面内容（文本或图片等，这些都可能是判断用例是否成功能的检查点），当WEB页面标记变更后，不需要在范围的修改脚本。

（5）选择适合自动化测试的用例

在编写自动化测试脚本前，首先要确定哪些用例适合做自动化测试，因为自化测试不像手工测试，它不能那么智能，也没有发发散思维。

通常适合自动化测试的用例有：

产品型项目。产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。

回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。

有一些交互性比较强，需要人工干预的操作，就不要指望通过自动化测试来完成了。例如，用户使用DKEY登录