做了几年自动化，也看了很多讲自动化的文章，基本上都是金字塔那个图
但是，我一直有一些疑问
1、都说自动化减少了测试的时间，在敏捷模式的团队里，自动化真的减少了测试的时间么？单次迭代的测试时间真的缩短了么？
我看到的大部分团队现状，在没有自动化之前是提测前写手工用例 1 天，然后提测后开始手工测试 3 天，4 天解决战斗，
在有了自动化之后，还需要额外 3 天去写自动化用例，于是 4 天解决的迭代变成了，7 天。
2、可能有同学要说，自动化解决了回归的问题啊，但是仔细想想，本次迭代改动影响到的点，原来的自动化用例能用么？还不是要花时间先去把原来的自动化用例改一改，然后才能再用，至此又多了自动化维护的时间，先不说维护需要多久，有的团队，自动化用例写的千奇百怪，你进去真的能维护起来么？维护起来的用例真的是有效的用例么？
3、我有一点想法，如果测试可以了解到开发的设计，程序的架构，再加上精准测试，是否就可以摆脱自动化了？起码目前来看，自动化对于大部分水平不行的团队不是帮助反而成了效率的负担，也是为了应付公司上面的负担。
通过以上，我得出了一些结论：不能盲目自动化，不考虑团队情况、项目情况盲目自动化是个很坏的决定，自动化并不是很好驾驭的一个东西，如果驾驭不好就无法提效，反而还会成为拖累。
欢迎各位大佬讨论
一般自动化测试分为两种 一种是接口自动化提前发现问题，一种是验收主流程。。所以和你说的并不产生冲突。在研发还未提测功能时，你就可以走接口测接口提前发现流程和一些单接口的问题还能提高健壮性。在迭代功能测完后也可以走验收主流程的自动化测试也能大大减少人力操作，因为有些迭代你也不知道是不是会影响一些主功能。所以自动化测试还是有必要的，能提高质量和保证质量
精准测试只有极个别的公司在推，自己想学习下都不知道如何入手，没法开展这个。效果怎么样，还得经过市场的考验吧。
小人物
回复
这是理想情况，但是往往的迭代过程都是研发还未提测功能时，测试还在上一个迭代的测试工作中。
走验收流程的自动化测试的话，那么花那么多人时投入自动化，是不是收益太低了？
结论很赞同，对于第二点简单说下看法：
首先每次小版本的迭代，影响的功能点或者说接口并不多，自动化稍作修改即可，比如有 100 个功能点，迭代影响 10 个功能点，则修改这 10 个即可，其他 90 个也可以用自动化跑。否则在手动测试大概率要跑 10 个改动的 +20/30 个可能有影响的。在发版前几天的迭代次数是很多的，这时候自动化就提现出来了。
Ikaros灬
回复
验收的话受益其实不低的，前期花点时间。提测功能那种也可以提前编写一些接口自动化的流程呀，提前保证一些流程性的业务，也花不了多少时间的，再评估看有没工作量的时间投入到一些细节测试，根据公司产品开发而定嘛。最主要的是前期推动，要从自动化体验出测试的价值
Miracle
回复
有这样一种场景，接口入参是定义了一个 bean，然后我在这个 bean 里面加了一个字段，校验是 NotNull，然后这个 bean 被很多个接口用到，那么在修改掉这个 bean 时，会导致自动化用例大规模的报错，然后再去一个一个修改自动化用例，这样成本就高了
其实这就涉及自动化的前提啦：成熟度
换而言之就是自动化的对象时那些固化的长时间不会进行更改的功能
实用性方面是有被过度夸大了，因为极大多数公司的产品状态其实是不适配的，但是一方面为了卷一方面为了面试都对其的出现率造成了一定程度的拉升
卷已是行业现状，面船干点也是既成事实
Ikaros灬
回复
这个就是具体的细节问题了，考虑下测试方法是否正确或者是否适合自动化。自动化在我司最重要的 2 个用途就是测试环境迭代回归和线上升级冒烟测试
被神化的一种可能是，能做到的人或者能做成功的人太少了。
不过有人很早就做成功了，看看十年前的段念，已经把自动化成功做起来了。
只能说很多公司还是在探索的阶段，人员的能力，产品的规划多少会有影响！
我司现状：接口自动化年初 LD 提出搞，哦···各个业务线的小组开始撸起袖子干，年中各组汇报接口自动化的 PPT，哦···完毕···几个月后，gitlab 上废弃了···
只能说楼主说的几点，都是自动化做不好的因素，和自动化本身没什么关系。 如果自动化做得好了，这几点都能在一定程度被解决。
- 敏捷模式： 难道你们的敏捷模式只跑一个 sprint？ 在后续的 sprint 里面不需要对已经做好的 story 进行回归测试？ 没有足够的自动化测试，怎么应对越来越多的功能和越来越大的回归测试范围？
- 因为产品变动引起的自动化测试维护问题。 首先确定一个点，你们的产品每一轮都会把所有的功能和页面都改掉吗？ 即使每一个 sprint 里面变动的功能有 20%，那维护的工作量也只是这 20% 的用例，而且如果 page object 的结构做得好的话，页面变动很多时候只是元素定位的变化，用例的本身不需要修改。
- 精准测试：
--1 首先你能保证每次提测的代码都可以识别到 100% 准确的影响范围？
--2 其次，如果识别出来的范围也很大，如果没有自动化测试，纯手工进行测试，工作量会小吗？
--3 再举个例子，如果开发和你说 JDK 升级了一个版本，或者服务器的操作系统升级了一个版本，你能精确识别出哪些测试范围呢？ 如果用足够的自动化，可能只是跑一次 job 的时间就能做到足够的覆盖，用纯手工的话要点多久？
而你最后的结论，都是基于你自己列举的自动化各种缺点得出来的，足够客观吗？ 能不能把优点也列出来对比呢？ 只看缺点的话，最后只会是一个片面的主观结论。
最后说一点吧，自动化测试都已经被提了几十年，从早期的商业化工具如 QTP，到已经迭代到 4.0 版本的 selenium，再到 appium，ATX， airtest ，cypress 等自动化框架，已经是百花齐放的局面了。如果只是盯着它的缺点或者不足，可能就会一直错过时代的发展。
自动化只是一个测试行为模式。
UI 自动化一开始投入会比现象中高，等大家熟练模式后，才能体会到好处。但是不包含录制回放的自动化，因为这个只是解决了一些问题，并不会让大家熟练模式。好比会使用微波炉，如果脱离微波炉，不一定会烹饪。
自动化还是要找到适用的场景，之前公司自动化做得好的业务，能从测试环境到线上环境一通跑下来，节省了不少回归时间；做得不好的主流程都没覆盖，都没跑起来，造成这种情况原因有很多：比如业务变更频繁，投入人力不足，人员能力参差不齐等等。自动化做成功的少之又少。
自动化测试本来就不是盲目的。。。一些项目本来就不适合自动化测试啊。不稳定的自动化测试用例实现比没有自动化更糟糕。
另外自动化测试优缺点我按自己理解罗列了下，供参考。
| 优点 | 缺点 |
|---|---|
| 提高测试质量 | 产生开发成本 |
| 提高测试效率，缩短测试工作时间 | 需要测试技术团队 |
| 提高单位时间测试覆盖率 | 脚本维护成本高 |
| 执行手工测试不易完成的测试任务（性能自动化测试） | 无创造性 |
| 更好的重现缺陷 | 引入更多的复杂性 |
| 更好的利用资源 | 容易出现偏离原始的测试目标 |
| 增进测试与开发合作伙伴关系 | 可能引入额外的错误 |
| 更快的反馈软件质量 | 更依赖用例的质量 |
| 提高测试系统稳定性和可靠性 | |
Jerry li
回复
现在企业里面有一种风气，就是测试必上自动化，尤其是领导层，只要一提到效率，必然就是做自动化，他们对于自动化的理解仅限于 ‘自动化’ 这三个字，对于他们来说，自动化就是被神话了，觉得自动化无敌，而不去考虑实施自动化所需要的前提条件，盲目追求自动化，最后时间没节省，反而更慢了
Ikaros灬
回复
测试必上自动化，我觉得这不是风气，而是每一个项目的管理者都必须会考虑到的必做项。
质量保障体系里面，有很多不同的环节：需求评审，设计评审，开发单元测试，系统集成测试，系统回归测试，用户验收测试，等等。而自动化是系统集成/回归测试阶段很重要的一步。
不做自动化，只用手动测试能做完集成测试和回归测试吗？ 当然可以。但问题是，你怎么保障测试的效率？怎么保证在不断迭代的过程中，测试人员不会疲惫而导致漏测？
我理解不是过度神话，可能是有很多人把它当做银弹了。把提高效率=自动化，没有根据实际项目去评估投入产出比。
其实视野大了后，提高效率的手段会多很多。比如多用靠谱的代码自动生成工具，有效减少手写代码的 bug，测试用例也可以精简不少；架构设计上减少重复，减少变更后要验证的范围，也能提高效率。只是确实会有一部分测试，视野只看到手工测试，提效想法就会局限在怎么让手工测试执行得更快，自然就会觉得能让执行速度大幅度提升的自动化非常好了。
我觉得不如楼主补充下，为何会觉得自动化被过度神话？是看了哪些资料产生这个感觉？
PS：金字塔的图印象中 2-3 年前已经改为菱形了，因为绝大部分互联网公司是不可能做那么完善的单测的，投入产出比相对高的是接口层的自动化。不知道你看的是什么时候的文章？
自动化测试并没有被神话……一直以来，因地制宜和投入产出比一直都是大家的讨论重点。但是自动化测试建设，是提质提效不可避免的可以尝试的一种方式
只是某些利益相关的人口中被神话了吧，而老板通常更会被这部分人影响。
其实，很多人老早就看到了你说的这些问题，而有些人只看到了问题，有些人却早就在想怎么解决这些问题了。
我很赞同 Jerry 的观点，只看到缺点的话，视线会被影响，只有同时明确自动化的优点和缺点，做到心里有数才能因地制宜。
生活有很多不如意，如果只看到不如意，应该不会快乐吧。
工作也一样。
今天自动化发现了一个策划配置 BUG，据测试同学说，这个 BUG 靠人工发现的难度很高
我理解，楼主说的是神化，而不是神话……按道理，自动化是应该被神化的，但是暂时还没有得到足够的重视
关于自动化测试，我想你可以看下这一篇文章：
Fixing a Test Hourglass
神话就过了，结合业务成功落了地的自动化确实好用，不好落地、维护麻烦，就没必要用，领导不懂这其中道理，直接跟他沟通就行了，好好讲，应该会明白的。
看了下评论，结合自己的思考，说说自己的看法
自动化测试主要作用有 2 个方面：
1.前端联调之前发现问题，这个我们之前是这样的做的，作用一般
2.回归测试，这个上面有个评论点到了，如果你的脚本的某个接口出现报错，是因为改字段出现的问题，这件事本身已经发现问题了，开发在写代码可能会遗漏一些场景，脚本发现了你再去改这个过程并不是一个无效的事务。功能测试每次回归测试漏跑了根本不知道，也没有数据支撑。
项目重构、合库等等，手工测试的效率的纵向测试面试不足的
在 PPT 上的内容基本上都是过度神话
实际的来讲，自动化只是一种 “方法”，重要的是用自动化达成的 “目的”（需求），这个 “目的” 能够大体决定自动化的 ROI
自动化还有一个重要的次要目标是代替人力，如果不能有效代替人力做掉繁琐重复的测试工作，那就是假的自动化
自动化并不是很好驾驭的一个东西——确实如此。没有一定技术基础，很容易做成假的自动化。
自动化有两种，基于 KPI 和 基于提高测试效率。
1.如果是基于 KPI，我们就做冲击 KPI 的事情，有没有用不要紧，领导喜欢，年底绩效给好，晋升加薪给好，愿意给人给时间，别说做没用的自动化，加入开发队伍做满全覆盖的单元测试都行。毕竟你没法改变领导的想法，就算想改变，你也得先照着领导意思做出数据来证明，KPI 考核的自动化对实际测试提效或质量建设没啥鸟用。
2.如果基于提高测试效率，情况就比较复杂了，要因地制宜找出合适自己团队的框架、用例结构、试行制度，不断迭代，没个半年到 1 年，你也试不出来目前自己辛苦做出来的自动化流程到底对自己团队有多少帮助，所以有经验的测试准确调研可行性的概率更高，没有经验的测试走弯路做无用功的概率更高。但，不能否认做自动化本身的意义和作用，楼上已经有大佬回帖举例说明。
我们需要自动化测试，但要有针对性，才能事倍功半，需要考虑的因素，包括但不限于
1、自动化测试的范围，原理上越往下越易，如：单元测试自动化，可老虑与开发结对，开发做好框架，测试设计用例，把正常、异常用例都考虑，相互补充；
2、自动化测试的时机，如果是业务功能自动化测试，需选择业务成熟时，当成回归测试来用
3、自动化测试技术管理，技术框架本身的设计，需要长远看，例如：定义一套接口规则，封装一些公共函数，代码维护原则，相关培训推广，发现的问题管理等一系列问题