自动化测试是测试行业里一个古老的话题。简单总结一下自己的一些思考。
自动化测试是软件测试的其中一种手段。特定是在于自动化：
自动化执行：以程序的方式替代手工执行用例步骤。所以一条用例可以完全自动化执行。
自动化记录执行结果：执行过程中可以通过断言来判断用例是否执行成功，并将结果记录下来。
自动化触发：通过与 Jenkins 等 CI 工具集成，可以根据条件自动触发任务执行，完成测试。
自动化测试的目的是以机器执行，节省人工执行的成本，所以测试执行的次数、频率越高，越能体现自动化的价值。常见的使用场景：
迭代次数较多的项目。这样每次在迭代开发时，都可以发挥自动化的作用，快速回归测试，发现问题。
长期维护的项目。项目上线运行过程中可能需要进行一些优化和 bug 修复，在版本更新时自动化测试也可以节省一部分的手工测试工作。
虽然提到自动化测试就会想到 QTP、 selenium 等 UI 自动化测试工具，但自动化测试的范畴并不局限于 UI 自动化：
UI 自动化。与用户场景以及传统的黑盒手工测试场景最为贴近，常见的工具有 QTP、selenium 等。
接口自动化。随着微服务框架的流行，前后端、甚至后端不同服务间的开发分离，接口的功能稳定越来越重要。因此越来越多的测试团队开始重视和搭建接口自动化框架。常见工具有 jmeter、loadrunner、postman、python request 等。
单元测试自动化。单元测试也是自动化的一种，可以在代码编译期间完成对应的测试，快速发现问题。
性能测试、兼容性自动化。目前主流的 app 都需要在云测平台上进行兼容性测试，其实所在的就是兼容性、性能的自动化。
数据自动化生成。有时候因为业务需要，需要制造大批量的数据，这时可以编写一些相关的脚本，快速生成。
自动化测试能否代替手工测试，取决于以下几个条件：
自动化用例的执行是否可靠？即设置的断言是否完整、测试结果是否可信。
自动化用例的健壮性是否足够？即能否保障频繁的重复执行 。
自动化用例的覆盖面是否足够？正常情况下是没办法把所有的场景都在自动化用例中实现（受编写用例、维护用例的成本限制）的，所以常见是把重要功能用自动化用例覆盖，配合部分人工执行，来完成回归测试。
这是很多团队或者测试人员拒绝使用自动化测试的理由：都在加班测试了，哪有时间做自动化？
但其实自动化是一种提高测试效率（机器执行比手动执行效率高）、确保测试覆盖面（手动执行可能会受疲劳因素的影响导致漏测，而机器可以保障设计的用例一定会执行）的工具，合理地使用自动化测试，可以把测试人员从重复、枯燥的执行中解放出来（不能完全解放，也能节省一部分的工作量），把精力投入到其他的方面。
这是另一个拒绝使用自动化测试的常见理由：你的框架或者工具不完美，我不想用。
没有任何一种工具可以完美解决你所有的痛点。只要能解决对你最重要的其中一个痛点，就值得去推行，然后在实用中发现自己的需求和更多痛点，不断改进。
针对这种想法，可以延伸到这个问题：
测试的根本目的是什么？ 是为了发现 bug ，还是为了确保大部分使用场景下没有 bug？
平时做的回归测试会发现很多 bug 吗？ 如果没有 bug ，是不是就没有价值？假如自动化测试执行了 100 个用例，没有发现 bug ，是不是代表这 100 个用例没有价值？
自动化测试本质上还是测试用例的另一种执行方式。因此如果测试用例覆盖面不够，不管是手动执行还是自动化执行，都不能避免漏测。
自动化测试的入门介绍往往是很简单的，QTP 的录制回放、selenium 的各种语言版本 helloworld 教程，都能在很短时间里照着实现。
但当你在慢慢做下去的时候，就会遇到以下的问题：
为什么用例有时报错，有时又问题？ 这是用例健壮性需要好的设计。
UI 改了一个界面的按钮，要修改十几个用例? 这是用例结构需要设计合理。
200 个用例跑了 2 个小时？ 用例的执行效率需要提高。
用例跑完之后不好统计结果？ 需要合理的报告统计。
各种测试工具和用例设计一样都是测试的基本功，都可以为提高测试效率和质量保障起作用。