`——前端框架一升级，全部选择器作废。
所以现在我写脚本有个习惯：能不用CSS选择器就不用，优先找`data-testid`属性。这玩意儿是测试和开发之间的暗号，相当于在代码里埋了路标，告诉测试机器人“嘿，往这儿走”。要是你的团队还没约定这个，建议下次开会提一嘴，能省下无数个抓狂的下午。
另一个坑是等待策略。新手最爱写死等待，`time.sleep(5)`，简单粗暴。但网络一波动，5秒不够用；网络顺畅时，白等3秒。正确做法是用显式等待——Selenium里的`WebDriverWait`，或者Playwright的`expect`，让程序自己判断元素何时可交互。这玩意儿就像钓鱼，你不需要数着秒数拉竿，等浮漂动了再提竿就行。
说到工具选择，我见过太多团队在Selenium和Playwright之间反复横跳。Selenium是老江湖，生态全，但API设计停留在2010年代。Playwright是后起之秀，自带自动等待、多浏览器支持、还能拦截网络请求，写起来像在写普通JavaScript。我的主观意见：新项目直接上Playwright，别犹豫。除非你的团队已经用Selenium积累了上千条用例，否则没必要守着旧工具。
真正的分水岭不是工具，而是你对待测试代码的态度。很多人把测试脚本当成一次性用品，写完能跑就扔。等到应用改版，脚本报错，一看报错信息，完全不知道当初自己写了什么鬼。
我见过最离谱的脚本，一个测试用例里塞了三百行，从登录到下单到退单全在一个函数里。那个同事离职后，没人敢动那条用例。后来产品说要把下单流程改一下，我们花了三天拆解那个“巨无霸”，最后干脆重写了。
测试代码跟业务代码一样需要设计。每个用例只测一件事，公共操作抽成Page Object模式，断言要精准——别断言整个页面文本，就断言那个你关心的数字。这些道理说起来轻巧，但真到赶进度的时候，最容易牺牲的就是测试代码的可维护性。
代价会在三个月后加倍奉还。
还有个事得提一嘴：别指望自动化测试能发现所有bug。它擅长的是回归验证——确保你改A功能的时候，没把B功能弄坏。但UI的视觉问题、交互的微妙手感、某些只在特定浏览器才出现的诡异行为，自动化脚本经常瞎了眼。我有个同事坚持用截图对比工具测样式，结果每周都被误报折磨，后来发现是字体渲染差异导致的像素级偏差，气得他把那个用例直接删了。
说到底，Web自动化测试是个性价比游戏。花时间写脚本，省下以后的手工重复劳动。但投入产出比需要自己拿捏——那种一个月才跑一次的流程，别自动化了，手动点两下更快；那种每次发版都要回归的核心路径，必须自动化，哪怕写起来再痛苦。
最后分享个真实瞬间。上周我把一条跑了半年的用例修好，按下运行键，看着浏览器自动打开、输入、点击、断言通过，绿色勾号亮起来的那一刻，确实有种微妙的满足感。就像训练了一只电子宠物，它终于学会了替你干活。
当然，它明天可能又会因为某个莫名其妙的网络超时挂掉。到时候再修呗，反正这就是这份工作的日常。