自动化测试不是免费的午餐

上周去雨花台那边的一家创业公司聊，测试团队的负责人一见面就把笔记本转过来给我看——屏幕上跑着刚写的UI自动化脚本，红一片绿一片，报错弹窗堆了快二十个。他挠头说，上个月刚咬着牙招了两个会写Python的测试，就想把核心流程的自动化率拉到60%，结果现在跑一次全量要四个多小时，半夜触发的定时任务，到早上看一半的用例都因为测试环境的服务挂了标红，根本分不清是代码出了问题，还是脚本本身写得烂。

先别急着算自动化率的KPI

这事没那么玄。 很多团队一提到自动化测试，第一反应就是要定KPI，半年内自动化率到多少，一年内到多少，仿佛这个数字上去了，测试团队的效率就自动翻倍了。我见过太多团队，为了凑这个数字，什么杂七杂八的用例都往自动化里塞，最后脚本越堆越多，跑一次的时间越来越长，误报率高到没人敢信。 说白了，很多人把自动化测试当成了能一劳永逸的补丁。写一次，跑一辈子。哪有这么好的事。 之前见过一个团队，为了把登录下单的流程做成自动化，花了三周写脚本，结果后来产品改了个下单页的交互，加了个必填的发票抬头字段，整个流程的脚本全废，重新改又花了一周。算下来这俩月的时间，人工跑核心流程都能跑上百次。

麻烦在于，很多人算自动化的账的时候，只算了‘不用人工点鼠标’省的时间，没算写脚本、调环境、维护脚本、排查误报的时间。我见过太多团队，自动化跑了半年，最后留下来能稳定跑的用例，还不到当初写的三分之一。剩下的那些？全是躺在仓库里没人管的垃圾代码。 没人会跟你说这些。毕竟对外吹的时候，只需要说我们自动化率做到了多少，没人会提那些跑一次炸一次的废脚本占了多少容量。

别把所有测试都往自动化上塞

自动化不是万能的。 真要算投入产出比的话，最适合自动化的场景，永远是那些需要反复跑、流程稳定、出错了代价大的环节。比如支付回调的逻辑，每次发版都要测，人工点的话还要等沙箱的回调，麻烦得很，这种写个自动化脚本，每次发版跑一遍，省的时间是真的。 那什么不适合？比如新做的活动页，改个按钮位置、换个文案的，你今天写完脚本，明天产品就改，纯纯浪费时间。还有那种需要主观判断的，比如页面好不好看，动效顺不顺，自动化根本测不出来，写了也是白写。 我之前碰到过一个做电商的团队，一开始啥都想自动化，连商品详情页的图片加载速度都写了脚本，结果后来CDN经常抽风，脚本动不动就超时，光排查这些误报，每天就要花测试团队俩小时。后来他们把这类用例全删了，只留了下单、支付、退款这几个核心链路的自动化，反而整个流程顺了，每天跑一次全量也就二十分钟，误报率降到了能接受的范围。

说实话，很多人对自动化的误解，就是觉得它能替代人工测试。其实根本不是。它只是帮你把那些重复到无聊的活干了，把人省下来去测那些需要动脑、需要判断的场景。你要是把所有活都扔给自动化，最后只会得到一堆没人看的报告。

维护成本才是真正的隐形支出

不过话说回来，谁刚开始搞自动化的时候没踩过这些坑呢？ 很多人以为自动化测试写完就完事了，哪有那么好的事。你写的脚本，用的第三方库升级了，原来的接口变了，脚本就跑不通了。测试环境的数据库被别人清了，测试账号被删了，脚本也跑不通。甚至你写脚本的时候用的是硬编码的测试数据，过俩月数据过期了，又要改。 这些破事，没人会写在自动化的宣传PPT里。你要是没提前把这些成本算进去，最后自动化只会变成团队的累赘。 现在很多人谈测试左移、测试右移，其实本质上就是别让所有的测试压力都堆在最后的UI自动化上。越靠近代码底层的自动化，维护成本越低，投入产出比越高。比如接口层的自动化，比UI层的稳定多了，能在接口测试的时候就把大部分问题拦下来，根本不用等到点按钮的环节才发现接口报错。 我见过最离谱的团队，自动化脚本全是测试自己写，开发根本不管，前端改了页面也不通知测试，最后脚本全炸，测试天天忙着改脚本，反而没时间测新功能。后来他们定了个规矩，只要前端改了核心流程的页面，必须同步给测试更新对应的元素定位，不然发版的时候出问题算开发的。就这么个小规矩，脚本的维护量直接降了一半。 对吧，这事本来就该两边配合，哪能全压在测试身上。 现在很多公司招自动化测试，上来就要求会写框架，会搞CI/CD，其实真的落地的时候，哪有那么多高大上的东西。很多时候你把核心链路的自动化跑稳，误报率压到能接受的范围，就已经比大多数团队做得扎实多了。别上来就想着搞什么全自动化测试，连手动测试的流程都没理顺，搞自动化纯纯是瞎折腾。 我之前见过一个刚毕业的测试，为了显得自己厉害，花了一个月写了个看起来很厉害的自动化框架，结果没人用，最后离职了，框架直接被删了，白忙活。 上周跟那个雨花台的测试负责人聊到最后，他说已经把之前那堆不稳定的UI用例全删了，先从接口层开始写，先把支付链路的自动化跑稳，再慢慢往上加。他说之前被自动化率的KPI逼得急了，现在反而慢下来，每天省下来的时间还能多测几个新功能的边界场景。