上周在软件大道边上的咖啡店碰着个做测试的老周，刚把手里的瑞幸杯捏扁，说花了三个月搭的自动化测试框架，上线第一周就崩了。
不是什么服务器挂了的大问题。是每次跑全量用例，一半的报错都来自登录态过期。他光在框架里配置token刷新逻辑，就折腾了快两周。
最先踩的坑从来不是工具选型
很多人刚接触自动化测试，第一反应是翻遍全网的测评，到底选Selenium还是Playwright，Cypress是不是比别的框架更快。说穿了，这事儿根本排不上号。
老周当初选框架的时候，对比了三个开源项目的功能列表，光写选型报告就花了两天，结果真正跑起来才发现，框架好不好用根本不影响最终效果——他把所有能想到的页面操作都写成了用例，连“点击帮助中心按钮”这种一年都点不了两次的功能，都写了三条断言。
大部分团队第一次搞自动化测试，90%的精力都花在了写用例上，剩下10%才去想这些用例跑起来是不是真的有用。
谁懂啊。那种等了一下午的测试报告出来，一半用例因为元素定位失效、文案改动报错的崩溃感。他之前写的用例里，有个定位元素的代码是找页面上文字为“立即提交”的按钮，结果产品上周改了个文案，把按钮文字换成“提交审核”，整整12条相关用例直接红成一片。
麻烦在于，很多人从一开始就把自动化测试当成了手工测试的替代品，觉得只要把所有手工点过的步骤都翻译成代码，就算完成了目标。可实际上，你写的每一行自动化用例代码，本身都是需要维护的资产。就像你自己写的业务代码一样，隔三差五就得回头改，不然放久了根本跑不起来。
没人算过的维护账
很多团队算自动化测试的投入产出比时，只会算刚开始搭框架花的那点人天——比如两个测试花两周写框架，花一个月写用例，之后就能一劳永逸。
从来没人往后算一步。
就拿老周之前的团队来说，一开始算的是，纯手工测试每次回归要花三个人天，有了自动化之后，每次回归只要跑一小时脚本，省下来的时间能多测好多边角功能。结果跑了半年才发现，每个迭代要安排两个测试花整整两天改失效的用例：有的是页面元素改了，有的是接口返回的字段名变了，还有的是测试环境的依赖服务又抽风了。算下来，花在维护用例上的时间，比纯手工回归的时间还多。
真正能长期跑下去的自动化测试用例，从来不是覆盖所有页面的全量用例，而是那些每次迭代都必跑、手工点一次就要花十几分钟的核心路径。
比如用户登录、核心商品浏览、下单支付、订单状态查询，这些流程一旦出问题，就是直接影响营收的大bug。把这些路径的用例写扎实，每次跑全量只要十几分钟，就能把最容易出问题的环节兜住。剩下的边角功能，比如设置页的主题切换、帮助中心的文章跳转，手工测反而更快，没必要硬往自动化里塞。
老周后来咬咬牙，把原来200多条用例砍到剩40条，全是核心交易路径的。现在每次跑全量只要12分钟，开发刚提测把代码推到测试环境，他喝口水的功夫就能拿到结果。那些因为文案改动导致的失效用例，因为都是核心路径的，他每次更新用例代码前自己先跑一遍，根本不会等到批量执行的时候才发现问题。
不过话说回来，很多人总觉得自动化测试覆盖的用例越多越厉害，好像写的用例条数少了，就显得自己工作没做到位。其实真不是，你写100条每次跑都要报一半错的用例，还不如写10条每次跑都能准确反映真实问题的用例——那些天天报错的用例，时间长了大家连看都懒得看，跟没有一样。
别让自动化测试变成新的负担
我见过太多团队，最后把自动化测试搞成了一个没人敢动的摆设。
为了维护那堆跑不顺的用例，专门招了个测试开发，天天对着报错的日志找原因，既不接触实际业务需求，也不参与手工测试的流程，就围着那些失效的用例转。到最后，每次版本上线前，大家还是要把核心流程手工点一遍，生怕自动化测出来的结果不准，反而平白多了一层维护成本。
自动化测试本质上是给人减负的工具，不是需要人供奉的KPI。
你要是发现团队现在为了跑自动化测试，要花的时间比纯手工测试还多，那趁早砍了那些没用的用例，别硬撑。没必要为了凑所谓的“自动化覆盖率”指标，写一堆根本没人看的用例。
老周现在已经不折腾那些花里胡哨的插件了。什么自定义测试报告，什么消息自动推送到群里，那些功能他全砍了，就用最基础的Playwright框架，跑出来的报告就显示哪条用例过了，哪条挂了，连个多余的图表都没有。省下来的时间他天天准点下班，去文体路吃碗鸭血粉丝汤，加个锅巴。
毕竟搞自动化测试的目的，从来不是为了证明自己有多厉害。是为了少加没必要的班。