自动化是否被过度神话了？

测试一根葱 9
2022-07-24 18:32:03 未知地区 1F
回复

一般自动化测试分为两种 一种是接口自动化提前发现问题，一种是验收主流程。。所以和你说的并不产生冲突。在研发还未提测功能时，你就可以走接口测接口提前发现流程和一些单接口的问题还能提高健壮性。在迭代功能测完后也可以走验收主流程的自动化测试也能大大减少人力操作，因为有些迭代你也不知道是不是会影响一些主功能。所以自动化测试还是有必要的，能提高质量和保证质量精准测试只有极个别的公司在推，自己想学习下都不知道如何入手，没法开展这个。效果怎么样，还得经过市场的考验吧。这是理想情况，但是往往的迭代过程都是研发还未提测功能时，测试还在上一个迭代的测试工作中。
走验收流程的自动化测试的话，那么花那么多人时投入自动化，是不是收益太低了？大致的思路都查得到，具体的实施细节可以自己研究一下。结论很赞同，对于第二点简单说下看法：
首先每次小版本的迭代，影响的功能点或者说接口并不多，自动化稍作修改即可，比如有 100 个功能点，迭代影响 10 个功能点，则修改这 10 个即可，其他 90 个也可以用自动化跑。否则在手动测试大概率要跑 10 个改动的 +20/30 个可能有影响的。在发版前几天的迭代次数是很多的，这时候自动化就提现出来了。验收的话受益其实不低的，前期花点时间。提测功能那种也可以提前编写一些接口自动化的流程呀，提前保证一些流程性的业务，也花不了多少时间的，再评估看有没工作量的时间投入到一些细节测试，根据公司产品开发而定嘛。最主要的是前期推动，要从自动化体验出测试的价值能力强的写可能没什么问题，但是团队里面能力良莠不齐，对于能力稍弱的同学可能就不太容易了，而且写完不是结束，后期维护才是大头慢慢来，已不可能纯粹做功能测试的，你会发现有时候很多东西功能测试满足不了或是不好满足的，自动化是一个渠道有这样一种场景，接口入参是定义了一个 bean，然后我在这个 bean 里面加了一个字段，校验是 NotNull，然后这个 bean 被很多个接口用到，那么在修改掉这个 bean 时，会导致自动化用例大规模的报错，然后再去一个一个修改自动化用例，这样成本就高了其实这就涉及自动化的前提啦：成熟度
换而言之就是自动化的对象时那些固化的长时间不会进行更改的功能
实用性方面是有被过度夸大了，因为极大多数公司的产品状态其实是不适配的，但是一方面为了卷一方面为了面试都对其的出现率造成了一定程度的拉升
卷已是行业现状，面船干点也是既成事实这个就是具体的细节问题了，考虑下测试方法是否正确或者是否适合自动化。自动化在我司最重要的 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 自动化一开始投入会比现象中高，等大家熟练模式后，才能体会到好处。但是不包含录制回放的自动化，因为这个只是解决了一些问题，并不会让大家熟练模式。好比会使用微波炉，如果脱离微波炉，不一定会烹饪。没有自动化提前去跑失败，你怎么知道哪些接口要加字段？ 自动化还是要找到适用的场景，之前公司自动化做得好的业务，能从测试环境到线上环境一通跑下来，节省了不少回归时间；做得不好的主流程都没覆盖，都没跑起来，造成这种情况原因有很多：比如业务变更频繁，投入人力不足，人员能力参差不齐等等。自动化做成功的少之又少。自动化测试本来就不是盲目的。。。一些项目本来就不适合自动化测试啊。不稳定的自动化测试用例实现比没有自动化更糟糕。

另外自动化测试优缺点我按自己理解罗列了下，供参考。

优点
缺点

提高测试质量
产生开发成本

提高测试效率，缩短测试工作时间
需要测试技术团队

提高单位时间测试覆盖率
脚本维护成本高

执行手工测试不易完成的测试任务（性能自动化测试）
无创造性

更好的重现缺陷
引入更多的复杂性

更好的利用资源
容易出现偏离原始的测试目标

增进测试与开发合作伙伴关系
可能引入额外的错误

更快的反馈软件质量
更依赖用例的质量

提高测试系统稳定性和可靠性

现在企业里面有一种风气，就是测试必上自动化，尤其是领导层，只要一提到效率，必然就是做自动化，他们对于自动化的理解仅限于 ‘自动化’ 这三个字，对于他们来说，自动化就是被神话了，觉得自动化无敌，而不去考虑实施自动化所需要的前提条件，盲目追求自动化，最后时间没节省，反而更慢了测试必上自动化，我觉得这不是风气，而是每一个项目的管理者都必须会考虑到的必做项。
质量保障体系里面，有很多不同的环节：需求评审，设计评审，开发单元测试，系统集成测试，系统回归测试，用户验收测试，等等。而自动化是系统集成/回归测试阶段很重要的一步。
不做自动化，只用手动测试能做完集成测试和回归测试吗？ 当然可以。但问题是，你怎么保障测试的效率？怎么保证在不断迭代的过程中，测试人员不会疲惫而导致漏测？我理解不是过度神话，可能是有很多人把它当做银弹了。把提高效率=自动化，没有根据实际项目去评估投入产出比。

其实视野大了后，提高效率的手段会多很多。比如多用靠谱的代码自动生成工具，有效减少手写代码的 bug，测试用例也可以精简不少；架构设计上减少重复，减少变更后要验证的范围，也能提高效率。只是确实会有一部分测试，视野只看到手工测试，提效想法就会局限在怎么让手工测试执行得更快，自然就会觉得能让执行速度大幅度提升的自动化非常好了。

我觉得不如楼主补充下，为何会觉得自动化被过度神话？是看了哪些资料产生这个感觉？

PS：金字塔的图印象中 2-3 年前已经改为菱形了，因为绝大部分互联网公司是不可能做那么完善的单测的，投入产出比相对高的是接口层的自动化。不知道你看的是什么时候的文章？自动化测试并没有被神话……一直以来，因地制宜和投入产出比一直都是大家的讨论重点。但是自动化测试建设，是提质提效不可避免的可以尝试的一种方式 只是某些利益相关的人口中被神话了吧，而老板通常更会被这部分人影响。
其实，很多人老早就看到了你说的这些问题，而有些人只看到了问题，有些人却早就在想怎么解决这些问题了。
我很赞同 Jerry 的观点，只看到缺点的话，视线会被影响，只有同时明确自动化的优点和缺点，做到心里有数才能因地制宜。
生活有很多不如意，如果只看到不如意，应该不会快乐吧。
工作也一样。今天自动化发现了一个策划配置 BUG，据测试同学说，这个 BUG 靠人工发现的难度很高不是说自动化没有用，是说做自动化的成本是低于收益的么？有用肯定是有用的。
我个人是觉得是有性价比的，当然也要看落地做的怎么样，如果不用心，敷衍了事那就不行我理解，楼主说的是神化，而不是神话……按道理，自动化是应该被神化的，但是暂时还没有得到足够的重视关于自动化测试，我想你可以看下这一篇文章：
Fixing a Test Hourglass神话就过了，结合业务成功落了地的自动化确实好用，不好落地、维护麻烦，就没必要用，领导不懂这其中道理，直接跟他沟通就行了，好好讲，应该会明白的。看了下评论，结合自己的思考，说说自己的看法
自动化测试主要作用有 2 个方面：
1.前端联调之前发现问题，这个我们之前是这样的做的，作用一般
2.回归测试，这个上面有个评论点到了，如果你的脚本的某个接口出现报错，是因为改字段出现的问题，这件事本身已经发现问题了，开发在写代码可能会遗漏一些场景，脚本发现了你再去改这个过程并不是一个无效的事务。功能测试每次回归测试漏跑了根本不知道，也没有数据支撑。
项目重构、合库等等，手工测试的效率的纵向测试面试不足的在 PPT 上的内容基本上都是过度神话

实际的来讲，自动化只是一种 “方法”，重要的是用自动化达成的 “目的”（需求），这个 “目的” 能够大体决定自动化的 ROI
自动化还有一个重要的次要目标是代替人力，如果不能有效代替人力做掉繁琐重复的测试工作，那就是假的自动化
自动化并不是很好驾驭的一个东西——确实如此。没有一定技术基础，很容易做成假的自动化。自动化有两种，基于 KPI 和 基于提高测试效率。
1.如果是基于 KPI，我们就做冲击 KPI 的事情，有没有用不要紧，领导喜欢，年底绩效给好，晋升加薪给好，愿意给人给时间，别说做没用的自动化，加入开发队伍做满全覆盖的单元测试都行。毕竟你没法改变领导的想法，就算想改变，你也得先照着领导意思做出数据来证明，KPI 考核的自动化对实际测试提效或质量建设没啥鸟用。

2.如果基于提高测试效率，情况就比较复杂了，要因地制宜找出合适自己团队的框架、用例结构、试行制度，不断迭代，没个半年到 1 年，你也试不出来目前自己辛苦做出来的自动化流程到底对自己团队有多少帮助，所以有经验的测试准确调研可行性的概率更高，没有经验的测试走弯路做无用功的概率更高。但，不能否认做自动化本身的意义和作用，楼上已经有大佬回帖举例说明。