避免 Playwright 测试抖动（Flaky Tests）
Playwright 抖动测试的系统治理：用好自动等待、locator 优先于 selector、正确用 waitFor、合理超时、自动重试、元素集合等待策略与 Trace Viewer 调试。让测试套件重新可信。
本文依据官方文档整理，未执行运行验证或性能基准。代码片段展示局部用法，业务函数、数据和环境需按项目补齐；版本与配置以所引文档为准。
直接回答：抖动测试（相同条件时过时败）的常见原因包括等待、定位、共享状态、网络依赖及资源争抢——Playwright 的 locator 自带自动等待与重试，优先用它而非原始 selector；别用 waitForTimeout 死等；配 retries 兜底；用 Trace Viewer 回放失败现场定位真因。
为什么抖动是大敌
时过时败的测试侵蚀团队信任——失败开始被习惯性忽略，真正的回归混在噪音里漏网。治理抖动是测试体系可信度的前提。
核心治理手段
1. 吃透自动等待：locator 的 click/fill 等动作自带等待元素就绪——多数手写等待都是多余甚至有害的。
2. locator 优先：
// 按 ID 定位也会自动等待，但可能绑定实现细节
await page.click('#submit-btn');
// 优先使用面向用户的语义定位
await page.getByRole('button', { name: '提交' }).click();
3. 等待明确条件：waitForTimeout(3000) 是抖动制造机——等待具体条件（waitForResponse、expect(locator).toBeVisible()）。等待响应时先创建等待 Promise，再触发点击，避免响应先到而漏事件。
4. 合理超时：全局 timeout 与 expect timeout 分开调；慢环境加余量但别无限大。
5. 自动重试：retries: 2（CI 上）——重试是缓冲不是遮羞布，配 --reporter 记录重试率，持续治理。
6. 元素集合：列表断言用 expect(locator).toHaveCount(n) 而非先取数组再断长度——前者自动等待数量达标。
调试抖动
--trace on-first-retry 记录第一次重试的现场（不是最初失败的那次运行）；要保留初次失败可用 retain-on-failure：Trace Viewer 回放 DOM 快照、网络请求与动作时间线——抖动真因（竞态/动画/接口慢）在回放里现形。
常见问题（FAQ）
Q：重试会不会掩盖真实 bug？
A：会——所以重试次数要小（≤2），且重试率要监控。持续需要重试的用例应该修，不该靠重试续命。
Q：本地不抖 CI 抖？
A：CI 机器慢/资源争抢放大时序窗口——CI 上加超时余量、并行度调低、trace 常开抓现场。
Q：动画导致的抖动怎么治？
A：测试环境全局关动画（CSS 注入；reduced-motion 只是偏好信号，应用须实现对应样式），等待动画完成事件而非固定时长。
官方参考
资料核对日期：2026-09-29。
