论文部分内容阅读
摘要:该文对软件质量保证的重要手段——软件测试进行了论述,给出一些软件测试的基本理论。随着软件测试研究的发展,软件测试提出了一些比较前沿的理论,如面向对象的软件测试,测试驱动开发理论,探索性测试等。为了克服手工测试的一些困难,提高软件质量和测试效率,自动化测试被广泛地引入进来。它以其自动化程度高、实用性强等特点,引起了人们的广泛重视,成为软件测试的发展方向。自动化测试框架产品的出现表明软件测试自动化技术正在趋于成熟。早期使用录制回放和脚本工具的不足正在被克服,使得自动化测试更加经济、有效,更加有利于实现和维护。随着在开发和维护脚本上的时间越来越少,更多的时间可用于提高测试的覆盖范围和产品质量,从而在自动化上的投资能够更快地得到证明。该文分析讨论了自动化测试框架方法以及实现,并将其应用到软件测试中。
关键词:软件测试;自动化测试;数据驱动;关键字驱动
中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)26-7428-04
The Research and Application for Software Testing Techniques and Automated Testing Framework
LIU Teng
(Information Technology Department Hunan Radio & TV University, Changsha 410004 ,China)
Abstract: Progress of studying with software testing, peoples have put forward some new theories, for example, Test Driven Development ,Exploratory testing , Model--based Testing use a model to generate test case and so on.In order to conquer the difficulties of manual testing, and enhance the quality of software as well as efficiency of software testing, the automation of testing process is widely applied. It catches the extensive attention with its characters, such as high automation degree, strong practicability, and so on. And it has been the developing direction of software testing.The appearance of test automation framework product indicates that the technology of software automated testing is going to be mature. The insufficiency of using capture/playback and script tools is being got over, thus, automates testing will become more economical and efficient, and be more advantageous to be implemented maintained.
Key words: software testing;automated testing;data-driven;keyword driven
1 自動化测试框架
自动化测试在过去的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.4WAF GUI映射
自动化测试工具录制应用程序中的每一个对象,并给每个对象命名来识别各对象,这个逻辑名能被修改,将其用在测试表中,测试工具使用他们来识别对象, GUI映射可由自动化测试工具自动产生。
2.5 测试数据
数据驱动测试是一种数据被包含在输入测试数据文件中,并且数据控制自动化测试脚本执行的流程和动作的测试。测试数据记录以文档的形式包含在输入文件中,输入文件包含测试数据和控制数据。测试数据进行必要的各种类型的测试,而控制数据引导测试脚本到达合适的位置并指示要执行的动作。测试数据是特定测试产品和测试组合的测试数据[6]。对于不同产品测试数据是不一样的。譬如对于文件传送功能的测试数据则表现为各种类型的文件。
2.6 测试用例
测试数据定义测试状态的初始化,测试步骤,应用在每一步中的测试数据以及其预期结果,是一个基本的测试单元[7]。测试组合是一个测试用例的集合,被指定来完成一个特定的测试目标。它可以被设计来测试一个函数,一个模块,或者是执行一个类型的测试,例如验收测试(Release Acceptance Test )。
在WAF框架模型中,测试数据是以标签的形式存放在XML文件中,每个标签对应一个测试数据,这样在一个独立的XML文件中可以对应多个测试用例,可以将XML文件看成是多个测试用例的集合。下面是对于一个XML文件的描述:
……….
//以标签的形式存放测试数据
测试数据1
测试数据2
………..
测试数据n
……………..
2.7 测试件配置文件
TESTWARE配置文件记录执行测试件(testware)的一些基本配置项。包括文件目录,数据目录,测试组合目录,log目录以及一些服务的配置等。
2.8 测试结果
WAF在执行完一个测试后产生三种类型的测试结果,日志文件,报告和相应的测试过程数据。
2.9 利用WAF进行自动化测试开发流程
运行一个使用WAF开发的TESTWARE时,主程序被执行。它初始化测试环境,解析配置文件,启动数据驱动引擎(Data-driven engine)。
进行测试时数据驱动引擎调用XML文件,解析文件中的标签,通过资源定位符定位到XML文件中的设计好的测试用例(或者测试组合),根据解析的结果调用函数库中相应的功能函数(lib),并通过测试數据来对相应的应用程序执行测试。最后将测试结果返回给主程序输出。
3WAF在软件测试应用中的实现
当决定把数据驱动的自动化测试框架应用于一个具体的项目,首先要确定所有的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 the 3rd International Conference on Quality Software,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,WickburgH.A method for Built-in Tests in Component-based Software Maintenance[C].Amsterdam, Netherlands:Proceedings of the Third European Conferenceon Software Maintenance and Reengineering,1999.
[11] Dustin E.軟件自动化测试:引入、管理与实施[M].北京:电子工业出版社,2003.
关键词:软件测试;自动化测试;数据驱动;关键字驱动
中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)26-7428-04
The Research and Application for Software Testing Techniques and Automated Testing Framework
LIU Teng
(Information Technology Department Hunan Radio & TV University, Changsha 410004 ,China)
Abstract: Progress of studying with software testing, peoples have put forward some new theories, for example, Test Driven Development ,Exploratory testing , Model--based Testing use a model to generate test case and so on.In order to conquer the difficulties of manual testing, and enhance the quality of software as well as efficiency of software testing, the automation of testing process is widely applied. It catches the extensive attention with its characters, such as high automation degree, strong practicability, and so on. And it has been the developing direction of software testing.The appearance of test automation framework product indicates that the technology of software automated testing is going to be mature. The insufficiency of using capture/playback and script tools is being got over, thus, automates testing will become more economical and efficient, and be more advantageous to be implemented maintained.
Key words: software testing;automated testing;data-driven;keyword driven
1 自動化测试框架
自动化测试在过去的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.4WAF GUI映射
自动化测试工具录制应用程序中的每一个对象,并给每个对象命名来识别各对象,这个逻辑名能被修改,将其用在测试表中,测试工具使用他们来识别对象, GUI映射可由自动化测试工具自动产生。
2.5 测试数据
数据驱动测试是一种数据被包含在输入测试数据文件中,并且数据控制自动化测试脚本执行的流程和动作的测试。测试数据记录以文档的形式包含在输入文件中,输入文件包含测试数据和控制数据。测试数据进行必要的各种类型的测试,而控制数据引导测试脚本到达合适的位置并指示要执行的动作。测试数据是特定测试产品和测试组合的测试数据[6]。对于不同产品测试数据是不一样的。譬如对于文件传送功能的测试数据则表现为各种类型的文件。
2.6 测试用例
测试数据定义测试状态的初始化,测试步骤,应用在每一步中的测试数据以及其预期结果,是一个基本的测试单元[7]。测试组合是一个测试用例的集合,被指定来完成一个特定的测试目标。它可以被设计来测试一个函数,一个模块,或者是执行一个类型的测试,例如验收测试(Release Acceptance Test )。
在WAF框架模型中,测试数据是以标签的形式存放在XML文件中,每个标签对应一个测试数据,这样在一个独立的XML文件中可以对应多个测试用例,可以将XML文件看成是多个测试用例的集合。下面是对于一个XML文件的描述:
……….
测试数据1
测试数据2
………..
测试数据n
……………..
2.7 测试件配置文件
TESTWARE配置文件记录执行测试件(testware)的一些基本配置项。包括文件目录,数据目录,测试组合目录,log目录以及一些服务的配置等。
2.8 测试结果
WAF在执行完一个测试后产生三种类型的测试结果,日志文件,报告和相应的测试过程数据。
2.9 利用WAF进行自动化测试开发流程
运行一个使用WAF开发的TESTWARE时,主程序被执行。它初始化测试环境,解析配置文件,启动数据驱动引擎(Data-driven engine)。
进行测试时数据驱动引擎调用XML文件,解析文件中的标签,通过资源定位符定位到XML文件中的设计好的测试用例(或者测试组合),根据解析的结果调用函数库中相应的功能函数(lib),并通过测试數据来对相应的应用程序执行测试。最后将测试结果返回给主程序输出。
3WAF在软件测试应用中的实现
当决定把数据驱动的自动化测试框架应用于一个具体的项目,首先要确定所有的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 the 3rd International Conference on Quality Software,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,WickburgH.A method for Built-in Tests in Component-based Software Maintenance[C].Amsterdam, Netherlands:Proceedings of the Third European Conferenceon Software Maintenance and Reengineering,1999.
[11] Dustin E.軟件自动化测试:引入、管理与实施[M].北京:电子工业出版社,2003.