【PHP开源代码栏目提醒】:网学会员为广大网友收集整理了,Octopus自动化工具设计 - 其它资料,希望对大家有所帮助!
测试自动化工具 Octopus 框架设计 作 者 赵椿玉 日 期 2011 年 10 月 版 本 初稿 摘要 本自动化工具主要用于质量部软件测试工作。
辅助系统功能测试进行自动化执行,快速实现自动化测试用例,减少测试回归成本,提高工作效率。
也可用于开发人员进行本地系统自测,提高开发人员自测效率。
本
论文主要针对自动化工具的需求分析,系统设计,实现等方面进行论述。
结合
开源框架 Selenium 和 Servlet 技术,使用 MySQL,通过 Selenium Grid 进行远程请求服务器, 实现任务分发和执行, 使用资源池人工分发实现用例并发执行,动态生成测试结果和记录系统日志,形成 B/S 架构的自动化测试工具 Octopus。
主要特点:系统轻量, 不需要安装客户端, 通过网站访问,新增和修改测试用例,启动用例执行。
测试用例统一使用 xml 格式编写,在执行过程进行数据解析,生成命令,对象,操作属性列表,顺序执行。
通过 Selenium 原理操作 JS 页面,实现测试用例自动执行,并实时生成测试报告。
适用情况: 1、 公司系统中稳定的核心模块,在系统更新后需要进行核心业务确认,避 免因为更新操作影响核心业务造成不必要的损失。
2、 新开发的软件功能,需要定义好操作对象的属性,操作步骤,即可进行 测试用例设计。
即可实现自动化测试,提高工作效率,缩短测试时间, 提高回归覆盖率。
3、 对系统
代码更新的情况,在测试阶段无法估计影响范围,使用全业务自 动化回归,实现最大范围的覆盖,降低因
代码更新而造成其他业务功能 失败。
4、 实现系统每日构建。
根据测试报告,分析评估更新影响范围。
快速发现 bug。
保证已有业务功能正常。
本文首先是对目前国内主流自动化情况进行分析,总结优缺点,针对分析结果,提出解决方案,并形成此系统设想。
接下来根据公司业务现状,内部需求设计实现方案, 进行项目规划。
然后是根据规划进行系统实现, 达到系统预期效果。
最后归纳总结,结合本系统实现后的情况进行进一步优化设想和进一步的猜想。
关键字:Octopus,自动化测试,Selenium,B/S 架构 目录第一章 绪 论 ....................................................................................................................5第二章 需求分析 ........................................................................................................... 16第三章 系统设计 ........................................................................................................... 27第四章 系统设计实现................................................................................................... 44第五章 总结和展望 ....................................................................................................... 55致 谢 ................................................................................................................................ 57参考文献.......................................................................................................................... 58 4 第一章 绪 论1.1 背景1.1.1 公司背景简介 本公司属于第三方支付公司,主要业务是进行网上支付交易,为商家和消费者提供专业电子支付解决方案和服务。
因此系统每天将会产生大量交易数据,涉及资金交易等敏感数据,为了满足客户的需求,新业务开放,bug 修改以及各银行系统的升级。
每天会定时对系统进行更新,必须保证系统更新不会对系统核心业务造成影响,保证客户资金安全,交易正常。
不能因更新或系统缺陷对交易过程,资金等造成任何损失。
1.1.2 自动化需求来源 随着计算机技术的发展软件在整个社会生活中的重要性变得越来越高软件测试的重要性亦随之变得日益突出.在传统手工测试已不能满足软件测试需要的情况下自动化测试技术孕育而生.软件自动化测试就是希望能够通过辅助工具或其它方法让测试按照预定计划自动进行从而达到减轻手工测试劳动量、提高软件质量的目的.。
而公司的每日更新操作,必须对系统已有业务进行完全回归,保证业务不受影响,在业务功能不断增加,测试资源缺乏,回归测试枯燥的情况,开展自动化测试工作成为必然的趋势。
1.1.3 自动化测试优势 简要说明自动化测试的优势,以充分的理由阐述,自动化测试工作是解决手工软件测试的最好解决方案。
也是支付行业,涉及敏感数据软件必不可少的一项技术。
1、自动化提高测试质量 每一次版本的更新,都会对系统产生一定的影响,自动化测试能节省大量的重复手工操作,保证测试用例的一致性,避免了人为因素的干扰。
从而提高软件测试的质量。
2、自动化提高测试效率,缩短工作时间 对于大规模的软件系统,上千上万个功能点,如果进行人工测试非常耗时间,对于繁琐的测试,测试效率必然会相当低下,而自动化测试可以较好的执行频繁的测试用例,合理利用测试工具,减轻测试工程师的手工测试工作,有效的保证测试质量并缩短测试时间。
3、提高覆盖率 自动化执行,大大缩短的测试时间,于此同时,可以进行更多的测试用例, 5保证能覆盖的功能点都能进行覆盖,提高覆盖率。
4、更好的重现软件缺陷的能力 自动化测试脚本的一致性和可重复性,而这种一致性人工很难做到,自动化用例脚本的一致性就能更好的发现和定位缺陷。
5、更好的利用资源 理想的自动化测试能够按照计划完全自动化地运行,所以在夜间执行自动化测试,次日查看测试报告,能更好的节约和利用资源。
6、保证核心业务交易正常 对于支付行业来说,核心业务随时都有客户使用,所以核心业务必须时刻正常运行,自动化测试能最大粒度的保证核心业务的正常运行,也保证系统的稳定性。
1.1.4 自动化测试误区 自动化测试工作的开展,也不能解决所有问题,自动化测试只是测试的一种辅助手段,需要明确自动化测试如下几点,才能更好的开展自动化工作,确保领导和相关人员对自动化测试正确理解和合理期望。
1、工具是万能的 自动化工具并不是万能的,不可能完成所有的测试工作,自动化工具也不能自动生成测试用例。
在前期,测试用例设计,测试脚本设计,后期的测试结果分析,这些都是需要人工主导。
自动化测试永远不能代替手工测试。
2、一种工具可以用于所有的测试 每种工具都可能适用于特定的环境,适用于不同的测试对象,一种工具是不可能覆盖所有的测试需求,一般情况下,需要利用多种测试工具,或者开发适用于本业务的自动化测试框架才能达到自动化测试的目的。
3、能使工作量大幅度减少 自动化测试工具是不会马上减少测试工作,相反,在大多数情况下,前期投入是非常的大,只有合理运用自动化工具,并得到一定积累,才能有效的减少对整个自动化工作的时间投入。
4、实现 100覆盖 自动化工具是不能 100覆盖测试用例,不是所有的测试都可以适用自动化实现,例如,开发周期很短,回归次数很少。
也不是所有的测试用例都能使用自动化实现,例如:验证码、声控、光学等。
5、自动化工具容易使用 自动化测试不可能通过简单的录制回放就能达到自动化测试效果的。
必须考虑捕捉的操作是否正确,是否能适用于回放,测试数据的动态变化,测试结果的统计,以及脚本编辑是否合理都会影响到测试结果。
一个简单上手的测试工具,工具本身必然强大。
而强大的测试工具,需要投入更多的技能,更多的培训。
6、自动化测试能发现大量的新缺陷 自动化测试主要用于保证系统正常业务不受影响,反复执行已有的测试用例,所以只能发现原来的缺陷,自动化测试常用于回归测试,而大量的新业务,未形成自动化测试脚本的业务还必须得依赖手工测试。
61.2 软件测试自动化基本概念 自动化测试就是通过测试工具或者其他手段,能够按照预定计划对软件系统进行自动化的测试,它是软件测试的一个重要组成部分,能够完成许多手工测试无法完成或者难以实现的一些测试工作。
自动化测试是相对于手工测试而言的,是通过工具执行测试用例。
所以称之为自动化测试。
软件测试自动化涉及到测试流程,测试体系,自动化编译,自动化测试等多方面的整合。
1.2.1 自动化测试适用场景 开展自动化测试工作必须先明确适用环境,适用对象,不是所有的测试都有必要实现自动化测试。
自动化测试适用于功能趋于稳定,并且可能会存在多次回归测试的情况下。
自动化测试适用场景 1、项目大于 3 个月,资源有余。
2、界面功能趋于稳定。
3、人工无法完成的大数据量测试。
4、系统执行有明确的预期结果。
5、系统人机交互界面能被工具识别。
6、稳定核心业务的回归测试。
7、资源满足(工具,技术,人员)。
1.2.2 自动化测试命门 自动化测试的命门:维护成本 我们可以用一个公式来计算自动化测试的实施成本: 自动化实施成本前期的开发成本后期的维护成本 前期开发成本基本趋于稳定,可以预估。
后期维护成本,因变更的不确定性。
则无法预估。
所以最大的成本在后期维护。
主要有两个方面:1. 产品的变更引起自动化测试脚本的变更 UI 自动化测试最常见的问题就是页面的变更,因为 UI 自动化测试脚本的内容是依赖于产品界面的,如果界面变化,将必须进行脚本维护。
2. 运行环境的随机事件引起脚本健壮性的问题 支付行业系统均与银行系统有关,如果银行系统发生变化,自动化脚本就可能需要维护。
在 B/S 架构的 UI 自动化测试中,主要不确定因素有: 运行环境中其他因素的干扰,如银行响应超时,Web 页面的展现速度, 从而导致脚本的超时错误。
浏览器版本的影响,升级后可能造成页面元素不识别问题。
浏览器弹出框的影响。
Web Server 的性能不稳定导致的问题。
71.2.3 自动化测试与手工测试比较 I 对于已经稳定系统 自动化测试的意义在于保证产品的稳定性,而手工测试则是在产品稳定满足的基础上,负责验证容错性,安全性等非核心功能,两者各司其职,互补长短。
II 对于开发中的系统 自动化测试主要保证已有系统功能的正确性,每次集成后的回归测试,及需要大数据量或者大量重复测试的部分。
而对于新开发的功能需要进行手工测试,保证正确性后才能进行自动化设计。
1.2.4 测试自动化开展流程 对于公司级别的自动化工作,开展流程如下图所示: 自动化测 脚本验收 试需求 通过 多次回归 未通过 自动化可行性 Y 测试用例设计 自动化脚本设计 自动化执行及维护 N 结束 图 1-1 自动化测试开展流程 测试人员提出自动化需求,自动化开发人员根据自动化测试适用场景评估自动化可行性。
如果可行则由测试人员设计测试用例,通过评审后,进行自动化脚本开发。
开发完成后,测试人员验收,验收通过后投入使用。
如不满足自动化测试可行性,则不进行开发,结束流程。
1.3 相关技术简介1.3.1 Selenium Selenium 是一款基于 Web 应用程序的
开源测试工具。
Selenium 测试直接运行在浏览器中,就像真正的用户在操作一样。
它支持 GoogleChrome、 Opera、Firefox、IE、Mozilla 等众多浏览器。
它同时支持 JAVA、C、Ruby、Python、
PHP、Perl等众多的主流语言。
特点:
开源、轻量 运行在多种浏览器中 8 简单灵活、支持很多种语言 IED 提供录制功能 灵活性高 高速1.3.2 Selenium Grid Selenium 的插件,提供多种执行机制。
允许同时并行地、在不同的环境上运行多个测试任务,极大地加快 Web 应用的功能测试。
实现原理如下图所示: 图 1-2 Selenium Gird 实现原理(资料来源:http://seleniumhq.org/) Selenium Grid 是提供了一个 Hub,类似于一个用于控制测试的远程控制器,但以显式地将测试请求发送到一个或多个机器上,将的某个有效的 Selenium-RC进行实例化。
这个 Selenium Hub 负责以下这些事情: 将一个 SeleniumRC 显式地分配给一个具体的测试 限制在每个 RC 最大并发测试数 将测试屏蔽在一个实际的网格结构之外。
1.3.3 其他成熟技术A、Tomcat Tomcat 是一个轻量级应用服务器, 在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试 JSP 程序的首选。
当在一台机器上配置好Apache 服务器,可利用它响应对 HTML 页面的访问请求。
实际上 Tomcat 部分是 Apache 服务器的扩展,但它是独立运行的,所以当你使用 Apache Tomcat 运 9行 tomcat 时,它实际上作为一个与 Apache 独立的进程单独运行的。
B、MySQL MySQL 是一个小型关系型数据库管理系统,是一种关联数据库管理系统,关联数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内。
这样就增加了速度并提高了灵活性。
MySQL 的 SQL“结构化查询语言”。
SQL 是用于访问数据库的最常用标准化语言。
MySQL 软件采用了 GPL (GNU 通用公共许可证)。
其体积小、速度快、总体拥有成本低,开放源码这一特点,为本次开发提供很好的数据库支持。
C、B/S B/S(Browser/Server)结构即浏览器和服务器结构。
它是随着 Internet 技术的兴起,对 C/S 结构的一种变化或者改进的结构。
在这种结构下, 用户工作界面是通过 WWW 浏览器来实现, 极少部分事务逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(Server)实现。
相对于 C/S 结构属于“胖”客户端,需要在使用者电脑上安装相应的操作软件来说, B/S结构属于一种“瘦”客户端,大多数或主要的业务逻辑都存在于服务器端。
因此,B/S 结构的系统不需要安装客户端软件,它运行在客户端的浏览器之上,系统升级或维护时只需更新服务器端软件即可,这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本(TCO) 。
1.4 结构 如下将对本文的结构进行一个简要的说明: 第一章:简介自动化发展趋势和相关技术。
第二章:对国内现有自动化框架进行简述,并分析其优缺点和使用领域。
再将结合本公司业务得出一套使用于本公司本行业的自动化框架构想。
第三章:对构想的自动化框架进行需求分析,进行详细的系统设计。
第四章:根据系统设计进行自动化框架实现。
第五章:对此自动化工具进行总结和进一步展望优化构想。
10 第二章 需求分析2.1 现状2.1.1 国内支付行业自动化现状 软件测试发展快速进行,自动化测试成为软件测试必然趋势,自动化工具也出现了很多,下面对市场主要流行的自动化工具进行说明。
1、QTP 自动化测试技术在国内也刚开始,很多小公司测试资源不足,也就没有精力投入自动化测试工作。
在测试人员充足的情况下,才会涉及到自动化测试。
自动化测试在前期投入比较大,对技术要求也比一般测试人员高。
从公司的投入和人员方面都可能会是一个瓶颈, 自动化测试覆盖范围还是比较小, 大部分公司都是处于起步阶段。
国内最流行的测试工具是 QTP 如:中国农业银行。
市场 40左右, QTP 是 QuickTest Professional 的简称,是一种自动测试工具。
使用 QTP 的目的是想用它来执行重复的手动测试, 主要是用于回归测试和测试同一软件的新版本。
因此在测试前要考虑好如何对应用程序进行测试,例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。
优点: 趋于成熟的自动化工具,入手简单,有成熟的培训机构。
支持录制回放功能。
功能强大,使用于多种系统。
缺点: 一个脚本只支持相同环境下回放功能。
很难满足兼容性测试。
需要安装庞大的客户端,必须在指定环境下运行。
采用对象识别方式,对象识别的支持还是有些欠缺。
维护成本大,需要专业维护。
工具价格昂贵。
2、TestComplete TestComplete 一款自动化工具,价钱便宜,支持 web 测试,如用友,市场10左右3、Selenium Selenium
开源自动化工具,如:支付宝 市场 20左右。
关于此工具的介绍,请查看 1.3.14、其他 如 Rational,E-Test Suite,Watir,WebKing,Tellurium 等适用于不同的系统的自动化框架。
在此就不做详细介绍。
112.1.2 第三方支付产品特点 第三方支付行业与项目类系统有很大的不同,系统已经投入使用,主要是新功能开发和线上系统维护。
主要特点: 1、更新频繁 为满足客户需求,和各银行接口的变动,新功能上线, 已有系统 bug 修改等。
所以需要对系统进行频繁的更新操作,每天均有上线操作,进行系统更新。
2、快速响应: 市场需求必须在最短时间内响应, 银行系统切换等, 在不影响交易的情况下,必须进行快速响应。
满足市场需求,也需要快速实现需要功能,这样才能更好的占有市场。
3、安全性: 主要是涉及大量敏感数据,需保证数据安全性。
4、正确性: 涉及客户资金交易,必须保证交易过程的正确性。
5、兼容性 涉及多浏览器,主流 IE6IE7IE8Firefox,必须保证市场主流浏览器能正常使用,满足不同环境需求。
2.1.3 第三方支付自动化需求 自动化需求完全来源于第三方支付的特点。
1、频繁更新,只要
代码发生改变,就可能会影响其他
代码,所以更新后必须对已有业务进行回归测试,保证已有业务不受影响。
一旦影响了其他业务,可能会造成不可预知的后果和巨大的损失。
2、市场需求需要在最短时间内响应。
当市场需求急迫的情况下,进行人工回归会占用大量的资源,一旦市场需求功能实现,将会快速上线。
为保证线上已有系统正常,必须进行自动化测试。
3、涉及大量敏感数据,交易金额等。
系统每次更新就需要保证业务正常,交易金额正确。
由于人为操作失误导致的金额验证错误或者测试遗漏时而发生。
而自动化测试将对需要校验的金额进行有效的验证,通过自动脚本执行来屏蔽人为操作风险。
4、涉及多系统多浏览器兼容,系统本身业务较多,回归工作量很大,对多系统多浏览器的回归测试更是枯燥和漫长。
而自动化测试可以很好的解决此问题。
2.1.4 本公司自动化系统目标 现状: 公司的自动化测试工作为初级阶段,投入资源不足,对自动化测试了解的也不够深入。
对自动化测试带来的效益没有明确的数字衡量,所以只能从探索阶段进行。
12 自动化目标:快捷、轻量、兼容性、方便。
快捷:实现快速执行和脚本快速开发及维护。
实现测试用例快捷,因系统本身更新频繁,所以对自动化测试用例的维护必须快速响应。
因涉及到交易,在服务器切换时,需要在指定时间内完成所有关键业务的自动化执行,避免长时间系统维护。
轻量:自动化工具执行效率高,工具本身资源利用低。
兼容性:B/S 系统必须满足 Web 端的正常使用,满足不同操作系统下不同浏览器的正常运行。
所以兼容性是必不可少。
工具实现的自动化脚本需要在多环境下能回放。
方便:使用和维护方便。
前期自动化测试工作,不会投入太多的人力和技术,要推广自动化必须在现有测试人员可培训技术的基础上进行实现。
工具不需要复杂的操作或者培训,即可让大部分人员使用该系统执行自动化测试。
2.2 自动化框架模型形成 要实现测试自动化,光靠自动化工具简单的录制回放是不行的,需要搭建一个实用的测试自动化框架,以下是经过分析形成公司测试自动化框架的过程。
2.2.1 自动化系统需求 根据上述目标和支付行业的特性,现有产品内工.