Playwright E2E 测试代理

为什么 AI 生成的 E2E 测试总是 flaky？

当你把生成 Playwright 测试的任务交给 AI 时，默认结果往往是一场灾难。模型可能会选择脆弱的 CSS 选择器，忽略页面加载的竞态条件，或者在脚本里到处塞满 waitForTimeout。这种测试不仅无法提供可靠的回归保护，反而会成为开发团队的噪音源。本技能旨在改变这种“盲目生成”的模式，强制要求在编写任何测试代码之前，先建立对被测应用的完整认知。

核心工作流：从上下文收集到终态断言

本技能通过一套严格的规范，引导 AI 按工程化标准构建测试套件：

• 强制收集上下文包（Context Pack）：在动手前，必须明确入口 URL、关键用户流（Given/When/Then）、鉴权方式以及已知的慢接口。这些上下文需以注释或 tests/_context.md 的形式固化。
• 稳定的选择器策略：优先使用 getByRole 配合可访问名称，其次是 getByTestId。严禁将冗长的绝对 nth CSS 链作为主选择器，从而降低 UI 结构微调带来的维护成本。
• 合理的等待与断言：放弃固定等待，全面采用 expect(locator).toBeVisible() 等自动等待机制，结合 waitForResponse 处理关键 API。断言必须聚焦于业务终态，而非仅仅检查某个按钮是否可见。
• 结构化的 Flaky 修复循环：遇到失败时，先在本地重跑 3 次，将问题归类为选择器、竞态、数据或环境问题。修复一类后再重跑，若仍不稳定则引入截图或 trace 诊断，直到实现 3 连过。

适用边界与合规注意

本技能专为端到端 UI 测试设计，不适用于单元测试或纯 API 契约测试。在实际执行中，必须严格遵守安全与合规边界：严禁绕过验证码、登录墙或反自动化机制；不得请求、保存或输出密码、Token 等敏感信息；在执行删除、支付等不可逆操作前，必须获得用户的明确授权。