前面介绍了功能测试和接口测试，在介绍接口测试时提到了实现API自动化。那具体什么是自动化，为什么要做自动化，这里我们集中总结。

一. 什么是自动化？

顾名思义，自动化测试是相对人工测试而言的，它是指把人工对软件的测试行为转化为由机器执行的一种实践。

需要说明的是，单元测试属于白盒测试，很多公司的单元测试都是由开发人员负责，本文不作讨论。本文讨论的重点是API测试和GUI测试。

手工API测试的做法是，使用接口测试工具（例如Postman），然后操作以下步骤：

1. 输入接口URL
2. 选择请求类型，例如GET、POST等
3. 填入header和参数信息
4. 发送请求
5. 验证响应，包括响应码和响应体。
6. API自动化即是自动请求对应的API，并自动验证其结果是否符合预期。

手工GUI测试的做法是，打开待测系统，参考根据需求写好的测试用例，逐个手动点击，验证结果是否符合预期。

GUI自动化即是模拟人工在软件界面上的各种点点点操作，并自动验证结果。

二. 为什么要做自动化？

自动化测试听起来很美好，可以将测试人员从简单重复的劳动中释放出来。但自动化测试的的本质是用一段代码（自动化用例）测试另一段代码（开发实现的业务逻辑），所以自动化用例本身属于开发工作，并且要随着被测对象的更新而更新，因此也有一定的维护成本。

既然有开发和维护成本，就要考虑其性价比。来看看自动化测试的优势：

1. 自动化测试可以替代大量的手工重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上。
2. 自动化测试可以答复提升回归测试的效率
3. 自动化测试可以更好地利用无人值守的时间频繁地执行测试，适合需要7*24小时持续运行的系统稳定性测试的关键业务

自动化测试可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏和疏忽
再来看看自动化测试的劣势：

自动化测试不能取代手工测试
自动化测试本身不具有任何“智能”，它只是按部就班地执行事先定义好的测试步骤并验证结果，无法应对被测系统的变化
自动化测试有一定的开发和维护成本。统计表明，当自动化永利的有效执行次数>=5时，才能收回自动化测试的成本。
自动化测试仅能发现回归测试范围的缺陷，无法像手工测试一样做探索性测试
结合自动化测试的优势和劣势，哪些场景适合使用自动化测试呢？

需求稳定、不会频繁变更的场景
需要频繁执行回归测试的场景
通过手工测试无法实现或者手工测试成本太高的项目
例如上面说的需要7*24小时保证稳定性的关键业务，用自动化测试技术可以不间断地操作。

三. 做自动化测试的准备工作

以测试用户登录为例，手工测试的步骤如下：

注册用户
测试用户登录
这里面有两个问题：

注册时，需要注册服务是可用的，如果无法注册用户，测试也就阻塞了
测试时，该用户没有被使用。换句话说，如果此时恰好有人做删除操作，把你刚创建的用户删除了，则测试失败。
问题1是测试数据的准备问题，问题2是测试环境的干扰问题。

3.1 测试数据的准备

仍然以测试用户登录为例，我们有几种方法来获取注册的用户：

直接通过GUI操作
这种方法简单直接，但效率较低
调用API生成
实现上没问题，问题是一个前端操作可能会调用一系列后端API，且不说获取这一些列API遇到的问题，单单逐个手动操作去调用的过程，都赶得上直接在前端操作了。
通过数据库操作
实现上没问题，问题是一则测试同学并不清楚一项业务修改了哪些数据库表，其次就算知道了手动插入也麻烦，而且直接修改DB的数据，一个不小心误删了或误改了，想想手都要抖。

其实还有一种比较好的方法，调用API或通过数据库操作，做成自动化工具。例如，正常的注册需要输入用户名、密码，甚至还有邮箱手机号啥的，最后生成了账号。而如果你要测试用户登录功能，用户名、密码、邮箱、手机号都不是要关注的重点，换句话说，这些值是什么都无所谓，你只是要一个可以登录的用户名/密码即可。由此我们可以在了解了API调用序列之后，做成自动化工具（需要有前端知识），有默认的用户名（例如test+<时间戳>）和密码（例如 test123），一键注册。如此则大大提高了效率，降低了手动操作的错误的可能性。

从广义上说，自动化工具的实现，也是自动化技术的一部分。

3.2 测试环境的准备

平时测试人员的操作都是在测试环境上进行的。需要专门为自动化测试搭建并维护一套测试环境吗？很显然，是有一定的物质成本和维护成本的。如果并用一套测试环境，会相互干扰。尤其是很多流程比较长的业务，你要验证一个环节，可能刚好这个数据被别人用了，就会导致用例的失败，由此又要去分析，最后发现是数据的问题。这里说下我曾经接触过的几个解决方案：

自动化用例中实时搭建环境，自动化用例执行完再释放环境
优点：自动化测试环境天然的隔离
缺点：实时搭建环境不仅需要大量的服务器，还需要大量的时间。
因此并不适用快节奏的互联网产品
分别维护手工测试环境和自动化测试环境
优点：数据的隔离
缺点：有更新时需要部署并维护两份。
互联网产品的快节奏决定了部署是很频繁的，这种方法效率也比较低
共用手工测试环境和自动化测试环境
优点：只需要部署并维护一份环境

缺点：数据会相互干扰

当然，可以有其他办法来解决数据的干扰，譬如命名规范，自动化用例相关的用户等固定有个前缀（例如auto），大家手工测试时不使用这类的数据。

使用哪种方案，要依据当前要解决的问题来决策。如果自动化处于起步阶段，大可先共用环境，等自动化建起来再说；如果比较成熟了且数据干扰严重，可以考虑维护两套环境等。

四. 自动化技术简介

4.1 API自动化技术

代码级的API测试是比较简单的，因为API测试的基本步骤是很标准的：

准备测试数据
发起请求
验证响应结果
而无论是请求参数还是响应参数，都是K-V的键值对，验证结果只需要解析这些键值对即可。因此常用的类和方法也就那么几种。

难点在于：业务流程设计哪些接口，接口用例如何设计、如何组织管理等。

本文不详细介绍，有时间 & 有人需要，我再更新吧~

4.2 GUI自动化技术

GUI自动化测试的核心思想是，基于页面元素识别技术，对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性。

GUI自动化测试主要有两大方向：

传统web浏览器的GUI自动化测试：主流方案是selenium
移动端的GUI自动化测试：主流方案是Appium，app+selenium
先来了解一下selenium和appium的工作原理。

作为TE的你肯定知道，selenium1.0和2.0的技术是截然不同的。前者的核心是Selenium RC，而后者的核心是webDriver。鉴于目前的2.0和3.0（和2.0本质是一样的）是主流，这里只介绍selenium 2.0的工作原理。

Selenium 2.0是典型的client-server模型，client端即测试用例，sever端即远程服务器，其执行流程如下：

了解原理之后，剩下的工作就只剩下用代码实现测试用例了。当然这里面的关键就是，如何识别页面元素（有人需要的话，专门开一篇来介绍）。

正确识别了页面元素，代码就是验证业务流程。这部分本身属于开发工作，和开发写代码一样，需要有代码规范、分层设计、封装（模块的封装、页面对象的封装等）。

五. 常见面试题

1. 如何定位页面元素
2. APP测试和web测试有什么区别？
3. 接口自动化是如何做的？
4. GUI自动化测试的原理及步骤
5. GUI自动化测试中，如何保证测试用例的稳定性？

六. 思考和总结

本文介绍了自动化的概念及为什么要做自动化，做自动化测试需要做的准备工作：测试数据及测试环境，最后简单介绍了代码级别的自动化测试技术。

从广义上说，自动化技术不仅仅包含代码实现的测试用例，还应包含代码实现的自动化工具。

关于代码级别的自动化测试技术，以后有了时间再来更新细节~

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！