凌晨两点，测试我盯着CI服务器上那排红彤彤的自动失败通知，第无数次点开日志。测试不是自动代码逻辑出错，是测试登录按钮的CSS选择器变了——前端同事昨天下午重构了页面，把id="login-btn"改成了data-testid="login"。自动这种破事每周都要上演两三回，测试每次都得花半小时改脚本再重新跑。自动

测试自动化听起来像是测试解放劳动力的神器，实际上更像养了只永远吃不饱的自动电子宠物。你喂它精心设计的测试用例，它回馈你一堆脆弱的自动断言；你给它配置持续集成环境，它转身就因环境变量缺失而罢工。测试真正跑过三年自动化的自动人，谁没在深夜为某个sleep(3)到底该不该加而抓狂过？测试

但别误会，我依然坚信自动化是条正路。只是它远没有招聘广告里写得那么光鲜。去年我们团队接手一个老项目，测试覆盖率号称70%，可每次发版前大家还是提心吊胆。后来查明白了——那70%里有一大半是纯前端样式断言，真正涉及核心交易流程的用例屈指可数。这就像给汽车做了全车喷漆，却从没检查过刹车片。

真正的转折点出现在一次线上事故之后。客户下单时库存扣减重复执行，导致超卖。当时自动化测试全绿，因为压根没人写过并发场景的用例。那晚修复完bug，技术总监说了句让我记到现在的话：“测试自动化的价值不在于跑得多快、覆盖多广，而在于它能不能在你睡着的时候，替你盯住那些你没想到会出问题的地方。”

从那以后我们改了策略。不再追求UI自动化全覆盖，转而把重心压在接口层和关键业务链路上。UI脚本只保留最核心的冒烟路径，剩下的交给更底层、更稳定的测试金字塔。奇怪的是，测试执行时间从40分钟缩短到9分钟，漏网之鱼反而少了。原来以前大量时间都耗在维护那些脆弱的页面元素定位上，真正的逻辑漏洞根本没被有效检测。

还有个反直觉的发现：写自动化用例最忌讳贪多求全。你越想覆盖所有分支，用例就越复杂，维护成本呈指数级上升。最后要么脚本腐化到没人敢改，要么干脆被注释掉当摆设。我们后来约定俗成——每个用例只验证一个核心行为，如果某个用例需要超过三个前置条件，就说明设计有问题，得拆。

工具链也在悄悄变化。最早用Selenium做端到端，后来发现Playwright的自动等待机制能省掉一半的sleep烦恼。现在连视觉回归都交给像素级对比工具，截图差异一目了然。但这些都只是手段，关键还是团队里得有个人愿意持续投入精力去维护测试代码——就像园丁修剪盆栽，得定期剪掉枯枝败叶，才能保证整株植物健康生长。

说到底，测试自动化考验的不是写代码的能力，而是对业务风险的判断力。你得知道哪些地方摔倒了会骨折，哪些地方擦破皮无伤大雅。上周我把一个跑了两年从没失败过的用例删了，同事问我为什么。我说那个页面功能已经下线，留着它只会让每次CI白白多花五秒钟。她愣了一下，然后笑了：“你终于开始把测试代码当成产品代码来维护了。”

对，就是这个意思。自动化测试不是一次性投入的保险箱，而是需要持续打磨的工具。它不会替你思考，但能放大你的思考成果。前提是——你得愿意为它花时间，而不是指望它替你省时间。