微风测试修复

要解决什么问题

Playwright 测试在本地全绿，一进 CI 就红，或者同一用例时而通过时而失败——这类问题通常被笼统地称作 flaky test，但真正的原因可能完全不同：也许是 waitForTimeout() 造成的时序竞态，也许是测试之间共享了可变状态，也可能是 CI 与本地的视口尺寸、字体渲染或时区不一致。凭经验反复加随机等待，只会让问题更难定位。

技能如何工作

这个技能把「修复失败测试」变成一个可重复的流程，核心是先分类、再动手：

• 复现失败：先运行目标测试（如 e2e/login.spec.ts 中的 "should redirect after login"），若直接通过，则用 --repeat-each=20 做 burn-in，必要时再以多 worker 并行运行，确认是否 flaky。
• 采集证据：开启完整 trace 并读取输出，可用 /debug 分析 trace 文件，对比本地与 CI 的截图和轨迹。
• 归类根因：技能内置的 flaky-taxonomy.md 将失败分为四类——Timing/Async（各处偶发，--repeat-each=20 可复现）、Test Isolation（套件中失败、单独运行通过）、Environment（CI 失败本地通过）与 Infrastructure（无规律且报错指向浏览器内部）。
• 定向修复：每类给出对应的修法。时序问题改用 web-first 断言（如 toBeVisible()）；隔离问题清除共享状态、每个测试生成独立数据；环境问题对齐视口、字体与时区，甚至用 Docker 在本地复现 CI；基础设施问题则调整超时、配置 retries: 2 或降低并行度以规避浏览器 OOM。
• 验证与预防：修复后连跑 10 次，全部通过才算完成；随后建议在 CI 中启用重试、trace: 'on-first-retry'，并把修法沉淀进项目测试规范文档。

适用边界与注意点

它只针对 Playwright 端到端测试，不覆盖单元测试或组件测试框架；分类依赖 flaky-taxonomy.md，遇到四类之外的失败模式（例如被测应用自身的真实回归）时仍需人工介入。另外，重试只是兜底，根因修复才是目标，不要把它当成长期策略。