自动化测试

软件测试的自动化
收藏
0 有用+1
0
一般是指 软件测试 的自动化,软件测试就是在预设条件下 运行系统 应用程序 ,评估运行结果,预先条件应包括正常条件和异常条件。
中文名
自动化测试
外文名
Test
定    义
人为驱动测试为转为机器执行过程
应    用
软件测试 的自动化
工    具
QTP

定义

播报
编辑
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了 测试用例 并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。

工具介绍

播报
编辑

QTP

全名HP QuickTest Professional software,2012年12月6日发布11.5版本,并更名为 Unified Functional Testing。
QTP 是quicktest Professional的简称,是一种 自动测试工具 。使用QTP的目的是想用它来执行重复的 手动测试 ,主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对 应用程序 进行测试,例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。
QuickTest针对的是GUI应用程序,包括传统的Windows应用程序,以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。其中包括:创建测试、插入 检查点 、检验数据、增强测试、 运行测试 分析结果 和维护测试等方面。

WinRunner

Mercury Interactive公司的 WinRunner 是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的 工作效率 和质量,确保跨平台的、复杂的企业级应用无故障发布及长期 稳定运行
企业级应用可能包括Web应用系统, ERP系统 ,CRM系统等等。这些系统在发布之前,升级之后都要经过测试,确保所有功能都能正常运行,没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统,是每个公司都会面临的问题。

Rational Robot

是业界最顶尖的功能测试工具,它甚至可以在测试人员学习高级 脚本技术 之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational Test Manager上,在这里测试人员可以计划、组织、执行、管理和报告所有测试活动,包括手动 测试报告 。这种测试和管理的双重功能是自动化测试的理想开始。

AdventNet QEngine

AdventNet QEngine是一个应用广泛且独立于平台的自动化 软件测试工具 ,可用于Web功能测试、web性能测试、 Java 应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用 HTML 、JSP、ASP、 .NET PHP JavaScript /VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发,因此便于移植和提供多平台支持。

SilkTest

是业界领先的、用于对企业级应用进行功能测试的产品,可用于测试Web、Java或是传统的 C/S结构 SilkTest 提供了许多功能,使用户能够高效率地进行软件自动化测试。这些功能包括:测试的计划和管理;直接的数据库访问及校验;灵活、强大的4Test 脚本语言 ,内置的恢复系统(Recovery System);以及具有使用同一套脚本进行 跨平台 、跨浏览器和技术进行测试的能力。

QA Run

QARun 的测试实现方式是通过鼠标移动、键盘点击操作被测应用,即而得到相应的测试脚本,对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的 功能点 进行 基线值 的建立,换句话说就是在插入检查点的同时建立 期望值 。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常,检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同。

Test Partner

是一个自动化的功能测试工具,它专为测试基于 微软 、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试,用户可以调用 VBA 的所有功能,并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化 导航器 来快速创建测试并执行。通过可视的导航器录制并回放测试,每一个测试都将被展示为 树状结构 ,以清楚地显现测试通过应用的路径。

Holodeck

-强大的故障植入软件测试工具
Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry , piece of data read or written.

Telelogic TAU

TAU第二代包含三个最新的、最强大的技术用来加速大规模 软件开发 和测试: 统一建模语言 (UML)及它的许多最新修订版本中的特性,UML2.0;功能强大的 测试语言 TTCN-3 和新的构造系统的方法:Model Driven Architecture( 模型驱动 构架)。这三个新的业界标准结合成TAU的已经过认可的 软件开发平台 ,形成了一个系统,一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软件开发解决方案的一个突破,它把业界从使用了太长时间的手工、易出错、以代码为中心的方法中释放出来,自然而然地迈向下一步,一个更加可视化、自动化及可靠的开发方法。Telelogic TAU/Tester是基于通用测试语言TTCN-3,用于自动化的系统和 集成测试 的强大工具。TAU/Tester以现代化的 开发工具 为基础,提供高层测试功能,支持整个测试 生命周期 ,加速自动化测试。TAU/Tester可使用户特别关注于测试的开发,因为TTCN-3语言是独立于开发语言或 测试设备 的,且是抽象和可移植的。

AutoRunner

AutoRunner 黑盒 测试工具,可以用来完成功能测试、回归测试,可以提高测试效率,降低测试 人工成本
产品可以对以下类型对象进行GUI功能性测试:
1 Windows类型对象,一般为用C++/Delphi/VB/VFP/PB/.NetForm等 技术开发 的桌面程序。
2 IE网页对象,一般性的网站,比如大的门户类网站。
3 Java对象,一般为用AWT/Swing/SWT等技术开发的桌面程序。
4 Flex对象,网页的内容是用Flex开发的。
5 Silverlight对象,网页的内容是用Silverlight开发的。
6 WPF 对象,一般为用WPF技术开发的桌面程序。
7 QT对象,一般为用QT技术开发的桌面程序。

Phoenix Framework

Phoenix Framework 是一款基于 Selenium ,Webdriver,autoIt研发的一款集 资源管理 和测试于一体的Web自动化测试工具。最新版本是1.1.8,该工具支持无脚本执行模式, 无人值守 执行模式,自由定制模式。不仅执行模式可以定制, 功能模块 也支持定制。使用该工具的界面创建 用例 ,组装脚本,启动执行。使用该工具其他开放的接口,可手动创建脚本,组装并执行。它支持两种部署模式,第一种是Server-Client方式,Server与Client均为EXE程序, 通信协议 是Socket;另一种是WEB版部署,方便与现有 系统集成 ,支持 Linux ,将Server与Client放到Tomcat或Weblogic服务器下部署,通信协议为Http,通过WEB页面控制并监控Client端的执行。

前提条件

播报
编辑
实施自动化测试之前需要对 软件开发 过程进行分析,以观察其是否适合使用自动化测试。通常需要同时满足以下条件:
1) 需求变动 不频繁
测试脚本 的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新 测试用例 以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。
项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用 手工测试
2) 项目周期 足够长
自动化测试需求的确定、 自动化测试框架 的设计、 测试脚本 的编写与调试均需要相当长的时间来完成,这样的过程本身就是一个 测试软件 的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。
3) 自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化 测试脚本 ,但是脚本的重复 使用率 很低,致使其间所耗费的成本大于所创造的 经济价值 ,自动化测试便成为了测试人员的练手之作,而并非是真正可产生效益的测试手段了。
另外,在 手工测试 无法完成,需要投入大量时间与人力时也需要考虑引入自动化测试。比如 性能测试 配置测试 、大数据量输入测试等。

适用场合

播报
编辑
通常适合于 软件测试 自动化的场合:
(1) 回归测试 ,重复单一的 数据录入 或是击键等测试操作造成了不必要的时间浪费和人力浪费;
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;
(3)采用自动化测试工具有利于 测试报告 文档的生成和版本的 连贯性
(4)自动化工具能够确定 测试用例 的覆盖路径,确定测试用例集对程序逻辑流程和控制流程的覆盖。
随着测试流程的不断规范以及软件测试技术的进一步细化,软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率,正是本期所要讨论的话题。
软件测试 自动化的研究领域主要集中在软件测试流程的自动化管理以及 动态测试 的自动化(如 单元测试 、功能测试以及性能方面)。在这两个领域,与 手工测试 相比,测试自动化的优势是明显的。首先自动化测试可以提高测试效率,使测试人员更加专注于新的测试模块的建立和开发,从而提高 测试覆盖率 ;其次,自动化测试更便于测试资产的 数字化管理 ,使得测试资产在整个测试 生命周期 内可以得到复用,这个特点在功能测试和 回归测试 中尤其具有意义;此外,测试流程自动化管理可以使机构的测试活动开展更加过程化,这很符合 CMMI 过程改进 的思想。根据OppenheimerFunds的调查,在2001年前后的3年中,全球范围内由于采用了测试自动化手段所实现的 投资回报率 高达1500%。

选型原则

播报
编辑
然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然,任何一种产品化的测试自动化工具,都可能存在与某具体项目不甚贴切的地方。再加上,在企业内部通常存在许多不同种类的应用平台,应用开发技术也不尽相同,甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之间存在技术差异。所以选择 软件测试 自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。
以下笔者给出企业用户进行 软件测试 自动化方案选型的参考性原则,这些原则是从笔者实际工作中凝练而成的,它包括以下六个方面的建议:
●选择尽可能少的自动化产品覆盖尽可能多的平台,以降低产品投资和团队的学习成本;
●测试流程 管理自动化 通常应该优先考虑,以满足为企业测试团队提供流程 管理支持 的需求;
●在投资有限的情况下, 性能测试 自动化产品将优先于功能测试自动化被考虑;
●在考虑产品性价比的同时,应充分关注产品的支持服务和售后服务的完善性;
●尽量选择趋于主流的产品,以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;
●应对测试自动化方案的 可扩展性 提出要求,以满足企业不断发展的技术和业务需求。

过程

播报
编辑
自动化测试与 软件开发 过程从本质上来讲是一样的,无非是利用自动化 测试工具 (相当于 软件开发工具 ),经过对测试需求的分析( 软件过程 中的 需求分析 ),设计出自动化 测试用例 (软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的 概要设计 ),设计与编写自动化脚本( 详细设计 与编码), 测试脚本 的正确性,从而完成该套测试脚本(即主要功能为测试的应用软件)。
1) 自动化测试 需求分析
当测试项目满足了自动化的前提条件,并确定在该项目中需要使用自动化测试时,我们便开始进行自动化测试 需求分析 。此过程需要确定自动化测试的范围以及相应的 测试用例 测试数据 ,并形成详细的文档,以便于 自动化测试框架 的建立。
2) 自动化测试框架 的搭建。
所谓自动化测试框架便是像 软件架构 一般,定义了在使用该套脚本时需要调用哪些文件、结构,调用的过程,以及 文件结构 如何划分。
而根据自动化 测试用例 ,我们很容易能够定位出 自动化测试框架 的典型要素:
a. 公用的对象。
不同的 测试用例 会有一些相同的对象被重复使用,比如窗口、按钮、页面等。这些公用的对象可被抽取出来,在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时,只需要修改该 对象属性 即可,而无需修改所有相关的 测试脚本
b. 公用的环境。
测试用例 也会用到相同的 测试环境 ,将该测试环境独立封装,在各个测试用例中灵活调用,也能增强脚本的 可维护性
c. 公用的方法。
当测试工具没有需要的方法时,而该方法又会被经常使用,我们便需要自己编写该方法,以方便脚本的调用。
d. 测试数据。
也许一个 测试用例 需要执行很多个测试数据,我们便可将测试数据放在一个独立的文件中,由 测试脚本 执行到该 用例 时读取 数据文件 ,从而达到数据覆盖的目的。
在该框架中需要将这些典型要素考虑进去,在 测试用例 中抽取出公用的元素放入已定义的文件,设定好调用的过程。

脚本编写

播报
编辑
该编写过程便是具体的 测试用例 的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为,以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

测试运行

播报
编辑
事实上,当每一个 测试用例 所形成的脚本通过测试后,并不意味着执行多个甚至所有的测试用例就不会出错。 输入数据 以及 测试环境 的改变,都会导致测试结果受到影响甚至失败。而如果只是一个个执行 测试用例 ,也仅能被称作是半自动化测试,这会极大的影响自动化测试的效率,甚至不能满足夜间自动执行的特殊要求。
因此,脚本的测试与试运行极为重要,它需要详查多个脚本不能依计划执行的原因,并保证其得到修复。同时他也需要经过多轮的脚本试运行,以保证测试结果得一致性与 精确性
自动化测试引入的原因是就把 软件测试 人员从枯燥乏味的机械性 手工测试 劳动中解放出来,以自动化 测试工具 取而代之,使测试人员的精力真正花在提高软件 产品质量 本身。

注意事项

播报
编辑
首先,一个企业实施测试自动化,绝对不是拍脑袋说干就能干好的,它不仅涉及 测试工作 本身流程上、 组织结构 上的调整与改进,甚至也包括需求、设计、开发、维护及 配置管理 等其他方面的配合。如果对这些必要的因素没有考虑周全的话,必然在 实施过程 中处处碰壁,既定的 实施方案 也无法开展。其次,尽管自动化测试可以降低人工测试的工作量,但并不能完全取代 手工测试 。100%的自动化测试只是一个理想目标,根据笔者的经验,即便一些如 SAP Oracle ERP 等测试库规划十分完善的套件,其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次,实施测试自动化需要企业有相对规模的投入,对企业运作来说,投入 回报率 将是决定是否实施 软件测试 自动化的最终 指挥棒 ,笔者建议企业在决定实施软件测试自动化之前,必须要做量化的 投资回报 分析。此外,实施 软件测试 自动化并不意味着必须采购强大的自动化 软件测试工具 或自动化管理平台,毕竟 软件质量 的保证不是依靠产品或技术,更多的因素在于高素质的人员和合理有效的流程。

实战模拟

播报
编辑

背景介绍

A公司是一家大型保险公司,拥有近20个城市的分公司,并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右(新 业务系统 和原有业务系统的主要版本发布)。A公司的专职测试团队人数不足30人而且测试团队的测试人员技能参差不齐测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段,主要依靠 手工测试 。由于已上线 应用系统 的问题,开发团队必须分出一部分资源去维护和修复上线应用,而同时测试团队的测试成果和效率却无法和这些应用质量挂钩,也更 无从谈起 软件质量 的控制。所以,A公司决定在 软件质量 和测试方面进行投入,他们考虑以下几方面:
●引进 软件测试 流程管理 的自动化,提高软件 测试过程 的管理水平,使软件测试和 软件开发 一样可被评估、被衡量。
●实现 性能测试 自动化,所有应用上线之前必须有应用性能 风险评估报告 和相关部门的确认。
●逐步实现功能测试的自动化,在目前人员配置的情况下,把部分 手工测试 变成自动化测试,提高测试 可信度 ,降低 人为错误
●通过 软件测试 自动化,管理软件测试中的案例、缺陷、报告等资产,进一步提升软件测试的效率并建立测试基础库。
●在规划中,将来的2~3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。

系统的情况

由于保险公司的业务种类繁多,同时在经过了几十年的经营后,公司内的应用系统从早期的终端方式到现代的J2EE和 .NET 等应有尽有,鱼龙混杂。IT部门已经建立的3年规划,即在未来的3年时间内将所有终端和 C/S 方式的应用转换成 B/S架构 ,但当前仍然需要对这些旧应用系统进行维护,以保证业务的顺利进行。对于开发部门来说,新应用开发基本上已经以B/S架构为主,主要是基于J2EE架构的Web HTTP 应用和部分Window.NETForm的应用。

公司现状

企业机构在做测试自动化 选型 时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定,缺乏实事求是的 理性思考
测试部门仅负责 系统测试 和对用户验证测试进行管理,对于之前的 单元测试 集成测试 主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段,测试部门也无法收集和确定 集成测试 单元测试 的完成情况,在整个 软件测试 过程中,业务需求是由开发部门通过RationalRequisitePro进行管理,但测试需求尚没有提出要求, 测试案例 主要通过在公司公用的 文件服务器 中的目录 管理方式 管理,对测试中缺陷流程等管理主要依靠邮件的流转进行处理90%以上的测试是通过 Excel 和Word等测试案例文档来完成,测试人员对 软件测试 自动化的认识仅停留在“记录+回放”的认识上。

方案

方案A:A公司可以采用美科利(Mercury)公司产品为主的 软件测试 自动化方案。
●依照原先的邮件流转过程配置 TestDirector 缺陷管理流程,为每个 保险业务 的开发小组和测试团队分配相应的用户许可证,取消原有邮件方式。
●部署MercuryQuickTestProfessional,以便完成 应用程序 相关功能测试。
●部署MercuryLoad-Runner。从测试团队中分化出专职的 性能测试 自动化工程师 和小组,和 业务部门 协调,建立A公司应用系统上线 性能指标 ,通过LoadRunner给出 测试指标
●建议A公司成立专门的质量控制部门,对 TestDirector 中的数据定期进行分析,建立相关 质量模型 ,以便于 企业量化管理 过程改进
方案B:A公司也可以采用 IBM Rational 产品为主的软件测试自动化方案。
●采用RationalTestmanager来进行整个测试流程的管理,为相关开发和测试小组成员分配相应权限,改变以前通过邮件以及Word、Excel 文档管理 测试的工作方式。
●部署RationalRobot,用它来完成功能相关的测试工作以及新版本发布时的 冒烟测试 。此外,RationalRobot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。
●部署RationalPurifyplus,使测试工作前移到 开发阶段 。由于Purifyplus能较好地支持 白盒测试 编程人员 在编码阶段引入的错误能尽早被检测到,这大幅降低了后期测试的开销。
●建议A公司成立专门的质量控制部门,对Testmanager中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。
方案C:A公司也可以采用 开源软件 为主的 软件测试 自动化方案。
●采用 Bugzilla 来进行Bug 跟踪管理 ,采用Bugzilla TestRunner 进行 测试用例 管理,采用 CVS 进行测试资源的 配置管理
●采用MaxQ和WebInject对 B/S结构 的应用系统进行功能测试。
●采用DBMonster、Open-STA、LoadSim进行性能相关测试。
●可采用Xunit架构的 开源工具 对不同语言的 程序单元 进行 单元测试
●建议A公司成立专门的开源 软件维护 小组,以解决可能会碰到的工具维护工作。
●建议A公司成立专门的质量控制部门,对 Bugzilla TestRunner CVS 中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。

方案评价

由于不同客户在 组织架构 、员工素质以及流程管理水平等方面的不同,我们很难用一个实例、一两句话来说明不同解决方案的 适用性 。在上面的例子中,笔者给出了3种可行的方案,具体选择哪一个,需要仔细权衡。这里笔者给出 一般性 的意见,对于不想受制于某个测试自动化厂家的企业, 开源 绝对是一个理想的选择。此外,它不需要支付成本,工具的 源代码 可以随意修改,因而具有较好的灵活性。但开源工具的弊端也是明显的:缺乏使用培训和 技术支持 ,工具的 用户界面 一般也较为粗糙。而对于那些比较看重培训和售后支持的企业,笔者建议选择IBMRational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用,但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好,笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法,不妨来信交流。