摘 要 根据Web自动化测试的特性，提出了一种基于数据驱动测试方法的开源Web自动化测试框架，并着重描述了其数据驱动文" />
免费阅读期刊
论文发表、论文指导
周一至周五
9：00&22：00
Web自动化测试框架的研究
　　摘 要 根据Web自动化测试的特性，提出了一种基于数据驱动测试方法的开源Web自动化测试框架，并着重描述了其数据驱动文件的设计。实践表明，该框架测试门槛低，独立性强，效率高等优点。 中国论文网 /8/view-4299321.htm　　关键词 Web；自动化测试；测试框架；数据驱动 　　中图分类号：TP311 文献标识码：A 文章编号：（0-00 　　随着Web应用的日渐庞大和复杂，Web应用的测试越来越得到人们的重视，同时对Web应用的测试的要求也更高。研究表明，一种良好的自动化测试技术可以实现许多手工测试不能完成的工作。同时，自动化测试技术大大减少了产品的发布周期和软件的测试成本，软件测试的效率和速度也有了显著的提高。所以，软件开发组织测试工作可以采用自动化测试方法，同时结合相应的测试框架进行，这样，既提高了效率，又降低了维护成本。 　　自动化测试框架是一个由假设、概念以及自动化提供支持的实践的集合。现在，许多企业和个人都认识到Web自动化测试框架的重要作用，并积极投身于其研发中，并不断有新的框架发布出来。本文中描述了几种常用的自动化测试框架，并在此基础上，研究了一种实用性强的开源Web自动化测试框架。 　　1 自动化测试的优缺点 　　自动化测试之所以得到人们重视，是应为其具有其他测试所无法替代的优点，概括一下有以下几点：1）效率高，测试时间大大减少。2）降低了测试成本，减少了开销。3）比手工测试完成的测试范围更广。4）测试可靠性、一致性和可重复性好。5）工作质量提高，资源利用好。6）软件推向市场时间更短。7）测试的复用性高。 　　尽管自动化测试有诸多优点，但在测试中仍然存在一定的局限性，具体表现如下：1）自动化测试并不适用于每种情况。2）测试的有效性并没有提高。3）自动化测试工具不具灵活性。4）对测试质量的依赖非常大。5）有时对软件开发有一定的制约。6）没有手工测试发现的缺陷多。 　　通过以上分析可知，让自动化测试完全取代手工测试是行不通的，只有将手工测试与自动化测试很好的结合在一起，才会发挥各自的优势，测试效果才会更好。 　　2 几种常用自动化测试框架 　　以下为几种常用的自动化测试框架，它是研究人员为解决脚本维护性问题而设计的。以这些自动化测试框架为基础，结合自己的经验与需求即可以设计出适合自己的自动化测试框架。 　　2.1 脚本模块化框架 　　该框架用创建的独立的小脚本代替被测试应用程序的函数和模块，采用分层的方式完成测试。脚本的实现层作为底层，测试用例的组合层作为上层。脚本模块化框架应用了封装和抽象的原则，提高了测试套件的可维护性。为掩盖应用程序的其他部分采取在一个部件前构建一个抽象层的方式完成。该框架易于掌握和精通。但因其底层脚本的实现依赖应用程序的功能，故缺乏灵活性。 　　2.2 测试库构架框架 　　测试库构架框架与脚本模块化框架很相似，只是其将应用程序分解后创建的不是脚本，而是过程和函数。被测对象的功能或模块通过创建库文件来描述，测试用例脚本直接调用这些库文件。这样，抽象度更高，测试用例组装更加灵活。 　　2.3 关键字驱动测试框架 　　该框架又叫表驱动测试框架，是一种比较理想的自动化测试框架。其测试逻辑的描述采用关键字和数据表实现。这些关键字和数据表可以用来“驱动”测试脚本代码，并独立执行测试工具，是应用程序和自动化测试框架彼此独立。这种测试方式与手工测试很像。 　　2.4 数据驱动测试框架 　　数据驱动测试框架是从特定的文件（如Excel文件、OOBC源文件、CSV文件、ADO对象文件等）中，把测试的输入和输出数据独立出来，通过变量传入测试脚本中。这些变量就是测试数据用来传递和验证应用程序的。在整个过程中，测试动作的控制（如数据文件的读取，测试信息和记录测试状态等）写进测试脚本中；测试数据不写进脚本，而只包含在数据文件中。这里，测试脚本只是一个传送数据的机制，或仅是一个“驱动”。 　　数据驱动测试框架是测试不同的输入、输出采用相同的测试过程，并将测试输入和预期输出以表的形式组织起来，一个测试作为表中一行。测试过程就是从表中逐行读入，即可实现执行每个测试输入和检验预期输出。将数据驱动测试过程以表组织在一起，执行新的测试就可以反复使用这个过程。这种测试需要执行的脚本大大的减少，大量的测试用例仅需少量的脚本就可实现，对由许多不同数据选项的应用非常有效。 　　3 开源Web自动化测试框架的研究 　　3.1 设计思路 　　本框架以开源框架Selenium为基础，进一步设计了此框架的“私有语言”，也就是数据驱动文件的编写规则。数据驱动文件的解析程序的实现就以这些“私有语言”为依据，Web应用的测试执行框架也是由这些“私有语言”和Selenium合并组成。依据这些编写规则，测试人员把数据和对Web应用的操作行为写入数据驱动文件中，测试框架负责对这些数据驱动文件进行解析，将这些解析后的数据传入并调用Selenium API的相应方法，从而使其自动执行。 　　3.2 框架结构 　　该框架是基于数据驱动的测试框架，并在其基础上进行了一些改进，开源Web自动化测试框架结构如图1所示。 　　此框架中，在Server端安装被测试Web应用，可以供远程访问，方便测试。Extended Selenium RC System作为测试执行引擎安装在Client端，它是本框架的核心，数据驱动文件解析系统是采用开源自动化测试工具Selenium开发的。它的主要功能是通过解析数据驱动文件，得到解析后数据及Web操作，而后调用Selenium API的方法，并将数据作为参数传入，这样对远程Server的操作即可实现。当Server的响应到达Client，Client进行各种元素验证，记录日志文件及保存测试结果等操作。测试工程存放在Project文件夹中，主要由若干XML数据驱动测试文件组成，在Project_Config.xml测试工程注册文件中对各种数据驱动文件完成统一的注册，然后又Extended Selenium RC System按注册的向后顺序对各XML文件依次进行解析。
　　3.3 设计数据驱动文件 　　相关操作和数据的文本文件构成了数据驱动文件。由自动化测试工具私有语言手动编写这些文件，接着对其变量赋值，并作为测试数据输入。这些变量使解析程序能通过外部的数据来驱动应用程序。软件自动化测试的一个重要环节是数据驱动文件的开发和维护。对测试文本做合理地修改和调整，可以扩大测试覆盖面，增加测试脚本灵活性，并且对被测试对象变量的应对能力大大提高。 　　本框架中，设计数据驱动文件的“私有语言”是重点，其设计包括以下几个方面。 　　3.3.1 对Web操作行为的定义 　　这一部分包括页面中数据的输入和对页面的各种操作。例如：将数据“efg”输入到页面标签中，具体设计如下： 　　
　　 　　 　　其中，方法结点用表示，表示向页面标签中输入数据。具体想哪个页面标签输入数据用表示，其中value属性可以是name或id等，表示定位关键字。具体输入哪个数据，用第二个 表示，value属性中放内容值。 　　3.3.2 验证部分 　　这部分是完成对页面标签及数据验证操作。同操作部分一样，方法结点与API的方法名称一致。例如：验证上例中页面中是否存在“efg”文本，具体设计如下： 　　
　　 　　其中与Selenium API中的isTextPresent（“”）方法相对应，表示要验证的内容结点，Value中放具体内容，本例中放的是文本“efg”。本例可以实现对页面中是否存在文本“efg”的验证。 　　3.3.3 设定测试环境 　　若Web应用要运行在不同操作系统上，就需要设计不同版本，虽内容差别不大，但若设计不同的测试工程，则工作量会大大增加。这个问题的解决，可以采取在同一数据驱动文件中写入不同版本的数据驱动文件来解决，并只需用测试环境结点加以标准区分，就可以在解析文件过程中通过操作系统类型与测试环境结点属性值得对比，来判断是否进行解析。 　　除了以上三个方面，还应对结点名称到API方法名的映射及结构等进行合理的设计，从而使数据驱动文件可控性更强，更具灵活性及更便于解释。 　　4 测试流程 　　首先将编写完的数据驱动文件添加到测试平台。接着解析数据驱动文件，实现测试脚本到执行引擎的映射。然后向Web服务器发送HTTP请求来模拟真实用户访问Web的场景，获得测试结果信息。最后，对得到的数据进行分析，得出测试报告及生成日志。 　　5 结束语 　　本文以数据驱动方法为基础，提出一种开源Web自动化测试框架，重点研究了数据驱动文件的编写规则。本测试框架可以应用不同的工程项目中，具有开发门槛低、独立性强、效率高等特点。特别适用于需要反复测试的回归测试阶段，大大提高了企业的经济效益。 　　参考文献 　　[1]赖利峰，刘强.Web应用程序的一种功能自动化测试模型与实现[J].计算机工程，）：42-44. 　　[2]朱少民.软件测试方法和技术[M].北京：清华大学出版社，2005. 　　[3]朱菊，王志坚，杨雪. 基于数据驱动的软件自动化测试框架[J].计算机技术与发展，）：68-70. 　　[4]李晓会.Web系统自动化功能测试框架研究与实践[D].北京：北京邮电大学，2011. 　　[5]樊付星，黄大庆，周未.基于Web的自动化测试框架的研究与实现[J].电子设计工程，）：36-38. 　　[6]黄侨，葛世伦.开源Web自动化测试框架的改进研究[J].科学技术与工程，）：. 　　[7]马春燕，朱怡安，陆伟.Web服务自动化测试技术[J].计算机科学，）：162-169. 　　[8]Mike K. Choosing a Test Automation Framework[S].IBMDeveloper. 　　作者简介 　　池云（1974-），女，副教授，硕士，研究方向：网络，多媒体。
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。用户名：巴巴玛玛
访问量：3624
注册日期：
阅读量：1297
阅读量：3317
阅读量：445539
阅读量：1131054
51CTO推荐博文
& 当故事看即可，只是个人看法...............& 目前在各个软件公司中基本上存在WEB和APP的对外系统，不管是电子商务、电信、新闻等基本上都有WEB和APP同时存在。对于APP个人感觉是新东西，但也觉得它就是个老东西，因为大家是否记得我们曾经装在电脑上的Application应用程序，当然一个管理软件当时就很NB了。不过现在手机上的Application和以前电脑上的Application当然不管技术上还是形态上都是不一样的，但使用上似乎是一样的，同样的下载---安装---使用。这些都是体外话题，我想说的是软件测试，当年的软件危机大爆发导致了软件测试这个职业的出现，测试中的懒人出现导致自动化测试的产生，而Application应用程序是最初的尝试产品吧。那个时候的自动化测试就是很NB的自动化测试，但现在呢，应该叫Application应用程序的UI自动化测试、接下来互联网的出现，应该出现了WEB的UI自动化测试、再接下来API技术的来临，应该出现了接口的自动化测试、这几年又出现了手机版本Application出现，然后就是APP自动化测试的出现（其实APP自动化测试按技术类型分也包含了UI(UI应该主要包含了NATIVE和WEBVIEW,还有加载中间的hybrid，我还是看好WEBVIEW的未来，哈哈。。。。)和接口。说了这么多只想说明我知道的挺多.....接下来我想说说WEB的UI自动化测试、接口自动化测试和APP的自动化测试。& WEB的UI自动化测试：&&&&很多人在说自动化测试的时候，基本上现在指的是WEB的UI自动化测试，但其实这是不对的，自动化测试包含了很多开发的技术，不只是界面上的自动化测试。WEB的UI自动化测试只是其中的一种，但它的工具确实最多的，我所知道的有WINRUNNER\QTP(UFT)\TESTCOMPLETE\SILKTEST\ROBOT\SELENIUM\RF\WAITER等等，当然最出名的是商业工具QTP和开源工具SELENIUM。现在各个公司通过开源搭建的自动化框架基本上都是以SELENIUM为底层，个人感觉SELENIUM还是非常的好的工具。而对于没有开发基础的测试人员，可以考虑QTP这个自动化工具，掌握比较快，但要学精还是需要掌握开发技术。但当你掌握了开发技术后就会放弃QTP想玩SELENIUM了。原因是QTP越做越烂了，虽然最新版本的UFT增加了API的测试，当我觉得这个更加是鸡肋，QTP这个产品在WINDOWS环境下做还可以，但是你想扩展到其他环境就麻烦了，如自动启停进程相关的操作....。工具介绍就到这吧,总体来说根据自己的需求来选择符合自己公司的工具和开发语言。接下来我说下WEB的UI自动化测试的优缺点：&&&&缺点：&&&&开发效率低、维护成本高、执行速度慢.......................几百种缺点。&&&&优点：&&&&用户操作真实性强。&接口自动化测试：&&&&接口自动化测试在后来出现，但现在大部分的互联网公司都喜欢用它作为测试工作辅助。原因很简单，UI自动化的缺点它都能进行弥补，但同时它也存在一个最大的问题：用户操作真实性不强。其实个人觉得接口自动化测试和UI自动化测试可以产生互补的测试。因为我们做接口测试时更多的是根据开发的技术进行测试HTTP\SOCKET等等（接口测试基本上不需要用到什么工具进行，如果一定需要的话建议是用SOAPUI），而非真实的进行对系统进行操作验证系统是否存在问题。&APP的自动化测试：& APP的自动化测试应该也要分为UI和接口自动化测试，接口测试与上面说的一样都是技术层面上的事情就不说了。那么还是关注APP的UI自动化测试，APP的自动化测试工具方面也有很多，但也都不成熟，我选择了APPIUM，主要考虑到的它可以进行跨平台测试，但最大的问题还是不稳定。所以也不敢大面积的布置其自动化测试用例。APP刚才说过了主要分为NATIVE和WEBVIEW，NATIVE的对象还好获取，像android可以直接使用uiautomatorviewer进行获取。而WEBVIEW就比较麻烦，不能直接获取要么就让开发提供给你，要么就直接下代码自己找，还有就是通过google的一个方法进行获取.......& 说了一下这三种技术的一些内容，其实我想说不管什么类型的自动化测试，我们测试的过程中都需要和开发进行紧密的结合，但测试优于开发的测试思想。另外这三种技术我们在实际的应用中更应该将其进行混合的测试：&&&&1、UI（WEB）自动化测试走主流程的测试、接口自动化测试走全面的测试：先布置接口的自动化测试用于测试和回归测试，特别在敏捷测试中，接口自动化测试应该占主体。后布置UI自动化测试用于住流程的回归测试。&&&&2、UI（WEB）自动化测试与APP自动化测试结合：需要一个自动化测试框架的协调，可以进行UI自动化测试到APP接口层的长流程场景自动化测试，也可以进行UI自动化测试到APPUI层的长流程场景自动化测试。&&&&3、接口自动化测试与APP自动化测试结合：其实和UI与APP自动化测试长流程的交换一样的原理，需要自动化测试框架的支撑。先进行接口测试用例的执行后进行APP的UI和接口测试的用例执行。& & 以上是我想说的这么个故事....看看就好....本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：未分类┆阅读(0)┆评论(0)