关于自动化测试的问与答

前言：

自动化测试是测试行业里一个古老的话题。简单总结一下自己的一些思考。

问题1： 什么是自动化测试？

自动化测试是软件测试的其中一种手段。特定是在于自动化：

自动化执行：以程序的方式替代手工执行用例步骤。所以一条用例可以完全自动化执行。

自动化记录执行结果：执行过程中可以通过断言来判断用例是否执行成功，并将结果记录下来。

自动化触发：通过与Jenkins 等 CI 工具集成，可以根据条件自动触发任务执行，完成测试。

个人观点：自动化不是什么神秘、高大上的技术，归根到底还是一种测试手段。

问题2： 什么情况下适用自动化测试？

自动化测试的目的是以机器执行，节省人工执行的成本，所以测试执行的次数、频率越高，越能体现自动化的价值。常见的使用场景：

迭代次数较多的项目。这样每次在迭代开发时，都可以发挥自动化的作用，快速回归测试，发现问题。

长期维护的项目。项目上线运行过程中可能需要进行一些优化和bug 修复，在版本更新时自动化测试也可以节省一部分的手工测试工作。

个人观点：只要是有重复性的执行（即使可能只跑3-5次）或者是需要跟进维护的项目，都有自动化的价值。

问题3： 自动化测试=UI 自动化吗？

虽然提到自动化测试就会想到QTP、 selenium 等UI 自动化测试工具，但自动化测试的范畴并不局限于UI自动化：

UI 自动化。与用户场景以及传统的黑盒手工测试场景最为贴近，常见的工具有QTP、selenium等。

接口自动化。随着微服务框架的流行，前后端、甚至后端不同服务间的开发分离，接口的功能稳定越来越重要。因此越来越多的测试团队开始重视和搭建接口自动化框架。常见工具有jmeter、loadrunner、postman、python request 等。

单元测试自动化。单元测试也是自动化的一种，可以在代码编译期间完成对应的测试，快速发现问题。

性能测试、兼容性自动化。目前主流的 app 都需要在云测平台上进行兼容性测试，其实所在的就是兼容性、性能的自动化。

数据自动化生成。有时候因为业务需要，需要制造大批量的数据，这时可以编写一些相关的脚本，快速生成。

个人观点：任何重复劳动，都可以想办法用工具来辅助。

问题4： 自动化测试可以替代手工测试吗？

自动化测试能否代替手工测试，取决于以下几个条件：

自动化用例的执行是否可靠？即设置的断言是否完整、测试结果是否可信。

自动化用例的健壮性是否足够？即能否保障频繁的重复执行 。

自动化用例的覆盖面是否足够？正常情况下是没办法把所有的场景都在自动化用例中实现（受编写用例、维护用例的成本限制）的，所以常见是把重要功能用自动化用例覆盖，配合部分人工执行，来完成回归测试。

个人观点：自动化测试是手工测试的辅助手段，两种可以结合起来使用。

问题5：项目时间紧的情况下，能不能做自动化测试？

这是很多团队或者测试人员拒绝使用自动化测试的理由：都在加班测试了，哪有时间做自动化？

但其实自动化是一种提高测试效率（机器执行比手动执行效率高）、确保测试覆盖面（手动执行可能会受疲劳因素的影响导致漏测，而机器可以保障设计的用例一定会执行）的工具，合理地使用自动化测试，可以把测试人员从重复、枯燥的执行中解放出来（不能完全解放，也能节省一部分的工作量），把精力投入到其他的方面。

个人经验：抽出半天时间把基本功能用例转换成自动化用例，可以节省不少的回归工作！

问题6：这个自动化测试工具可以解决我们的所有问题吗？

这是另一个拒绝使用自动化测试的常见理由：你的框架或者工具不完美，我不想用。

没有任何一种工具可以完美解决你所有的痛点。只要能解决对你最重要的其中一个痛点，就值得去推行，然后在实用中发现自己的需求和更多痛点，不断改进。

个人观点：勇敢迈出第一步最重要。

问题7：自动化测试根本发现不了bug ，价值不大。

针对这种想法，可以延伸到这个问题：

测试的根本目的是什么？ 是为了发现bug ，还是为了确保大部分使用场景下没有bug？

平时做的回归测试会发现很多bug 吗？ 如果没有bug ，是不是就没有价值？假如自动化测试执行了100个用例，没有发现bug ，是不是代表这100个用例没有价值？

个人观点：测试的目的是质量保障，就是保障正常场景没有问题；只要验证了对应的点，就产生了价值。

问题8：你不是做了自动化测试吗？为什么还会有bug 漏测？

自动化测试本质上还是测试用例的另一种执行方式。因此如果测试用例覆盖面不够，不管是手动执行还是自动化执行，都不能避免漏测。

个人观点：自动化测试不是万能。自动化省下来的时间，还是要花在进行更多手动测试上。

问题9：自动化不就是简单录制和写一些代码嘛，没什么技术含量。

自动化测试的入门介绍往往是很简单的，QTP 的录制回放、selenium的各种语言版本 helloworld教程，都能在很短时间里照着实现。

但当你在慢慢做下去的时候，就会遇到以下的问题：

为什么用例有时报错，有时又问题？ 这是用例健壮性需要好的设计。

UI 改了一个界面的按钮，要修改十几个用例? 这是用例结构需要设计合理。

200个用例跑了2个小时？ 用例的执行效率需要提高。

用例跑完之后不好统计结果？ 需要合理的报告统计。

个人观点：talk is cheap， show me the code！

问题10：不就是敲代码吗，找个应届生两个月就入门了；还是先把用例设计什么的基本功做好吧！

各种测试工具和用例设计一样都是测试的基本功，都可以为提高测试效率和质量保障起作用。

个人观点：技多不压身；在测试行业，仅有一技之长是不够的。