告别浏览器测试慢：别把“技术债”当成“不稳定”
其实这种所谓的“不稳定”，根本不是工具的问题，而是我们过去半年在测试用例里累积的无数个微小决策导致的。
一、环境差异是最大的隐形坑
很多同事在本地跑通过的测试，到了 CI 环境就崩了。大家习惯性地认为是 CI 资源不足，但实测下来，很多时候是因为环境配置根本不对等。
最典型的一个踩坑点就是 CSS 动画。开发机默认开启动画，但 CI 容器里的浏览器可能会触发 prefers-reduced-motion（减少动画）设置。这导致动画执行时长从 300ms 变成了 0ms，或者某些元素直接跳过了过渡状态。结果就是：测试脚本在等一个元素出现，但元素因为动画逻辑不同而没能按预期渲染，最终导致超时报错。
为了解决这个问题，我们现在强制要求在测试配置文件中显式声明环境参数，而不是依赖容器默认值。比如在 Playwright 的配置中明确指定 viewport 和 locale，确保本地和 CI 的行为完全一致。
二、Feature Flag 带来的“平行宇宙”
公司现在推行灰度发布，Feature Flag（功能开关）用得极多。但问题是，一个开关就让产品变成了两个版本，五个开关就是 32 种组合。
我们之前遇到过一个诡异的 Bug：同一个测试用例，早晨跑是绿的，下午跑就红了。排查了半天发现，是因为该测试账号被随机分到了某个新功能的灰度组，导致 DOM 结构发生了变化，原有的选择器失效了。
最糟糕的是，之前的测试报告只截了图，没记录当时的 Flag 状态。这意味着开发者在调试时，根本无法复现那个特定的 UI 状态。现在我们修改了工作流，在测试失败的日志中强制输出当前的 Flag 集合：
{
"test_status": "failed",
"active_flags": {
"new_checkout_flow": true,
"beta_dashboard_v2": false,
"experimental_search": true
},
"app_version": "v2.4.1-build.102",
"user_segment": "beta_tester_group_A"
}有了这个上下文，排查时间从 2 小时缩短到了 10 分钟。
三、断言逻辑的误区
很多同事写测试习惯于校验实现细节，而不是用户可见的结果。比如，他们会去检查某个内部状态变量是否为 true，或者某个隐藏的 DOM 属性是否被修改。
但在现代前端框架（如 React Server Actions）中，很多操作是“乐观更新”的。界面先变，服务器后响应。如果你在请求还没完成时就去断言最终结果，或者在不恰当的时机去检查 DOM 属性，就会产生大量随机失败。
我们现在的实战准则是：只断言用户能看到的东西。不要管内部状态怎么变，只要界面上出现了“提交成功”的提示，或者 URL 跳转到了正确页面，这个测试就算通过。
总结下来，测试套件变慢、变乱，其实是系统在提醒我们：你的架构出问题了。与其一遍遍地重启 CI 祈祷它能过，不如花时间把那些模糊的配置项给固定下来。
