Test Automation Frame--主要框架的介绍|江阴雨辰互联

2023年6月29日发(作者：)

选择一种自动化测试框架--Choosing a test automation framework

本文介绍了5种基本的自动化测试框架：

 测试脚本模块化之框架--The Test Script Modularity Framework

 测试库架构之框架--The Test Library Architecture Framework

 关键字驱动或表驱动测试之框架--The Keyword-Driven or Table-Driven Testing

Framework

 数据驱动测试之框架--The Data-Driven Testing Framework

 自动化测试之混合框架--The Hybrid Test Automation Framework

翻译：fennek

2007年2月6日

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

特点：

1. 创建小粒度、且独立的脚本，这些脚本代表AUT中的模块、区域和功能；

2. 小粒度脚本使用等级方式来构造更大的测试，实现特定的测试用例。

原理：

开发策略中的模块化设计，在组件之前构建一个抽象层，以此对其他应用程序隐藏该组件。

意义：

利用此抽象和封装原则提高自动化测试序列（suites）的可维护性和可伸缩性。

程序示例：

AUT—Windows Calculator program图1所示图1 AUT示例

底层脚本—表示最基本的加法和减法功能，图2和图3所示：

图2 加法功能脚本图3 减法功能脚本

二级脚本—表示View菜单中的标准型和科学型窗口，这一级的脚本包含了对前面那些底层脚本的调用，图4以标准型窗口为例：

图4 二级脚本—包括了对底层（基本功能）脚本的调用

最后，是最顶层的脚本，它表示了一个具体的测试用例，测试应用程序不同类型下的窗口，脚本代码如图5所示：图5 最高层的脚本—表示了一个具体的测试用例

从上面这个简单的例子可以看出，此框架的脚本模块化程度很高，同时也增加了测试序列总的维护量。如果计算器上的控件发生了变化，那么需要修改与此相关的所有底层脚本，并不需要修改与此对应的测试用例。

译者注：我曾经翻译过一篇名为《Robot实例研究》的文章，文中所提及的测试脚本的构建框架，与此框架非常类似。

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

此框架与测试脚本模块化之框架非常类似，并且具有相同的优点。它把AUT分为过程和函数。同时，此框架需要创建库（library）文件—如SQABasic库、APIs和DLLs等，表示AUT的模块、区域和功能。这些库文件直接由测试用例的脚本来调用。

我们使用一个SQABasic库，把上面那个相同的测试用例自动化。这个库包含了执行此操作的功能。脚本示例程序如图6和图7所示：

图6为头文件—header file（.sbh）

图7为库的源文件—library source file（.sbl）

图6 头文件（.sbh）图7 库的源文件（.sbl）

使用此库，可产生下列的测试用例脚本，图8所示：图8 测试用例的脚本

从上面这个简单的例子可以看出，此框架的脚本模块化程度很高，同时也增加了测试序列总的维护量。如同测试脚本模块化，如果计算器上的控件发生了变化，那么需要修改与此相关的所有库文件，并不需要修改对应的测试用例。

关键字驱动或表驱动之框架（The Keyword-Driven or Table-Driven Testing

Framework）

关键字驱动测试和表驱动测试是可以互换的术语，它们代表了一种独立于应用程序的自动化框架。这个框架需要开发数据表和关键字，这些表和关键字要独立于所使用的自动化测试工具和脚本代码。关键字驱动测试看上去非常像手工的测试用例。在关键字驱动测试中，AUT的功能被放入到一个表中，并进行描述，每一个测试都有一步一步地说明。

我们可以做一张表，如下所示：

 “Window”（窗口）一栏包含了应用程序的窗口名称，表示我们的鼠标行为发生的区域（在这个例子中所有的行为都发生在计算器窗口中）；

 “Control”（控件）一栏包含了控件类型的名称；

 “Action”（行为）列中是一些鼠标行为；

 “Arguments”（控件的参数）列中是具体的控件名称（如1,2,3,4,5,+-等等）。

Window Control Action Arguments Calculator

Calculator

Pushbutton

Click

Verify Result

Clear

Click

Verify Result

View, Standard

它表示了一个完整的测试；我们也可以做更多的表来表示一个系列的测试。一旦我们创建了数据表，那么可以简单地编写一些代码或者脚本，读取并执行这些基于关键字的步骤，它们包含了Action字段、检查执行时的错误，并记录相关的信息。这些代码或脚本看上去像伪码，具体如下所示：

Main Script / Program

Connect to data tables.

Read in row and parse out values.

Pass values to appropriate functions.

Close connection to data tables.

Menu Module

Set focus to window.

Select the menu pad option.

Return.

Pushbutton Module

Set focus to window.

Push the button based on argument.

Return.

Verify Result Module

Set focus to window.

Get contents from label.

Compare contents with argument value.

Log results.

Return.

通过这个例子，我们可以看到，此框架只需要很少量的代码来生成测试用例。在复用相同的代码时，数据表被用来生成单个的测试用例。

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

数据驱动测试之框架指测试的输入和输出值，是从外部的数据文件中读取的（比如datapools、ODBC源、cvs文件、Excel文件、DAO对象和ADO对象等），同时，脚本代码中有对应的数据变量。在此框架中，输入值和输出的校验值在脚本代码中都使用变量表示。通过代码导航，读取数据文件，并记录测试的状态和信息，所有的这些代码都包含在测试脚本中。

这有点类似于表驱动测试，同样是测试脚本中不包含数据文件，这样的脚本就像数据的“驱动器”，或者传送机构。与表驱动测试不同的是，导航数据并没有包含在表结构中。对于数据驱动测试而言，数据文件中只包含测试数据。

针对此框架的使用，我们会以一个简单的订单程序为例来说明。如下图所示：

如果我们要记录此窗口中录入的数据，我们可以得到如下的脚本代码：

我们可以使用数据池（此文的作者选用IBM Rational Robot为测试工具，datapools是robot中的一项重要功能）来设置测试用例，以此测试有效和无效的信用卡卡号和截至日期。下图是一个datapools的例子，它包含了我们要测试的数据字段。

如果我们要修改脚本以接受这些数据，那么我们可以得到如下的脚本代码：  添加了用以操作数据池的SQABasic命令；

 添加了一个While循环，把数据池中的每一行数据都进行处理；

 添加If UCase Then语句，UCase被用来制造参数（此例中为数据池的返回值）。

此框架可以减少测试脚本的总量，且维护和修改都具有很大的灵活性。与表驱动测试非常类似的是，数据驱动测试也只需要很少量的代码来生成测试用例。在具备恰当的测试工具时（原文作者在此以IBM Rational的工具集为例），此框架实施起来非常容易，并且有大量的细节文档和实例说明。

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

一般说来，我们实施的测试框架都是以上所有技术—框架的组合体。自动化测试之混合框架的具体形式如下图所示：

译者注：原文处的此图亦无法放大，只能以此形式示人，非常遗憾。

综述（Roundup）