面向C/S结构的软件自动化测试工具的设计

刘汉烨

（榆林学院 信息工程学院，陕西 榆林 719000）

随着IT技术的迅速发展，软件的规模越来越大，软件测试在整个开发流程中所占的比重越来越大。有关统计表明，在软件开发总成本中，软件测试所占的开销为30%～50%[1-2]。有人估计，测试阶段的开销要占到整个软件生存周期开销的50%甚至50%以上。如此巨大的软件测试工作量，以往以手工测试为主的软件测试方法往往会显得力不从心，这为整个自动化测试理论的产生提供重要的应用背景。

软件自动化测试是解决当今软件复杂化测试的一个必然方向。软件测试过程有很多操作是重复性的、非智力创造性、细致的工作。这类型的工作很适合做自动化，因此如果能将软件测试中大部分这种类型的工作实现自动化测试，将会对软件开发工作的质量、成本和周期带来非常显著的效果[2]。

1 相关概念

1.1 回归测试

在软件开发过程中，测试工作的很大一部分是回归测试（Regression Testing）。回归测试主要是验证系统的变更是否影响系统在变更前所具有的功能，保证当前变更功能的正确性。在渐进和快速迭代开发中，新版本的连续发布使回归测试的执行更加频繁，而在产品即将发布的时间段内，更是要求每天都进行若干次回归测试。为了验证修改的正确性及其影响，就需要进行回归测试，执行回归测试时，首要应考虑覆盖范围足够大，而且用尽可能少的时间执行回归测试，尽量进行自动化的回归测试[3]。

1.2 关键字驱动技术

为了让测试程序按照我们的意图去执行测试，就需要使用一组控制命令来控制脚本的执行。这些控制命令是由测试软件的共享函数库来解释的[4]。这些控制命令就是关键字，代表某个动作。关键字的不同组合可以构成不同的测试逻辑。

2 自动化测试工具的设计

2.1 总体框架模型的设计

测试工具包括以下组件：测试引擎、测试用例列表、测试用例配置文件集、测试用例集、日志生成器及公共函数库等。测试工具的体系结构如图1所示。

图1 测试工具系统架构

2.2 自动测试框架的实现

测试软件的测试框架基于3层脚本驱动方案，即测试软件的测试脚本分为3类：高层脚本、中层脚本及低层脚本[4-6]。高层脚本为测试引擎，其主要工作为解析测试用例表，并将解析出的结果传递给中层脚本或底层脚本。中层脚本位于测试脚本集中。测试脚本集是中层脚本和底层脚本所在目录，测试脚本根据测试用例的不同分类分布在不同的文件夹下。中层脚本主要负责接收高层脚本的解析结果，并调动底层脚本。底层脚本为测试用例具体执行脚本，是测试过程的主要实施者，每个测试用例对应1个底层脚本，脚本名与测试用例名一致。

2.3 测试工具主要模块

2.3.1 测试引擎的设计

测试引擎主要由初始化、命令行解析、测试用例执行及系统清理和恢复等4个模块组成。

1）初始化模块 主要负责处理初始化工作。初始化工作包括检查被测软件的工作状态，修改相关文件夹属性，载入相关运行函数库等。

2）命令行参数解析模块 主要负责解析运行测试工具的命令行，以便完成不同类型的测试。

3）配置文件备份和恢复模块 主要负责测试工具运行前被测软件部分配置文件的备份情况，以便在测试工具发生运行错误时及时恢复被测环境。

4）测试用例执行模块 测试引擎4个模块中最核心的模块。该模块的主要任务有：从测试用例表中自动调用所需的测试用例并执行之；生成测试日志和测试报告；从已结束的测试用例中获取返回信息；清理及重新初始化系统。

2.3.2 配置模块设计

配置模块主要负责测试工具测试环境的配置。测试工作所需的各种环境变量都是可配置的，测试人员在测试时可以根据自己的测试场景选择配置。该配置模块中主要有用户配置、机器配置、测试用例列表、测试数据文件及测试软件测试过程中所需要的其他配置信息。测试用例列表是整个配置模块的核心文件，整个测试工具在测试过程中所要用到的有关测试用例的信息全部在测试用例列表中获取。测试用例列表最基本的组成部分应包括测试用例ID、测试用例执行脚本的目录位置及测试用例功能描述信息等。测试数据文件中包含的内容有测试用例测试逻辑、关键字及测试数据等。在测试的执行过程中，测试工具会依据不同的测试场景从中取得所需要的数据，用以替代测试驱动和执行脚本中的变量。

2.3.3 日志系统设计

日志系统也是测试工具的设计中非常重要的一个模块。测试工具的日志系统包括3部分，分别是单个测试用例的测试日志，测试用例组的测试报告及整个测试过程的测试报告。从日志系统产生的日志类型来划分，日志由2部分组成：一部分是输出到测试机器屏幕上的日志，用户使用输出到测试机器屏幕上的日志可以很方便的跟踪测试过程；另一部分是以文件的形式保存起来的日志。后一种类型的日志保存在一个文件夹内，该文件夹是测试日志的顶级目录，文件夹内的测试日志又以不同分类的测试用例而归类保存。日志系统目录结构图如图2所示。

图2 日志目录结构图

2.4 测试用例模板方案

被测软件测试点依据功能的复杂程度来划分，一般情况下可以划分为2大类：复杂功能测试点和简单功能测试点。针对这两种不同类型的测试点，可以采用两种不同的设计方案。即结构化单脚本测试模板方案和关键字驱动技术方案[7]。

2.4.1 结构化单脚本模板方案

结构化脚本模板方案主要是针对复杂的功能测试点而设计的。被测软件的测试用例被划分成了很多测试组，每一组测试用例在功能上基本接近，组内不同测试用例有可能只是所用的参数不同。那么这类测试用例就可以使用结构化单脚本模板方案。该方案的实施方法是：首先为测试用例开发一个模板脚本，组内其他测试用例脚本负责向模板脚本传递参数。

2.4.2 关键字驱动技术方案

关键字驱动技术方案主要是针对功能比较单一的测试点而设计的。该方案的实施方法是：首先在配置文件目录中新建一个数据文件，数据文件中存储的是各测试用例的配置信息，具体包括测试逻辑的定义、测试所需的数据及定义好的关键字。由于该方案主要针对于单一测试点，所以测试逻辑可以分为4大部分，逻辑结构可用以下结构来表示：

其中，Begin和End是测试工具保留字，用来定义每个测试用例的开始和结束，紧接着它们的是测试用例的测试序列号，该测试序列号在整个测试工具中是唯一的。preAction用来定义测试用例执行之前的一系列初始化操作，比如测试时所需要创建的文件、配置所需配置信息等。testAction是真正的测试用例执行步骤，测试用例在测试中所需完成的测试动作都需要在这一项定义。resultCheck是用来检测测试用例执行结果的，判断测试用例是否通过测试。postAction负责一系列的收尾工作，比如删除测试过程中产生的临时文件、杀死进程等工作。

配置信息中的关键字是根据被测试用例的特点而设计的，比如需要运行命令，可以设计一个关键字gRuncmd，需要创建文件可以设计一个关键字gCheckfile，关键字的解释需要专门的函数库来支撑。

2.5 测试工具的测试流程

测试工具的测试流程如下：

1）向CVS服务器发送更新代码请求，获取最新的测试工具代码。

2）启动测试引擎，并解析配置信息文件。

3）根据测试配置信息中的配置信息，确定启动相应的测试方案。如果是为测试点编辑了单独的测试脚本，那么根据配置信息中提供的脚本路径寻找脚本；如果测试点选用关键字驱动技术方案进行测试，那么调用测试数据文件并解析之，驱动数据文件中的关键字执行测试。

4）自动判断测试成功与否，并将结果实时返回。

5）在执行各个测试用例的同时启动日志产生程序，将每个测试用例的测试日志按组保存在测试报告文件夹中。

3 结束语

测试工具主要使用B-shell语言实现，可以使测试软件部署在不同的操作系统中；测试工具使用测试引擎自动调动测试用例及配置测试环境，提高了测试效率；根据测试软件功能块的不同特点，设计了2种不同的测试方案，增强了测试软件的灵活性。该测试方案在platform公司Job scheduler产品上完成了实施，取得了预期的效果。但该方案也有一定的缺陷。由于该工具主要使用B-shell语言实现测试脚本，速度比较慢。所以如果测试软件测试用例比较多的话，建议使用其他语言来实现测试引擎及测试脚本，比如Perl或Java。

[1]Cen Kaner，Jack Falk，Hung Quoc Nguyen.计算机软件测试技术[M].王峰，陈杰，喻琳，译.北京：机械工业出版社，1992：19-46.

[2]陈雷.基于软件功能的自动化回归测试技术的研究与应用[D].西安：西北工业大学，2005.

[3]商宇.基于STAF的自动化测试工具的研究和设计[J].云南大学学报，2009，18（3）：279-282.

[4]朱菊，王志坚，杨雪.基于数据驱动的软件自动化测试框架[J].计算机技术与发展，2006，16（5）：69-70.

[5]徐振良，樊滨温，王志鹏.关键字驱动技术在SAFS中的研究[J].微计算机信息，2006，22（15）：80-83.

[6]王铁江，郦萌.基于关键字驱动脚本的安全软件自动测试系统[J].同济大学学报，2002，30（6）：720-722.

[7]王蕾.基于数据驱动的软件自动化测试框架系统的研究与实现[J].软件导刊，2009，8（6）：32-33.