automated-e2e-testing

# 自动化 E2E 测试（automated-e2e-testing） 本 skill 覆盖 Web 应用自动化测试的完整工作流：将手动测试用例（markmap + Schema）转化为 Playwright spec → 运行并验证 → 发现 Bug → 输出测试报告。 核心原则： 1. **先熟悉业务再写测试** — 对功能不熟悉时，先用自动化脚本主动探索系统，理解实际行为后再动手写测试代码 2. **有疑问就提问，不自行假设** — 编写过程中遇到任何不明确的地方，必须向用户提问澄清，绝不凭猜测写代码 3. **每条自动化用例对应一条手动用例，每条 test 只测一个点** 4. **每个 test 独立**（自建数据 + 自清理） 5. **必须使用 Page Object** — 正式测试中禁止裸写定位器，所有页面交互封装在 Page Object 中 工程约定（脚手架、配置、场景代码模板、Page Object 规范）统一在 `references/playwright-conventions.md`——写代码时加载；通用 Helper（登录、多会话、证据收集）的参考实现在 `references/helpers_reference.md`；类型域三类执行片段（a11y 扫描 / 视觉基线 / 多浏览器矩阵）见工程约定第 12–14 节，type_scope 判入对应轴时按档加载取用 ## When to Use - 给定测试用例（markmap / Schema），需要生成 Playwright spec 文件并执行 - 编写自动化前，需要小规模业务熟悉探索（踩点页面结构、提取选择器） - 自动化执行中发现 Bug，需要收集证据并记录测试报告条目 - 需要编写新的 Page Object 或 Helper 函数 ## When NOT to Use - 端到端测试整个需求（理解→策略→用例→执行→报告的流水线）→ 用 `qa` skill 编排 - 编写手动测试用例 → 用 `test-case-writing` skill - 纯 API 接口测试（无 Web UI 流程）→ 用 `api-testing` skill - 以**理解系统 / 发现风险**为目的的独立探索式测试会话（charter 驱动、产出探索笔记）→ 用 `exploratory-testing` skill；本 skill 的工作流零只做「为写自动化踩点」的小规模探索 - 已确认 Bug 的根因定位、影响分析、回归建议 → 用 `bug-analysis` skill；本 skill 只负责收集 Bug 证据（截图/API/控制台）并记录报告条目 - 代码变更后判断回归范围 → 用 `regression-testing` skill - 单元测试 → 用 Jest/Vitest；性能压测 → 专业工具（k6、locust）；安全测试 → 安全审计专项（见 `test-strategy` 的 handoff 约定） ## 提问时机（必须遵守） **核心规则：不确定就问，宁可多问不要瞎猜。** 格式与裁决规则统一按 `../core/clarify-pattern.md`（场景用「执行确认」）。 | 场景 | 应提问的内容 | 不要自行假设 | |------|-------------|-------------| | 元素定位失败 | "在{页面}上找不到{元素}，实际页面结构是否与预期一致？" | 不要随意换选择器猜测 | | 操作路...