周五下午四点二十七分，动化我盯着屏幕上那个红色的测试失败标记，第无数次怀疑自己写的动化脚本是不是被诅咒了。测试用例明明在本地跑得好好的测试，一到CI环境就翻车。动化后来发现原因荒诞得可笑——测试代码里有个`time.sleep(3)`，测试而CI机器比我的动化Mac慢了一秒半。

这就是测试Web自动化测试的日常。你以为在测试应用，动化其实是测试在跟时间、网络、动化浏览器版本和玄学搏斗。测试

但别误会，动化我还是测试要说它的好话。手动回归测试才是动化真正的酷刑——点开页面，输入账号密码，点击保存，刷新，再输入一遍。重复二十次以后，你会开始对着屏幕说“求求你了，让我点个别的按钮吧”。

自动化测试的核心逻辑简单到令人发指：定位元素，操作元素，断言结果。三句话就能讲完。真正的门槛在于，你永远不知道页面下一秒会变成什么样。

上周我遇到一个案例。某个输入框的id原本是`username_input`，前端同事觉得这个名字不够优雅，改成了`user-name-input`。我的脚本瞬间瘫痪。这还算好的，更常见的是某个按钮在A页面是``，换到B页面变成了`

`——前端框架一升级，全部选择器作废。

所以现在我写脚本有个习惯：能不用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自动化测试是个性价比游戏。花时间写脚本，省下以后的手工重复劳动。但投入产出比需要自己拿捏——那种一个月才跑一次的流程，别自动化了，手动点两下更快；那种每次发版都要回归的核心路径，必须自动化，哪怕写起来再痛苦。

最后分享个真实瞬间。上周我把一条跑了半年的用例修好，按下运行键，看着浏览器自动打开、输入、点击、断言通过，绿色勾号亮起来的那一刻，确实有种微妙的满足感。就像训练了一只电子宠物，它终于学会了替你干活。

当然，它明天可能又会因为某个莫名其妙的网络超时挂掉。到时候再修呗，反正这就是这份工作的日常。