在最近加入的公司准备自动化测试的培训。 这是知道我要进行自动化测试的训练后，顺手画了个图，吓了我一跳：
这是我能想到的关于自动化测试的几点。 然后根据我三年前写的关于自动化测试的随笔进行了更新。 当然很遗憾，到目前为止，我接触并成功的敏捷开发项目还很少。 虽然敏捷软件近年来一直很受欢迎。 因为对于敏捷自动化测试这个块也只有一次不太成功的经验，所以文中避开了这个块：
1 .自动化测试是指用程序测试程序，用代码代替思维，用脚本运行代替手工测试。 自动化测试包括功能(黑匣子)自动化测试、功能(白匣子)自动化测试、性能测试、压力测试、图形用户接口(GUI )测试和安全性测试。
关于自动化是什么，我调查了一些资料，但是没有权威规范的解释。 以下摘自维基百科：
In software testing，testautomationistheuseofspecialsoftware (separatefromthesoftwarebeingtested )。 ocontroltheexecutionoftestsandthecomparisonofactualoutcomeswithpredictedoutcomes.testautomationcanautesomerepetitivebut sbut ingprocessalreadyinplace，oraddadditionaltestingthatwouldbedifficulttoperformmanually。
首先，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 TestObject
atList: 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）异常处理与场景恢复
提交自动化测试产物：大致需要提交执行情况，测试结果，分析报表，测试报告，质量情况等。
测试脚本维护：严格来讲，每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。
如果你①从事功能测试，想进阶自动化测试
②在测试界混了1、2年，依然不会敲代码
③面试大厂却屡屡碰壁
我推荐一个群吧！来吧~~测试员，313782132（Q群里有技术香蕉酒窝一起交流分享，学习资源的价值取决于你的行动，莫做“收藏家”）获取更多大厂技术、面试资料