上周去南京找朋友蹭饭。他在本地一个做企业服务的团队当测开，刚熬了三个大夜改完自动化脚本，转头就被产品经理拍了桌子。
原因说起来有点好笑：他花三个月搭的自动化测试框架，跑出来的全量回归脚本，上周迭代完直接崩了三分之二。页面上多了三个自定义输入框，原来写的元素定位规则全失效，控制台一片红，跑一次全量要等四十分钟，最后出的结果还没一个能信的。
脚本写得越顺，业务变得越快
说实话，这场景我跑了快十年技术访谈，见得太多了。
很多团队一开始搭自动化测试的时候，满脑子想的都是“把所有手动测试的用例都搬去脚本里”。登录要测，下单要测，权限校验要测，甚至连页面上的提示文案对不对都要写个脚本去抓。一开始跑通的时候特别有成就感，看着控制台绿色的通过提示，觉得这下以后发版再也不用熬通宵跑回归了。
麻烦在于，你根本猜不到业务下个版本会改什么。
上个月我在苏州见的一个电商团队，为了赶大促的活动，把商品详情页的按钮位置挪了三次。之前写的UI自动化脚本，光是找按钮的元素定位就改了四版。算上改脚本、调环境、重新跑脚本验证的时间，两个测开花了整整一周，最后算下来，花在修脚本上的时间，比他们三个测试同学手动跑三轮核心流程的时间还多。
没人说做自动化测试不对。但你要是真的把那些每次发版都要跑、流程稳定、输入输出固定的用例全自动化，确实能把测试同学从重复的机械劳动里捞出来——可大部分团队的业务流程，根本没稳到那个份上。你写脚本的速度，永远赶不上产品改需求的速度。
别把成本账算错了地方
我见过太多团队算自动化测试的收益，只算最表面的那部分。
“原来手动跑一次回归要2小时，现在脚本跑只要5分钟，投入产出比超高。”
这话听着没错，但他们从来不算另一笔账：脚本写完不是放那就不管了。元素定位变了要调，接口参数改了要改，测试环境抽风了脚本跑出来的无效结果要排查，甚至新人进来接手，得花一周时间看懂几百行脚本到底测的是什么场景。这些时间成本，全是维护成本。
我见过最离谱的团队，给自动化脚本写的注释比代码本身还长，就怕哪个新来的测开手滑改坏了，连当初写这个脚本的业务逻辑都对不上。到最后，整个团队没人敢随便动那些脚本，自动化覆盖率的数字看着好看，真到发版的时候，大家还是抱着手动测试用例表跑一遍，脚本就扔在CI流水线上当摆设。
说白了，自动化测试从来不是覆盖率越高越好。
你把90%的精力花在最上层的UI测试上，看着数字漂亮，实际一遇到页面调整就全线崩盘；反过来，把精力往底层挪一挪，最基础的单元测试让开发自己写，代码一提交就跑，出问题立刻拦截；中间层的接口测试，挑那些核心的、变更少的接口做自动化；最上层的UI测试，只留十几个核心主流程的用例，其他的场景全留给手动测试。这么做一开始的覆盖率数字不会好看，甚至会被领导质疑“你们花了钱搞自动化，怎么才覆盖30%”，但你心里清楚，这30%的用例，每次发版跑一遍，能拦住80%的低级错误，比你写两百个一变更就崩的空架子有用多了。
工具从来解决不了流程问题
不过话说回来，很多团队自动化测试搞不起来，根本不是工具的问题。
今天换个新的测试框架，明天买个贵得离谱的商业自动化平台，折腾一圈，发现脚本还是没人维护，跑出来的结果还是不准。为啥？因为流程没跟上。
开发提代码之前，根本不考虑接口的兼容性，改个参数名连个同步通知都没有，接口的自动化脚本隔三差五就挂；测试环境的版本跟正式环境差了三个迭代，脚本跑的全是无效结果；甚至没有明确的脚本维护责任人，脚本写出来扔在代码仓库里，过俩月谁都不知道当初写的是啥场景。
这事没那么玄。
你就算把行业里最顶尖的测开专家请过来，给你搭一套最完善的自动化平台，要是没人盯着版本变更同步机制，没人定清楚每段脚本的维护责任，不出三个月，那套平台就会变成仓库里一个没人点开的文件夹。
我那个在南京蹭饭的朋友，最后是怎么解决的？
他把之前写的两百条UI脚本砍到只剩12条，全是登录、核心下单流程、权限校验这几个最稳的链路，剩下的精力全放在接口层的自动化上。现在全量跑一遍只要8分钟，每个月花在维护脚本上的时间不超过两个小时。上次发版，脚本提前拦住了一个权限校验的接口bug，要是漏到生产环境，至少要赔客户几万块的服务费。
值了。
很多人对自动化测试的误解，就是觉得它是用来替代人的。根本不是。它是用来把人从那些根本不需要动脑子的重复劳动里拽出来，让人有时间去测那些真正需要思考的、复杂的、边界的场景。你要是抱着“上了自动化测试就能裁掉一半测试”的念头去搞，最后大概率是花了钱，耗了人，什么都落不了地。