基于只使用一种捕获工具例如IBM Rational® Robot来录制并且回放测试用例而得出自动化测试工作量是有缺陷的。只使用一种捕获工具来运行复杂且巨大的测试是非常耗费时间和昂贵的。因为这些测试是随机创建的，他们的功能性是很难追踪和重现，而且维护成本也是非常昂贵的。

对于一个刚刚起步的自动化测试小组，更好的选择是使用一种测试自动化框架，它已经定义好了由一些假设，概念和制定工作平台或为自动化测试提供支持的实践组成的集合。在这篇文章中我试着将一些我熟悉的测试自动化框架－特别是测试脚本模块化，测试库构架，关键字驱动/表格驱动测试，数据驱动测试和混合的测试自动化。我并不会评价哪一个框架更好或更差，而只是提供了一些关于他们的描述和演示，所适用的地方和如何使用IBM Rational工具集实现的一些技巧。

测试脚本模块化框架（The Test Script Modularity Framework） 

测试脚本模块化框架需要创建能够代表测试下应用程序（application-under-test）的模块，零件（Section）和函数的小的，独立的脚本。然后用一种分级的方式将这些小脚本组成更大的测试，实现一个特定的测试用例。

在我将提及的所有的框架中，这种框架应该是最容易精通且掌握的。就在一个部件前面构建一个抽象层以掩藏应用程序其他的部件方面，它是一个很著名的编程策略。它把应用程序从在部件的修改中隔离开来并规定了在应用程序设计中的模块性。为了提高自动化测试套件（test suite）的可维护性和可测量性，测试脚本模块化框架应用了抽象或封装的原则。

为了演示这种框架的应用，我以自动化Windows计算器程序中的测试其基本功能（加，减，乘和除）的一个简单测试用例（如图）为例。

脚本层次结构的最下层是独立的加减乘除的脚本。下面的第一个脚本是加法，第二个是减法。

然后在层次结构中下一级的两个脚本用来代表视图菜单中的标准视图和科学视图。就像下面的关于标准视图的脚本中表现的一样，这些脚本调用了我们在之前创建的脚本。

最后，在层次结构中最顶层的脚本应该是用来测试应用程序不同视图的测试用例。

从这个简单的例子中你可以了解到这种框架是如何产生高度的模块化并且增加测试套件的全面的可维护性。如果以后计算器上的某一个控制键被移动了，你所需要改变的只是底层调用这个控制键的脚本，而不是测试这个控制键的所有测试用例。

测试库构架框架（The Test Library Architecture Framework）

测试库构架框架和测试脚本模块化框架非常相似，有着同样的优势，但是它把测试下的应用程序分成过程和函数，而不是脚本。这种框架要求创建代表测试下应用程序模块，零件和函数的库文件（SQABasic libraries, APIs, DLLs等等）。然后这些库文件被测试用例脚本直接调用。

为了演示这种框架的应用，我将自动化同上的测试用例，但使用了一个SQABasic的库文件。这个库文件包括执行操作的一个函数。以下是头文件（header file (.sbh)）和库文件（library source file (.sbl)）。

使用这个库文件，产生以下测试用例脚本。

从这个例子中，你能够看到这种框架也产生了高度的模块化，同样增加了测试套件的全面可维护性。就像在测试脚本模块化一样里，如果计算器中的一个控制键移动了，你所要做的只是更改库文件，这样同时也更新了所有调用控制键的脚本。

关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework）

关键字驱动和表格驱动测试是一种独立于应用程序的自动化框架，它们是可以互相替换的术语。这种框架要求开发于用来运行的自动化工具，驱动测试下应用程序和数据的测试脚本代码相独立的数据表和关键字。关键字驱动测试看上去非常象手工测试。在关键字测试里，应用程序的功能特性被写在表格和每个测试的详细指引里了。

如果要映射出手工测试Windows计算器功能过程中用鼠标执行的操作，我们可以创建如下的表格。” Window”一列包含了我们执行鼠标操作的应用程序窗口的名字（在这个例子中，他们都发生在计算器窗口里）。” Control”一列指出了鼠标点击的控制键的类型。” Action” 一列列出了鼠标的操作（或是测试人员的）。”Arguments”列指出了特定的控制键（1, 2, 3, 5, +, -等）

这个表格代表了一个完整的测试，为了表示一系列测试可以根据需要增加。一旦你创建了数据表，你就可以简单地编写用来读取每一个步骤的程序或脚本集，基于Action字段中的关键字执行步骤，完成错误检查，然后记录任何相关的信息。这种程序或脚本集看上去象下面的伪代码：

从这个例子里你可以看到为了生成许多的测试用例，这种框架只要求非常少的代码。用数据表生成不同的测试用例却可以重用相同的代码。IBM Rational工具集可以通过使用交互式的文件读取，查询或数据池延伸开来，或者你可以连同IBM Rational一起使用其他的工具（免费，其他的开发工具等）来构建这种类型的框架。

数据驱动测试框架（The Data-Driven Testing Framework）

数据驱动测试是测试从数据文件（数据池，ODBC源，cvs文件，Excel文件，DAO对象等）中读取输入和输出数值并载入到捕获的或手工编码的脚本中变量里的一种框架。在这种框架里，输入数值和输出验证数值都使用变量。在测试脚本中编写贯穿程序的导航，数据文件的读取，记录测试状态和信息的日志的代码。

测试用例包含在数据文件里而不是在脚本里的方面上，这种框架和表格驱动测试有些相似；脚本只是一种“驱动器”（driver）或传送数据的机制。尽管导航的数据不包含在表结构中，但和表格驱动测试还是不同的。在数据驱动测试里，只有测试数据包含在数据文件中。

如果使用SQABasic语言和IBM Rational的数据池功能，IBM Rational工具集里有自带的数据驱动功能。为了演示这种框架的使用，我们将测试一个简单应用程序中的订单表格。

如果我们录制这个窗口中的数据输入，得到以下脚本：

我们可以使用数据池来设置测试有效和无效信用卡号和过期日期的测试用例。例如，下图中是用于测试数据字段的测试用例中的数据池，

为了接收这些数据，我们修改脚本如下：

为了使用数据池，我增加了SQABasic命令，还增加了“While”循环来处理在数据池中每一行数据。我必须说明一下在“If…Then”语句中的Ucase（SQABasic命令）函数。Ucase用于将参数（在这个例子里是指数据池返回的数值）全部转换成大写。这种方法不是大小写敏感的，所以代码更强壮。

这个框架趋向于减少你为了实现所有测试用例而需要的全部的脚本数量，并且在开发绕开错误的办法（Workaround）和维护方面提供了最好的灵活性。和表格驱动测试非常相似的是，表格驱动测试只需要非常少的代码就可以产生大量的测试用例。用IBM Rational工具集实现这种框架是非常容易，并且它也提供了大量的关于指引和例子的详细文档。

混合的测试自动化框架（The Hybrid Test Automation Framework）

最常见的已实现的框架是上述技术的组合，抽取它们的优点，剔除其弱点。这种混合的测试自动化框架是发展时间较长且应用项目最多的框架。下图可以让你对如何用IBM Rational工具集组合不同的框架有初步的认识。

总结  

我描述了自动化测试小组可以考虑使用的5种测试自动化框架，而不是依赖某一种捕获工具。你可以使用一种或它们之间的组合。你可以通过嵌套测试脚本实现模块化并使用SQABasic库文件来实现功能和过程。不管你选择哪一种数据驱动技术，你都可以使用数据池，或者你还可以扩展Robot来处理其他数据存贮类型。应用最好的框架的窍门和解决他们的唯一方法是投入进去并开始使用它们。