精华内容
下载资源
问答
  • 作者:zzxxbb112时间:2011/10/26 版权所有,侵权必究。出处:...那么这一次主要来讲解如何使用MTM的自动化模型来自动化MTM与QTP.相信大家都已经了解了什么是QTP的AOM自动化模型,那是qtp安装

    作者:zzxxbb112

    时间:2011/10/26 版权所有,侵权必究。

    出处:http://blog.csdn.net/zzxxbb112


    在上一次的讲座中,我们已经简单介绍了使用MTM这个工具,并且讲解了如何利用MTM的命令行模式来自动化QTP执行自动化测试脚本

    那么这一次主要来讲解如何使用MTM的自动化模型来自动化MTM与QTP.

    相信大家都已经了解了什么是QTP的AOM自动化模型,那是qtp安装完成之后所提供的一种自动化组件,如果不清楚的话,可以看一下本讲座的第10篇

    那么MTM的自动化模型其实就是类似于AOM自动化模型,它是一种COM组件,可以通过CreateObject方式进行调用。


    MTM模型

    ProgID: MultiTestManager.Application


    实例1:自动加载多个脚本并执行

    '创建oMTM自动化模型组件
    Set oMTM = CreateObject("MultiTestManager.Application")
    
    '设置为可见模式
    oMTM.Visible = True
    
    '加载需要执行的脚本,并设置为
    oMTM.AddTestScript "c:\test1",True
    oMTM.AddTestScript "c:\test2",True
    oMTM.AddTestScript "c:\test3",False 
    
    '执行脚本
    oMTM.Run
    
    '直到运行完毕
    While oMTM.IsRunning : Wend
    
    '释放对象
    Set oMTM = Nothing 


    分析: 以上脚本的关键在于AddTestScript函数,其中第一个参数为脚本的路径,第二个参数为是否为计划执行脚本,如果是true,则添加并执行,false则只添加不执行。

    结果:


    如上图可以看到很明显,第三个脚本由于设置为false,因此状态为Do not run,并且脚本行为灰色,前面没有打勾,也就是非执行选项。


    实例2:加载多脚本,执行完毕生成报告,并关闭QTP以及MTM

    '创建oMTM自动化模型组件
    Set oMTM = CreateObject("MultiTestManager.Application")
    
    '获取报告设置对象
    Set oReportSettings = oMTM.Preferences.ReportSettings
    '获取运行设置对象
    Set oRunSettings = oMTM.Preferences.RunSettings
    
    '设置为可见模式
    oMTM.Visible = True
    
    '设置运行后关闭QTP以及MTM
    oRunSettings.CloseQuickTest = True
    oRunSettings.CloseTestManager = True
    
    '设置创建报告,并在运行完毕后打开报告
    oReportSettings.CreateReport = True
    oReportSettings.ReportName = "IQuickTest Report"
    oReportSettings.ViewReport = True
    
    
    '加载需要执行的脚本,并设置为
    oMTM.AddTestScript "c:\test1",True
    oMTM.AddTestScript "c:\test2",True
    oMTM.AddTestScript "c:\test3",False 
    
    '执行脚本
    oMTM.Run
    
    '直到运行完毕
    While oMTM.IsRunning : Wend
    
    '释放对象
    Set oRunSettingss = Nothing
    Set oReportSettings = Nothing
    Set oMTM = Nothing

    分析:以上脚本分别获取到了MTM的报告设置对象与运行设置对象,并且设置了运行完毕后自动关闭QTP和MTM

    运行结果:


    由于脚本中已经设置了报告标题名称,因此在图中的箭头处可以看到报名名称为IQuickTest Report。


    总结:

    总体来说MTM虽然是一个小小的辅助工具,但是我们可以看到Mercury当初还是在此工具上花了不少心思,对于没有QC的用户来说,它可以说是一款非常不错的多脚本执行工具,那么讲座对MTM工具的介绍就到此为止。


     Rss订阅IQuickTest关于如何订阅?

    GoogleReader订阅地址: http://feeds.feedburner.com/iquicktest



    展开全文
  • 自动化测试成熟度模型

    千次阅读 2012-12-11 20:41:55
    自动化测试成熟度模型 这里讨论一下不同的脚本技术及用途。接下来要讨论的这些技术并不是相互排斥的,事实恰好相反,它们是相辅相成的,每种种脚本技术在支持脚本完成测试用例的时间和开销上都有各自的长处和短处。...

    自动化测试成熟度模型
    这里讨论一下不同的脚本技术及用途。接下来要讨论的这些技术并不是相互排斥的,事实恰好相反,它们是相辅相成的,每种种脚本技术在支持脚本完成测试用例的时间和开销上都有各自的长处和短处。应该注意到,对于软件测试来说,使用哪种脚本技术并不是最主要的,脚本所支持的实现测试用例体现的整体考虑才是最重要的。

    按照自动化测试的成熟度模型,自动化测试可被划分为5个级别:

    级别1:录制和回放
    这是使用自动化测试的最低的级别。
    优点:自动化的测试脚本能够被自动地生成,而不需要有任何的编程知识。
    缺点:会产生大量的测试脚本,同时当需求和应用发生变化时,相应的测试脚本也必须重新录制。
    用法:当测试的系统不会发生变化时,可进行小规模的自动化。

    级别2:录制、编辑和回放
    在这个级别中,测试人员使用自动化工具来捕获想要测试的功能。将测试脚本中的任何测试数据,如名字、账号等,从测试脚本的代码中完全删除,并将他们转换成为变量。
    优点:测试脚本开始变得更加完善和灵活,并且可以大大减少脚本的数量和维护的工作。
    缺点:需要一定的编程知识。频繁的变化可能会引起“意大利面条式的代码”(可读性差,很难确定它到底完成什么工作。很多代码开始还是结构化的,但后来不断的修改之后,逐渐失去了结构性),并且变更和维护几乎是不可能的。
    用法:当进行回归测试时,被测试的应用有很小的变化,例如仅是针对计算的代码变化,应用程序界面和逻辑没有发生变化。测试人员可以使用这种技术来快速编制一些测试脚本以检验脑子里的想法来探索预定的测试设计。通常如果适当的软件配置管理(SCM)良好的内部构建设计相结合时,使用级别2的技术已经足够了。

    级别3:编程和回放
    这个级别是多个被测试软件版有效使用测试自动化的第一个级别。测试经理需要在实际投资开始前确保测试团队和客户对项目有充分的信心和安全感。如果没有经过技术培训,测试人员将不具备到达这个级别的能力。因为在这个级别中,测试人员要很好地理解自动化测试工具所有的测试功能,还要掌握测试脚本语言知识。
    优点:确定了测试脚本的设计,在项目早期就可以开始自动化测试。测试人员能够在项目的早期就开始进行测试脚本的设计,与开发人员一起研究他们认为可能会存在的问题的地方,确保了开发人员把精力放在设计得到可用于测试的方案上。
    缺点:需要测试人员具有很好的软件技能,包括设计、开发等。
    用法:大规模的测试用例被开发、执行和维护的专业自动化测试。

    级别4:数据驱动的测试
    对于自动化测试来说这是一个专业的测试级别。测试人员拥有一个强大的测试框架,这个测试框架能够基于根据被测试系统的变化快速创建一个测试脚本的测试功能库。维护成本相对比较低,而且测试中还会使用到大量的真实的数据。
    优点:测试人员能够维护和使用良好的测试数据,这些数据有效地模拟真实生活中的数据。
    缺点:要求测试人员具备软件开发的技能,能够访问相关的测试数据。
    用法:可用于大规模的测试用例被开发、执行和维护的专业自动化测试。该级别对测试数据要求较高。一个测试人员要花费一些暗为识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的,这些工作完成后,测试人员才能够通过使用现实的数据来运行大量的测试。使用良好的数据将为测试人员提供发现错误的能力,而这些错误通常在项目后期才会被发现或者被客户发现。

    级别5:关键字驱动的自动化测试
    这是自动化测试的最高级别,主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能的测试团队,这些测试人员能够将测试工具的知识与他们的编程能力结合起来,这个团队负责在测试工具中生成并维护测试方案,能够使测试工具从外部的来源,例如Excel表或者从数据库中执行测试用例。这是一种称为DDE的概念,测试人员关注点放在Excel表中创建测试用例上面,保存和使用一些特定动作的关键字,执行过程是从Excel表中读取测试用例,并将测试用例转换成为测试工具能够理解的形式,然后使用不同的测试功能来执行测试。
    优点:测试用例的设计被从测试工具中分离出来,测试人员可将关注点放在设计良好的测试用例上。允许测试用例的快速执行和基于用例的评估。
    缺点:需要一个熟悉工具和具有开发技能的测试团队,以提供并维护测试工程(框架)
    用法:这种专业的测试自动化能够将技能的使用达到最大化。使用关键字驱动的测试框架,测试人员可以使用Excel来生成实际的测试用例。这个级别对于那些按照正规使用测试用例的组织或者项目来说是非常适合的。测试人员可以集中精力来生成第一个包含被需要“对象映射”的测试用例(主流程)。如果测试用例设计不错,需要做的工作也非常简单。根据测试应用的复杂程序,通常这会花费大约半天到一天的时间。后续的每一个测试用例大概会花费15~20分钟的时间,因为通常大多数测试用例可以复制已有的测试用例,并对其进行必要的修改,通常这种修改工作量不大。关键字驱动框架能够通过使用测试用例,使紧密的、并行的测试用例开发变为可能。
         目前,大多数企业中,测试工具还处于数据驱动阶段,或者数据驱动到关键字驱动的阶段。

        你开始关键字驱动了吗?


     

    展开全文
  • Rss订阅IQuickTest(关于如何订阅?)GoogleReader订阅地址: http://feeds.feedburner.com/iquicktest作者:zzxxbb112时间:2010/7/6 版权所有,...希望不要错过,耐心看完,呵呵,在自动化测试中不管是相对路径还是

     Rss订阅IQuickTest关于如何订阅?

    GoogleReader订阅地址: http://feeds.feedburner.com/iquicktest

    作者:zzxxbb112
    时间:2010/7/6 版权所有,侵权必究。

    出处:http://blog.csdn.net/zzxxbb112


          今天讲的内容比较精彩也比较重要。希望不要错过,耐心看完,呵呵,在自动化测试中不管是相对路径还是保留对象PathFinder在框架开发中都是常用+实用。大家都知道对于一个脚本的相对路径的实现是非常重要的,这样方便以后的脚本移植,同样也能方便管理QTP的一些加载的对象、函数、场景恢复function,环境变量等等。

     

     

    • 相对路径设置方法: Tools -> options -> Folders ->

     

     

    如图我们可以看到QTP默认存在的一个<current test>这个就是本test的一个动态路径,此处添加了"d:/framework/",也就是我设置的相对路径, 如果此时我在这个路径下有一个tsr的对象库文件,就可以直接使用相对路径加载到共享对象库里。如图

     

     

    当然如果是开发框架的话完全可以使用AOM在QTP启动时就事先加载好这些路径,不过今天我讲的重点不在相对路径的设置。

     


     

    而是一个非常有用的对象,就是PathFinder对象,这才是我今天要讲的核心部分。

    其实PathFinder我相信很多朋友也一定很熟悉,QTP中的普通的不能再普通的保留对象,而今天我就要把它的作用完完全全的发挥出来。

    • 普通用法: msgbox pathfinder.Locate ("123.vbs")

    当我们在QTP中输入pathfinder之后输入"."后QTP会由于complete word而自动补充Locate方法。也就是说在QTP中,pathfinder就只有这一个Locate方法。此方法返回一个相对路径的完整路径。而由于我们之前设置过"d:/framework/"的相对路径,因此我们运行后会显示完整的路径。

     

     

    这一点相信很多人都会使用,也应该都很熟练了。

     

    • 隐藏用法: (MFL自动化路径模型)Mercury.FileLocator  (QTP的所有帮助文档中都没有任何蛛丝马迹)

    其实这个MFL自动化路径模型对象就是在QTP中的PathFinder对象,那我们就来见识一下MFL对象的庐山真面目。

     

    打开vbsedit。输入Set mfl = CreateObject("Mercury.FileLocator")并查看mfl的方法

     

    如图:

     

     

    在vbsedit中我们可以发现MFL对象的所有方法,同样Locate方法也在里面。

     

    我们可以使用一下其中的几个方法:

    • count方法:获取相对路径的个数

    ->      msgbox PathFinder.count

    • CurrentTestPath方法:获取当前测试路径

    ->      msgbox PathFinder.CurrentTestPath

    • Insert方法:运行时动态插入一条相对路径,参数1为路径,参数2为相对路径的index

    ->      PathFinder.Insert "D:/Program Files", PathFinder.count+1

     

    运行完我们可以看到在Tools -> options -> Folders ->下自动插入了一条记录。

     

     

    小结:

     

    剩下的方法大家可以自行去研究,这里就简单的介绍几个比较实用的。今天这一章主要就是讲MFL的这个对象,此对象在路径控制上非常有用,特别是在框架开发中。大家一定还在琢磨我为什么会知道这个对象吧。其实很简单,还是注册表。

     

     

    宝藏地点:

     

    进入HKCU -> SOFTWARE -> MERCURY INTERACTIVE -> QuickTest Professional -> MicTest -> FileLocator

     

    可以看到prog id的键值为: Mercury.FileLocator

     

     

    还不快去挖你的宝藏?

     

    如有任何问题请去IquickTest Q&A问题库进行提问


    展开全文
  • 自动化测试介绍 自动化测试(Automated Testing),是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架,编写自动化测试用例,来模拟手工测试过程。比如说,在项目迭代...

    自动化测试介绍

    自动化测试(Automated Testing),是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架,编写自动化测试用例,来模拟手工测试过程。比如说,在项目迭代过程中,持续的回归测试是一项非常枯燥且重复的任务,并且测试人员在每天重复劳动的工作之下,也丝毫得不到成长。

    此时开展自动化测试就能够帮助测试人员从重复、枯燥的手工测试中解放出来,提高测试效率,缩短回归测试时间。一般来说,自动化测试通常都会跟持续集成系统(比如Jenkins)配合使用。

    但在自动化实践过程中,往往会发现理想和现实之间的差距很大。自动化测试的劣势,主要体现在以下几方面:

    1 相对手工测试,自动化测试对测试人员的要求相对较高;

    2 测试用例需要根据版本迭代进行更新,有一定维护成本;

    3 不能指望自动化测试去发现更多新的BUG,自动化测试能发现的缺陷远远比手工测试少;

    4 自动化测试的产出价值往往在于长期的回归测试,短期内发挥的作用可能不明显;

     

    希望借助自动化流程解决的问题

    1 测试时间紧张,手工测试可能覆盖不全,容易错过某些边界情况;

    2 模块间强耦合时,单纯从页面进行测试时,比较难深入的发现问题;

    3 回归测试时,需要投入较大的人力/工时;

    4 实现手工测试无法达成的测试任务;

    5 通过编写测试用例,加深对业务/数据的认知,有助于下阶段迭代中发现隐藏的问题;

     

    引入自动化测试的前提条件

    项目周期长,需求变动不频繁 测试用例的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试。如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

    项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

    自动化测试脚本可重复使用 如果费尽心思开发了一套近乎完美的自动化测试脚本,但是脚本的重复使用率很低,致使其间所耗费的成本大于所创造的经济价值,自动化测试便毫无意义。

    测试任务手工测试难以实现 比如压力测试,大数据或者大量重复数据测试,必须有自动化工具的支持。

     

    做自动化测试需要具备的能力

    • 拥有编码能力 至少要熟悉自动化工具/框架的代码语言,最好有一定的编码能力,同时代码逻辑要清晰,否则不仅不能保证用例的逻辑性、业务性与健壮性等要素,也不能保证效率;

    • 熟悉被测系统; 熟悉被测系统对任何测试人员来说都是最起码的要求;

    • 掌握一个自动化测试框架/工具; 可以根据所掌握的代码,学习一门自动化测试的框架,如 Selenium/Appoum/Robot Framework/Nunit/TestNG等;

    • 不断学习,善于学习,知其然知其所以然; “落后就要挨打。”

     

    自动化用例一般在哪个阶段完成

    一般落后于新功能的手工测试阶段,可以在手工用例执行完成或功能上线后,再去补充自动化的用例。 自动化不是跟着新需求走,而是测变化的东西对不变东西的影响,一定不要做为了自动化而自动化的工作。

     

    分层自动化测试

    在理解分层自动化之前,我们先看一下经典的测试金字塔。

    • UI层:界面自动化测试。可以看出它的价值最小,它最接近用户真实场景,也容易发现问题,但它的实现成本最高且太容易受外部依赖,容易影响脚本成功率。总体来说,适当的界面自动化测试是有必要的,但是没有必要在UI层投入太多;

    • Service层:接口自动化测试。它的价值居中,覆盖大多数主要的接口是比较合适的。这一层要求测试人员对系统的结构和系统间的调度非常清楚,同时要了解接口逻辑关系,否则接口测试代码很容易遗漏一些异常场景;

    • Unit层:单元测试。最有价值的测试,但是对测试人员要求比较高,一般由开发人员完成,否则只能采用结对编程。 通常来说,手工测试是最基本的,可以做到接近100%,而对于自动化测试来说,它更像是一件"防弹衣",用来防护身体的主要部位。有人认为自动化率提高了,就可以节省人力,这实际是非常片面的,因为提高自动化率,意味着需要投入更大的人力在维护的成本上。因为系统的需求是在不断变化的,每一个变化都会导致自动化测试用例需要更新调整。


    所以,自动化测试做到什么样才算好,也要结合上面的测试金字塔来分析。对于UI层面的自动化测试,保证少量必要的主流程即可,切勿在这一层面将自动化测试的"防弹衣"变成臃肿的"宇航服";Service层面的接口自动化测试,可以考虑覆盖大部分的流程;Unit层面的单测,做到100%是最好的,即使有需求变化,一般也很少影响到已有的用例。一般来说,单元测试可以发现80%的缺陷。

     

    设计自动化用例的原则

     

    基本原则

    • 自动化测试用例的范围必须是相对核心的业务流程,即覆盖主体功能的核心测试点和重复执行率较高的模块;

    • 在测试脚本和被测代码都保持不变的情况下,测试用例的结果应该是稳定的,这一点非常重要;

    • 除非是必要的情况,否则任何用例都应当避免做持久化的操作,以保证环境始终是干净的;

    • Once Written, Run Anytime as Desired ;

    • 不是所有的手工测试用例都可以使用自动化测试来实现,自动化测试替代不了手工测试,两者的有效结合是保证项目质量的关键。

    • 回归测试场景中,测试用例的选择一般以正向为主,逆向为辅;

     

    用例设计原则

    保持Case的独立性

    通常来说,一个Test Suite下包含了一组相近的或者有关联的Test Cases。而每一个 Test Case 应该只测试一种场景,根据case复杂程度,不同场景同样可大可,可以是某个单元的测试,也可以是端到端的测试(E2E),当然也有特殊的写法比如工作流测试和数据驱动。

     

    Case的独立性有哪些需要关注的点呢?

    首先Test Suite内的Cases在执行时不应该相互影响,意思是说当我们有随机的跑其中某个Case或乱序的跑这些Cases时,测试的结果都应该是准确的。Suite level和Directory level同样要注意独立性的问题。系统较为庞杂时,可能会将数百上千的Cases放在一起跑,Robot本身不会规定Case执行的顺序,所以从某种程度上来说同一层级的Cases是随机执行的。

    很典型的情况就是,测试用例在本地调试时怎么跑怎么过,放到Server上所有Cases一起跑的时候就会Fail,还可能是偶发的,这种情况下就很可能是由于其他Case的痕迹影响到了它,查找问题的根源往往比较耗时。

     

    保持Case的可迁移性

    Case的可迁移性主要考虑三点 : Case对执行环境的依赖 ; Case对外部设备的依赖;Case对测试对象的依赖。

    Case对执行环境的依赖 尽量减少对执行环境的依赖。举一个例子,你在本地PC上使用rf框架编写、调试用例后,上传到Git,然后你的领导可能会拉取你的用例在他的本地运行,随后又被部署到持续集成服务器上。

    所以你编写的用例时就要尽量避免使用不同平台的库或者shell命令。

    再举个例子,如果你因为业务需要而修改了测试库源码的话,此时不管是组内其他人还是CI服务器,肯定都会运行失败,这种情况该怎么解决呢?

    这里提供两个解决方法:

    1 将修改后的库做成测试库,上传到Git或者Pypi,对方可以通过pip安装更新;

    2 使用robotremoteserver做一个共享库放在远程主机上,具体请参考虫师的文章;

     

    Case对外部设备的依赖 有时为了业务测试需要,我们会引入一些外部设备来辅助测试,外部设备可能会持续升级或者更换,在编写用例时我们就需要考虑如何用一套Case更好的兼容这些测试设备。比如可以将外部设备的操作从测试用例中抽离出去,封装成测试库或关键字;

    Case对测试对象的依赖 如果测试对象是一个软件平台,软件平台通常需要适配多种的设备,而设备的硬件配置可能是多种多样的:CPU、内存、组件的性能和数量都可能不同。对测试对象的依赖不仅要考虑在不同设备上的可执行性,重点还要考虑测试覆盖率。由于设备组件的增多你的用例可能无法覆盖到这些组件,或者捕捉不到某个性能瓶颈,这样测试结果的可靠性也大打折扣。

     

    提升Case执行效率

    不同的case执行时间相距甚远,短则数秒长则持续数天。数秒钟的简单功能测试用例和耗时数天的稳定性测试用例本身是没有什么可比性的。但是我当我们放眼某一个或者某一组case时,我们就需要重视Case的执行效率。

    不论是敏捷流程还是持续集成都讲究快速的反馈,开发人员能在提交代码后快速的获得测试结果反馈,测试人员能在最短的时间内执行更大范围的测试覆盖,不仅能提高团队的工作效率,也可增强团队的信心。

    以使用rf为例,在编写用例时可以通过以下方面来提高用例的执行效率。

    1.如果有对执行条件的检查,若检查失败,则尽快退出执行; 2.将数据准备或环境清除等工作抽取成关键字放到更高的层级中,,抽取时可能需要做一些组合, 但不允许出现重复的建删操作; 3. 用例中尽量少的出现sleep,建议用"wait until ..."来代替; 4. 可以采用并发执行用例的方法来提升效;

     

    自动化用例编写规范

     

    命名规范

    Keyword命名

    第一个单词应以小写字母作为开头,后面的单词则用大写字母开头。 如:getProjectId, connectDB

     

    常量命名

    常量的名字应该都使用大写字母,并且指出该常量完整含义。如果一个常量名称由多个单词组成,则应该用下划线来分割这些单词。 如:MAX_CHAR_LENGTH

     

    参数命名

    参数的命名规范和方法的命名规范相同,请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。

     

    如:{investorName}

    使用Tags

    RF提供了通过在Settings中设置tags来管理用例的方法。Tag的应用非常的广泛和灵活,比如可以用来做用例筛选、版本管理、统计策略等。

     

    怎么打tag看起来会更便捷?

    • 可以在各个文件夹下打文件夹名字的tag,这样就可以根据tag单独的跑该文件夹下的用例,查看测试报告也更好看些;

    • 在一些重要的用例上打上tag,可以单独跑关键用例;

    • 某些用例如果不想执行,可以打上tag,设置不执行。

     

    让case具有文档性

    在考虑Coding Style时我们可以设置一些固定的规则,大家只要按照这个规则来做,实践几次之后Coding Style就会趋于统一. 而考虑将Case写的如同文档一般则需要更多的主观能动性。

     

    敏捷开发(Agile Development)在国内的发展已经越完善,伴随之而来的便是敏捷测试(Agile Testing)。敏捷思想强调以人为核心,在整个开发流程中,只写有必要的文档或尽量少写文档,这也是它与传统的瀑布模型的差别。

     

    为了不造成误解,这里有必要插入的说一下敏捷测试的几个特点:

    • 敏捷测试应该是敏捷开发的一部分;

    • 敏捷测试具有鲜明的敏捷开发的特征,如测试驱动开发(TDD),验收测试驱动开发(ATDD)。也就是说,单元测试是敏捷测试的基础,如果没有足够的单元测试,就无法应对将来需求的快速迭代,也无法实现快速而稳定的持续交付;

    • 优秀的敏捷测试是基于自动化测试的;

    • 敏捷测试无时不在,无处不在。

    需求设计不断的更新,而文档往往不能被很及时的更新,那这样的话怎么才能让测试人员如何快速的掌握某个功能或者产品的需求和当前状态呢?

     

    清晰易懂的用例名

    在实际的工程中,我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点,而用例名则应该概括总结对应测试点的核心内容,这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。

    在实际的工程中,我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点,而用例名则应该概括总结对应测试点的核心内容,这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。

    展开全文
  • 软件测试自动化框架的探讨

    千次阅读 2008-01-14 21:22:00
    上个月,测试时代举办了一次软件测试沙龙,专门探讨自动化测试框架技术,本次沙龙感觉高度还不错,在业内应该算先进的,第一次这么多人就软件测试自动化框架搭建技术进行探讨。 主要的内容:细节话题:1、什么是...
  • 《测试自动化最佳实践:来自全球的经典自动化测试案例...本书作者Dorothy Gramham和MarkFewster之前写的《软件测试自动化》(Software Test Automation)就很有影响,作为其姐妹篇,一定不会差,会更胜一筹。更让我感
  • 文章目录敏捷scrumscrum里面的角色迭代开发敏捷中的测试软件测试的V模型软件测试W模型 敏捷 “敏捷”是新的过程家族的名称 《敏捷宣言》:我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,...
  • 如果你对此文有任何疑问,如果你也需要接口项目实战,如果你对软件测试、接口测试、自动化测试、面试经验交流感兴趣欢迎加入Python自动化测试技术群:953306497群里的免费资料都是笔者十多年测试生涯的精华。...
  • 软件测试自动化的一些具体做法

    千次阅读 2005-03-12 18:28:00
    软件测试自动化的一些具体做法 作者在上篇文章略微谈到了软件测试的自动化,但并没有把本文的内容也一起写进去。原因主要是希望读者先努力考虑在自己的企业或项目内,可以有一些怎么样的做法,而不会先入为主地受到...
  • Selenium+Python 自动化测试模型

    千次阅读 2016-01-11 15:38:29
    学习Selenium+Python,最终的目的是为了实现自动化测试的操作。 前面几篇文章,详细介绍了搭建环境、...自动化测试模型自动化测试架构的基础。1.模块化与类库 我们 测试过程中,即使自动化测试,写的脚本,很多内
  • 自动化软件测试杂谈

    千次阅读 2012-03-28 11:45:11
    写这篇日志其实是有感而发。刚刚偶然看到论坛上有位童鞋在询问...确实,正如我上一篇博文《软件测试工程师的“三十六变”》所写的,自动化测试工程师/架构师是我们测试人员的发展方向之一,要想向技术方面发展的话,可
  • 软件智能自动化测试

    千次阅读 2013-11-29 20:39:54
    对于软件工程有所认知的人都会知道,手动测试是无法取代自动化测试的。但是我觉得,在将来,自动化测试是完全可以取代手工测试的。( ( ⊙ o ⊙ )啊!!????? )  在大家喷我之前,我想说,我说的情况是在足够...
  • (翻译)测试自动化组织模型

    千次阅读 2005-09-28 16:22:00
    测试自动化组织模型 ---Unknown《Test Automation Organization Models》 ---Kiki翻译于2005/9/27 在一般的软件开发中,组织是基于项目,产品或两者兼有。 In general software development organizations are ...
  • 软件测试与软件质量模型

    千次阅读 2020-04-03 12:53:53
    系统测试软件质量模型软件质量模型六大属性功能性可靠性易用性效率可维护性可移植性 软件质量模型六大属性 功能性 可靠性 易用性 效率 可维护性 可移植性 ...
  • “.Net软件测试自动化之道”

    千次阅读 2008-07-07 21:09:00
    看后感觉前半部分对测试人员来说还是不错的,但是后面部分过于倾向代码开发,比较适合做白盒测试,单元测试。整体上要求读者有一定的开发能力,但是测试人员也可以把它作为一本了解开发人员如何做测试的参考书。术语...
  • 基于模型驱动的自动化测试设计

    千次阅读 2015-06-07 19:58:02
    序言:一直在思考一个问题:业界自动化测试被大家认为应用的场景主要是产品稳定、周期较长的测试项目,而且自动化测试不是用来发现和定位问题的。大家应该知道,“杀虫剂效应”,虫子对农药产生抗体的,那产品何尝...
  • 用手工或者自动化的方式执行测试用例的一个过程 2.软件测试的对象包括哪些? 参考答案: 源程序、目标程序、数据和相关文档 3.试结合软件开发流程模型,描述对应不同的阶段测试需要哪些工作? 参考答案: V模型主要...
  • 软件测试人员能力模型

    千次阅读 2014-03-12 19:54:27
    软件测试人员能力模型 测试思维 系统&全局思维 发散思维 逆向思维&批判思维 细致入微&问题敏感 追求卓越/知难而进 沟通&心态&责任 协作&推动&影响力 客户意识&质量意识 测试方法&能力 测试...
  • 软件测试的新模型

    千次阅读 2005-04-14 10:22:00
    软件测试的新模型作者:Brian Marick 翻译:Blueski 通常情况下,一个软件模型说明的内容主要包括,在测试过程中你应该考虑到哪些问题,如何对测试进行计划,测试要达到什么目标,什么时候开始,在测试中你要用到...
  • TMM软件测试成熟度模型

    千次阅读 2014-02-25 14:01:13
    第一级 初始级 测试处于一个混乱的状态,缺乏成熟的测试目标,测试处于可有可无的...第二级 定义级 测试目标是验证软件符合需求,会采用基本的测试技术和方法。 特征: 1.测试是有计划的活动 2.测试和调试分开 3.
  • 软件自动化测试基础

    千次阅读 2007-01-24 16:54:00
    Slide *第6章 软件自动化测试基础6.1 自动化测试基础6.2 软件自动化测试生存周期方法学6.3 软件自动化测试生存周期方法学的应用6.4 软件自动化测试工具简述本章教学目标理论环节认识与理解应用软件自动化测试的基本...
  • 目录一、软件测试阶段划分1、按照开发阶段划分1)单元测试2)集成测试3)系统测试4)验收测试5)回归测试2、按照是否手工1)分为手工测试与自动化测试2)自动化测试的优点3)自动化测试的局限3、按照代码运行进行...
  • 软件自动化测试浅析

    万次阅读 多人点赞 2019-03-31 21:27:58
    软件测试(Software Testing): 描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。 软件测试并不只是一个发现软件BUG的过程,通过找出错误,分析其产生的原因和错误的发生趋势,可以帮助项目管理者...
  • 软件手工测试自动化测试的比较

    千次阅读 2009-10-23 09:59:00
    软件手工测试和自动化测试的比较 摘要:随着现代软件业的发展,软件测试在软件开发中占据了越来越重要的地位。本文就从实际的软件测试项目工作流程的角度探讨了手工测试和自动化测试的特点。并对它们各自的优缺点做...
  • 一、概述GraphWalker就是一个基于测试模型的用例生成工具。...MBT中文名称为基于模型的测试, 基于模型的测试属于软件测试领域的一种测试方法。MBT步骤如下:首先由被测系统(SUT, system under test
  •  一个测试模型是有向图表示的FSM或者EFSM模型,由箭头和节点组成,如图所示。  一个箭头,代表了一次测试动作;  一个节点,代表一次测试验证。 2、测试需求选择Test requirements selection 目的:指导测试用例...
  • 问:软件测试的原则? 答:https://blog.csdn.net/weixin_30363263/article/details/102986878 问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 1、将问题提交到缺陷...
  • 1.1 功能测试自动化类似软件开发过程 录制,回放是不能满足自动化测试的需求的,所以要测试人员掌握开发知识,和编程技巧。 1.2 功能自动化测试是个长期的过程 首先我们不能再短时间内有很多的测试成果,找到...
  • 年过去了,但是软件测试自动化领域的改变并不大! 我们仍然面对相同的问题: We are still preoccupied with questions such as: Is record and playback an effective automation approach? (录制和...
  • 自动化测试

    千次阅读 多人点赞 2017-05-23 21:44:19
    什么是自动化测?    做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多。... 首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 147,852
精华内容 59,140
关键字:

软件测试自动化模型