什么是自动化测试
俗话说，懒人有懒法，自动化就是所谓的懒人方法。用工具代替人工干一些重复性的工作。自动化测试也就是用一些自动化脚本或工具代替手工测试。我们只需要配置一些环境信息、测试数据，运行自动化脚本，即可进行测试。在测试过程中，通过脚本判断输出的正确与否。自动化脚本执行完毕后，所有测试用例的执行结果都保存在文件中。测试人员只需要对失败的用例进行再次分析，大大减少了测试时间，提高测试效率。
为什么要做
我们在对产品或业务进行测试时，可能会遇到以下这几种情况：
（1）一直在重复做某些操作（比如重复的代码、重复的参数、重复的判断、重复的逻辑等）
（2）相同的产品或业务，不同的环境，不同的版本，不断的配套测试
（3）新增功能，担心对产品老功有影响，要对老功能的全量覆盖测试
这时我们就很有必要对测试实现自动化了。因为实现自动化后，可以大大节省测试时间，提高测试效率。相同的工作，反复的手工测试，最容易让测试人员产生疲劳感，发现错误的效率必然降低，尤其是一些简单低级的错误（人工很容易忽略，潜意识认为软件不会出现低级错误），如果用自动化测试则可避免这些问题。
是不是需要实现自动化
当我们准备对某产品或业务的测试实现自动化之前，首先而且必须要考虑的是，是不是需要做自动化
（1）是不是稳定的
如果待测试的产品是新开发的，还在迭代开发中，有些东西还没有完全确定，这类产品就不适合立即实现自动化。因为开发人员对代码不断改动，会造成自动化测试工程也要随之改动，对人力和时间都有一定的损失。如果待测试的产品已经开发完成，功能基本都实现且稳定，则比较适合实现自动化。
（2）是不是一次性的
这里要从待测试产品的性质来看，如果待测试的产品并非用户实际使用，经常操作的，例如只是演示的demo等，像这类的则没有必要去实现自动化。我们要对产品的实际功能，用户真正使用的东西，使用自动化测试可以提高效率的才去实现自动化。
（3）实现自动化的成本
对于自动化实现方法简单，短时间或有限时间内就可以搞定的，那就果断去做。如果实现方法不定，实现人员的能力有限，实现过程比较艰难，搞自动化需要耗费大量的人力和时间，投入大于产出，则不推荐一定去做自动化。
什么时候做
大家都知道，测试越早进行越好，越早发现错误损失会越小。在软件开发生命周期中，我们应该尽量做到测试前移。在设计阶段，测试人员就需要对产品需求进行分析，及时发现设计人员对产品需求理解的一些偏差。在理解产品需求的同时，要主动和设计开发人员沟通，对产品的实现开发流程有所了解。在开发人员进行产品开发时，测试设计人员可进行测试框架的搭建，分析后续测试的重复劳动性，对于有必要实现自动化的测试，在此阶段就可进行自动化实现方法的预研。要有前瞻性，能做到前面的事情尽量提前做，为后续的测试工作做好铺垫。
怎么做
自动化就是要解决重复劳动的问题，怎么做不用拘泥于语言、形式、方法。不论黑猫白猫，能抓到老鼠的就是好猫。可以是一段自动化测试的代码、可以是一个可操作的界面、也可以是命令行脚本等，根据产品的形态灵活实现。
此处以接口自动化测试实现为例，rest接口测试，不同的请求对应不同的响应。同一个接口，不同的入参，接口调用后返回不同的出参。
自动化实现：参数配置文件+测试用例文件+自动化脚本+测试结果文件 （测试用例也可以直接关联在参数配置文件或自动化脚本中）
参数配置文件：公共参数，使用全局变量来定义。不同测试用例使用的参数均可定义在参数配置文件中。
测试用例文件：保存待测试的所有正常异常的用例，文件可以是txt文档，也可以是.java、.cpp、.py等等
自动化脚本：脚本主要是实际接口调用，处理接口入参，关联参数和测试用例，对于接口响应做判断（接口响应和预期值一样，则用例pass，否则用例failed）
测试结果文件：保存测试用例及用例测试结果，测试人员通过查看该文件，关注测试失败的用例。
不同的语言，可以根据语言的特点进行自动化。
自动化维护
自动化方法实现后并不代表就此结束，在进行自动化的测试过程中，可能会发现有些地方优化下，可提高自动化测试的效率，那我们还需要继续完善。
产品测试在实现自动化之后，如果产品部分功能有所变更，那我们的自动化脚本也要随之更新。