前言
一直以来，测试团队都面临一个迫在眉睫的问题：自动化测试收效甚微，甚至被认为是"为了实现自动化而自动化"。之前写过一篇博客自动化测试的评价维度，其实自动化的评价不乏有其他的评价指标。但这里想说的一点是，自动化方案产出低的一个重要原因是自动化整体方案的不合理。
下面根据自己的经验，做下总结，个人之见，不免有不足之处，欢迎补充交流！！！
** 自动化整体方案不合理的证据**
1、自动化发现bug率太低/甚至很长一段时间没有发现过bug
可能你会说自动化本来就不如手工测试容易暴露问题，况且有些业务本来bug就不多。但注意了，这里强调的是自动化发现bug的占比，如果这个比例趋向于0，那自动化实现的价值还有多少呢
2、没有减少手工成本/或时间成本
自动化虽然也不断暴露问题，但自动化测试一次，与手工测试一次相比，并没有节省多少 人工成本和时间成本(例如，执行过程中还需要人工参与等)，甚至反而增加了自动化的维护成本。那么这样算起来，自动化可能成为了一种"摆设"。
这种情况流行的一种说法是："为了自动化而自动化"。将不适合做自动化的地方，强行自动化实现后，是得不偿失的。
3、自动化运行失败， 极大概率并不能说明真的bug存在
这在实际业务中，是大多数实现自动化的测试同学比较痛心疾首的情况了。日常的工作就是不断调试自动化，确保运行时不再那么频繁失败了。很早之前，自己也曾经历过这样的痛苦。
这种情况除了白白浪费很多时间精力外，还会让参与自动化建设的同学丧失继续实现自动化的信心。 说白了，自动化实现的目标是帮测试同学干活的，如果失去这个作用，还不如果断放弃自动化。
4、自动化执行后仍然需要重复投入手工测试
这种自动化运行类似于"空跑"一样，并没有起到什么作用，其实这种情况也是"为了自动化而自动化"的一种证明了。目前很多团队评价自动化好坏的重要指标就是自动化case数量、运行稳定性/成功率，其实这两个指标对评价自动化并没有那么的有说服力。
自动化整体方案不合理的几个原因
根本原因是自动化整体方案与实施不合理，具体说来，有几点值得注意：
1、自动化方案与手工测试流程千差万别
不会做手工测试的同学，真心很难做好自动化测试(当然了，这里的自动化排除掉压测)。不敢想象，如果自动化方案与手工测试流程完全不在一个维度上，自动化怎么能像手工测试一样大量暴露问题呢！！！
2、实现的自动化只能"一条腿走路"
这里说的"一条腿走路"是说，只实现了半自动化，并没有实现100%的自动化，运行前/中/后需要人为参与。 半自动化的例子，在实际的业务中，还是挺多见的。比如，自动化执行前输入人为输入一些参数、或自动运行前需要人为准备一些数据、或自动化运行后需要人为check一些东西。
3、试图将一切自动化
所谓过犹不及，试图将一切自动化的后果是自动化变得臃肿不堪，要么常常失败，要么成了摆设。
4、没有根据业务实现特点进行自动化
各个公司/团队的业务、实现千差万别，哪怕是不同产品线都会因为团队合作、迭代、架构设计的不同，导致自动化方案的千差万别，进而自动化使用的工具、平台都会有很大不同。因而，在别的业务上运行完美的自动化，拿过来直接用，很可能会产生"水土不服"。
如果自动化目前用的不顺手，或者没有达到效果预期，那么不妨评估一下，你的自动化方案是不是也正在"水土不服"呢
** 写在最后**
自动化实现的方法论：
1、承认不是所有的东西都适合自动化；
2、自动化测试的前提是强大地进行手工测试；手工测试是自动化测试的必要条件。自动化测试应该尽可能模拟手工测试的流程
ps: 这里的手工测试，当然是完美、大神级别的了， 并不是仅仅是说点点点的功能级别测试
3、自动化实现之前，不妨先列一些自动化实现最为核心的目标。
在频繁的迭代上线过程中，如果遗漏到线上的问题太明显，太多，这是测试技能问题；但如果线上无遗留，测试技能没有问题，只能说明自动化整体方案可能有很大的提升空间。
【整整200集】超超超详细的Python接口自动化测试进阶教程合集，真实模拟企业项目实战