点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快最近要在新入职的公司准备一份自动化测试的培训这是我在得知要做自动化测试培训以后随手画了个图压压惊这是我能想到的关于自动化测试的一些要点然后根据一篇我三年前写的关于自动化测试的随笔更新了一下当然遗憾的是到目前为止我接触的成功的敏捷开发项目还很少虽然敏捷近些年一直很火。关于敏捷自动化测试这一块也只有一次不太成功的经验所以本文中我回避了这一块1、什么是自动化测试以程序测试程序以代码代替思维以脚本的运行代替手工测试。自动化的测试涵盖了功能黑盒自动化测试功能白盒自动化测试性能测试压力测试GUIGraphical User Interface测试安全性测试等。关于什么是自动化查阅了一些资料并没有一份权威规范的解释以下摘自维基百科In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or add additional testing that would be difficult to perform manually.首先test automation跟 automation test是有区别的测试自动化涵盖的面更广泛。本文阐述的是自动化测试在这里暂且混淆这两个概念。这一段英文不难自行翻译。我眼里看到的几个要点1.需要工具2.工具控制流程比较预期输出与实际输出3.重复性高且有必要的测试流程可以自动化4.用于手工测试难以达成的领域说说我自己的理解自动化测试是测试思想的一个延伸为测试工程师提供了一个“触须”其行为可以看成一个工具但是本质上自动化测试还是一种思想。顺便提一句狭义上的自动化测试指的就是基于GUI的自动化测试而单元测试跟API测试你有想过怎么用手工不借助任何工具去做吗所以它们天生就属于测试自动化的范畴。2、自动化测试的优势回归测试更方便可靠 可运行更多更繁琐的测试且快速高效可执行一些手工测试执行相当困难或者做不到的测试如大量的用户并发更好的利用资源具有一致性和可重复性的特点自动化测试脚本完全可复用提升了软件的可信度多环境下测试等。自动化最实在的优势在于——工作好找有一个测试工程师并不是本人发现一个有趣的现象她申请过的几乎所有测试职位在招聘时都需要自动化测试经验。但当她开始工作后就发现这些公司都试图做自动化测试但是结果大多不怎么地。不过尽管她参与的都是一些杯具的项目不过她总能把这些杯具包装成洗具以应对下一次面试。所以呢既然自动化测试有那么多优势为什么还有那么多项目做失败了呢我个人有个推论自动化测试的优势都是自动化测试成功完成得到的结论而自动化测试的劣势才是自动化项目立项的基础。还有个优势自动化测试可以将产品的知识固化到脚本中以降低测试人员流动对项目造成的影响。但是这个优势的前提是这些脚本易于维护这就需要一些必要的文档这又是另一个议题了。3、自动化测试无法做到的事以及劣势永远不可能完全替代手工测试自动化测试无法做到手工测试的覆盖率不是每个测试用例都适合做成自动化如建议一个页面的布局是否正确、安装测试、文档测试、兼容性测试、恢复性测试。手工测试发现的缺陷远比自动化多。自动化测试是几乎无法发现新缺陷的最大的用途是用来回归确保曾经的bug没有在新的版本上重新出现。自动化测试工具是死的它不具备任何想象力。自动化测试的好坏完全取决于测试工程师。成本投入高风险大。对测试人员的技术要求高对测试工具同样有要求。关于成本包括了资金预算人力资源人员培训硬件资源等。下图显示了自动化测试的投入成本与时间的关系很显然前面多数时间成本是很高的。基于以上劣势所以虽然“贵为”自动化测试工程师我有一大半的时间在劝老板“亲能不能不做自动化”。这真是个悲伤的故事。4、合适引入自动化项目周期长系统版本不断并且需求不会频繁变更此时是适合引入自动化测试的。系统的测试对象基本可以正常识别以及对无法识别的控件能否提供一个解决方案。系统中不存在大量的不可识别第三方控件。需要反复测试如可靠性测试、回归测试等需要进行上千次的系统测试。5、不适合自动化项目周期短需求频繁变更。即使是周期长的项目如果经常需求变更也不适合做自动化。软件版本还没有稳定的情况下主功能或大量功能有被重新更改的可能话也不适合做自动化。没有明确的项目测试自动化计划措施和管理。多数对象无法识别以及脚本维护频繁与艰难二者有其一自动化必定失败。6、自动化测试的流程合理的自动化切入点 通常项目只有经历了完整的系统测试之后才算具备了基本的引入测试自动化的条件。个人观点无论什么测试越早介入则越有利于降低成本降低风险。而随着新型的开发模式兴起自动化测试也具备了尽早介入的条件。比如敏捷开发中某核心模块核心功能完成后则可针对该模块的该功能开始实施自动化测试。测试自动化分析1可行性分析2抽样demo分析,demo一般选取冒烟测试用例检查脚本是否能够成功运行通过已设计的测试点是否全部执行3测试需求分析分析哪些功能点准备进行自动化1可行性分析是自动化测试最重要的部分之一。可行性分析是自动化测试最重要的部分之一。可行性分析是自动化测试最重要的部分之一。重要的话要讲三遍。关于可行性分析请参考2,3,4,5点你的一个错误决定自动化测试项目立项很可能给好几个人带来全职工作机会从这个角度来讲还能促进鸡的屁2抽烟Demo主要还是用来验证你的工具是否能用3自动化测试不是100%测试不可能达到手工测试的覆盖率要筛选功能点进行自动化测试测试计划定制自动化测试计划越全面后期越能循规蹈矩的去实施自动化测试的成功率越高计划赶不上变化有时候太全面了或许也不是什么好事。自动化测试设计阶段主要分为自动化测试框架和自动化测试用例。1自动化测试框架的设计开发与搭建应能保证测试的分布执行脚本模块化数据驱动日志分析错误截图报表回收共享对象库公共函数库环境配置统一设计模式异常处理场景恢复的一个无人值守的针对每个独立项目的测试框架关于为什么需要自动化测试框架我有另外一篇文章详细说明了这里不再复述然后我顺便说说找对象的事是自动化测试框架找对象不是我找对象通常每种框架都应该支持动态跟静态两种找对象的方式静态找就涉及到对象库包括对象库的读、写、合并、维护等一系列问题这些都可以交给框架做关于动态查找我举个RFT的例子你们意会一下Two types of find API in Rational Functional Tester:find(Subitem Properties).find(Subitem Properties, Boolean mappableOnly).Subitems can be either atChild() or atDescendant() or atList().atChild: One or more properties that must be matched against the direct child of the starting TestObject.atDescendant: One or more properties that can be matched against any child of the starting TestObjectatList: A sequential list of properties to match against. Valid subitems for atList are atChild, atDescendant, and atProperty.mappableOnly: Arguments that limit the search. If it is set to true, the search for children will be limited to those test objects that are mappable, otherwise non-mappable test objects are also searched.首先测试工具会提供动态查找的接口或者方法RFT里面提供的是find方法调用这些接口或者方法即可实现动态查找。动态查找的好处是可以采用“相对路径”来定位对象而相对的对象库则采用的是“绝对路径”。如果一旦对象的一些属性改变静态查找的方式可能会找不到对象当然了现在的自动化测试越来越智能已经可以做到选取匹配度最高的对象返回。动态查找还有个好处是它找到的对象是“代码”你可以进一步在框架里去对这些对象进行处理而对象库里的每一个对象都是一个独立的对象你可以使用它们但是很难改变它们。通常现在的自动化测试框架都是采用动静结合的方式即两种找对象的方式都会兼顾因为一般来说静态查找的方式速度更快效率更高。但是静态查找带来的问题也是显著的主要集中在对象的维护管理以及合并上如何共享对象避免重复加对象等。此时规范对象命名就显得很重要了。以往我做的自动化测试项目中这些都是坑。2自动化测试用例设计三部曲手工测试用例是从无到有然后自动化测试用例是根据手工测试用例来写的。首先筛选手工测试用例。然后转换手工测试用例最后新增补充自动化测试用例。为什么不能用手工测试用例完全替代自动化测试用例自动化测试用例的范围往往是核心业务流程或者重复执行率高的自动化测试的覆盖率不能达到手工测试的覆盖率。自动化测试的用例选择一般以正向为主而反向的情况却有很多但是并不是所有反向情况自动化测试都会涵盖而是有筛选的选取一部分。也并不是所有的手工测试用例都可以用来做自动化的如页面布局的检查。手工测试可以不需要回原点但是自动化测试往往是必须的。自动化测试用例与手工测试用例不同不需要每个步骤都写预期结果。通常做自动化测试的时候我都会写一个叫做shake-down test的测试用例这个用例会把系统里所有完成了的表单都过一遍只是做一个Navigate的操作以确保某个页面是否可用。每次做回归测试前可以先跑一遍shake-down test很快可以确定哪些功能是accessible相当于做了一整个系统的一个冒烟测试。测试脚本设计与开发测试脚本大致可划分为1线性脚本通过录制直接产生的线性可执行的脚本2结构化脚本具有顺序循环分支等结构的脚本3可共享脚本可以被多个测试用例使用被其他脚本调用的脚本即模块化的脚本4数据驱动脚本测试数据跟业务流程控制分离的脚本通过读入数据文件来驱动流程进行的脚本5关键字驱动脚本脚本数据业务分离数据和关键字在不同的数据表中通过关键字来驱动测试业务逻辑。关键字驱动的特点是它更像是描述一个测试用例在做什么而不是如何做。6混合型脚本以上任意两种及以上7敏捷自动化测试脚本/框架这一块等我有了成功经验再补充。自动化测试执行1无人值守的测试环境搭建部署与配置自动化测试用例与测试脚本相互绑定自动化测试用例执行顺序排列与组合2异常处理与场景恢复提交自动化测试产物大致需要提交执行情况测试结果分析报表测试报告质量情况等。测试脚本维护严格来讲每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。