E2E 测试模式

为什么 E2E 容易拖慢发布

单元测试覆盖不了「用户点完一整条链路是否真的可用」：选择器随 UI 重构失效、用例在 CI 里偶发失败、关键流程没人敢动。团队往往在「补几条冒烟」和「维护成本爆炸」之间摇摆，回归问题常常要到线上才被发现。

技能在做什么

本技能围绕可维护的端到端测试套件展开，强调在发布前抓住回归，而不是堆脚本数量。核心思路包括：

• 先锁定关键用户旅程和可验证的成功标准，避免把每个边角页面都塞进 E2E
• 用稳定选择器（如 data-testid、语义化定位）和可重复的测试数据策略，降低 UI 微调带来的大面积修改
• 在实现层加入重试、追踪与用例隔离，便于定位 flaky 用例而不是盲目加长超时
• 在 CI 中并行执行并保留失败制品（截图、trace），让调试不依赖本机复现

配套资源 resources/implementation-playbook.md 提供更细的模式与模板，便于在团队内统一约定。

适用边界与安全

若你只需要单元或集成测试、运行环境无法支撑稳定的 UI 自动化，或无法提供隔离的测试账号与数据，不宜强行上全套 E2E。操作上应避免对生产环境执行破坏性步骤；敏感信息应脱敏，日志与报告里不要泄露真实用户数据。