脚本编辑是否合理都会影响到测试结果。
一个简单上手的测试工具,工具本身必然强大。
而强大的测试工具,需要投入更多的技能,更多的培训。
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 自动化系统需求 根据上述目标和支付行业的特性,现有产品内工.
上一篇:
EPICS控制系统中的callback机制
下一篇:
对网络营销的渠道策略分析研究