精华内容
下载资源
问答
  • 此文档为软件代码回归测试流程,介绍回归测试定义,策略和流程
  • 测试流程 回归测试

    千次阅读 2020-08-06 10:14:40
    拿到需求之后 进行一个评审需求—编写测试计划—制定测试方案— 编写测试用例— 测试环境搭建 — 执行测试用例 —进行问题的回归测试 — 再进行测试结果评估和总结 — 提交测试报告 回归测试就是执行测试用例发现bug...

    拿到需求之后 进行一个评审需求—编写测试计划—制定测试方案— 编写测试用例— 测试环境搭建 — 执行测试用例 —进行问题的回归测试 — 再进行测试结果评估和总结 — 提交测试报告
    回归测试就是执行测试用例发现bug之后 对bug的提交 随后开发人员对bug进行修改 修改了旧代码后,重新测试以确认修改没有引入新的错误或导致其他代码产生错误。

    回归测试的场景:1.开发修改完bug之后:
    a.测试同学需要将之前发现bug的用例再次执行一遍,已验证此问题已经修复,然后关闭对应的bug单,写明必要备注
    b.验证其他和此bug有依赖关系的场景用例是否正常

    2.迭代上线前:每个迭代不同模块肯定有很多不同类型的bug,在前面场景1中都是零零散散的回归了开发修复的bug,等到最后上线时,往往我们会再进行一次回归测试范围:本次迭代全部场景方法:抽取其中部分用例做为回归测试用例执行:再次执行抽取的测试用例,记录结果

    展开全文
  • 这正是云计算的特点,而为了应对这样一个动态的计算资源,仅仅通过前几弹描述的一些含有相当强烈针对性的测试作业来模拟真实状况显然是远不够完备的。因此,我们需要对每一个新发布的Hadoop版本进行真实的业务线作业...
  • 软件测试之回归测试

    万次阅读 2018-05-21 20:34:28
    相信很多同学都是听过回归测试这个说法的吧,而自动化测试很多时候都应用在这个时候,今天就来说一说回归测试吧。一、软件回归测试的定义: 回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或...

    相信很多同学都是听过回归测试这个说法的吧,而自动化测试很多时候都应用在这个时候,今天就来说一说回归测试吧。


    一、软件回归测试的定义: 

    回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的一种测试方法。

    1、回归测试是指重复以前的全部或部分的相同功能测试

    2、新加入测试的模块,可能对其他模块产生副作用,因此要进行某些程度的回归测试

    3、回归测试的重心,是以关键性模块为核心


    二、做回归测试的好处如下:

    1、自动回归测试将大幅度降低系统测试、维护升级等阶段的成本,回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都可以进行多次回归测试。


    2、回归测试的意义:

    1)在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试;因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的


    3、做回归测试的测试用例的选择:

    1)对于一个软件开发项目来说,项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。

    2)同时测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面,

    (1)删除过时的测试用例:

    因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时,例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试。所以,在软件的每次修改后都应进行相应的过时测试用例的删除

    (2)改进不受控制的测试用例:

    随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例:,这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求。

    (3)删除冗余的测试用例:

    如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率:,所以需要定期的整理测试用例库,并将冗余的用例删除掉。

    (4)增添新的测试用例:

    如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试:,并将新开发的测试用例合并到基线测试包中,通过对测试用例库的维护不仅改善了测试用例的可用性,而且也提高了测试库的可信性,同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

    3)选择回归测试应该兼顾效率和有效性两个方面,常用的选择回归测试的方式包括:

    (1)再测试全部用例:

    选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高。全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度。

    (2)基于风险选择测试:

    可以基于一定的风险标准来从基线测试用例库中选择回归测试包,首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级,一般而言,测试从主要特征到次要特征。

    (3)基于操作剖面选择测试:

    如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度:。

    (4)再测试修改的部分

    当测试者对修改的局部部分有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。

    通常,一个回归错误一定涉及一个新的、修改的或删除的代码段,在允许的条件下,回归测试尽可能覆盖受到影响的部分。

    4)回归测试的基本过程:

    (1)重点测试软件中被修改的部分;

    (2)从原基线测试用例库中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库。

    (3)依据一定的策略从测试用例库中选择测试用例测试被修改的软件。

    (4)如果必要,生成新的测试用例集,用于测试无法充分测试到的软件部分。

    (5)用新软件测试用例集执行修改后的软件。

    展开全文
  • 回归测试方法梳理

    千次阅读 2019-09-16 19:03:01
    测试流程的重要性不言而喻,互联网公司拥有一套严格的测试流程测试规范是把关线上代码质量的重中之重。一个项目或者需求,从提出,到开发,测试,上线,线上回归,每一个环节都是必不可少的。很多经验不够丰富的...

           测试流程的重要性不言而喻,互联网公司拥有一套严格的测试流程和测试规范是把关线上代码质量的重中之重。一个项目或者需求,从提出,到开发,测试,上线,线上回归,每一个环节都是必不可少的。很多经验不够丰富的测试同学会认为在测试环境测试用例都执行通过了,那么相同的代码上线之后就肯定没有问题,这种想法是完全不正确的:

    1. 代码每次增量上线时,有可能会漏掉一些代码没有上线或者相关变更表结构的脚本没有执行,导致新功能上线之后会出现bug,如果没有回归测试,后续系统在运行时,用户使用app就会出现问题;
    2. 由于生产环境和测试环境并不完全一样,生产环境的机器配置也与测试环境无法一致,所以如果没有生产环境的线上回归,无法预知生产环境的上线代码相关的性能测试结果;

           软件测试的最终目的是什么,就是要保证软件的质量稳定运行无问题。

     

           测试工作中,讲究很多方式方法:测试工具的使用,测试技巧的掌握,都能令自己的工作事半功倍。本人刚入行测试行业的时候,回归测试过程中总是感觉阻碍重重。

           按我的总结,线上回归之所以难,遭受到很多抱怨,无非就是两点原因:

    1. 由于在线上环境,环境受限,部分测试场景或者测试数据不容易构建;
    2. 相关页面的权限没有拿到,测试受限;

    第2点比较好解决,小厂的话和leader或者相关开发沟通一下,出于对新代码的测试考虑,肯定是不会拒绝的;大厂的话可能需要邮件并抄送相关leader,虽然流程慢一些,但是也会给与相关的权限或者支持的。

    找了一下csdn上回归测试相关的文章,大多写的都是比较笼统且没有具体的实施步骤。这里提供一些线上回归的思路以及关键测试点如何校验;

    1. 挑选部分测试用例,选择性的进行回归验证;例如一个活动的各种状态的校验;
    2. 利用接口的调用去完成一些不好构造的业务流程或者冗长的流程;
    3. 提前申请好相关页面的权限,校验相关功能的话用户控制在相关用户分群或者白名单,这样可以让构建的数据真实用户不可见;

           这里针对第二点展开说明:需要了解端内页面和服务端的数据交互逻辑:多去了解接口相关的东西,上篇文章也介绍了通过接口如何构建一些测试数据。这里不再做说明。

           之前在某叫车服务公司担任测试工作,在奖励系统,有很多复杂的逻辑触发各种不同的奖励机制,需求的大部分变更都是这个页面改一点,后台奖励活动配置条件或者策略增加那么一两个。所以变动点在上线之后,尽量多利用现成的线上订单数据来回归是最好,数据多且全面;

    举个例子:某活动只邀请快车类型司机参加,专车司机不可报名;这个时候线上如何回归?

    常规方法是:创建一个白名单的测试活动,找个专车司机账号,找该活动,报名。

           测当然可以这样测,但是这个活动可能直接对专车司机不可见了,那么报名参加的二次拦截的测试点可能就无法测试到了。这个时候就可以调用报名的接口,输入专车的账号和其他参数,测试是否有校验和拦截;活动的列表页展示的数据,也是另一个接口返回的数据,传入专车司机账号,调用活动列表页的接口,然后查询一下是否有自己创建的测试活动,如果没有就是验证通过;

           以上两个测试点可以很轻松的利用调用接口的方法完成回归测试,数据展示直观可靠,效率也更高;

           如果是端内原生页面或者h5有样式上的改动,那我们就具体情况具体分析,原生页面我们去更新包测试,h5的话可以问前端要线上链接,直接就可以在浏览器查看展示,接口的调用也可以在控制台查看调用的接口和数据,非常便捷;

           如果测试点在活动后的奖励领取,看发送奖励的脚本是以什么维度来派发的:活动的维度,活动状态的维度,或者白名单的维度等等,线上脚本的执行,也是可以控制在少数数据执行测试的;发送成功后,如果有真实的数额进账到司机的钱包,那么在回归测试完成之后记得把钱如数退还公司哦~

     

     

    划重点:测试思路要灵活,app&web/h5测试,不要被业务的流程固化了思维,找准自己想要的测试点。

    展开全文
  • 自动化测试全流程总结

    千次阅读 2021-10-08 19:10:11
    自动化测试 一般是指软件测试的自动化,软件测试就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。 定义 人为驱动测试为转为机器执行过程 应用 软件测试的自动化 工具 ...

    自动化测试

    一般是指软件测试的自动化,软件测试就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。

    定    义

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

    应    用

    软件测试的自动化

    工    具

    QTP

    目录

    1. 定义
    2. 工具介绍
    3. ▪ QTP
    4. ▪ WinRunner
    5. ▪ Rational Robot
    6. ▪ AdventNet QEngine
    7. ▪ SilkTest
    1. ▪ QA Run
    2. ▪ Test Partner
    3. ▪ Holodeck
    4. ▪ Telelogic TAU
    5. ▪ AutoRunner
    6. ▪ Phoenix Framework
    7. 前提条件
    1. 适用场合
    2. 选型原则
    3. 过程
    4. 脚本编写
    5. 测试运行
    6. 注意事项
    1. 10 实战模拟
    2. ▪ 背景介绍
    3. ▪ 系统的情况
    4. ▪ 公司现状
    5. ▪ 方案
    6. ▪ 方案评价



    定义

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



    工具介绍

    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、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的应用。




    公司现状

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

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




    方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




    方案评价

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

      

     最后总结

    博主持续更新自动化测试相关文章及视频~加大佬云集测试交流群:550412533(备注:csdn999)
    即可免费领取测试学习资料,笔记,视频~海量资料更新中……,
    软件测试任何技术问题免费一对一解答加微信:mashang-zz(备注:csdn站999)
    收藏等于白嫖,点赞,关注才是真情!你还等什么 ,赶快行动叭 ! 

    展开全文
  • 一种再现测试流程以实现自动化回归测试的方法.pdf
  • 详解回归测试

    千次阅读 2020-04-15 16:31:47
    测试工作中,新人对于测试流程、测试方法都有可以直接拿来用的教材,但是对于回归测试中的bug处理的细节,往往需要我们更多的经历才能更好的完成自己的工作,下面我们来谈一谈回归测试bug的处理中需要关注的点: ...
  • 本文讨论了一种可以帮助客户更快,更便宜地运行集成和回归测试以改善CI / CD流程的方法。 介绍 让我们考虑一个场景,在该场景中,开发人员添加了新功能或对现有产品进行了错误修复,并检查了更改。 作为CI / CD管道...
  • 一款用于测试部门协作进行接口测试的小框架,主要适用于冒烟测试和回归测试,支持单接口和多接口场景流程测试,目前他支持一下相关功能: 支持json文件内部的参数化操作 支持自定义方法并在json文件中参数化引用 支持...
  • 【软件测试】回归测试的策略

    千次阅读 2019-05-03 10:38:16
    1.什么是回归测试回归测试是贯穿在整个测试的各个阶段的一个测试活动。它的目的是检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷。软件在测试或者其他活动中发现的缺陷经过修改后,都...
  • 回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。 在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端...
  • 作为测试经验尚且不足的初级TE,近半年以来,参与了2个较...1.测试流程:(仅供参考,个人工作流程:) web测试 参与一个新项目的测试前,先搜集测试相关的资料,包括原型图、各种需求文档、业务相关的说明,比如要开
  • 回归测试注意事项

    2020-04-16 09:49:53
    白盒测试中,回归bug时,如何在流程中避免问题的修改引入: ...由此发现,当修改公用模块时,测试需不断进行大量回归测试,因此,自动化测试显得极为重要,每次发版本钱最好跑一次全量脚本。 3、要考...
  • 回归测试与冒烟测试的区别

    千次阅读 2020-08-04 10:15:20
    回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 ALM+TestCenter(覆盖生命周期的研发过程管理平台) 回归...
  • 知识点一: 什么是冒烟测试?冒烟测的目的是什么 一、什么是冒烟测试? 冒烟测试(Smoke Testing)是指:针对每个版本或每次需求变更之后,在正式测试之前,对产品或...回归测试的目的、流程是什么? 一、什么是回归
  • 接口测试全流程

    万次阅读 多人点赞 2018-05-28 11:16:07
    1.什么是接口? 2.接口都有哪些类型? 3.接口的本质是什么? 4.... 接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些...
  • 回归测试用例设计是回归测试中一项重要的内容,本文从应用的角度出发,在商用软件测试工具产生的程序流程图基础上,提出了覆盖变化结点的所有路径算法,并开发了相应的工具软件。应用实践表明,该工具软件能够有效地...
  • 回归测试策略概览

    千次阅读 2018-03-01 00:00:00
    本文要点回归测试不同于其他类型的测试。回归测试分为多种类型,因为不同的原因,采取不同的方法。建立回归测试的策略,重点是要考虑上下文和其他一些因素。回归测试有很多方式和方法。不同的方法论需要采用不同的...
  • 完整测试流程详解

    万次阅读 多人点赞 2020-08-06 20:04:44
    (了解熟悉业务,分析需求测试点) 1.确认功能(业务功能,辅助功能,数据约束,易用性需求,编辑约束,参数需求,权限需求,性能约束) 2.场景分析(考虑场景调用者和系统内部各个场景之间联系) 3.挖掘隐性需求( ...
  • 回归测试VS重新测试

    千次阅读 2020-09-18 17:58:03
    你不是唯一一个为区分回归测试和重新测试绞尽脑汁的人。它俩都是用于开发之后,很多人因为这两种软件测试类型之间有很多的相同点而陷入疑惑。然而在一些大的方面他们是不一样的。 所以呢? 在正式讨论区别之前让...
  • 是指对软件中最小可测试单元进行检查和验证单元测试当一段代码完成之后,是由白盒测试工程师或者开发人员自行测试,比如java中执行单元测试叫做junit测试。目前大部分公司单元测试由开发人员简单编译和调试一下自己...
  • 在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有...
  • web自动化测试全流程

    千次阅读 2020-04-30 17:47:18
    一.web自动化入门 1.什么是web自动化测试?...需要回归测试 3.测试工具: web自动化测试:selenium app端自动化测试:Appium 接口自动化测试;jemeter,postman 性能测试:jemeter.loadrunner 4.selenium webdriver工作...
  • 一般的软件测试流程是后期快速迭代的,bug在后期是快速收敛的,debug和测试的周期也是越来越短,频率是越来越高,譬如说第一轮测试需要花上10天跑用例,那么到后期就没那么长的时间,可能就是1~2天的测试时间,在...
  • 咱们就不讲哪些严格的定义 冒烟测试概念其实每个公司定义都有点不一样: 叫法1:有些公司把软件上线前的最后一轮测试叫冒烟测试, 叫法2: 有些公司...叫法1和叫法2还是有共同点的:就是都是测试流程,叫法1 测试...
  • 冒烟测试&回归测试&UAT&SIT

    千次阅读 2019-05-16 10:16:30
    在软件研发中,冒烟测试其实是微软首先提出来的一个概念,和微软一直提倡的每日build(构建版本)有很密切... 回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回...
  • 软件测试工作基本流程

    千次阅读 多人点赞 2019-06-24 19:54:13
    最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试官的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • 测试全流程质量保证

    千次阅读 2016-09-08 14:26:24
    测试,只是项目过程中的一个阶段;我们不是软件的生产者,但是我们是软件质量的守护者。为了保证我们的产品质量,不能...我们必须在软件生产的整个流程、每一个阶段进行控制、监管,所以我们提出了“全流程质量保证”。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 58,839
精华内容 23,535
关键字:

全流程回归测试