0 引言

　　软件测试是保障和提高软件质量的重要手段[1]。软件开发者和使用者必须对软件进行充分的测试，以确保其正常工作。统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40%以上[2，3]。因此提高软件测试过程的效率至关重要。

　　为了提高测试效率，越来越多的测试工作引入了自动化测试的思想和方法。实践证明，软件自动化测试技术提高了软件测试的速度和效率，节省了软件测试成本，缩短了产品发布周期。同时，自动化测试技术也完成了许多手工测试无法实现的工作。所以，采用自动化测试方法和相应的测试框架成为了软件开发组织测试工作的重要支撑手段。例如，采用自动化测试工具能在测试活动中减少一部分开销，同时，有些测试活动是靠手工方式难以实现和度量的；自动化测试框架能够提高测试效率，快速定位测试软件各版本中的功能、性能缺陷。

　　目前的自动化测试框架主要可以分为三种：录制/回放测试框架、数据驱动的自动化测试框架、关键字驱动的自动化测试框架。通过比较，发现关键字驱动的测试框架较前两者具有更好的可复用性，而且随着测试量的增加，测试代码的不断累积，其优越性愈加明显。但当前基于关键字驱动的测试框架研究尚未给出直接可用于Linux桌面测试的框架。而Linux下支持GUI自动化测试的测试框架对于Linux的应用程序的丰富与成熟具有至关重要的保障作用。因此为了弥补理论和实践的差距，本文给出了一种实用、有效的关键字驱动的测试框架 LKDT，并验证了LKDT在自动化测试领域的实用性和优越性。

　　1 自动化测试框架概述

　　1.1 自动化测试框架定义

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

　　1.2 自动化测试框架开发原则

　　一个优秀的自动化测试框架应该满足以下特点：

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

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

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

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

　　2 常用的自动化测试框架

　　2.1 录制/回放测试框架

　　录制/回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

　　其优点是简单，通过录制就可以得到所需脚本。但同时也有很大的缺点，它不具有逻辑判断的能力，可维护性差，效率低下。

　　2.2 数据驱动的自动化测试框架

　　该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存放控制信息，测试时输入直接从文件中读取，这样同一脚本可以运行于不同的测试用例中，实现了脚本与数据的分离。其优点是可以快速增加相似测试，测试者增加新的测试不必掌握测试工具语言，对此后的类似测试无额外维护开销；缺点是初始建立测试脚本的开销较大，进行数据扩展的脚本需要针对相同的测试内容并具有相同的测试逻辑。

　　2.3 关键字驱动的自动化测试框架

　　关键字驱动（表驱动）是对数据驱动的逻辑扩展，它的核心思想可以概括为三个分离。

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

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

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

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

3 用于Linux下桌面应用程序的关键字驱动的自动化测试框架

　　当前Linux下的测试工具主要是针对内核和服务器方面进行测试，对桌面应用程序的测试基本不支持，开发一个支持Linux下桌面应用程序测试的测试框架对于解决Linux下应用程序的发展与成熟具有积极的促进和保障作用。本文根据测试自动化框架开发原则，结合软件测试的实际需求，提出一个可行的自动化测试框架：LKDT（an automated testing framework of keyword driven for Linux）。

　　3.1 LKDT总体架构

　　LKDT主要由测试用例管理、测试计划、测试脚本编写、测试执行和测试结果收集等组件构成。

　　测试用例管理组件采用与测试用例管理工具，如目前常用的test runner管理工具集成的办法，提供对test runner中已有测试用例的导入、导出功能，从而方便测试人员对于测试用例的统一管理。

　　测试脚本编写组件允许采用两种脚本编写方式：a）测试人员通过录制工具产生测试脚本，即测试人员根据测试用例中的步骤，对应用程序进行操作， 录制工具将这些动作捕获下来，存成脚本文件；b）测试人员通过关键字的方式手动进行编写，即在该框架中测试人员可以通过拖放关键字来进行脚本的编写。

　　测试计划组件的主要作用即允许测试人员对测试用例的执行方式（顺序、并行、条件、分支、循环、分布式等）、执行时间、日志级别等进行定制。

　　测试执行组件是对测试用例或者测试计划所关联的测试用例按照要求进行执行，该过程为自动执行过程，无须人工进行干预；如果需要手动控制测试脚本执行，需以debug的方式执行。

　　测试结果组件收集测试结果信息，包括一个测试结果总结，如测试执行了几个测试用例、执行时间以及成功、失败的用例数；还包括一个失败的测试用例执行的详细信息，包括失败的测试脚本所属的测试计划、所属的测试用例、在测试脚本中的位置以及出错过程中的截图。

　　3.2 关键字驱动模块

　　关键字驱动模块是LKDT的核心模块，在LKDT框架中起着不可或缺的作用。该模块主要解决了脚本关键字的定义、关键字解析等问题。

　　关键字驱动的测试脚本为测试数据关键字和测试逻辑关键字的有机组合。数据关键字相对简单，与数据驱动技术类似，一个数据关键字代表一个测试脚本中的测试数据。在脚本运行时只需通过框架用真实的测试数据对数据关键字进行替换。

　　逻辑关键字的定义与测试活动的结构密不可分。在真实的测试活动中，一个测试目标需要有一组测试用例来支持，而每个测试用例又由一系列的测试步骤完成。这是一个三层结构，测试步骤为测试活动中的最小单位，测试目标为{zd0}单位，测试用例居中。逻辑关键字基于测试活动的这种结构即可分为高层脚本、中层脚本和底层脚本三层，分别对应于测试中的测试目标、测试用例和测试步骤。高层次脚本由逻辑关键字代表的低层次脚本，加上数据关键字代表的测试数据组合而成。

　　该模块主要由核心模块、脚本语言解释器模块和支持库模块组成。

　　3.2.1 核心模块

　　该模块主要作用是对测试脚本中的关键字信息进行解析，并控制脚本的执行。它由数据解析器、脚本解析器、脚本执行器、中间层四部分组成。其中，数据解析器负责数据关键字的解析；脚本解析器负责解析脚本中的逻辑关键字；脚本执行器负责脚本的执行；中间层负责测试库调用。

　　3.2.2 脚本语言解释器模块

　　脚本语言解释器模块包括三个部分，即词法分析器、语法分析器和解释器。词法分析器负责将输出的字符流解析为一个个的词[5~7]；语法分析器负责将词序列解析为具有语义的语句[8]；解释器负责语义的翻译。

　　3.2.3 支持库模块

　　支持库包括两个部分：a）所有测试可以共用的库，包括日志库和测试支持库。日志库负责向测试人员提供日志记录的功能；测试支持库则提供所有测试能共用的功能。b）GUI测试库主要作用是支持Linux下对桌面应用程序的测试。

　　4 结束语

　　依靠传统的自动化工具来完成Linux下的GUI测试非常困难。一是因为捕捉产生的脚本维护困难;二是由于录制的测试脚本与测试数据耦合得太紧密导致录制生成的测试脚本可复用性较差，生存期短。而LKDT框架采用的关键字驱动则是一种截然不同的思想，它把传统测试脚本中的变化与不变的东西进行了分离，这种分离使得分工更明确，并且避免了它们相互之间的影响。

　　当然对于该框架仍有许多工作需要探讨。例如如何使测试框架提供分布式测试支持以及需要考虑到Linux操作系统中用户权限问题等，通过后续研究以期使之成为一个更加简单、易用、高效的自动化测试框架。