返学费网 > 培训机构 > 南京信盈达

13160092935

全国统一学习专线 8:30-21:00

自动化测试平台开发和普通自动化测试区别是什么?

1、测试效率不同
完成同等数目的测试,启动自动化速度更快,手工测试则需要消费更多的时间。但是自动化测试的脚本开发比用例开发耗时长,包括编写脚本、调试脚本、维护脚本,而手工测试虽然也要对测试用例进行撰写、评审、修订,由于用例编写更多为自然语言,时间上会少。
2、资源利用率不同
自动化测试在设备、仪表资源能够7*24小时利用,这点上手工测试没有可比性。
3、执行可靠性不同
自动化测试中可靠的按脚本执行,后续定位、复现有明确的配置路径可循,而手工测试往往会因为自己的判断导致测试出错,并且在测出来的问题上有一部分是不能复现的。但是自动化的稳定来源于其死板,而人的智慧体现在思维的跳跃,跳跃的思维也会导致后期不易定位。
4、覆盖率不同
在同等时间内,启动自动化测试能够覆盖更多的功能,而手工测试只能覆盖小部分功能。但是自动化测试适合回归测试,开发中的功能不划算。对于开发中功能,需求或者实现的更改,都会导致自动化脚本的变更,开发中的功能更适合手工测试。

自动化测试基本流程是什么?

自动化测试基本流程

1、制定测试计划

在展开自动化测试之前,最好做个测试计划,明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求,并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后,下发给用例设计者。

2、分析测试需求

用例设计者根据测试计划和需求说明书,分析测试需求,设计测试需求树,以便用例设计时能够覆盖所有的需求点。一般来讲,基于Web功能测试需要覆盖一下几个方面:

1)页面链接测试,确保各个链接正常;

2)页面控件测试,确保各个控件可靠;

3)页面功能测试,确保各项操作正常;

4)数据处理测试,确保数据显示准确、处理精确可靠;

5)模块业务逻辑测试,确保各个业务流程畅通。

3、设计测试用例

通过分析测试需求,设计出能够覆盖所有需求点的测试用例,形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行,所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时,要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据,便于脚本开发。

4、搭建测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件,添加对象。测试环境的搭建,包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等。

5、编写测试脚本

根据自动化测试用例和问题的难易程度,采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件,然后再用结构化语句控制脚本的执行,插入检查点和异常判定反馈语句,将公共普遍的功能独立成共享脚本,必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后,需要反复执行,不断调试,知道运行正常为止。脚本的编写和命名要符合管理规范,以便统一管理和维护。

6、分析测试结果、记录测试问题

应该及时分析自动化测试结果,建议测试人员每天抽出一定时间,对自动化测试结果进行分析,以便尽早地发现缺陷。如果采用开源自动化测试工具,建议对其进行二次开发,以便与测试部门选定的缺陷管理工具紧密结合。理想情况下,自动化测试案例运行失败后,自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间,确认这些自动上报的缺陷,是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复,如果不是系统缺陷,就检查自动化测试脚本或者测试环境。

7、跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去,以便定期跟踪处理。开发人员修复后,需要对此问题执行回归测试,就是重复执行一次该问题对应的较薄,执行通过则关闭,否则继续修改。如果问题的修改方案与客户达成一致,但与原来的需求有所偏离,那么在回归测试前,还需要对脚本进行必要的修改和调试。

8、自动化脚本的维护

如果系统发生变更时,对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护,以适应变更后的系统。

自动化测试难点解析:如何降低误报率?

随着自动化测试的深入推进,通过自动化测试运行的案例数量越来越多,执行错误全部由人工分析的方式已经不能满足接口自动化测试结果的分析需求。本文介绍一种基于缺陷知识库的接口自动化测试结果分析方法,通过接口测试结果模型化方法和基于错误码库、非缺陷知识库的错误归类分析方法,辅助测试人员高效实施大规模、多系统的接口自动化测试结果分析处理,降低自动化测试的误报率。

一、接口测试结果模型化
首先,我们需要将接口自动化测试的结果模型化,模型信息包括结果标志、错误码、错误信息和返回信息。在接口测试的过程中,从通讯级到应用级提取该模型数据,方法如下:

1、在平台执行接口测试的过程中,若出现任何程序未处理的内部异常,则结果标志为I,此时错误码、错误信息和返回信息均为空。

2、在常见的http通讯、tcp通讯、通讯等通讯方法中,若无法正常通讯并获得预期的返回报文,则认为在通讯级发生异常,结果标志为U,此时错误码、错误信息均为空,通讯异常的返回信息存储在返回报文中。

3、在能够正常获取返回报文的情况下,被测系统往往会返回应用级处理是否正确的信息。若应用级处理错误,则还会返回错误码和错误信息。

(1)若应用级处理正确,则结果标志为N,此时错误码、错误信息均为空,返回信息存储返回报文。

(2)若应用级处理错误,则结果标志为E,错误码、错误信息存储在返回报文中,返回信息存储在返回报文中。

(3)为保障资金安全,重要金融交易一般存在双人复核或者远程授权的过程。如缺乏授权信息,被测系统将返回“需要授权”的信息,则结果标志为A,错误码、错误信息均为空,返回信息存储在返回报文中。

4、在实际实施组织级接口测试覆盖时,一些存量系统未在公有域特定字段返回应用级处理结果。此时,自动化测试平台将进行通讯级结果判断,若正常通讯并获得预期的返回报文,则结果标志为N,此时错误码、错误信息均为空,返回信息存储在返回报文中。

二、基于错误码库、非缺陷知识库的错误归类分析方法
基于接口测试结果的模型化数据,可以通过建立错误码库和非缺陷知识库,对大规模接口回归测试的结果进一步分类、分析。对于被测应用系统,可以由用户在自动化测试平台建立错误码库,对标志为E的接口测试结果,通过以下三种匹配方式进行细分:

1、精确匹配:对于有固定错误码和错误信息的应用系统,可以采用精准匹配方式,完成错误码库与接口测试结果模型的匹配。

2、错误码模糊匹配:适用于能够从固定字段输出错误信息,但没有固定字段返回错误码或者错误码定义不规范(如错误码是中文信息)的被测系统。此类系统错误码和错误信息由测试人员自行定义,每类错误码需设计匹配表达式,通过正则匹配的方式实现错误归类。

3、返回报文模糊匹配:适用于返回错误信息无固定字段的被测系统。此类系统错误码和错误信息由测试人员自行定义,每类错误码也需对应设计对应的匹配表达式。

在接口测试中,由于被测系统配置错误、被测系统铺底数据异常等问题而出现的错误并非本次测试结果中需重点关注的内容。对于此类错误,将错误码库中的对应错误条目增加标志位,即可纳入非缺陷知识库。

三、接口测试结果归类分析方法
基于接口测试结果模型化和错误码库、非缺陷知识库,将接口测试的结果分类分析,输出概要表和错误分类表。

概要表如下:

执行错误的交易将进一步处理为错误明细表,如下:

利用该分析结果,测试人员可重点关注结果类型为“执行错误”的分类,确认为缺陷的应提交给开发人员修复。对于“执行错误非缺陷”的分类,则往往不是被测系统自身缺陷导致的报错。通过这种方法,为测试人员提供“智能”分析结果,辅助测试人员快速完成对自动化测试结果的判断和分析。

自动化测试常用工具有哪些?

自动化测试的问题我们已经探讨了很多次了,所以今天我们就给大家简单分享了在自动化测试过程中常用的一些测试工具和方法,下面java课程就一起来了解一下吧。希望通过对本文的阅读,能够提高大家对自动化测试的认识和理解。



1.带的Selenium


Selenium无疑是受欢迎的Web自动化测试工具。其开源的特性是被广泛使用的原因之一。您可以使用不同的语言在Selenium中实施各种框架,从而为自动化测试提供更多的功能。


Selenium能够支持多种操作系统(Windows、Mac、Linux)和多种浏览器(Chrome、火狐、IE和Headless类型浏览器)。我们可以运用多种语言(如Java、Groovy、Python、C#、PHP、Ruby和Perl)来开发出不同的测试脚本。


Selenium内置了许多工具和框架,您可以启用它们来进行持续测试。是Selenium用来进行持续测试的一种常用的框架。通过Robot,您可以运行各种自动化测试,包括由所提供的、基于UI元素和API的测试。


Selenium既可以使用关键字驱动的方法进行验收测试,也可以进行验收测试驱动式的开发(-,ATDD)。通过使用Python和Java所实现的附加测试库,其测试功能得到了进一步扩展。而不仅可以用于Web应用的测试,也可被用来测试Android和iOS的应用。


但是,Selenium本身并不能满足所有的持续测试需求。它需要与大量的工具相集成,以满足在软件开发生命周期(SDLC)中的不同目的。此外,Selenium还需要使用者具有高级的编程技能,并愿意花费专门的时间与精力,来构建自动化框架,以满足其特定的测试需求。


2.Testsigma


Testsigma是一个统一的、以AI驱动测试的自动化平台。它采用Shift-Left方法,将持续测试集成到了端到端的持续交付生态系统之中。Testsigma通过减少自动化测试技术中的复杂性,为功能和自动化团队带来了更多的灵活性。


功能测试人员可以轻松地使用自然语言,编写出简化的代码,来进行自动化测试。Testsigma通过可重用的步骤组合、与集中对象存储库()大限度地提高了测试代码的重用性。同时它通过使用AI,来大幅降低了与测试有关的维护开销。


Testsigma能够与各种开源的或三方工具相集成。它支持上千种不同“设备+浏览器+操作系统”组合的云端测试环境,以不断满足各种的动态测试需求。


Testsigma能为企业级的自动化测试、和持续测试提供所有必需的功能,其中包括:数据驱动测试、跨浏览器测试、可重用性测试套件、测试计划与数据管理、电子邮件与Slack通知、并行测试执行、集中对象/元素存储库、综合报告、与CI工具的集成、以及自动化Bug报告等。


作为一款基于云端的自动化测试工具,Testsigma为Web、移动Web、Android、iOS应用、以及RESTful服务提供了各种类型的应用支持。


3.


RFT是另一种能够进行功能、API、性能和回归测试的工具。使用记录和回放来创建自动化的功能测试,并将预期结果与执行时系统所产生的实际结果相比较。


IBM支持广泛的应用程序,并能够与等工具相集成。另外,还支持在API级别、用户界面级别、以及整个系统级别进行回归测试,以实现在DevOps或持续交付生命周期内的各种测试目标。


什么是自动化测试?

一般是指软件测试的自动化,软件测试就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

基本信息

中文名称

自动化测试

外文名称

Test

定 义

人为驱动测试为转为机器执行过程

应 用

软件测试的自动化

工 具

QTP

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

折叠编辑本段工具介绍

折叠QTP

全名HP QuickTest software ,2012年12月6日发布11.5版本,并更名为Unified Testing

QTP是quicktest 的简称,是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试,例如要测试那些功能、操作步骤、输入数据和期望的输出数据等

QuickTest针对的是GUI应用程序,包括传统的Windows应用程序,以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。

折叠WinRunner

Mercury 公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

企业级应用可能包括Web应用系统,ERP系统,CRM系统等等。这些系统在发布之前,升级之后都要经过测试,确保所有功能都能正常运行,没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统,是每个公司都会面临的问题。

折叠

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

折叠

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

折叠SilkTest

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

折叠QARun

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

折叠

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

折叠Holodeck

-强大的故障植入软件测试工具

Holodeck is an advanced fault-injection tool that gives you the power to attack an while it monitors and logs your does - every function call, registry entry, piece of data read or written.

折叠

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

折叠

是黑盒测试工具,可以用来完成功能测试、回归测试,可以提高测试效率,降低测试人工成本。

产品可以对以下类型对象进行GUI功能性测试:

1 Windows类型对象,一般为用C++/Delphi/VB/VFP/PB/.NetForm等技术开发的桌面程序。

2 IE网页对象,一般性的网站,比如大的门户类网站。

3 Java对象,一般为用AWT/Swing/SWT等技术开发的桌面程序。

4 Flex对象,网页的内容是用Flex开发的。

5 对象,网页的内容是用开发的。

6 WPF对象,一般为用WPF技术开发的桌面程序。

7 QT对象,一般为用QT技术开发的桌面程序。

折叠

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过程改进的思想。根据的调查,在2001年前后的3年中,全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。

折叠编辑本段选型原则

然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然,任何一种产品化的测试自动化工具,都可能存在与某具体项目不甚贴切的地方。再加上,在企业内部通常存在许多不同种类的应用平台,应用开发技术也不尽相同,甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。

以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则,这些原则是从笔者实际工作中凝练而成的,它包括以下六个方面的建议:

●选择尽可能少的自动化产品覆盖尽可能多的平台,以降低产品投资和团队的学习成本;

●测试流程管理自动化通常应该优先考虑,以满足为企业测试团队提供流程管理支持的需求;

●在投资有限的情况下,性能测试自动化产品将优先于功能测试自动化被考虑;

●在考虑产品性价比的同时,应充分关注产品的支持服务和售后服务的完善性;

●尽量选择趋于主流的产品,以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;

●应对测试自动化方案的可扩展性提出要求,以满足企业不断发展的技术和业务需求。

折叠编辑本段过程

自动化测试与软件开发过程从本质上来讲是一样的,无非是利用自动化测试工具(相当于软件开发工具),经过对测试需求的分析(软件过程中的需求分析),设计出自动化测试用例(软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的概要设计),设计与编写自动化脚本(详细设计与编码),测试脚本的正确性,从而完成该套测试脚本(即主要功能为测试的应用软件)。

1) 自动化测试需求分析。

当测试项目满足了自动化的前提条件,并确定在该项目中需要使用自动化测试时,我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据,并形成详细的文档,以便于自动化测试框架的建立。

2)自动化测试框架的搭建。

所谓自动化测试框架便是像软件架构一般,定义了在使用该套脚本时需要调用哪些文件、结构,调用的过程,以及文件结构如何划分。

而根据自动化测试用例,我们很容易能够定位出自动化测试框架的典型要素:

a. 公用的对象。

不同的测试用例会有一些相同的对象被重复使用,比如窗口、按钮、页面等。这些公用的对象可被抽取出来,在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时,只需要修改该对象属性即可,而无需修改所有相关的测试脚本。

b. 公用的环境。

各测试用例也会用到相同的测试环境,将该测试环境独立封装,在各个测试用例中灵活调用,也能增强脚本的可维护性。

c. 公用的方法。

当测试工具没有需要的方法时,而该方法又会被经常使用,我们便需要自己编写该方法,以方便脚本的调用。

d. 测试数据。

也许一个测试用例需要执行很多个测试数据,我们便可将测试数据放在一个独立的文件中,由测试脚本执行到该用例时读取数据文件,从而达到数据覆盖的目的。

在该框架中需要将这些典型要素考虑进去,在测试用例中抽取出公用的元素放入已定义的文件,设定好调用的过程。

折叠编辑本段脚本编写

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

折叠编辑本段测试运行

事实上,当每一个测试用例所形成的脚本通过测试后,并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变,都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例,也仅能被称作是半自动化测试,这会极大的影响自动化测试的效率,甚至不能满足夜间自动执行的特殊要求。

因此,脚本的测试与试运行极为重要,它需要详查多个脚本不能依计划执行的原因,并保证其得到修复。同时他也需要经过多轮的脚本试运行,以保证测试结果得一致性与精确性。

自动化测试引入的原因是就把软件测试人员从枯燥乏味的机械性手工测试劳动中解放出来,以自动化测试工具取而代之,使测试人员的精力真正花在提高软件产品质量本身。

折叠编辑本段注意事项

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

折叠编辑本段实战模拟

折叠背景介绍

A公司是一家大型保险公司,拥有近20个城市的分公司,并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右(新业务系统和原有业务系统的主要版本发布)。A公司的专职测试团队人数不足30人而且测试团队的测试人员技能参差不齐测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段,主要依靠手工测试。由于已上线应用系统的问题,开发团队必须分出一部分资源去维护和修复上线应用,而同时测试团队的测试成果和效率却无法和这些应用质量挂钩,也更无从谈起对软件质量的控制。所以,A公司决定在软件质量和测试方面进行投入,他们考虑以下几方面:

●引进软件测试流程管理的自动化,提高软件测试过程的管理水平,使软件测试和软件开发一样可被评估、被衡量。

●实现性能测试自动化,所有应用上线之前必须有应用性能风险评估报告和相关部门的确认

●逐步实现功能测试的自动化,在目前人员配置的情况下,把部分手工测试变成自动化测试,提高测试可信度,降低人为错误。

●通过软件测试自动化,管理软件测试中的案例、缺陷、报告等资产,进一步提升软件测试的效率并建立测试基础库。

●在规划中,将来的2~3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。

折叠系统的情况

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

折叠公司现状

企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定,缺乏实事求是的理性思考。

测试部门仅负责系统测试和对用户验证测试进行管理,对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段,测试部门也无法收集和确定集成测试和单元测试的完成情况,在整个软件测试过程中,业务需求是由开发部门通过进行管理,但测试需求尚没有提出要求,测试案例主要通过在公司公用的文件服务器中的目录管理方式管理,对测试中缺陷流程等管理主要依靠邮件的流转进行处理90%以上的测试是通过Excel和Word等测试案例文档来完成,测试人员对软件测试自动化的认识仅停留在"记录+回放"的认识上。

折叠方案

方案A:A公司可以采用美科利(Mercury)公司产品为主的软件测试自动化方案。

●依照原先的邮件流转过程配置缺陷管理流程,为每个保险业务的开发小组和测试团队分配相应的用户许可证,取消原有邮件方式。

●部署,以便完成应用程序相关功能测试。

●部署-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组,和业务部门协调,建立A公司应用系统上线性能指标,通过给出测试指标。

●建议A公司成立专门的质量控制部门,对中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。

方案B:A公司也可以采用产品为主的软件测试自动化方案。

●采用来进行整个测试流程的管理,为相关开发和测试小组成员分配相应权限,改变以前通过邮件以及Word、Excel文档管理测试的工作方式。

●部署,用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外,也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。

●部署,使测试工作前移到开发阶段。由于能较好地支持白盒测试,编程人员在编码阶段引入的错误能尽早被检测到,这大幅降低了后期测试的开销。

●建议A公司成立专门的质量控制部门,对中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。

方案C:A公司也可以采用开源软件为主的软件测试自动化方案。

●采用Bugzilla来进行Bug跟踪管理,采用进行测试用例管理,采用CVS进行测试资源的配置管理。

●采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。

●采用DBMonster、Open-STA、LoadSim进行性能相关测试。

●可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。

●建议A公司成立专门的开源软件维护小组,以解决可能会碰到的工具维护工作。

●建议A公司成立专门的质量控制部门,对Bugzilla、、CVS中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。

折叠方案评价

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

温馨提示:为不影响您的学业,来校区前请先电话咨询,方便我校安排相关的专业老师为您解答
  • 详情请进入南京信盈达
  • 已关注:476
  • 咨询电话:
  • 热门课程
姓名不能为空
手机号格式错误