第一章      前言

为 了提高测试效率和准确性，越来越多的测试工作引入了自动化测试的思想和方法，随着自动化测试工具的发展，自动化测试更加容易实现更高效。实践证明，软件自 动化测试技术帮助软件开发和测试人员在更短的时间内开发出更高质量的产品，通过代替频繁重复的手工测试从而节省了大量的时间开支。同时，自动化测试技术也避免了手工测试出现的人为错误，完成了许多手工测试无法实现的工作。

自动化测试相较于手动测试有许多明显的优势，执行高效率、测试数据覆盖面大、结果可信。但同时自动化测试也存在着一些限制。简单的录制/回放测试工具本省无法提供高效的测试。依靠捕捉产生脚本的维护需要耗费大量的时间。在项目需求不稳定或页面频繁变动的阶段，自动化测试的效率将非常低下。

面对自动化测试的这种尴尬，关键字驱动的自动化测试可有效地提高自动化测试脚本的维护效率。关键字驱动的自动化测试搭建了一个自动化测试框架，测试框架脚本与业务、数据分离，节省了大量对脚本的维护工作。本文对关键字驱动的自动化测试做具体介绍。

第二章      自动化测试工具存在的问题

基本的录制/回 放自动化测试具有简单易用、快速上手的特点，但在实际应用过程中存在很多问题。最常见的一个问题是对程序界面进行测试时，一旦界面有任何改动，都需要我们 去手工修改已录制的相应测试脚本，或者重新进行一次录制。这需要消耗很大的工作量，尤其对于程序中各模块都要使用的公共程序部分（如登陆页面），他的改动 会引起大量脚本的返工。如在使用Rational Robot录制的点击按钮操作的脚本：测试工具通过按钮的名字、显示文本来识别这个按钮。可以想象，当其中任何一个部分发生变化时都会对脚本造成影响，维护如此的脚本将很可能花费大量成本。

另一个问题是移植风险大。被测试软件转换平台，或转变自动化测试工具都可能造成测试用例被破坏，很可能要对现有脚本进行大量修改或重新录制。因此转换平台或转换工具可能对自动化测试带来毁灭性影响。

第三章         自动化测试的发展

3.1自动化测试框架的发展

一 个自动化测试框架就是一个由假设、概念以及为自动化测试提供支持的实践的集合。自动化测试框架可以减少测试脚本实现和维护的成本，使测试人员把精力集中在 测试用例的设计上。自动化测试框架的好坏直接影响到自动化测试的成功与否。一个优秀的自动化测试框架应该满足以下特点：

1) 测试框架与被测应用程序独立。虽然测试的应用程序不一样，但被测应用程序之间却会有相同的地方，测试框架应聚焦在不同测试应用程序中共同的部分，把与具体应用程序有关的部分从框架中移除。

2) 测 试框架应易于扩展、维护。测试框架应被高度模块化，这样可以提高框架的维护性。各个模块之间相互独立，对模块内部的修改不应该影响其他模块。除此之外，系 统应该有充足、详细的文档，与软件开发一样，这也是必不可少的。设计文档可以帮助开发人员扩展、维护测试框架，而使用文档则可以告诉用户要怎么使用该框 架。

3) 测试脚本所使用的测试语言应该是与框架独立的。不同的测试框架可能在不同的应用领域有不同的表现，有些适用于Java应用程序的测试， 有些可能适用于Web应用程序的测试，如果测试脚本所采用的语言是私有的、与测试框架绑定的，那么当需要从一个测试框架迁移到另外一个测试框架时，所有的测试脚本都需要重写。

4) 测 试框架不应该让框架的复杂性影响到测试人员。在大多数情况下，测试人员就是测试人员而不是开发人员，甚至有的时候，他们不是专业的测试人员，可能只是具有 很少软件开发经验的某个应用领域的专家。对于这些使用者来说，测试框架的使用要简单、测试语言要易于理解，这样可以使他们专注于业务相关内容的编写。

基于界面的软件自动化测试框架和工具的发展大致经历了三个阶段：

1）简单的录制／回放：由工具录制并记录操作的过程和数据形成脚本，通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起，几乎一个测试用例对应一个脚本，维护成本很高。而且即使界面的简单变化也需要重新录制，脚本可重复使用的效率低。

2）数据驱动 （data driven）的自动化测试：从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离，脚本的利用率、可维护性大大提高，数据的覆盖率也较高，但受界面变化的影响仍然很大。

3）关键字驱动（keyword driven）的自动化测试：关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。 主要关键字包括三类：被操作对象（Item）、操作（Operation）和值（value），依据不同对象还有其他对应参数。关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。数据驱动的自动化测试框架在受界面影响方面，较数据驱动和录制/回放有明显的优势，可根据界面的变化更新对应的关键字对象，而不用重新录制脚本。

关键字驱动的自动化测试系统与数据驱动的系统相比，主要的不同有两点：第一点是数据文件 的设计方法不同，数据驱动系统中数据文件存储的是测试输入数据，脚本中仍然存在业务逻辑，这样业务的变化会引起脚本的更改，而关键字驱动系统数据文件的设 计将业务和测试输入数据都集成在数据表格中，虽然设计复杂，但当业务发生变化时，无需更改测试所用的脚本，从而提高了测试的效率。第二点是与数据驱动系统 相比，由于关键字驱动系统中数据文件的设计包含了业务信息，因此，将测试所进行的操作封装为关键字支持脚本。由动作封装的关键字支持脚本不包含任何的数据和业务信息，其重用性得到了极大的增强。

3.2自动化测试脚本的发展

相应地，软件测试自动化脚本的类型也依据脚本框架的演进在不断发展，从低到高的发展层次是：

1)   线性脚本：通过录制直接产生的线性执行的脚本，类似于宏录制。

2)   结构化的脚本：具有顺序、循环、分支等结构的脚本。

3)   共享的脚本：可以被多个测试用例使用，被其它脚本调用的脚本。

4)   数据驱动的脚本：数据和流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本。

5)   关键字驱动的脚本：脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是它描述一个测试事例做什么, 而不是如何做，测试脚本调用测试用例再具体执行。

第四章  关键字驱动的自动化测试框架

4.1基本原理

关键字驱动的自动化测试框架是对数据驱动的逻辑扩展，用关键字的形式将测试逻辑封装在数据文件中，测试工具只要能够解释这些关键字即可对其应用自动化，它的核心思想可以概括为三个分离。

1）界面元素名与测试内部对象名的分离 在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。

2）测试描述与具体实现细节的分离，把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常与特定的平台以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。

3）脚本与数据的分离 最后，可以把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。

以上这三个分离各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度地实现了测试工具的自动化。

例如在一个登陆页面输入用户名，用一个测试表（表格1）来表示：

图表 1 登陆测试表

这个测试表的含义是在LoginPage窗口的UserID文本框中输入“admin”。其中InputText是关键字，当测试程序读取它的时候，就会调用相应的处理函数，处理脚本动作。

 关键字驱动测试模型

图 1 关键字驱动模型

测 试首先由初始脚本开始，把高层测试表传递给高层驱动器，高层驱动器在处理这些表的过程中，遇到中层测试表就调用中层驱动器，中层驱动器处理中层表。当低层 驱动器处理低层表的时候，他试着使应用与测试保持同步。当低层驱动遇到某一成员的关键字指令时，它调用相应的函数模块来处理关键字的动作指令。所有这些元 素都要依靠映射表中的信息，踏实自动化模型和应用间的桥梁。

应用映射表

映射表是关键字驱动自动化测试中的关键组件之一。映射表是对应用中的每一个对象定义一套命名规范，并利用映射表把这些名字和自动化工具识别的对象名联系起来，是工具能准确定位和操纵对象，我们的脚本只需进行单点维护。

映射表的建立有许多种，简单的就是 通过自动化测试工具进行自动捕获，将捕获的对象信息存储于指定的数据表格或数据库之中。如果是自动捕获可以分类记录尽可能多的对象的属性，使得测试脚本更 方便地标识对象。另一种就是采用人工录入，即对于自动化软件测试需要用到的对象信息采用手工识别的方式录入数据文件或数据库之中。这种方式通常是挑选最能 达到测试效果的一组对象属性即可。对于结构复杂的软件可以根据软件的不同层次或是软件界面的不同区域划分对象库。例如对于窗口空间，我们可以将窗口命名为 上下左右主几个部分，将位于不同窗口区域的控件信息保存到相应的窗口名称之下，这样当软件升级或者是GUI界面发生变化时，对于增加的窗口或者是控件，只需要使用测试工具捕获其标识属性，并人工填充到映射表内即可。这样就为测试脚本提供了对象识别的仓库。

成员函数

成员函数是实现用户对界面对象操作指令的函数，一个成员对象的类型对应一个成员函数库。例如对以一个文本框对象，可对它进行多种操作：输入文本、验证文本框的值等，实现这些操作行为的函数就被放在文本框的成员函数库中。一般的测试工具都提供了这样的函数。

成员函数相当于在应用和自动化工具之间提供了一个隔离层，如果没有这个隔离层，自动化工具本身的改变会影响到已有的脚本。有了隔离层，当测试工具发生变化时，可以在成员函数库中增加一段修补代码来适应变化。

测试表和核心驱动程序

测试表分低层、中层、高层。低层测试表指定了测试的每一步指令语句，这些指令都是直接作用在界面对象上的，是无法再锌粉的指令。中层测试表把低层表组装起来执行任务，形成测试用例。高层测试表把中层表组装起来，利用循环完成不同的中层测试，形成测试集。

例如打开网页、登陆、关闭页面这三个动作可以用三个低层表来表示（如表），每个表定义了实现相应动作的具体步骤，所以低层表示又叫做步骤表。低层表中使用了映射表中定义的对象名，和成员函数库定义的底层关键字库。

图表 2 “登陆”步骤表

这个“登陆”动作的低层表可能出现在“验证正确登陆”，“验证错误登陆”和“验证空白登陆”等中层用例表中，这些中层表合起来构成了“验证权限”高层表。