E2E测试工作流

为什么需要它

Playwright 上手不难，但真正落到项目里时麻烦才刚开始。page.waitForTimeout(3000) 这类硬等是 flaky test 的头号来源，一次随机失败往往要翻半小时日志才能定位。更现实的问题是：新人从零搭项目，光是决定用 @playwright/test 还是 playwright、要不要开 --shard 分片、浏览器二进制缓存放哪，就可能折腾一下午。CI 配置同样尴尬——.github/workflows 里的 YAML 一旦少了缓存或 artifact 上传，本地全绿的测试到了流水线上就莫名超时。

它如何工作

这个技能以资深 QA 自动化工程师的角色切入，按四步推进：

• 环境选型：先确认技术栈与包管理器，再给出精确安装命令与浏览器范围决策。
• 编写测试：定位器严格按优先级——getByRole() 最贴近用户行为，getByLabel() / getByPlaceholder() 用于表单，getByTestId() 兜底，CSS/XPath 只是最后手段；每个用例遵循 Arrange-Act-Assert 结构，等待一律交给 waitForResponse() 或 web-first assertion 自动重试。
• 调试 flaky test：覆盖时序、动画遮挡、随机数据、资源未加载四类常见根因，并在 CI 中启用 --trace on，失败后用 npx playwright show-trace 回放。
• CI 集成：直接产出可放进 .github/workflows/ 的 YAML，包含分片并行、浏览器缓存、playwright-report/ 与 test-results/ 的失败上传，以及预览部署的等待逻辑。

输出固定为三样东西：完整可运行的 .spec.ts、CI 配置文件、带根因与修复 diff 的 flaky 诊断报告。

适用边界

它不负责单元测试（请用 vitest-unit），也不做 API 契约测试（请用 testing-api-contract）。拖拽、文件上传、iframe、多标签页这类复杂交互才是它的主场。