上周跟个做了八年测试的老炮喝咖啡，他说现在团队里90%的自动化测试用例，都是写出来给领导看的。
真到上线前没人跑。
那些刚入职的校招生成百上千攒的用例，要么是依赖早就下线的测试环境，要么是参数写死了连个边界值都没测，跑一次能报三十个不相关的错，最后还是得靠人工点页面走一遍主流程。
没人愿写的前置成本
之前碰到过一个做电商的团队，花了三个月攒了两百多接口的自动化用例，结果每次跑之前得先手动搭三套不同版本的中间件，配五个测试账号，等环境稳定就得四十分钟，跑用例反而只需要十分钟。后来谁都不愿意碰，慢慢就荒废了。
麻烦在于，很多团队做自动化测试之前，根本没算过这笔账。大家默认的投入是写脚本的人天，从来没算过后续维护环境、更新用例、排查误报的长期成本。比如你写一个登录接口的用例，当时跑通了，过了两个月产品加了个验证码逻辑，你得回来改用例吧？过半年中间件升级了，返回值的字段名改了，你得回来调吧？这些细碎的活，没人提前排进排期，最后全变成测试组额外的加班。
误报比没测试更闹心
之前碰到过更绝的，有个团队的自动化测试用例集，跑一次的通过率是60%。啥概念？就是每次跑完一堆红的，大家根本不看，直接点全部忽略，合着跑这一趟纯粹是为了在周报里写一句”本周完成自动化测试用例全量回归”。
太扯了。
很多人做自动化测试追求的是用例数量，是覆盖率百分比，从来没在意过用例本身的可信度——你写的用例如果连续三次跑出来的结果都不一致，那这个用例本质上就是个噪音，还不如不写。
我见过最聪明的测试负责人，接手团队第一件事就是把之前攒的三百多个用例砍到只剩八十个。剩下的全是每次版本迭代必须跑的核心主流程：下单、支付、退款、用户权限校验。这些用例跑一次的通过率是100%，只要红了肯定是真的出问题了。大家愿意用，因为跑一次只要五分钟，能省下来至少两个小时的人工回归时间。
别把自动化当甩锅工具
很多开发碰到线上bug，第一反应是”你们自动化测试没测出来吗？”。对，就这种话，听着就来气。说白了，自动化测试从来不是万能的。它能覆盖的是固定逻辑、重复流程的校验，那些需要主观判断的交互细节，比如弹窗的动效是不是卡，新的营销页面的文案是不是有错别字，复杂的多用户权限交叉的场景，自动化脚本根本摸不准。
之前有个团队的测试组，为了应付开发甩锅，硬把所有UI交互的场景全做成了自动化用例，结果光维护这些元素定位的选择器就花了一半的人力——前端每次改个类名，所有相关的用例全挂。最后测试组的人天天就在改选择器，根本没时间去测真正的复杂场景。这就是最蠢的取舍。
对吧？
真正好用的自动化测试，从来不是追求全场景覆盖，而是把人从重复的、无意义的机械点击里解放出来，把时间花在那些需要动脑的探索性测试上。比如你每次发版都要测一遍的主流程，你让脚本跑，省下来的时间去琢磨琢磨新功能的边界场景，去试试用户可能会瞎点的奇怪路径，这才是自动化测试真正的价值。
现在很多人吹大模型能自动写自动化测试用例，我跟几个实际落地的团队聊过，目前也就是能把之前写过的用例改改参数，真要从零开始写一个能稳定跑的用例，还是得人来兜底。这事没那么玄。
上次那个老炮跟我说，现在他们团队的自动化测试用例，总共也就一百来个，每次发版前跑一遍，十五分钟出结果，有问题直接定位到接口，大家都愿意用。没人给领导表演”我们有上千个用例”，但线上的问题确实比之前少了一半。
就够了。