软件测试自动化框架

软件测试自动化框架（精选8篇）

软件测试自动化框架 第1篇

1网格软件的特点和自动化测试难点

1.1网格软件的特点

网格软件的应用范围广泛, 其科技化程度高, 网格软件与其他的软件相比具有以下特点:

1.1.1具备虚拟资源能力

网格软件能够针对网络系统中的多项硬件环境、操作系统等进行虚拟单元计算, 能够跨越多个平台进行操作。

1.1.2对网络环境进行异构

在网络环境的形成, 由不同制造生产计算、网络设备相互支持和系统共同运行所组成不同的计算机系统运行, 需要不同的操作系统和通信协议, 为了实现对网络资源的管理, 需要对解决异种机系统的任务, 由此可见, 网格软件在还具有异构网络环境的特点。

1.1.3对集群模式下的节点关系进行协调、管理以及针对性的控制

在互联网网络系统中, 当一个客户与集群相互作用时, 集群转变为单一运行的服务器在网格软件的支持下, 能够实现系统关系的相互协调。

1.2网格软件的自动化测试难点

基于网格软件与一般软件之间的差别, 那么在进行网格软件的自动化测试环节中将会出现很多问题, 这些问题都是软件测试环节中的难点, 需要对这些难点进行详细分析, 才能够制定有针对性的网格软件自动化测试方案。首先, 网格软件能够运行于复杂的异构网络环境中, 能够完成其集群管理的职责, 对集群中的重点参数进行相应的测试。因此, 网格软件自动化测试系统需要在异构网络环境下具备良好的跨平台性;其次, 网格软件属于一种大型的应用软件, 其结构与功能参与比较复杂, 在进行软件测试环节中, 其测试规模庞大, 难度系数也增加了;最后, 网格软件对于集群进行管理中, 主要通过命令行的方式进行管理。那么在进行网格软件测试环节中, 也需要软件测试系统能够适应命令行的环境。

2网格软件自动化测试框架的设计

2.1系统基本框架

在网格软件自动化测试框架设计中, 基于Testgrid的框架结构主要分为四部分, 最上层为测试套件, 下面一层为自动化测试框架。第三层为行为库, 最底层为被测系统。

2.2 Testgrid多重异常处理

当测试软件在进行测试工作时, 或多或少的对被测试系统产生一定的破坏性, 自动化测试也不例外。软件测试从人工手动测试的方式转变为系统自动化测试, 那么人工将会失去了对于软件测试环节的控制, 对测试中可能出现的异常环节难以把握。当测试环节中出现异常, 将会严重的影响软件测试的质量与效率。针对软件测试中出现的这样的问题, 需要建立网格软件自动化测试框架异常处理机制。在进行网格软件自动化测试之前, 需要Testgrid框架调度其他模块, 对被测系统状态进行综合判断, 若被测系统符合软件测试需求, 那么该模块就能够应用到实际测试中, 如果被测系统不符合软件测试需求, 那么需要调动其他模块进行测试。

2.3 Testgrid的超时控制

自动化测试将测试环节交由给自动化工具, 能够有效的节约时间, 减少成本。但是在很多情况下, 网络通讯不畅将会导致软件自动化操作的动作严重超时, 是测试迟迟不能结束。Testgrid应用自动化测试中, 能够对测试过程中超时的情况进行严格控制, 设置最大的时间, 控制每一个测试单元。处于同一测试组的测试用例, 需要设定Timeout时间, 通过配置文件的方式, 将软件测试控制在合理的范围内。

3网格软件自动化测试框架Testgrid的实现

3.1测试驱动

在网格软件自动化测试框架Testgrid的实现中, 首先需要对其测试驱动模块进行分析。在测试驱动模块中存在着作用比较重要的类, 即Driver。Testgrid软件自动化测试框架需要对其所需要的脚本文件格式进行分析, 常见的三种格式为Xml文件、Excel电子表格、常见的文本文档。在众多的文本格式下, 需要将Driver类设计为一个抽象类, 能够为测试系统提供相应的属性和方法。根据测试对象的继承关系, 为不同的文件格式设计不同的类, 如, Text Driver针对常见的文本文档、Excel Driver针对Excel表格、Xml Driver针对Xml文件。一般情况下, Xml文件结构为树形结构, 文本灵活性较高。

3.2配置管理

在配置管理模块中, 需要对不同的标签进行功能进行分析。test Suite Name为测试套件名, 该名称也会出现在系统中的生成日志中;Port是一组可以被使用的端口号;report File Name为指定的测试报告命名;Groups为此间节点对测试套件的分组;init为运行本次软件测试, 系统所需要做的初始化工作, 例如系统中需要导入哪些数据安装包, 开启哪些功能等。

4结论

综上所述, 网格软件的应用范围广泛, 其科技化程度高, 网格软件与其他的软件相比特点突出, 具备虚拟资源能力, 对网络环境进行异构, 对集群模式下的节点关系进行协调、管理以及针对性的控制。在本文中对网格软件的自动化测试框架特点与难点进行分析, 并对网格软件的自动化测试框进行设计研究, 探讨其功能实现方式。

摘要：在科技信息技术高速发展的当今社会中, 软件设计、研发与应用的规模逐渐扩大。对于软件进行测试, 是提升软件运行安全的关键环节。基于网络化的软件自动化测试的效率更加的高, 测试成本较低, 是新时期软件开发领域中的重点测试技术之一。基于此, 本文将对网格软件自动化测试框架进行研究, 分析其实现方式。

关键词：网格软件,自动化,测试框架,研究,实现

参考文献

[1]钟华.基于云计算的软件测试服务研究[D].上海:东华大学, 2012.

[2]贾志娟.基于Django框架的软件自动化测试分布式部署系统的研究与实现[D].北京:北京邮电大学, 2012.

[3]韩振斌.基于网格系统的自动化测试系统的研究与实现[D].西北工业大学, 2007.

[4]徐崇浪.集群系统自动化测试技术研究及其工具开发[D].西安:西北工业大学, 2007.

基于框架的软件测试性分析 第2篇

【关键词】软件产品线测试；面向对象的软件测试；自动化工具支持

软件产品线是一套软件密集型系统，它拥有一组能满足特定需求的公共的、可管理的特性，并且是按预定义的方式由一组公共的核心资产开发而来。在软件开发过程中，测试是一项持续性活动，同时也是一项劳动密集型活动。传统的面向对象的测试方法是产品线测试的基础，因为软件产品线，尤其是框架通常是用面向对象技术来进行设计和实施的。为了确保框架的可靠性，在应用它之前必须进行仔细的检测。实践中，通常是通过测试应用程序来测试框架，因而难以区分框架和应用程序的编码错误。同时，当前测试框架和产品线的方法还非常不成熟，因此对成熟测试方法的需求十分迫切，测试过程也应获得测试工具更多的支持。

1.面向对象的软件系统测试

1.1面向对象系统的测试方法与过程

为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段，对软件进行严格技术评审。近年来，测试的作用在很多组织中得以扩展，进而为软件可靠性的评估提供技术支持。

面向对象技术产生更好的系统结构，更规范的编程风格，极大地优化了数据使用的安全性，提高了程序代码的使用率，然而正是因为面向对象技术开发的软件代码重用率高，这就需要更严格的测试，避免错误的繁衍。

1.2测试自动化和工具支持

近几年来，许多研究工作者通过使用自动化的测试工具对软件的质量进行保障研究。到现在为止自动化测试工具已经足够完善了，完全可以应用自动化测试工具来大幅度地提高软件测试的效率和质量。在使用自动化的测试工具的时候应尽早地开始测试工作，这样可以使修改错误更加地容易和廉价，并且可以减少更正错误对软件开发周期的影响。

自动化支持的一个关键因素是是否有用于所有测试交付物和工作产品的中心项目数据库。这可以指的是测试管理系统，包括用于对测试进行保存、描述、文档化和跟踪，并且对测试目标和结果进行记录、跟踪、评审的辅助设施。好的工具可以使得这些信息很容易被项目组获得，并且提供稳定的工作流支持来简化和跟踪软件开发过程。

2.软件产品线测试方法

在软件产品线测试时虽然可以使用传统面向对象的测试方法，但仍强烈需要一个明确定义的产品线测试过程和方法，包括工具支持。这是因为当一个产品线或多个产品线被测试时，一些具体问题就会暴露出来。例如规模问题，因为产品线中的所有应用都需要测试，这就使得产品线的测试要比单独的产品测试要复杂得多。产品线测试的关键在于重用测试用例和测试件（Testware，指测试工作形成的产品），而不是将产品线中的每个软件作为一个单独的产品来进行测试。

2.1软件产品线测试

产品线测试关系到多个方面，包括回归测试、非完整性项目测试和有效使用可重用的测试资产等等。回归测试是用来确认前期可正常工作的组件在面临某些修改时，是否还能正确运行。产品线中的成员在共享许多共性特征的基础上又各自变化，因此回归测试适合于产品线或重用情况。与单个系统开发项目不同，测试也是可以重用于大多数产品中的活动，它本身产生可重用的核心资产。建立可重用的测试资产能使产品线测试拥有较高的成本效益比。

产品线测试的主要问题可以从两个方面来进行论述。在领域工程中测试核心资产时，测试者试图减少应用测试，但却很难保证软件在不明确的用例情景下都正常运作；产品线中的成员在共享许多共性特征的基础上又各自变化，测试者发现根据V 模型进行集成和系统测试并不可行。而在应用工程中，在核心资产和其它应用测试的基础上，测试者想使充分测试特定产品的费用最小化，但很难确定哪些已有测试结果是可以利用的，哪些产品测试是必须进行的。

2.2当前产品线测试状况

目前产品线测试的工作重心主要放在验收和系统测试上。

但由于产品线中大量重用组件，因此它们的低级别测试（例如，单元级）也应该得到保证。换而言之，当前的研究和实践主要集中在高级别的产品线测试上。假设传统的面向对象的测试方法可以不做任何修改就用于产品线测试过程，那么这一假设存在许多疑点。例如，目前尚不清楚將使用哪一种面向对象的测试方法以及如何将之用于产品线测试，更加不清楚是否还需要新的、具体的产品线测试方法。

在基于框架的软件产品线测试方法中，应用框架是产品线的核心，在所有应用从它产生之前就应该得到很好的测试。但是以框架为基础的产品线的实际测试中，往往没有使用产品线的任何信息。例如，诺基亚的移动浏览器产品线是按照如下要求进行产品线测试的：“产品线测试的复杂性要远大于单个软件产品的测试。必须测试在不同情景下的产品线。为了控制测试的复杂性，应缩减单个产品的测试，取而代之的是对整个产品线的测试。这样才能保证测试的简化以及产品质量”。

2.3软件产品线自动化测试及相关工具支持

在软件产品线测试方法中，工具支持比在传统面向对象测试中更加重要。这是因为包含数个相同体系结构的产品线测试规模要大于单个产品测试。当一个组织有几个产品线时，规模的问题就更加突出。产品线的工具支持因使用可重用的测试资产可以减少费用，并且使复杂的测试过程更易于管理。

现今有许多成熟的测试工具，但是产品线和框架测试缺乏有效的工具支持。通常这些工具也能够应用于产品线的测试，但它们只适用于像单元测试这样低级别的测试。在产品线方面，需要详细而精确的测试工具。测试工具应有效地管理可重用的测试资产。工具支持应从测试执行和测试结果的分析扩展到集成产品线测试的整个过程。

目前赫尔辛基大学已经开发出RITA工具。RITA是一个能覆盖所有领域的测试支持工具。但是所有设计功能并没有在RITA的第一版中完全实现。同时，RITA工具的焦点在于支持基于框架结构的低水平的白盒测试。

3.结束语

软件产品线受到越来越多的关注和研究，特别是在工业应用领域。但是产品线的测试所受到的关注还是很少。产品线需要一个详细规划的测试过程，它要能够比较容易地被不同的产品线应用领域所采纳和运用。然而，测试产品线是一项非常具有挑战性的工作。因此迫切需要一些成熟的测试方法和工具。

【参考文献】

[1]王建辉.论软件产品线技术[J].福建电脑，2007，（02）.

[2]江瑜.基于软件产品线的需求分析研究[J].计算机工程与设计，2007，（08）.

[3]邢瑜琨，刘超，高仲仪，金茂忠.基于构件和框架、面向方面的软件产品线开发方法CFB-AOD[J].微计算机信息，2006，（27）.

软件测试自动化框架 第3篇

自动化测试在过去的20年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉/回放功能:记录并播放键盘按键,然后捕捉和比较屏幕。这些测试方法虽然最容易应用,但是几乎不可能维护。捕捉/回放工具最终被功能和灵活性更强的测试脚本工具代替。后来,一种新的自动化测试产品出现了。它可以减少实现和维护的成本,使测试人员可以把精力集中在应用程序的测试用例设计上,而不是开发我们的测试。这些工具提供预先写好的测试框架,可以极大的减少,甚至消除学习和使用脚本语言的需要。这个测试产品就是自动化测试框架。

自动化测试框架定义了由假设、概念和制定工作平台或为自动化测试提供支持的实践组成的集合[1]。它能有效地弥补单一依靠测试工具所带来地一些缺陷。自动化测试小组可以考虑吸收几种测试框架的优点,设计适合自己团队的混合型测试框架。不是依赖某一种捕获回放的自动化测试工具。

基于GUI的捕获回放工具都有维护性差的缺陷。因为GUI经常根据功能变更或者其他需求而改变,当GUI有重大变化时,会导致自动化测试中断,结果需要手工的干预或全部重新返工。因此更好的方案是引入自动化框架。

自动化测试框架为支持自动化软件测试设计了平台架构和最佳的实践经验。主要有4种基本框架结构类型[2]:脚本模块化架构,测试库架构,关键词或表格驱动架构,数据驱动架构。

1)脚本模块化框架创建代表AUT基本模块和功能的底层脚本。然后以一种层次关系组合这些小脚本,实现一个特定的测试用例。

2)测试库框架和测试脚本模块化框架非常相似,但是底层由过程和函数组成,而不是脚本。这种框架要求创建库文件(如SQABasic libraries,APIs,DLLs等等)代表AUT的模块和功能。这些库文件被测试用例脚本直接调用。每步的指令操作都在表格中维护。

3)关键词驱动或表格驱动测试框架是一种独立于应用程序的自动化框架,这种框架要求开发数据表和关键字,不依赖于运行的自动化工具和脚本。关键词驱动测试看上去与手工测试用例非常相似。在关键词测试里,应用程序的功能特性和每步的指令操作都在表格中维护。

4)数据驱动测试框架是从数据文件中读取输入和输出数值并载入到捕获的或手工编码的脚本变量里的框架。这种框架和表格驱动测试有些相似,脚本只是一种“驱动器”(driver)或传送数据的机制,不同的是导航的数据不包含在数据文件中,而只包含有测试数据。

测试框架是用来执行测试的总体环境,其中的核心是一种自动化工具。本文主要介绍一种数据驱动的自动化测试框架WAF,对自动化测试的实施做出尝试,并对该框架模型做出一些改进。

自动化测试框架WAF是作为一个模块来设计和实现的,属于即插即用的构架,是一种数据驱动的软件自动化测试框架。当测试系统,测试数据和测试次序改变时不需要修改代码[3]。数据驱动引擎被设计并实现来支持现有模块的复用。只需要改变配置文件,测试用例表以及数据文件就可以实现当测试系统,数据和测试的次序改变时,不再需要改变其他的程序和函数等;通过实现新增模块的功能就可以引入新的测试或者新的验证行为。新的模块一旦创建就可以被应用,只需要对数据驱动引擎的头文件做些许的修改即可使用这些功能。

如同图1描述的那样,框架本身由WAF主程序,配置文件,WAF GUI映射,数据驱动引擎,测试用例或者测试组合(XML file),以及功能函数所定义。

2 WAF结构组成

2.1主程序

当运行一个用WAF来开发的测试件(testware)时,主程序首先被调用执行。它根据对配置文件的解析结果来确定运行什么测试组合或测试用例,同时触发数据驱动引擎来解析测试用例文件,并根据解析结果来调用相应的数据文件同时触发相应的功能函数来执行测试。

2.2数据驱动脚本

数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写成自动化工具私有的语言,然后对其中的变量赋予合适的数值,作为测试数据的输入[4]。这些变量作为一些关键应用程序输入的媒介,使脚本能通过外部的数据来驱动应用程序。

1)可变数据,硬编码组件标志

这些数据驱动的脚本经常包含硬编码的数据,有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时,脚本很容易由于程序的更改而失去作用,而且这种情况并不是个别现象。

2)高度技术化的、重复的测试设计

数据驱动脚本的另一个共同特点就是,所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中,或者复制到手工和自动化测试脚本中。

2.3模块

WAF中的模块包括框架以及公共模块,专业模块,产品特定的模块。框架和公共模块包含一些框架和公共函数,例如数据驱动引擎。而产品特定的模块包括测试待测产品或应用所需要调用的功能函数。专业模块则包括处理特定的功能或者协议所需要的支持函数这些功能模块都放在函数库lib中[5]。

2.4 WAF GUI映射

自动化测试工具录制应用程序中的每一个对象,并给每个对象命名来识别各对象,这个逻辑名能被修改,将其用在测试表中,测试工具使用他们来识别对象,GUI映射可由自动化测试工具自动产生。

2.5测试数据

数据驱动测试是一种数据被包含在输入测试数据文件中,并且数据控制自动化测试脚本执行的流程和动作的测试。测试数据记录以文档的形式包含在输入文件中,输入文件包含测试数据和控制数据。测试数据进行必要的各种类型的测试,而控制数据引导测试脚本到达合适的位置并指示要执行的动作。测试数据是特定测试产品和测试组合的测试数据[6]。对于不同产品测试数据是不一样的。譬如对于文件传送功能的测试数据则表现为各种类型的文件。

2.6测试用例

测试数据定义测试状态的初始化,测试步骤,应用在每一步中的测试数据以及其预期结果,是一个基本的测试单元[7]。测试组合是一个测试用例的集合,被指定来完成一个特定的测试目标。它可以被设计来测试一个函数,一个模块,或者是执行一个类型的测试,例如验收测试(Release Acceptance Test)。

在WAF框架模型中,测试数据是以标签的形式存放在XML文件中,每个标签对应一个测试数据,这样在一个独立的XML文件中可以对应多个测试用例,可以将XML文件看成是多个测试用例的集合。下面是对于一个XML文件的描述:

2.7测试件配置文件

TESTWARE配置文件记录执行测试件(testware)的一些基本配置项。包括文件目录,数据目录,测试组合目录,log目录以及一些服务的配置等。

2.8测试结果

WAF在执行完一个测试后产生三种类型的测试结果,日志文件,报告和相应的测试过程数据。

2.9利用WAF进行自动化测试开发流程

运行一个使用WAF开发的TESTWARE时,主程序被执行。它初始化测试环境,解析配置文件,启动数据驱动引擎(Data-drivenengine)。

进行测试时数据驱动引擎调用XML文件,解析文件中的标签,通过资源定位符定位到XML文件中的设计好的测试用例(或者测试组合),根据解析的结果调用函数库中相应的功能函数(lib),并通过测试数据来对相应的应用程序执行测试。最后将测试结果返回给主程序输出。

3 WAF在软件测试应用中的实现

当决定把数据驱动的自动化测试框架应用于一个具体的项目,首先要确定所有的testWare的一个目录结构。编写main程序来初始化环境,解析配置文件,启动测试引擎。抽象具体项目需要的Action,编制功能函数,放到lib函数库中。组织测试用例,准备测试数据。当所有的准备工作做完后,设置配置文件,运行测试,最后到result目录查看测试结果。

这就是把WAF应用到一个具体的项目测试的过程。

3.1 TestWare目录结构

TestWare的目录结构对于框架来说是很关键的。每一个目录都有自己的意义而且必须被遵从来向其中加入新的功能。目录结构包括以下部分。

BIN:包括主程序(main),启动(launch)脚本和测试配置文件。这是WAF的主要接口。TestConfig.ini文件用来定制和建立测试件(testWare)。启动脚本用来启动测试件(TestWare)。

Testdata:这个目录包括所有的在测试表中使用的测试数据。针对不同的测试软件存放各自的测试数据,比如各种文件等。

Lib:这个目录包括testWare的模块。不仅包括WAF框架的模块还包被测软件的特定模块。

Default config:产品的内部架构和设计被定一语这个目录文件中。被测试软件的配置文件被存放在这个目录下。

Testsuites:这个目录包括所有的测试表。这些测试表以树形结构来组织。

3.2编写功能函数和组织测试组合/测试用例

lib函数库目录下不仅包括WAF公用的函数还包括产品特定的功能函数。数据驱动引擎的代码也保存在lib中。实现数据驱动引擎的代码包括解析测试表,运行测试用例,访问测试数据,返回测试结果等[8]。

3.3组织测试数据

图2详细的显示了测试数据的组织。在被测软件的testware中,所有的测试数据都存放在一个特定的目录testdata下。在testdata目录下,测试数据分别存放在相对应的目录下,然后在testware配置文件的相应配置项中置上测试数据所在的目录即可。

3.4检查测试结果

TestWare会把测试的全部结果结束按照测试执行的时间输出到testWare/results目录中。图3是一个测试结果的索引,它列出了所执行的所有测试。

点击相应的测试用例,就会打开具体的测试用例的执行情况,是成功还是失败(success/fail),以及每个测试步的执行结果是成功还是失败,如下图4所示。一旦测试执行失败,可以定位到具体的测试步骤。

3.5 WAF的优点

跟当前主流的测试工具相比,WAF具有以下优点[9]:

1)实现了数据与脚本的分离。使得脚本的维护变得简单而方便。框架的重用性得到提高,能减少测试成本;

2)使测试自动化而无需额外技术支持,减少测试人员学习自动化测试的时间;

3)可以根据需要指定测试计划,测试表容易创建且维护简单,且简单的表结构重用性高;

4)不必等到产品稳定以后才开始自动化测试。可以尽早的进行自动化测试,节约大量的手工测试的时间;

5)测试人员不需要知道测试工具实现的细节,只需要和表打交道和执行自动化脚本;

6)配置项从脚本中分离使得易于实现平台的转换,测试的移植。

4工作总结

本文中主要介绍了自动化软件测试技术,核心部分在于提出应用软件自动化测试框架实现软件自动化测试。以某软件作为应用背景提出一个适合该软件自动化测试的基于关键字和数据驱动的自动化测试框架。并将该框架模型应用于软件开发过程中的软件自动化测试。

这是一个最新的也是比较热门的发展方向。自动化测试中的自动化测试框架的研究也称为一个新的发展趋势。

现在,己经有一些商业化的自动化测试框架。在大多数情况下,他们和已有的商业化测试工具捆绑在一起。他们的主要不同点在于他们的底层的执行引擎或脚本库,是被映射到关键字,窗口还是对象或类,这也是将来自动化测试框架发展的几个趋势。关键字驱动的测试引擎已经实现,接下来,窗口引擎,对象引擎和类引擎等底层引擎的实现将会是商业化自动化测试框架的主要研究方向。

摘要：该文对软件质量保证的重要手段——软件测试进行了论述,给出一些软件测试的基本理论。随着软件测试研究的发展,软件测试提出了一些比较前沿的理论,如面向对象的软件测试,测试驱动开发理论,探索性测试等。为了克服手工测试的一些困难,提高软件质量和测试效率,自动化测试被广泛地引入进来。它以其自动化程度高、实用性强等特点,引起了人们的广泛重视,成为软件测试的发展方向。自动化测试框架产品的出现表明软件测试自动化技术正在趋于成熟。早期使用录制回放和脚本工具的不足正在被克服,使得自动化测试更加经济、有效,更加有利于实现和维护。随着在开发和维护脚本上的时间越来越少,更多的时间可用于提高测试的覆盖范围和产品质量,从而在自动化上的投资能够更快地得到证明。该文分析讨论了自动化测试框架方法以及实现,并将其应用到软件测试中。

关键词：软件测试,自动化测试,数据驱动,关键字驱动

参考文献

[1]Pressman R S.软件工程实践者的研究方法[M].北京:机械工业出版社,2002.

[2]Berard E V.Essay on Object-Oriented SoftWare Engineering[M].Addison Wesley,1993.

[3]Zeyu J,Gao H S,Tsao J,et al.Testing and Quality Assurance for Component-Based Software[M].London:Artech House,2003.

[4]Dustin E.软件自动化测试:引入,管理大与实施[M].于秀山,胡兢玉,译.北京:电子工业出版社,2003.

[5]严少清,陈革,万年红.软件测试自动化管理系统的设计与实现[J].计算机工程,2002,28(9):152-154.

[6]Beydeda S,Gruhn V.State of the art in testing components[C].Dallas,TX,USA:Proc of the3rd International Conference on Quality Soft-ware,2003.

[7]Maurer P M.The design and implementation of a grammar-based data generator[J].Software Practice&Experiencies,1992,23(3):233-244.

[8]冯玉才,唐艳,周淳.关键字驱动自动化测试的原理和实现[J].计算机应用,2004(7).

[9]金大海.数据驱动自动化测试方法研究[J].装甲兵工程学院学报,2004(2).

[10]Wang Y X,King G,Wickburg H.A method for Built-in Tests in Component-based Software Maintenance[C].Amsterdam,Netherlands:Proceedings of the Third European Conference on Software Maintenance and Reengineering,1999.

软件测试自动化框架 第4篇

自动化测试是近十几年刚刚兴起的新技术, 一般是指各种测试活动的管理与实施, 包括测试脚本的开发与执行, 以便使用一种自动测试工具来验证测试需求。

测试自动化是一个类似于应用程序开发的过程, 一般应包括自动测试计划、自动测试设计、自动测试开发、自动测试执行以及自动测试活动评审5个阶段。

1 基于三层驱动机制的自动测试框架设计思想

在测试自动化过程中, 一个关键的原则就是在测试过程中使用的自动测试框架要易于扩展、维护和增强。随着用被测应用软件版本的不断更新, 自动测试脚本也随之需要维护。维护的级别取决于实现方法。而降低维护的关键是从自动测试脚本中移出测试数据, 并使用数据来驱动测试脚本以及开发在自动化测试项目间可以共享的、可重用的子例程和函数。降低测试脚本维护的关键是从脚本中移出测试数据, 并使用数据来驱动测试脚本以及开发在自动化测试项目间可以共享的、可重用的子例程和函数。为了使自动测试框架易扩展、易使用, 并能最大程度地缩短测试的时间, 采用了以下策略来设计自动测试框架:

1.1 移出测试数据

将测试数据移出测试脚本并存放在外部文件中可以减少自动测试脚本的个数、减少修改脚本的工作量。当测试数据需要改变时只需在外部文件中修改相应的数据记录而不必修改测试脚本。如果要增加额外的测试数据, 只要在外部文件中增加更多的记录就可以了。如果需要, 或者想创建不同的场景, 可以创建多个包含测试数据的外部文件, 依据需要从中选出要用于测试的文件, 这样就无须修改测试脚本, 甚至无须修改提供测试数据的外部文件中的记录。

1.2 使用关键字驱动

为了让自动测试脚本具有一定的智能, 让测试程序按照我们的意图去执行测试, 就需要用一组控制命令来控制脚本执行。在脚本内部对应这些控制命令编写一套简单的代码或者调用相关处理函数。这些控制命令就是关键字, 代表某个动作。而这些关键字的排列组合将构成不同的工作流, 表示执行不同程序路径时需执行的步骤。

1.3 处理脚本调用

自动测试脚本的调用关系有两种。一种是顺序调用, 一种是嵌套调用。对于顺序调用的处理就是从外部文件中获得要调用的脚本名称, 同时增加对以脚本调用失败后的跳转处理, 驱动自动测试调用脚本的执行。这种处驱动方式就形成了高级数据驱动机制。而对于嵌套调用的处理也是通过读取外部文件获得要调用的测试脚本的名称, 在调用脚本执行完毕后恢复测试环境。对嵌套调用的处理就形成了嵌套调用机制。

1.4 验证点处理

在自动测试框架中应支持通用验证点和复杂的逻辑验证点。将通用验证点操作按控件类型和验证点类型抽象出来形成共享函数, 并为用户定义的复杂逻辑验证点提供接口。

1.5 测试粒度控制

为了使自动测试框架可以支持功能测试、系统测试、确认测试以及回归测试等类型的测试。根据RUP中对测试用例、测试场景以及业务流程的定义, 将测试的执行粒度分为三个级别。第一个级别是业务流程测试, 是根据业务需要挑选多个测试场景按顺序执行;第二个级别是场景测试, 是针对一个完整的功能点, 挑选该功能点的基本流、备选流组成不同的测试场景来执行。第三个级别是测试用例测试, 即一次执行一个事件流 (在RUP中一个测试用例就对应一个事件流) 。

1.6 对脚本的划分

在系统中负责测试操作具体实现的脚本应划分为两类:一类是负责实现被测应用程序单点功能的脚本;另一类是负责集成功能调用的脚本。通过这两类测试脚本实现自动测试脚本的无缝集成。

2 基于三层驱动机制的自动测试框架实现

自动测试框架实际上是由核心数据驱动引擎、支持库、控件映射表、事件流驱动表、测试调用表以及测试数据表构架起来的。测试执行时, 首先是从初始化自动测试环境开始的。这个脚本主要完成创建测试过程中需要的数据。如果希望进行业务逻辑测试, 就从主调用脚本启动测试。主调用脚本从业务逻辑测试调用表中读取要调用的场景或事件流, 然后启动数据驱动机制从事件流驱动表中查找到对应测试场景或事件流的二级或三级测试脚本执行测试。其中, 如果调用的是二级脚本, 在读取并执行控制码过程中遇到嵌套调用其它事件流的命令时, 就在事件流驱动表中查找到该事件流对应的事件流记录, 并调用该事件流对应的测试脚本 (可能是一个二级脚本、也可能是一个三级脚本) 执行测试, 执行完后回到当前二级脚本继续执行。如果该二级脚本不调用其它脚本, 执行完控制码命令后, 将执行业务逻辑测试调用表中指定的下一个场景或事件流。如果调用的是三级脚本, 执行完控制码命令后直接执行业务逻辑测试调用表中指定的下一个场景或事件流。在三级脚本中不会调用其它脚本。测试数据表将在执行测试的过程中提供测试数据。当要进行功能点测试或场景测试时, 在执行完初始化操作后就从二级脚本或三级脚本执行, 从场景测试调用表或功能点测试调用表开始读取事件流执行脚本。

在实际使用中, 证明了这种自动测试框架对于实现大型软件产品的自动测试极为有效, 极大程度上解决了大型软件产品自动测试脚本实现难和维护难的问题。

虽然基于三层数据驱动的自动测试框架灵活实用, 但由于自动测试工具自身的局限和被测应用程序的多样性和复杂性, 这种测试框架还存在以下缺点:

(1) 虽然支持对验证复杂验证点, 但实现的方式不是很灵活。自动测试工具中只支持常用的验证点功能并且有些验证点功能不符合实际测试需要。如果当前界面与保存基线文件时的界面存在象素差别即使两个文件中的图形形状颜色等信息相同, 验证也会失败。而在实际测试中, 只需要图形外观相同就算通过验证了。在这种情况下, 设置验证点就没有多大用处。测试人员还是必须亲自验证。

(2) 自动测试框架使用的数据池的维护和使用不很方便。被测应用程序的规模越大, 需要的数据池文件就越多。自动测试工具中没有提供对这些数据池文件的查找和管理功能, 因此要使用和维护这些数据池文件需要花费较多的时间。

对于实现复杂验证点的方法不灵活的问题, 由于受到自动测试工具自身的功能限制目前还没有什么有效的解决办法。但是对于加强数据池的维护和使用, 可以采用开发外部编辑器的方式来实现。外部编辑器可以提供一个更友好的用户界面方便用户在事件流驱动表中创建新记录, 填写事件流编号、脚本名称、控制码、控制码参数、控制码定义规则说明以及事件流的说明等信息。同时还应提供创建、删除自动测试框架中使用的各种类型的数据池的功能。除了允许创建和编辑数据池外, 还应让外部编辑器具有一定的管理功能, 例如创建自动测试脚本与其使用的测试数据池和调用测试表之间的关联关系。此外, 随着被测应用程序的规模增大, 相应的自动测试数据池也会增多。为了方便地管理这些数据池, 如何在大量的数据池文件中快速地查找到目标数据池文件对于维护管理数据池就显得十分重要了。因此在外部编辑器中应该提供强大的查询功能让用户能方便地查找到需要编辑的数据池、数据池与自动测试脚本之间的关联关系、系统中定义的控制码规则、事件流以及测试数据的说明信息等数据。最后, 在外部编辑器中还应提供帮助功能, 将测试框架中函数说明做成帮助, 同时允许扩充帮助信息, 让使用者能迅速地得到自动测试框架使用方法的信息。具有管理功能和友好界面的外部编辑器能解决对数据池的维护和管理的问题, 从而提高测试脚本开发效率, 推广这种自动测试框架的应用。

参考文献

[1].Elfriede Dustin, Jeff Rashka, John Paul.软件自动化测试:引入、管理与实施[M].于秀山, 胡兢玉, 译.北京:电子工业出版社, 2003.

[2]Pettichord, Bret.Success with Test Automation, Proceedings of the International Software Quality Week, San Francisco, California, 1996.

[3]Junguang Dai, guangju chen, Object-Oriented graph test software, Future Sustainment for Military And Aerospace, Disney grogshop of Los Angeles in the United States, 2000.

网页自动化测试框架的设计与实现 第5篇

随着软件开发技术的日益成熟,软件开发项目的日益庞大,自动化测试技术的重要性日益突出[1]。自动化测试工具广泛地应用于回归测试、设计文档验证、路径覆盖等场景。然而自动化测试工具本身仍然存在不少缺陷,尤其针对网页应用的自动化测试,更是存在不少难点,这也是很多公司畏惧推行自动化测试的原因之一。下面将网页自动化测试中的难点进行列举分析,本文将针对这些难点给出相应的解决方案。

首先,是网页的维护。网页自动化测试本质上是自动化测试工具模拟人的动作与网页进行交互的过程。然而网页模板的更改是很频繁的,如何在页面模板更改的条件下,尽可能做少量的修改就可以兼容自动化测试脚本,是一个巨大挑战。

其次,是数据和测试脚本的组织方式。数据和脚本应该保持分离,才能做到测试脚本的复用。这也是自动化测试中的难点之一。

另外,还有工具的可扩展性、测试用例的组织方式、测试执行控制、生命周期管理等,都是自动化测试工具必需面对并且解决的问题。NetAuto在开源项目Selenium[2]的基础上,提出了对象库的概念,使网页对象化,从而降低了网页的频繁变动对自动化测试带来的影响。利用文件的层次结构和数据注入的方式实现了测试脚本和数据的分离;并且在保证功能完备性的前提下,提供了扩展接口,使用户可以在NetAuto上做定制开发。除此之外,NetAuto还使用Ant[12]进行编译和构建,使用Log4j[3]做日志的管理,使用swt[4]做界面的开发。总之,NetAuto提供了一个完备的网页自动化测试框架和解决方案。在产品线上的推广结果表明,使用NetAuto进行测试用例的编写比Selenium快4倍以上,利用NetAuto进行自动化测试的效率比手工快10倍以上;而且,可以利用NetAuto在空闲的时间自动进行测试,不需要人工的干预。

1 Selenium开源框架介绍

Selenium[2]是一个开源的Web 应用程序自动化测试及验收工具。Selenium直接在浏览器中运行,能够模拟真实的用户操作,包括浏览页面、点击链接、输入文字、提交表单等等,并且能够对结果页面进行种种验证。

Selenium 有两个产品:

1) Selenium IDE

Selenium IDE提供了一个浏览器的插件,可以记录用户的动作,自动生成对应的测试脚本。

2) Selenium Remote Control(Selenium RC)

Selenium RC允许用程序语言编写测试用例,支持多种平台和多种浏览器,可以用多种语言编写测试用例。利用Selenium RC可以把 Selenium和其他测试框架如Junit集成,进行集成测试。NetAuto主要是在Selenium RC的基础上进行改进,下面,简要介绍Selenium RC的构成以及工作原理。

如图1所示,Selenium RC主要由两部分组成,Selenium server和Client lib。Client lib是测试脚本用来调用和控制Selenium server的库。Selenium server负责控制浏览器,它包括三个部分,Launcher,Http proxy,Selenium core。Selenium server通过Launcher可以启动浏览器。Selenium core 是js的集合,可以内嵌到浏览器中,这样Selenium Server就可以控制浏览器进行各种操作。于是可以将浏览器的代理设置成Selenium server的Http Proxy。当执行测试脚本的时候,脚本通过Client lib向Selenium server发送http请求,server将请求进行解析,然后通过Http proxy发送js命令通知Selenium core,进而控制浏览器执行相应动作。同理,Selenium对页面返回的结果也可以进行验证。

Selenium作为自动化测试工具,有着很明显的缺陷和不足。首先,用户友好度很差,操作界面非常粗糙,只提供了最基本的操作,而在测试套件管理、报表打印、系统配置、用例调试等方面都支持不够。其次,Selenium对页面元素没有进行有效的维护,它直接通过Xpath来定位页面元素,表现在脚本的编写上,就是直接将元素的Xpath作为参数传入脚本,如果页面发生改变,很多测试脚本都需要修改。总之,Selenium只是具备了一个雏形,它的核心价值就是提供了底层与浏览器交互的库。它虽然不适合直接部署应用,但是却给研究人员提供了很好的基础和研究平台,研究人员可以按照自己的想法去进行改造、升级,从而设计出一个真正适合企业应用的页面自动化测试工具。

2 NetAuto的设计思想

2.1 数据分离和脚本复用

上文提到,测试数据和测试脚本的分离是每一个自动化测试工具必需面对和解决的问题,否则,脚本的复用将会是一句空话。这也是开发NetAuto框架首当其冲的问题。因为NetAuto底层是selenium,而在selenium框架中,函数的调用,基本是这样的形式:

selenium.clickAt(xpath,coordstring)

这是对应点击动作。其中,xpath指要操作的元素对象在当前页面上的xpath;coordstring指鼠标点击对应页面的x,y坐标位置;

selenium.type(xpath,str)

这是对应字符串输入操作。其中,xpath同上;str是指所要填入的字符串值。

从中,我们可以看出,selenium框架中代码的复用率是极低的,主要原因是脚本和页面元素,以及测试数据之间的耦合度很高。为解决这个问题,笔者设计了一系列模块,包括解决在函数中直接引用xpath而设计的对象库,以及为实现数据分离而实现的dataprovider接口等。

2.2 页面元素对象化

元素对象化同上文提到的对象库的概念是相辅相成的。是NetAuto框架相对于selenium的一次巨大的创新,也可以说是NetAuto框架存在的最核心支撑。

笔者在研究selenium以及其他框架底层函数的时候发现,自动化测测试框架与页面的交互函数可以归结为两类:动作类和验证类。动作类比如在文本框中输入字符、点击链接、选择复选框等;验证类比如验证某些文字是否在页面上存在,某个元素的显示效果是否符合预期等。于是笔者设想,如果把一个页面元素抽象成一个对象来看待,那么我们可以得到的关于页面元素的信息就丰富很多。我们可以将元素的xpath, name, id, property 等都作为对象的属性,进行保存。而且,动作类和验证类的函数正好对应javabean中的set方法和get方法。

对象库的思想,使测试工具所针对的对象,由页面上得元素转移为对象库的元素,降低了代码的耦合性,增加了脚本编写的灵活性。

2.3 可扩展性

网页自动化测试工具,如果要推广,必要的条件就是工具具有可扩展的接口,可以载入用户自己封装的,针对特定产品的库,或者留出给用户二次开发的接口。NetAuto的设计也考虑了这点。NetAuto除了提供基本的function(动作类库函数)和check(验证类库函数)两个模块,给用户直接调用外,同时提供一个action模块作为用户的扩展接口。Action模块中附带添加扩展模块的模板。用户可以根据所要测试网页的特点,在底层函数的基础上,封装自己常用的函数,只需要将这些函数打成jar包,放在指定的路径下,那么NetAuto就可以将其加载。测试脚本编写的过程中就可以直接调用。

2.4 良好的用户体验

自动化测试,很重要的一点就是完整地记录整个测试过程,包括测试过程中系统的情况、脚本的执行结果、是否出现异常等。概括来说,主要包括异常处理和日志两方面。 selenium框架中,几乎不涉及这两方面的内容,但NetAuto框架在设计之初就特别注重这两方面的处理。其中,在异常处理方面,除了Java标准库中定义的异常之外,NetAuto自身又定义了15种异常,用于涵盖所有的可能抛出异常的情况。在日志系统方面,笔者经过调研,最终决定引入apache log4j[3]包。日志分为两大类,正常log和异常的wflog。而且还提供了报表的输出,使测试人员可以有效监控脚本的执行情况,定位异常。

3 NetAuto系统实现

如图2所示,NetAuto框架主要包括以下几方面的内容:

对selenium底层函数封装形成的function(动作类库函数)和check(验证类库函数)库模块;

基于swt编写的可视化交互界面;

以TestNG[5]框架和Ant[12]框架为基础的测试和编译模块;

以数据注入和数据驱动为基础的测试执行模块;

解决页面元素识别的对象库模块;

给用户提供扩展应用的action接口模块;

负责生命周期管理的基础用例模块;

以apache log4j为基础的日志系统,报表系统等。

NetAuto提供了一个基础用例,BaseCase。测试用例的生命周期管理都封装在BaseCase中,包括脚本的入口函数以及退出、日志系统、异常系统等,都定义在BaseCase中。测试人员实现自己的测试脚本时,只需要继承自BaseCase,然后实现测试逻辑即可。脚本中除了代码外,还包括引用页面元素的参数和引用测试数据的参数,它们最终分别通过对象库和Data Provider 进行解析,得到确切的值。

通过NetAuto的界面,可以进行系统设置,设置包括测试所使用的浏览器类型及浏览器参数、所要测试的网页应用的baseurl以及端口、要运行的测试脚本的根路径等。脚本可以批量加载,测试数据和测试脚本是分离的,测试数据默认位于与测试脚本同级的路径下,且测试数据与测试脚本文件有相同的层次结构。因此NetAuto可以根据测试脚本文件的路径找到与之相对应的测试数据文件。

当设置完成后,NetAuto会查找测试脚本的根路径,将所有测试脚本以树状结构显示在界面上。可以用鼠标选取想要运行的测试脚本,点击运行按钮,就会通过Ant框架进行编译,然后加载运行。在运行过程中,NetAuto会将日志信息以及异常报告输出到界面上,便于测试人员了解运行的状态。当所有的脚本都运行结束后,NetAuto还会给出整体的报告,包括一共运行了多少脚本、有多少成功、多少失败以及失败的原因等等。

4 用NetAuto测试的工作原理及流程

如图3所示,NetAuto的工作原理及流程如下:

1) 转化用户编写的脚本

原始的测试脚本中,有两部分是由参数代替的,一是测试所要操作的页面元素;二是测试需要的数据。通过查找对象库,可以确认最终对应的页面元素;通过Data provider机制,可以抽取出所需要的数据。综合就可以生成selenium框架可识别的脚本。

2) 脚本通过Client lib 向Selenium server 发送http请求,要求和Selenium server 建立连接。

3) Selenium server 上得launcher启动浏览器,把selenium core加载到浏览器,并且把浏览器的代理设置成selenium server的http proxy。

4) 脚本通过Client lib向Selenium server发送http请求,server 将请求进行解析,然后通过http proxy发送js命令通知selenium core执行浏览器动作。

5) Selenium Core 接收到指令后执行动作。

6) 浏览器接收到新页面请求信息后发送http请求下载新Web应用页面。

7) Selenium server 接收到浏览器的http请求后自己重组http请求,获取相应的Web页面。

8) Selenium server 的http proxy 把Web页面返回给浏览器。

可以发现,整个过程中,http proxy起到了重要作用,使用http proxy,是因为我们的测试主要是在Firefox浏览器上进行,而Netscape曾提出了js脚本执行的同源策略,即只有当js脚本与请求的Web页面同源时,js才会被执行。

5 NetAuto关键模块具体实现

5.1 对象库

引入对象库的概念,使测试脚本编写时的关注对象从页面元素转移到了对象库中的元素,提高了开发的效率。并且,在网页做出更改的时候,只需要更改相应的对象库中的对象即可,测试脚本不需要做出任何改动。

对象库在实现上采用了xml文件的形式。下面是一个简易版的对象库。

<xml version=″1.0″ encoding=″UTF-8″?>

<page name=″page1″ reg=″www.url1.com″ title=″页面1″>

<element name=″element1″ disc=″″ type=″text″>

<xpath>key</xpath>

<page name=″page2 ″ reg=″www.url2.com″ title=″页面2 ″>

<element name=″element2″ disc=″″ type=″button″>

<xpath>image</xpath>

</pageroot>

pageroot代表了测试过程中可能涉及到的所有页面的集合。一级子节点page代表一个具体的页面。页面可以通过reg,即页面对应url的正则表达式和页面title两种方式识别。二级子节点element代表网页上的元素。element的识别是通过页面元素对应的xpath,即文件中的xpath子节点完成的(页面上的所有元素都有自己的xpath)。Element包含三种属性,分别是name,disc,type。Name指页面元素在对象库中的名称。type标识页面元素的类型,这是必须的,因为同样的动作作用在不同的页面元素上意义可能是完全不同的(比如点击文本框和点击复选框)。disc没有实际的作用,是预留的给用户添加注释的空间。

由此可见,对象库是页面以及页面上元素的一种抽象的表示。当页面发生改变时,我们只需要更改对象库中相对应的部分,而测试的脚本不需要做任何的改变。

5.2 数据注入与DataProvider

DataProvider是testng框架中提供的一个数据的注入接口,NetAuto框架实现了这个接口,提供txt,excel,xml等多种测试数据注入方式,并创建了一套测试数据文件组织方式。以txt数据文件为例:

测试数据文件组织和注入方式如图4所示。

对于一个用例而言,存在三种文件,.java结尾的测试脚本,.txt结尾的测试数据,.properties结尾的属性文件。测试脚本和属性文件是一一对应的,文件名的前缀是一致的。对于一个测试用例(case),脚本中会调用多个方法(method),每个方法涉及的数据可以存放在不同的数据文件中,具体的对应关系保存在属性文件中。

method中引用测试数据的时候,用变量或者参数替代。DataProvider机制通过CaseName.properties文件找到与测试脚本对应的数据文件,然后将读取的内容注入到对应方法的参数或变量中。这样,如果数据有更改或者增删,都只需要在.txt文件中进行,脚本不需要做任何改变。

5.3 Action模块扩展应用接口

为了使工具更契合用户的需要,给用户提供一个二次开发的平台。NetAuto提供了一个扩展应用的接口,用户可以提供自己的库函数,或者对NetAuto提供的库函数进行封装,使脚本的编写更快速、便捷。

Action模块起先是不存在的,试验推广的时候,有人提出,如果所有的脚本都直接调用底层的function模块和check模块,那么脚本会很长,并且一旦某个流程有所改变,可能很多脚本,都要做相应更改。而且,很多脚本会涉及同样的功能,比如,都有用户登录的部分,这完全可以封装起来,直接调用。于是,扩展应用接口应运而生。

Action模块本质上是一个jar文件,用户在Java开发工具中,按照NetAuto的要求编写自己的库代码,然后打包成jar文件,覆盖NetAuto指定路径下的默认包action.jar。这样,系统就可以加载并识别用户的库。

6 NetAuto的评测

NetAuto曾经推广应用,根据反馈的结果,我们做了统计分析。基于NetAuto框架的自动化测试,耗时主要在三个方面:对象库的构造、脚本编写、脚本执行。

对象库的构造需要花费一定的时间,因为在测试之前要把所有的页面和页面元素映射到对象库中。不过,由于对象库是一次构建,长久使用,所以从长期均摊来看,成本还是很低的。

脚本的编写,需要花费一定的时间在工具和测试流程的熟悉上,花费在代码编写上的时间反而比较少。而且随着熟悉程度的加深,可以编写适合自己风格的库函数,更好地契合不同的产品线,大大加快脚本开发的速度。

脚本的执行,如果只比较单一用例,NetAuto自动运行和人手工执行的时间几乎相同。但是,NetAuto可以批量执行,可以将人工完全解放。而且,NetAuto可以用在回归测试上,可以说,一次编码,终身受益。

NetAuto和Selenium相比,虽然在前期需要花费一定的时间构造对象库,甚至要针对产品线的特点对一些功能进行封装。但是,当这些前期工作完成后,NetAuto的优势就非常突出。

在产品线上的推广结果表明,在NetAuto上进行测试用例的编写比Selenium快4倍以上,利用NetAuto进行自动化测试的效率比手工快10倍以上。而且,可以利用NetAuto在空闲的时间自动进行测试,不需要人工的干预。编好的脚本还可以用来进行回归测试,将测试人员从重复的劳动中解放出来。

7 相关工作

自动化测试工具可以分为两类,负载压力测试工具和功能测试工具。分别针对性能测试和功能测试。

负载压力测试工具的代表有LoadRunner[7],QALoad[8],OpenSTA[9]等。以LoadRunner为例,主要是通过以模拟成千上万用户实施并发负载及实时性能监测的方式来确认和查找问题。使企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

NetAuto主要关注于功能测试,类似的工具也有很多,包括QTP[6],WinRunner[8]等。QTP是一套比较成熟的商用自动化测试工具。提供了很多插件,如.NET的插件,Java的插件,SAP的插件,Terminal Emulator的插件等等,分别用于各自类型的产品测试。QTP支持录制和回放功能,提供了通过类属性来识别对象的方法。有一套工作良好的测试用例组织方式,和测试用例生命周期管理方法。提供了Excel形式的数据表格,来存放测试数据和参数。并且对于每一个测试脚本,都有测试结果的分析和呈现。QTP是一个比较实用的自动化测试工具,但是它是纯商业性的,价钱非常昂贵,很多中小型企业负担不起。NetAuto在功能上基本可以替代QTP,而且更加简单易用。而且我们秉承开源的原则,促进学术的进步。

当然,除了Selenium之外,目前也存在不少的开源自动化测试工具,如ETF[10],ComUnit[11]等。但这些工具大都比较粗糙,很多都只能实现比较基础的功能,虽然适合作为一个研究的平台,但不适合直接在企业中部署应用。

8 结 语

随着信息技术的发展,软件日益庞大,自动化测试的作用愈发突出。在这篇论文中,我们分析了目前在网页自动化测试方面存在的难点和问题。针对这些问题,我们提出了解决问题的原则和方法。并以其为指导,基于Selenium开源框架,设计出了一个扩展性强,可用性好,功能完备的网页自动化测试工具NetAuto。通过对象库实现了数据和脚本的完美分离。在企业产品线上的推广证明,NetAuto可以极大地提高测试人员的积极性和效率。

为了进一步完善NetAuto,在未来的工作中,我们将在以下几个方面进行研究:1) 目前,NetAuto只支持前端页面的测试,但是后台的测试也是很重要的部分。我们将研究NetAuto能否用来进行后台的自动化测试;2) 尝试扩展NetAuto的并发功能,使其支持性能测试。

参考文献

[1]Bartram D,Bayliss R.Automated testing:Past,present and future[J].Journal of Occupational Psychology,1984,57(3):221-237.

[2]Badle Samit,Bakken Jari,Barantsev Alexei.What is selenium and howto use it[EB/OL].[2011-11-11].http://seleniumhq.org/.

[3]The Apache Software Foundation.Introduction to Apache Log4j project[EB/OL].[2011-11-11].http://logging.apache.org/log4j/.

[4]Steve Northover,Mike WilsonSwt.The standard widget toolkit,volume1[M].Addison-Wesley Professional,2004.

[5]Alex Ruiz,Yvonne Wang Price.Test-Driven GUI Development withTestNG and Abbot[J].IEEE Software,2007,24(3):51-57.

[6]Practice for QTP8.2Automatic Testing Implement Technology[J].In-formation Technology&Standardization,2008(4).

[7]Zhou Gan.The Realization of Page Load-stress Testing with LoadRun-ner[J].Journal of Jiangxi University of Science and Technology,2010.

[8]Zhang Huachuan,Xu Jing,Tian Je.Research on the parallel algorithmfor self-similar network traffic simulation[C]//iccsit,2nd IEEE Inter-national Conference on Computer Science and Information Technology,2009:355-359.

[9]OpenSTA Community.OpenSTA User HomeFor those Researching,Learn-ing and Using OpenSTA[EB/OL].http://www.opensta.org/.

[10]Tanja E J Vos,Arthur I Baars,Felix F Lindlar,et al.Industrial ScaledAutomated Structural Testing with the Evolutionary Testing Tool[J].icst,Third International Conference on Software Testing,Verificationand Validation,2010:175-184.

[11]Gabriel Garcia,Jim Karabatsos,Guillermo Palli,et al.How to get star-ted building your own unit tests with COMUnit[EB/OL].(2002-09-16).[2011-11-11].http://comunit.sourceforge.net/page=tutorial.html.

软件测试自动化框架 第6篇

关键词：自动化测试,敏捷开发,迭代开发,回归测试,接口自动化测试,数据分层

0 引言

随着互联网等技术的飞速发展,计算机软件已经融入到人类生活的各个领域,人们对计算机软件的要求越来越高,需求越来越多样化。在软件开发领域同样也面临着更激烈的竞争,软件需快速适应用户的需求与变化。Google前CEO埃里克·施密特提出: 如果你反过来看摩尔定律,一个IT公司如果今天和18 个月前卖掉同样多的、同样的产品,它的营业额就要降一半,IT界把它称为反摩尔定律。

在这种情况下,敏捷开发方法开始逐渐流行与成熟,敏捷开发方法强调更快的交付价值与灵活的适应变化。敏捷开发往往采用迭代开发方法,整个开发过程被组织成一系列短小的、固定长度( 如2周) 的迭代,每个迭代结束时都按照业务价值输出可工作的软件,为保证软件可工作,每个迭代中一般都需包含测试过程,并且因为本迭代的开发可能影响前几个迭代交付的软件,因此需对之前迭代交付的软件做回归测试,由于手工回归测试成本与时效性难以接受,这样敏捷开发对自动化测试技术提出了强烈的需求,通过自动化测试可以提供快速反馈机制,提高测试效率,快速交付软件。

经过多年的研究与实践,本文提出了一种用于接口测试的自动化测试框架,并在实践中应用,取得了理想效果。

1 分层自动化测试介绍及接口自动化测试的意义

1. 1 自动化测试分类

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程,自动化测试可以从软件的各个层级发起,根据测试发起的层级可以把自动化测试分为UI测试、接口测试、单元测试等。

界面测试: 模拟用户在界面的操作在UI端发起的、端到端的自动化测试。

接口测试: 模拟软件各系统间的通讯报文,在接口端发起的自动化测试,接口种类如HTTP、RPC、用户自定义的通讯协议等。

单元测试: 在代码的单元粒度上进行的测试,代码单元可以是一个函数、一个子程序或者是其它形式但具有清晰边界的一段代码。

1. 2 分层自动化测试

因上述3 类测试的成本和反馈速度各不相同,一个软件产品往往同时使用上述3 类测试中的一个或多个。Mike Cohn在其著作《Succeeding with Agile》中对上述测试做了详细论述,并提出了测试金字塔概念,如图1 所示,金字塔各层的宽度表示每层的自动化案例的数量,越往底层建议的守护案例数量越多,如Google建议的理想的各层案例数比例为1∶ 2∶ 7。

Mike Cohn提出的分层自动化测试是为了追求更快速的质量反馈和更低的质量守护成本,分层测试规划就是构建高效的测试金字塔,不同层次的测试可以用尽量低的成本防御不同类型的风险,各软件产品需根据自身特点和需要构建适合自身的测试金字塔模型。

1. 3 测试金字塔演变

单元测试和界面测试在实际应用中有一定局限性,如: 大多数软件产品的代码质量都不支持单元测试,代码需经过重构才能进行单元测试,但没有测试保护的重构是异常危险的; 单元测试粒度小,需编写大量单元测试案例,导致单元测试投入大、效果差。因此除非采用测试驱动开发( TDD) 方式,否则案例质量难于保证,而在实际项目中因代码的复杂性和彼此关联,TDD难于实施。

因一般软件产品中界面是最不稳定的,界面变更需经常同步维护案例; 因界面测试是端到端的,流程长、对环境依赖高,导致案例经常因环境原因失败、执行速度慢,例如某项目编写了126 个Selenium案例,全量案例执行平均需3 小时左右,并且经常因环境问题导致部分案例失败,增加无谓的排错工作量。

基于以上原因,大多数软件产品使用如下策略构建测试金字塔来实现,即少做界面测试,界面测试主要用于冒烟测试,多做接口测试,不强推单元测试。这样测试金字塔将演变成如图2 所示,大量案例应部署到接口测试层级。

1. 4 接口自动化测试的意义与挑战

为什么要多做接口测试,主要是接口测试有如下优势:

接口能够覆盖业务规则,并体现系统行为,测试可信度高、效果好; 接口一般稳定、数量可控,要求的案例数量和变更频率均适中; 接口易于测试,且需要时可并行测试,案例执行速度快; 接口级发现的bug定位成本较小。

同时,接口测试也面临着挑战,接口因不是直接面向用户,接口测试数据中会存在大量冗余数据,这些冗余会给案例的编写和维护带来大量成本。为了解决这项挑战,下文提出了一种基于数据分层的接口自动化测试框架,可大幅降低接口测试案例编写和维护的成本。

2 关键概念定义

测试引用数据( Test reference data) : 是指对测试行为影响小,但与测试相关缺失后会引起报错的数据,如可共享的数据、空数据、技术数据等。

测试专有数据( Test specific data) : 是指真正影响测试行为的特征数据,如用户输入的数据、有意义的业务数据等。

为便于理解,举一个简单的银行卡取款接口的例子,表1 中每一行都是一组接口输入数据,用来测试接口的一条路径,可以注意到表中的数据有大量冗余,其中地区号、网点号等是各组数据可以共享的数据,属于测试引用数据,而金额、密码等是用户输入的数据,属于测试专有数据。

3 基于数据分层的接口自动化测试框架设计

3. 1 为什么接口测试案例需分层设计

界面测试是从界面发起,模拟界面输入,输入数据基本是测试专有数据,数据基本无冗余,而单元测试往往是对函数级别的模块测试,输入参数较少,因此对于界面测试和单元测试而言一般都无需考虑案例的数据分层。

但对于接口测试而言,接口自动化测试案例的本质是包含一组特定输入数据的脚本发送给接口,用来测试接口的一条路径,由于接口属于软件的中间层,往往包含较多技术数据、冗余数据等,实际中一组输入数据往往包含几十、数百个数据段,其中往往绝大多数属于测试引用数据,这些冗余数据段会给测试案例维护带来大量的成本,实践中这些成本往往是不可接受的。因此接口测试中应将测试引用数据和测试专有数据分离,把引用数据从案例中剥离出来,把专有数据放到案例中,复用测试引用数据,可大幅提升案例的可维护性和可读性。

3. 2 数据分层设计思路

通过分层设计可实现测试引用数据和测试专有数据的准备过程分离,本文利用Java的面向对象特性,通过把接口输入数据各字段定义成Java类的成员变量,以便输入数据在各层间继承,在不同层为接口输入数据赋不同类型的值,实现了这种分层机制,各层次设计如图3 所示。

各层的实现方式、作用和用户维护成本说明如下:

基础层: 是一个命名为基础类的Java类,提供与被测接口通讯、日志等基础功能。由测试框架提供,无需用户维护。

接口定义层: 是多个继承于基础类的Java类,命名为接口定义类,一个接口定义类对应一个被测接口,由工具根据接口定义文档( 如XML、TXT等格式) 自动生成,并根据接口各字段的数据类型自动赋默认值,如字符型赋空格、数值型赋0 等。本层包含接口输入数据的全量字段,当接口定义变更时,如新增、修改字段等时,依靠默认值可保证部分存量案例不修改也可以测试通过,降低案例维护工作量。本层通过工具自动生成,无需用户维护。

引用数据层: 是多个继承于接口定义类的Java类,命名为引用数据类,对可共享的引用数据赋值,可供下层多个案例使用。当需要变更某引用数据时,只需在此层变更一次,下层多个案例即可共享。

案例层( 专有数据层) : 是一个或多个继承于引用数据类的Java类,命名为案例类,并使用Test NG框架,实现测试案例的驱动。每个案例赋值一套测试专有数据,完成最终案例。

为便于理解,以表X的数据为例,案例层的伪代码如下,其他层采取类似的代码赋值。

3. 3 数据分层设计解决的问题总结

通过案例层的设计,使用户主要关注案例层的业务数据,排除测试引用数据的干扰,增加案例的可读性。

通过引用数据层的设计,复用了测试引用数据,大幅减少案例编写和案例变更的工作量,这也符合了DRY原则( Don't repeat yourself) 。

通过接口定义层赋默认值的设计,自动适应接口变更,如新增、修改、删除字段时,避免部分存量案例失败,减少存量案例维护工作量( 接口变更往往是新增业务功能,不影响接口原有功能) 。

3. 4 实际应用及结果分析

基于本框架,在某实际项目中编写了107 个接口自动化测试案例,通过Jenkins开源持续集成调度平台执行,全量案例执行平均需0. 5 小时左右,案例运行稳定。与某项目126 个Selenium案例平均需执行3 小时左右,且经常因环境问题导致案例失败相比,接口测试的测试效率、稳定性、维护成本都有较大幅度提升。

4 结束语

本文先简要介绍了自动化测试在敏捷开发中的作用,并根据在自动化测试领域的研究与实践,提出多做接口测试更具有现实意义,之后提出并实现了一种基于数据分层的接口自动化测试框架。本测试框架是自动化测试领域新的尝试,从实际应用看,可减少案例维护工作量,提高案例的可读性、稳定性和运行效率,基于本框架的衍生框架可广泛应用于各类自动化测试框架的研究与实现中。

参考文献

[1]Craig Larman,Bas Bodde.精益和敏捷开发大型应用指南[M].孙媛,顾全,译.北京:机械工业出版社,2011.

[2]Mike Cohn.Succeeding with Agile[M].Boston:Addison-Wesley Professional,2009.

[3]Jez Humble,David Farley.持续交付:发布可靠软件的系统方法[M].乔梁,译.北京:人民邮电出版社,2011.

[4]Martin Fowler.重构:改善既有代码的设计[M].熊节,译.北京:人民邮电出版社,2010.

[5]James Whittaker,Jason Arbon,Jeff Carollo.Google软件测试之道[M].黄利,李中杰,薛明,译.北京:人民邮电出版社,2013.

[6]Lisa Crispin,Janet Gregory.敏捷软件测试:测试人员与敏捷团队的实践指南[M].孙伟峰,崔康,译.北京:清华大学出版社,2010.

[7]Dorothy Graham,Mark Fewester.自动和测试最佳实践[M].朱少民,张秋华,赵亚男,译.北京:机械工业出版社,2013.

软件测试自动化框架 第7篇

关键词：模板工程,软件开发自动化,模型,视图,控制

1 软件开发自动化框架

对于这一自动化框架来说, 它包含了四项核心要素, 分别是层语言、模板、框架以及构件。这四项核心要素彼此之间存在着一定联系, 同时又保持一定的独立性。而在对自动化框架进行设计的过程之中, 需要对一些要求与原则进行严格的遵守, 主要如下:首先, 需要对层语言这一核心要素的三个性能进行有效的保障, 分别是完整性、一致性以及可映射性;其次, 模板工程在其中具有十分重要的作用, 因此需要对其进行广泛的应用。

2 模板工程分析

对于模板来说, 究其实质, 它其实是一种脚本语言。而在一般情况下, 脚本语言主要分为两个部分, 分别是模板语言以及模板引擎, 前者主要进行对于映射规则的描述, 而后者则是对前者进行解释, 并对相关的对象与模板进行一定程度上的结合并最终输出。

而对于模板工程来说, 它主要指的是一种在相关工程之中对模板进行广泛使用来实现对于框架、构建等工件建造的技术。目前状况下, 这一技术发展迅速, 尤其是近几年来领域工程、MDA以及技术体系架构等方面的进步, 使得模板工程迎来了全新的发展契机, 新型的模板不断被定义。模板工程在软件开发的过程之中发挥了越来越重要的作用, 在很大程度上对生产效率进行了提高。

3 映射模式分析

主要从模型、视图以及控制器三个方面来对软件开发自动化框架的映射模式进行一定程度上的分析, 主要如下:

3.1 模型支持

对于模型来说, 它在软件系统之中发挥着十分关键的作用, 因此它可以说是软件系统的核心。模型的映射模式图主要如下:

当对相关的实体类模型已经设计完成之后, 就可以对相应的对象模板对其进行一定程度上的转换。最终转换完毕的关系模式采用DB结构XML描述, 同时, 以这个结构作为基础, 能够对实体引擎构件进行有效的使用, 并以此来实现对于持久层服务的提供。除此之外, 实体引擎构件还提供了相应的生成器, 通过对这一生成器进行有效的利用, 实体引擎构件还能够自动为相关数据库结构中每张表的对象模型生成4个类。

3.2 视图支持

对于数据视图来说, 它主要指的是用户与数据之间所存在的相关接口。而执行程序就是通过某种方法使得用户与数据视图之间进行一定程度上的交互。而视图的职责就是对相关的数据进行有效的显示, 同时对用户与数据之间的交互进行一定程度上的管理。视图映射模式主要入下图所示:

由图可知, 主要存在着两种模式来对视图进行显示, 分别是拉模式以及推模式。当采用拉模式来对视图进行显示时, 在页面中既存在着静态的样式, 又存在着一定的动态数据视图。拉模式的优点主要表现在能够独立的对数据视图进行有效的控制, 而不需要其他开发人员的协助。然而, 同时也存在着一定程度上的弊端, 主要有页面样式和数据视图的显示、控制逻辑混杂, 这样一来, 就为相关程序的理解以及维护带来一定的困难。而对于推模式来说, 它被广泛的应用于对象的开发技术之中。这种模式能够实现对于静态模式以及动态数据逻辑的明确划分, 能够解决较为复杂的问题。

3.3 控制器支持

在相应的自动化开发框架之中, 控制流程的自动化转化存在着较大的难度。因为, 对于框架有着较为严格的要求, 首先, 框架必须保证能够对所有种类的业务规则的定义以及执行进行支持。其次, 还要求框架必须能够对逻辑模块进行合理而有效的划分, 以此来实现模块之间的高内聚、低耦合要求。但这样所取得的效果是十分明显的。因为这样一来, 用户就可以在不需要相关开发人员的帮助之下实现自主阅读与修改。控制器映射模式主要入下图所示:

结束语

软件测试自动化框架 第8篇

随着Web技术的发展, B/S模式的应用程序逐渐成为互联网应用的主流。为保证Web应用的质量, Web应用的测试成本往往占了软件成本的大头[1]。在软件测试过程中, 为了节省人力、时间、花费和硬件资源, 提高测试效率和测试覆盖率等等, 良好的测试框架可以为测试人员提供极大的便利[2]。

Web应用的一个最大的特点就是需求频繁变化, 这种变化往往直接反映在页面上。一个迎合客户需求的Web应用, 是需要进行多次需求与所形成产品校验的过程[3]。在这样的过程中, 如果没有灵活的测试框架, 测试人员为了应对变化的需求, 所需花费的精力和对测试的维护成本是非常高的。当整个产品的测试延后, 将会影响整个应用的迭代和发布周期, 造成无可估量的损失[4]。

本文通过Selenium的平台无关行和易操作性, 研究能够直接在浏览器中运行, 多语言多平台支持的低耦合测试框架。该框架能够根据脚本之间的依赖, 最优化脚本执行流程的路径和分配进程的数量, 提高对单个的功能点或者集成测试的覆盖率;通过自定义信息的输出和格式, 实现对脚本执行的过程和状态进行跟踪和定位, 快速搜集错误的信息与类型, 减少人工错误定位的时间和花销。该框架主要针对如何降低脚本之间的耦合性, 如何灵活地组合不同的脚本, 以及如何快速的定位脚本的错误的问题来适应如今Web应用开发中需求频繁变动的问题。

1 Selenium

Selenium是一个用于Web应用程序测试的工具。Selenium的最大优势是, 它的测试能够直接运行在浏览器中, 就像真正的用户在操作一样[5]。Selenium支持几乎所有的浏览器, 它支持自动录制动作, 并且能够自动生成Net、Java、Perl等不同语言的测试脚本[6]。

2自动化测试框架与多维度测试覆盖率

2.1常见测试框架

测试脚本模块化框架根据小粒度的独立的脚本来规划测试用例脚本, 达到脚本模块化的标准[7]。

测试库框架该框架与测试脚本模块化框架非常的类似。它在于把Automation Test分成过程和函数两个部分。

关键字/表驱动测试框架关键字/表驱动测试框架需要开发数据和关键字, 这些表和关键字要独立于所使用的自动化测试工具和测试脚本代码。

数据驱动测试框架数据库驱动测试框架指的是测试的输入和输出值, 同时, 脚本代码中有对应的数据变量。

混合测试框架根据不同的测试工具和测试要求, 将以上的这些自动化测试框架的优点进行结合, 形成混合型的测试框架[8]。

2.2测试覆盖率计算

基于文献[9]提出的多维度软件测试覆盖率的评估概念, 测试覆盖率是用来度量软件测试是否充分和完善的一种必需的手段[10], 覆盖率的计算公式如下:

式中, 我们需要从不同的角度对item进行统计, 这就需要考虑不同侧重点的测试覆盖率指标:基于代码的覆盖率 (如语句覆盖率、判定覆盖率、条件覆盖率、函数覆盖率、指令块覆盖率) , 基于需求的覆盖率 (如功能覆盖、需求覆盖) 和面向对象的覆盖率 (如继承上下文覆盖、线程上下文覆盖) 等等。

根据文献[9]的多维度概念, 本文假设测试覆盖率的维度为N, 那么就有N中测试覆盖率C1、C2、、Cn, 这些测试覆盖率都是由式 (1) 得出的结果, 所以0Ci1, 1in。假设每个测试覆盖率所对应的权重不同, 这N种测试覆盖率的权重为P1、P2、、Pn。根据不同覆盖率的不同权重, 计算测试的综合覆盖率计算公式如下:

测试需要达到一个满意度, 我们给每个测试覆盖率一个期望值, 则这些覆盖率的期望值为E1、E2、、En, 0Ei1, 1in。计算总的满意度的计算公式如下:

3基于Selenium的测试框架改进实现

3.1分层测试框架

本文基于Selenium自动化测试的改进框架, 从数据层、逻辑层和业务展示层三个层面出发。数据层面, 测试数据库和应用数据库都是作为独立运行部分, 测试数据独立于测试逻辑。逻辑处理层, 该框架使用的测试驱动是Selenium的测试驱动。测试用例层, 为了能够降低脚本之间的耦合性, 增强脚本之间的灵活性, 将测试脚本的业务逻辑和控制模块相分离。利用脚本之间的依赖关系, 结合Test NG来对脚本流程进行控制。并通过对代码输出逻辑的控制, 实现对测试脚本执行结果的定位和跟踪。视图层, 我们需要一个测试报告来形象地显示测试结果, 直观显示测试结果, 该测试报告需要提供失败脚本的具体原因和错误类型。该框架主要针对如何降低脚本之间的耦合性, 如何灵活地组合不同的脚本, 以及如何快速地定位脚本执行的错误。该框架执行能够直接在浏览器中运行, 能够多语言多平台和多浏览器支持, 完全模拟用户的操作;能够根据脚本之间的依赖, 通过图的拓扑排序来最优化脚本执行流程的路径和进程的数量, 能够对单个的功能点或者集成测试提高覆盖率的自动化测试;通过自定义信息的输出和格式, 实现对脚本执行的过程和状态进行跟踪和定位, 对脚本的执行结果进行分析, 快速搜集错误的信息与类型, 减少人工错误定位的时间和花销。图1是整个框架的整体设计图。

综上所述, 我们可以知道, 一个好的Web测试框架, 如果具备以下几个因素, 就可以极大地提高这个测试框架的效率:

1) 能够随着需求的不断变化而最小化测试用例的修改;

2) 平台无关, 能够自适应各种不同的平台;

3) 测试的业务逻辑应该与测试的数据进行分析, 这样可以测试用例的复用;同时, 数据的多样性, 增加测试用例的覆盖率;

4) 降低脚本与页面之间的耦合度, 减少页面的修改对脚本的影响;

5) 在可复用的情况下, 应该增强测试用例的灵活组合性能;

6) 能够对测试脚本错误信息进行定位和跟踪, 以便测试和开发人员重新进行修改和测试;

7) 提供一个更直观更快捷的方式查看测试脚本的运行情况, 便于测试人员更直观高效地查看测试结果。

3.2降低Selenium脚本耦合度

根据Web页面需求频繁变动的特点, 我们首先要考虑的是如何降低脚本之间的耦合性。本文提出的测试框架主要从数据层和测试逻辑层两个层面来组建, 实现数据与测试逻辑的分离, 尽量减少后期脚本的改动, 为脚本的复用提供了可能。

Selenium录制的脚本主要分为三个部分:Command, Target和Value。其中对Command进行分类总结, 可以像图2这样进行分类。

Action是对当前操作的状态命令。如果Action操作失败, 那么当前的执行停止。Accessors用于检查应用的状态并把结果存储在变量中, 比如“store Title”。Assertions有点类似于Accessors, 但是它们把应用的状态跟预期作对比。我们根据不同的命令分类, 建立Action、Accessors和Assertions三个命令库, 在我们需要调用某个命令的时候, 调用命令库, 并初始化该命令。

建库的时候, 我们可以对一个命令进行扩展和封装, 比如调用click命令:当只需要点击事件时调用click () ;当需要对点击事件有个响应时调用click And Wait () ;如果当一个事件的响应时间有一定时限, 类似于网络包的反应, 这个时候我们就可以封装为click And Wait (int pause Time) 。

Selenium录制的脚本中的Target, 为了能够针对页面的修改进而可能少的修改我们的脚本目标, 我们不采用绝对路径, 用XPath来实现相对路径。我们将录制的页面的所用控件的路径进行归类整合, 写入单独的文件中。举个例子, 对于页面Login.jsp, 那么它的文件内容可以定义为:

单个测试用例执行流程如图3所示。

每当一个测试用例执行的时候:

1) 首先查找该Target是否存在, 当Target存在, 执行操作;否则, 终止该用例, 并且可以通过下文所提及的Log4j来定位错误的类型, 方便测试人员立即反映错误的来源, 报告定位错误;

2) 能否对该目标执行所定义的Command命令, 如果能够执行, 继续;否则, 终止该用例, 报告执行命令错误;

3) 从数据库中读取测试数据, 能读取数据, 循环执行所获得的数据, 完成用例执行;否则, 连接数据库错误, 执行用例失败, 报告读取数据错误。

Selenium所录制的脚本主要用于对Web进行的黑盒测试。结合Test NG的对代码进行的白盒测试功能, 能够很大程度上对一个测试进行大面积的覆盖。

3.3提高脚本灵活度

如何提高脚本的灵活度, 实现多样性脚本, 本文对每一个脚本按照先后执行顺序进行分级。Test NG的机制能够对测试用例的执行顺序进行控制, 它们之间有一定的依赖, 通过图的拓扑排序来最优化脚本执行流程的路径和规划开启进程的数量。我们先将测试的用例分成不同的steps, 每个step上的用例有不同的前后依赖, 利用这些依赖, 我们可以很顺利地对不同的脚本进行组装和拆分。使用Test NG的Test Suit功能, 我们可以对单独的某个点的功能进行测试, 也可以对一个完整流程下的模拟操作进行流程测试。与此同时, 级联之后的脚本运行时, 当一个脚本出错, 后续的脚本将无法运行。这样的设计便于快速错误定位。

利用Test NG的描述文件进行脚本的组合, 灵活性还是有一定的限制。改进方案就是, 将所有的脚本按照完整的流程存储到一颗树当中, 当需要对脚本进行组合调用时, 使用树的遍历算法遍历这棵树的根节点到叶子节点的所有路径。当测试人员需要对Web的所有或部分逻辑功能进行测试时, 遍历脚本树。

利用Selenium的便捷和跨平台录制, 修改测试脚本, 将测试脚本中的数据分离。数据的分离, 保证了测试数据的丰富多样, 也保证了脚本的易改动性和复用率。利用Test NG提高测试用例的复用性和覆盖率。将各种测试用例进行有逻辑的组合, 这样不仅一个测试用例能够用于多种情况, 多次被复用, 还能大面积的覆盖测试所需的场景。

3.4定位跟踪脚本错误

当一个测试用例执行失败的时候, 产生的原因是多种多样的。当大量的测试用例和测试数据被执行的时候, 测试执行完成的结果不可能给测试人员一个全面完整的分析。这就要求测试人员在设计测试框架的时候能够提供一种更轻松更快捷的方式, 让测试人员能够快速的定位到测试失败的原因。本文在测试的逻辑引入Log4j, 对错误的类型和输出信息进行自定义, 在测试报告的输出方统一整理测试过程中出现的错误信息, 引起错误的原因以及错误的时间等等测试人员所需要的信息, 然后以文件或页面的形式输出。Log4j强大的可配置型, 为测试人员的工作节省了大量的时间和精力。

4实验及结果分析

4.1基本实验对比

该实验挑选了数个典型的Web应用进行脚本录制和对比实验。实验采用前文所提及的改进框架, LoadRunner, QTester, 以及Selenium录制脚本四者进行脚本录制和实验对比。定制测试用例36个, 形成对应的脚本。这些脚本中, 其中有24个是相对独立的功能脚本, 12个脚本是由不同的脚本组合而成的脚本, 对应不同的功能。例如:客户的登录是一个单独的脚本, 查询本月支出也是一个单独脚本, 登录系统并增加一项支出以及登录系统并查询本月支出并退出系统, 这就是两个不同的组合脚本。其中, 改进框架的测试脚本是用Selenium进行录制, 并通过上文的框架进行脚本修改, 实现数据, 逻辑和显示进行分离。下面一系列实验都是根据相同测试用例来录制的脚本, 不同的测试工具所录制的脚本不一样, 但是针对的测试目的都必须一致。针对不同的实验情况进行对比和分析。

从表1的对比情况来看, 在不同的浏览器下, 各种工具的脚本执行情况各不相同, 其中Selenium录制的脚本执行所花的时间最短。这是Selenium工具本身所具有的优势。而改进过后的框架所化时间比Selenium所花时间长一点, 这是因为不同的脚本执行的过程中, 需要去加载测试数据, 脚本所需执行命令的命令库, 脚本目标预加载, 执行结果判断这些附加过程, 整体的时间影响比较小。在不同的浏览器下, 不同工具执行的脚本运行时间也不一样, IE7的运行结果最慢, Chrome最快。

可以看出, 在不同的浏览器下, 改进框架的执行情况比较稳定, 效果比较明显的, 并没有明显的显现出不同工具和模块之间的互斥性。

接下来, 对脚本的灵活度进行对比实验。首先, 修改不同的脚本数据。然后对其中的单独的测试脚本进行组合。这些组合有以下几种:登录+增、删、查、改;登录+增加+查询;登录+增加+删除;登录+增加+修改;登录+查询+退出八种针对支出的执行结果对比。

表2的实验仍然采用的是24个独立脚本。我们修改了每个脚本的测试数据, 这个时候, 前面三种工具所录制的脚本的数据都包含在执行脚本中, 这就要求我们去修改对应脚本中的数据。而改进框架中的数据都在数据库中, 我们只要去修改相应的数据库即可。组合脚本的运行情况下, 其中LoadRunner和QTester在执行登录+增、删、查、改的组合中, 运行成功。当条件变复杂时, 两者执行结果报错, 执行对象不存在。Selenium在运行登录+增加+查询;登录+增加+删除;登录+增加+修改三种情况时, 也报出所加载对象不存在的错误。而改进框架执行组合脚本运行正常, 八种组合都成功运行。可以看到改进框架在脚本灵活度方面, 明显比其他三种工具好。

单独脚本的执行和修改以及组合测试进行对比之后, 接下来根据组合脚本进行对比测试。这些组合脚本都是一个完整的执行流程。对此, 我们的实验很简单, 把登录界的角色一栏由下拉框改成单选框, 然后进行实验, 实验结果如表3所示。

从表3的结果来看, 执行的12个脚本, 执行结果的报错, 前三个工具的报错类型和报错数目都一样, 对象不存在, 即所录制的下拉框对象已经不存在。而改进框架的报错数也是2个。这是因为在执行过程中, 改进框架的组合脚本都是根据独立的脚本进行组合的。这就意味着改进框架的这12个组合脚本共用一个登录脚本, 而这个登录脚本出错, 后面的组合的单独脚本就不会运行。改进框架报出两个错误, 第一个是点击下拉框的命令错误, 下拉框的目标不存在。这样能够直观地告诉测试人员错误在哪个位置, 能够更快速的让测试人员找到错误所在。而后根据页面对脚本进行修改, 前面三种工具必须根据修改每个脚本的登录部分。而改进框架的12个脚本共用一个登录测试脚本, 所以只需要修改这个登录脚本的角色部分就可以了。

在不同的工具之间进行了脚本之间的灵活性, 耦合度和错误跟踪之后, 我们对这些脚本进行并发测试, 对其进行一个性能方面的对比。

表4是针对这12个组合脚本, 模拟1 000个用户进行并发的性能测试。对比结果我们可以发现, LoadRunner本身作为性能测试脚本的优势, 领先于其他三个工具。Selenium Grid是Selenium用于性能测试的一个工具, 所花的时间比QTester少。而改进框架的性能测试方面, 明显不足, 但是也优于QTester, 本研究的后期将试着结合性能测试工具JMeter进行框架改进。

从上面的几个实验结果表明, 在测试过程中, 改进框架能够快速地定位错误位置, 并能迅速指导测试人员修改错误。并且在录制过程中, 数据的修改也方便快捷。

4.2测试覆盖率对比

这组实验是对Selenium和对其录制脚本进行改进的改进框架, 两组之间的测试覆盖率的对比。Selenium是一种页面脚本录制工具, 它不能做到对代码进行单元测试。录制的脚本不能够进行白盒测试, 所以本实验从需求覆盖率的方面对两者进行对比。对比情况如表5所示。

根据式 (2) 和式 (3) 计算综合覆盖率和满意度对比如表6所示。

由表6得出, 改进框架测试的综合覆盖率比Selenium高, 其满意度为1.0485, 超出预期估计。此实验得出改进框架的测试覆盖率得到了改进。

5结语

使用Selenium录制的脚本语言极大地简化了测试人员的工作, 而本文提出的低耦合自动化测试框架, 极大地增加了测试的覆盖率, 增加的测试脚本的灵活度, 快速地帮助测试人员跟踪和定位测试的错误信息。但是该测试平台在压力测试方面的性能还有待改进。总的来说, 基于Selenium的低耦合自动化测试框架, 由于降低了脚本的耦合度, 增加了灵活性, 使得测试效率、测试覆盖率等有了较大的改善, 可以广泛地应用于Web应用自动化测试中。

参考文献

[1]Patton R.软件测试[M].北京:机械工业出版社, 2006.

[2]赵彬.软件测试技术经典教程[M].北京:科学出版社, 2007.

[3]冯振华, 高菊, 曾红卫.Web应用自动化测试的研究[J].计算机工程与设计, 2010 (1) :175-178.

[4]李秋英, 陆民燕, 阮镰.软件可靠性测试充分性问题的理论研究[J].北京航空航天大学学报, 2003, 29 (4) :312-316.

[5]Xinchun Wang, Peijie Xu.Build an Auto Testing Framework Based on Selenium and FitNesse[C]//Information Technology and Computer Science, 2009.

[6]黄华林.使用Selenium进行Web应用自动化测试的研究[J].电脑开发与应用, 2012, 25 (4) :54-56.

[7]邓青华.软件自动化测试工具研究[J].软件导刊, 2011, 10 (1) :57-59.

[8]Zeng Wandanm, Jiang Ningkang, Zhou Xubo.Design and Implementation of a Web Application Automation Testing Framework[C]//2009Ninth International Conference on Hybrid Intelligent System, 2009 (2) :316-318.

[9]安金霞, 王国庆, 李树芳, 等.基于多维度覆盖率的软件测试动态评价方法[J].Journal of Software, 2010, 21 (9) :2135-2147.