自动化测试并没有想象的那么完美
自动化测试到底都有哪些问题？我们为什么会经常感觉做不下去了？为什么投入那么多，效果总是那么一点点。
自动化测试本身有自动测试自己的问题，随着大量投入地去做自动化测试，这些问题会越来越明显，比方说：
- 编写维护自动化测试脚本成本太高了
- 天天在跑自动化测试，发现的缺陷数量怎么就那么少
- 自动化测试为什么就没有节约人力成本
- 自动化测试为什么就你们几个能用，那么多手工测试人员就不能用起来吗？
这些问题，其实本身不是自动化测试的问题，而是把自动化测试本身放错了位置。就像开篇说的，自动化测试其实不是这样的。
我们拿自动化测试怎么办
自动化测试一般都是需要编写脚本，通过脚本的执行来达到测试的目的，一般被测系统稳定的话，那么脚本是不需要怎么维护的，反之的话，就比较恐怖了。所以要进行自动化测试，就需要下工夫去开发维护脚本，而且工作量不小。由于他有这种特性，所以自动化测试，尤其是针对业务的功能测试中，最好不要去拼命地覆盖全业务，覆盖所有案例，而且抓住重点核心业务进行回归测试。这样可以减少开发维护工作量，还能尽量保证重点业务的测试质量，测试性价比是最高的。
原则1: 针对重点业务，进行回归的自动化测试
另外，尽量针对较为稳定的业务，或者较为稳定的测试方式进行自动化测试，这样人力的投入主要集中的初期脚本的编写，而之后由于较为稳定，那么脚本的维护工作量也不会太大。当然，这种投入不是越早越好，很多项目经理都觉得自动化测试及早投入，这样我们在项目研发中就可以及早用，及早的享受到自动化测试带来的便利。其实自动化测试，一般要做环境比较稳定的情况再投入开发，这样可以减少维护的成本，另外对于不稳定的环境，执行自动化测试也没有太好的效果，经常跑出的脚本一堆问题，分析来半天其实就是不能用，这样测试的意义就不大了。
原则2：针对稳定的业务（或接口），在环境比较稳定的情况，前期投入脚本开发，有利于减少后期维护成本
还有很多自动化测试，几乎每天都在跑，老是发现脚本错误，怎么就没有真正的缺陷呢，出缺陷的概率这么多，就盲目地增加校验点，结果还是一样。其实不用为了发现不了缺陷而烦恼，自动化一般都是保证主要功能完整可用，这些是他的核心价值，而不是发现多少缺陷。
原则3：自动化测试主要是为了保证主要功能完整可用，而不是为了多发现缺陷
当然，还有些人，做自动化就是为了节约手工测试人员的人力成本，做着做着，发现做了那么长时间自动化测试，为什么人力成本没有减少。不减少我为什么做自动化测试啊？这也是一个误区，自动化测试并不能减少测试的人力成本，而是为了加快测试反馈，提升测试质量。我建议自动化测试可以跟自动化部署工具绑定，在每日构建的时候，自动化执行，可以更早的发现产品的问题，自动地反馈开发人员，从而提升开发修复缺陷的效率。
原则4：自动化测试并不能减少测试的人力成本，而是为了加快测试反馈，提升测试质量
还有一个问题，这个问题在初期开始做自动化测试的人，会比较容易走上的误区----录制回放最好了。其实录制回放，并不好，录制的脚本很多时候是不能直接使用，而且业务或者系统发生变化，很有可能很难修改脚本需要重新录制恢复，这样的工作量也不小。而且还有很多人，自动化测试脚本应该跟业务能挂钩起来，让人一目了然我自动化测试脚本都做了些什么，脚本最好能做到"可视化"。其实这些看似的方便，都给脚本维护带来很多困难，业务和系统是在变化的，脚本是要不断维护，可视化和录制回放其实并不能提升效率，反而是为脚本维护增加工作量。建议如果有能力的话，对脚本本身进行管理即可，编写脚本不用录制回放，使用一些辅助工具，或者设计一些框架，编写脚本会更好。
原则5：不要对录制回放抱有幻想了，可视化也不是一个好的想法
最后一个问题，有很多人任务自动化测试执行这么方便，是否手工测试人员可以进行自动化测试啊？可以吗？很多人持不同观点，有的人任务测试其实要成为开发测试，有开发能力，去写自动化测试脚本；还有的人，觉得测试和自动化测试要分开，两个团队管理；还有的人任务，测试执行，测试数据编写等可以让手工人员参与。其实我觉得这都不是最好的想法。真正应该参与自动化测试的应该是开发。
原则6:开发参与自动化测试，让开发和测试融合在一起
作者：乱步
链接：https://www.jianshu.com/p/2473af93034b
來源：简书