测试修复专家能系统化诊断并修复失败或偶发不稳定的测试用例，通…

# Playwright 登录冒烟测试偶发失败排查与修复

一、为什么本地稳定、CI 随机挂

• 环境差异：CI 机器 CPU/内存受限，页面加载和渲染更慢，容易踩到等待不足的问题。
• 资源竞争：CI 常并行跑多个 worker，登录页可能共用测试账号导致 session 冲突或被顶号。
• 网络波动：CI 出网走代理/VPN，第三方依赖（字体、验证码服务、SSO 跳转）偶发超时。
• 脏状态：CI 缓存的浏览器上下文、storageState 过期，或测试间未隔离 cookie/localStorage。

二、排查步骤

• 先留证据：CI 上开启 trace、截图、视频（use: { trace: 'on-first-retry' }），失败时下载 trace.zip 用 Trace Viewer 回放，定位到底卡在哪一步。
• 看失败报错类型分类：
• Timeout waiting for selector → 定位策略问题
• Navigation interrupted → 网络或重定向问题
• Test finished but browser not closed → 泄漏的资源
• 统计失败规律：是固定某条用例、固定某个 worker 序号、还是固定某时段？规律指向对应根因。

三、常见根因与修复方案

• 用自动等待替代硬等待：删掉 waitForTimeout，改用 expect(locator).toBeVisible()、waitForURL、waitForResponse 断言，并按需调大单步超时。
• 确保登录动作真正完成：登录后不要只判断元素出现，应等待跳转后的关键接口响应（page.waitForResponse）再断言。
• 隔离测试数据：每个测试用独立账号或 API 预创建用户，避免并行抢同一账号。
• 固定可控依赖：mock 掉验证码/SSO 等外部服务（page.route），或用测试环境专用的万能码。
• 收敛并发：CI 上把 workers 降到 1–2 验证是否消失，确认是资源竞争后再决定是限流还是加 CI 资源。
• 开启自动重试兜底：retries: process.env.CI ? 2 : 0，配合 trace 才分析首次失败原因，别只靠重试掩盖问题。
• 处理 storageState：若复用登录态，过期时间要覆盖测试周期，或在 beforeAll 重新登录。

四、验证修复

• 本地用 --repeat-each=20 --workers=2 跑压力循环复现。
• CI 连续观察 2–4 周，失败率应归零或仅剩可解释的网络类失败，且有 trace 可查。

优先级建议：先加 trace + retries 止血，再按报错类型逐个根治等待与数据隔离问题。