以程序测试程序，以代码代替思维，以脚本的运行代替手工测试。自动化的测试涵盖了：功能（黑盒）自动化测试，功能（白盒）自动化测试，性能测试，压力测试，GUI（Graphical 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测试，你有想过怎么用手工不借助任何工具去做吗？所以它们天生就属于测试自动化的范畴。

回归测试更方便可靠 ；可运行更多，更繁琐的测试，且快速高效；可执行一些手工测试执行相当困难或者做不到的测试，如大量的用户并发；更好的利用资源，具有一致性和可重复性的特点，自动化测试脚本完全可复用；提升了软件的可信度；多环境下测试等。

自动化最实在的优势在于——工作好找：有一个测试工程师（并不是本人）发现一个有趣的现象，她申请过的几乎所有测试职位，在招聘时都需要自动化测试经验。但当她开始工作后，就发现这些公司都试图做自动化测试，但是结果大多不怎么地。不过，尽管她参与的都是一些杯具的项目，不过她总能把这些杯具包装成洗具以应对下一次面试。

所以呢，既然自动化测试有那么多优势，为什么还有那么多项目做失败了呢？

我个人有个推论：自动化测试的优势都是自动化测试成功完成得到的结论，而自动化测试的劣势才是自动化项目立项的基础。

还有个优势：自动化测试可以将产品的知识固化到脚本中，以降低测试人员流动对项目造成的影响。但是这个优势的前提是，这些脚本易于维护，这就需要一些必要的文档，这又是另一个议题了。

永远不可能完全替代手工测试，自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合做成自动化，如建议一个页面的布局是否正确、安装测试、文档测试、兼容性测试、恢复性测试。

手工测试发现的缺陷远比自动化多。自动化测试是几乎无法发现新缺陷的，最大的用途是用来回归，确保曾经的bug没有在新的版本上重新出现。

自动化测试工具是死的，它不具备任何想象力。自动化测试的好坏，完全取决于测试工程师。

成本投入高，风险大。对测试人员的技术要求高，对测试工具同样有要求。

关于成本，包括了资金预算，人力资源，人员培训，硬件资源等。下图显示了自动化测试的投入成本与时间的关系，很显然，前面多数时间，成本是很高的。

基于以上劣势，所以虽然“贵为”自动化测试工程师，我有一大半的时间在劝老板，“亲，能不能不做自动化”。这真是个悲伤的故事。

​

项目周期长，系统版本不断，并且需求不会频繁变更，此时是适合引入自动化测试的。

系统的测试对象基本可以正常识别，以及对无法识别的控件能否提供一个解决方案。

系统中不存在大量的不可识别第三方控件。

需要反复测试，如可靠性测试、回归测试等需要进行上千次的系统测试。

项目周期短，需求频繁变更。即使是周期长的项目，如果经常需求变更，也不适合做自动化。

软件版本还没有稳定的情况下，主功能或大量功能有被重新更改的可能话，也不适合做自动化。

没有明确的项目测试自动化计划，措施和管理。

多数对象无法识别，以及脚本维护频繁与艰难，二者有其一，自动化必定失败。

​

合理的自动化切入点： 通常，项目只有经历了完整的系统测试之后才算具备了基本的引入测试自动化的条件。

个人观点：无论什么测试，越早介入则越有利于降低成本，降低风险。而随着新型的开发模式兴起，自动化测试也具备了尽早介入的条件。比如敏捷开发中，某核心模块核心功能完成后，则可针对该模块的该功能开始实施自动化测试。

测试自动化分析：

（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）异常处理与场景恢复

提交自动化测试产物：大致需要提交执行情况，测试结果，分析报表，测试报告，质量情况等。

测试脚本维护：严格来讲，每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。

最后我邀请你进入我们的【软件测试学习交流群：785128166】， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路

作为一个软件测试的过来人，我想尽自己最大的努力，帮助每一个伙伴都能顺利找到工作。所以我整理了下面这份资源，现在免费分享给大家，有需要的小伙伴可以关注【公众号：程序员二黑】自提！