H5 活动页面测试全流程 Workflow

本 skill 是 H5 活动页面开发完成后的自动自测编排器。它不做具体测试工作，而是按固定流程调度子模块，确保开发产出经过完整的"需求 Spec → 测试分析 → 用例生成 → 执行 → 修复 → 回归"闭环。

三层产物递进（每一层都是下一层的唯一输入，不允许跳层）：

00-需求Spec.md  →  01-测试分析.md  →  02-测试用例.md  →  执行报告(md)  →  99-最终报告.html
   需求事实基线      核心路径+测试场景      1场景1用例        逐步截图留痕     可交互、覆盖总览在末尾

触发条件

当以下任一条件满足时触发本 workflow：

1. AI 完成 H5 活动页面开发（包括新建或修改），且用户未明确说"不需要测试"。
2. 用户显式要求对某个 H5 活动页面做测试/自测。
3. 用户提到"提测""自测""活动页测试"等关键词。

核心原则

1. 开发即自测 —— AI 开发完代码后主动进入本 workflow，不等用户手动要求。
2. Spec 先行 —— 先把分散的需求收敛成一份结构化 Spec 并锁定为需求事实基线，测试分析只消费 Spec，不边分析边翻需求、不靠常识补全需求。
3. 核心路径优先 —— 用例的定位是验证核心路径没问题（主链路 + 阻塞 / 资损 / 数据一致性 / 玩法主干分支），不是穷举边界；分析阶段必须先识别核心路径清单（CP-nn），场景与用例只围绕它生成。
4. 先分析、后用例 —— 分析阶段产出的是测试场景（SC-nn），要把"测什么、怎么操作、预期是什么"在场景粒度讲清楚；用例由场景 1:1 转写，不允许跳过分场景直接写用例。
5. 通用功能强制覆盖 —— H5 活动通用功能（尤其上传图片、保存图片、分享）只要页面存在入口，就必须有 P0 场景与用例，不允许以"边界/次要"为由跳过。
6. 用例规模受控（≤30 条） —— 单次产出用例上限 30 条（场景数同为上限）；边界场景（字体缩放、深色模式、极端弱网档位、超长文案组合、无障碍、非主流机型等）只做风险分析、不生成用例，登记进「边界场景风险清单」。
7. 分析与执行分离 —— 分析、用例生成、执行是三个独立模块，各自有完整的输入输出契约。
8. 用例是中间产物 —— 用例生成模块的产出是执行模块的唯一输入，不允许执行模块自行编造用例。
9. 真实执行 —— 执行模块必须真实打开页面、真实操作、真实验证，不做纸上谈兵。
10. 报告按场景呈现 —— 执行报告先给场景覆盖总览（每个场景后打 ✅/❌/⚠️/⛔），再给详细执行记录；不允许只罗列用例编号让人看不出覆盖了哪些场景。
11. 最终报告必须是 HTML —— 单文件自包含、截图缩略图点击即放大查看原图、浅色主题可打印；不接受只给 Markdown 最终报告。
12. 覆盖总览放在第二部分 —— 最终报告的覆盖总览紧跟测试结论，按「通用功能覆盖（F-nn）」+「核心路径覆盖（CP-nn）」两种视角分组呈现，用于一眼确认"该测的是不是都测了、结果如何"。
13. 测试-修复闭环 —— 发现 Bug 后必须修复代码并重跑验证，不允许只报不修。
14. 逐步截图留痕 —— 测试过程中每一个执行步骤都要有一张对应截图，任何一步都能点开回看；缺失截图的步骤视为未执行。
15. 结论前置 —— 最终报告必须在开头给出明确的测试结论（通过 / 不通过 / 有条件通过），不允许把结论埋在报告末尾或只给数据不给判定。
16. 结果可追溯 —— 用例 → 场景 SC-nn → 核心路径 CP-nn → 需求 REQ-nn → 假设 Q-nn → 步骤截图，全链路可追溯。
17. 截图可点击查看 —— 每个执行步骤的截图在 md 报告中是链接 + 内嵌图，在 HTML 最终报告中是缩略图点击放大，用户点开即可查看原始截图。

Workflow 总流程

┌─────────────────────────────────────────────────────────┐
│  Phase 0: 初始化                                         │
│  - 确认被测 H5 页面 URL / 本地路径                        │
│  - 确认需求文档/PRD/设计稿/接口等来源                      │
│  - 创建工作目录                                           │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  Phase 1: 需求 Spec 总结【新增·前置】                     │
│  - 加载 references/00-requirement-spec.md                │
│  - 多源采集 → 冲突消解 → 结构化 Spec → 完整性自检          │
│  - 玩法类型初判 + 待确认项 Q-nn + 环境前置                │
│  - 产出: 00-需求Spec.md（测试分析的唯一需求输入）          │
└───────────────────────┬─────────────────────────────────┘
                        │ 用户确认 Spec（或自动继续）
                        ▼
┌─────────────────────────────────────────────────────────┐
│  Phase 2: 测试分析（核心路径 + 具体测试场景）             │
│  - 加载 references/01-test-analysis.md                   │
│  - (特性加载: 04-activity-quiz / 05-activity-team)       │
│  - 以 00-需求Spec.md 为唯一需求输入                       │
│  - 核心路径 CP-nn → 通用功能 F-nn → 风险识别 → 场景 SC-nn │
│  - 产出: 01-测试分析.md（场景清单 + 详细步骤与预期）      │
└───────────────────────┬─────────────────────────────────┘
                        │ 用户确认分析（或自动继续）
                        ▼
┌─────────────────────────────────────────────────────────┐
│  Phase 3: 用例生成（1 场景 = 1 用例，≤30）                │
│  - 加载 references/02-test-case-design.md                │
│  - 以 01-测试分析.md 为唯一输入，逐场景转写               │
│  - 步骤细化（操作对象+动作+数据+等待+检查点）、预期可判定 │
│  - 产出: 02-测试用例.md（场景-用例映射 + IBO 分组）       │
└───────────────────────┬─────────────────────────────────┘
                        │ 用户确认用例（或自动继续）
                        ▼
┌─────────────────────────────────────────────────────────┐
│  Phase 4: 测试执行（Round 1）                            │
│  - 加载 references/03-test-execution.md                  │
│  - 逐条执行用例，逐步截图，结果回写到场景                 │
│  - 产出: 03-执行报告-round1.md（场景覆盖总览+截图可点）   │
│  - 产出: screenshots/（执行过程截图）                      │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
              ┌──── 有 FAIL 用例？────┐
              │                       │
         是   │                       │  否
              ▼                       │
┌─────────────────────────────────┐   │
│  Phase 4.5: 问题修复             │   │
│  - 分析失败原因，定位代码问题     │   │
│  - 修改代码修复 Bug              │   │
│  - 记录修复内容到报告             │   │
│  - 产出: 04-修复记录.md          │   │
└───────────────┬─────────────────┘   │
                │                      │
                ▼                      │
┌─────────────────────────────────┐   │
│  Phase 5: 回归验证（Round 2）    │   │
│  - 重跑 Round 1 失败的用例       │   │
│  - 验证修复是否生效              │   │
│  - 产出: 05-回归报告.md          │   │
└───────────────┬─────────────────┘   │
                │                      │
                ▼                      │
              ┌──── 仍有 FAIL？────┐  │
              │                    │  │
         是   │                    │  │
              ▼                    ▼  ▼
        (最多循环 2 次)    ┌─────────────────────────────┐
                          │  Phase 6: 最终汇总（HTML）      │
                          │  - 合并所有轮次结果             │
                          │  - 生成 99-最终报告.html        │
                          │  - 覆盖总览放第2部分（功能+路径）│
                          │  - 用 present_files 呈现        │
                          └─────────────────────────────┘

Phase 0 — 初始化

输入收集

启动本 workflow 时，需要确认以下信息（已有则跳过，缺失则向用户索要）：

> 需求来源不足时的处理：不要停下来干等，先按已有来源产出 Spec，把缺口写进「待确认项」并标注 Spec 完整度为 ⚠️ 不完整，请用户补充；用户确认后即可进入 Phase 2。

工作目录创建

<workspace>/h5-test/<活动名称>-<日期>/
├── 00-需求Spec.md          # Phase 1 产出（需求事实基线，测试分析的唯一需求输入）
├── 01-测试分析.md          # Phase 2 产出（核心路径 CP + 测试场景 SC + 风险 + 边界清单）
├── 02-测试用例.md          # Phase 3 产出（由场景 1:1 转写，执行的唯一输入）
├── 03-执行报告-round1.md   # Phase 4 产出（首轮执行，场景覆盖总览 + 每步截图）
├── 04-修复记录.md          # Phase 4.5 产出（如有修复）
├── 05-回归报告-round2.md   # Phase 5 产出（回归验证）
├── 99-最终报告.html         # Phase 6 产出（HTML 汇总报告，截图可点击查看）
├── screenshots/            # 执行过程截图（按轮次/用例分子目录，每步 1 张）
└── state.json              # 流程状态

状态管理

用 state.json 记录当前阶段和循环次数：

{
  "activity_name": "xxx",
  "page_url": "https://...",
  "phase": "spec|analysis|case-design|execution|fix|regression|done",
  "spec_confirmed": false,
  "spec_completeness": "complete|incomplete",
  "scenario_count": 0,
  "case_count": 0,
  "current_round": 1,
  "max_rounds": 3,
  "rounds_completed": [],
  "bugs_found": [],
  "bugs_fixed": []
}

Phase 1 — 需求 Spec 总结（前置，不可跳过）

加载参考文件：references/00-requirement-spec.md

这一步把散落在 PRD、设计稿、接口文档、代码、线上页面与口述中的需求信息，收敛成一份结构化、可追溯、单一事实源的 Spec，作为 Phase 2 测试分析的唯一需求输入。

执行方式：

1. 读取并遵循 references/00-requirement-spec.md 中的全部指令。
2. 该模块会完成：来源盘点 → 逐源提取 → 冲突消解 → 结构化落地 → 玩法类型初判 → 完整性自检 → 待确认项收敛。
3. 产出 00-需求Spec.md 并写入工作目录，同时更新 state.json（phase=spec）。
4. 用 present_files 呈现 Spec 文档，暂停等待用户确认（用户说"确认/继续/OK"后进入 Phase 2）。

跳过确认的条件：用户在触发 workflow 时明确说了"全自动""不需要确认""直接跑完"，或使用 --quick / --skip-confirm。此时 Spec 中的待确认项与缺口必须带到后续产物与最终报告。

Spec 不完整的处理：核心项（活动信息/功能点/业务规则/状态机）任一缺失时，Spec 顶部标记 ⚠️ 不完整 并列出缺口；默认仍等待用户补充或确认后继续，--quick 下带缺口继续。

暂跳过 Spec 的唯一条件：用户显式使用 --skip-spec 且 工作目录已存在一份确认过的 00-需求Spec.md（或用户直接提供等效 Spec 文档）。否则不得跳过。

Phase 2 — 测试分析（核心路径 + 测试场景）

加载参考文件：

执行方式：

1. 先读取工作目录的 00-需求Spec.md，以它作为需求事实的唯一来源。Spec 缺失时必须先回到 Phase 1。
2. 读取并遵循 references/01-test-analysis.md 中的全部指令。
3. 复核玩法类型判定并加载对应特性文件（两类特征并存则都加载）。该步骤不可跳过。
4. 该模块会完成：Spec 消费与校验 → 玩法类型复核与特性加载 → 核心路径识别（CP-nn） → 通用功能识别与强制覆盖（F-nn，含上传/保存/分享） → IBO 风险识别 → 测试场景设计（SC-nn） → 边界场景登记（ED-nn）→ 规模控制（≤30）。
5. 产出 01-测试分析.md 写入工作目录，更新 state.json（phase=analysis、scenario_count）。

本阶段的交付标准（缺一不可）：

> 本阶段不产用例 —— 用例在 Phase 3 由场景 1:1 转写，避免"分析即用例"导致步骤与预期过于粗糙。

6. 用 present_files 呈现 01-测试分析.md，暂停等待用户确认（用户说"确认/继续/OK"后进入 Phase 3）。

跳过确认的条件：用户在触发 workflow 时明确说了"全自动""不需要确认""直接跑完"，或使用 --quick / --skip-confirm。

Phase 3 — 用例生成（1 场景 = 1 用例，≤30）

加载参考文件：references/02-test-case-design.md

执行方式：

1. 读取 01-测试分析.md 作为唯一输入，逐条场景转写为用例（1:1，不增删场景）。
2. 读取并遵循 references/02-test-case-design.md 中的全部指令。
3. 该模块会完成：场景转用例 → 步骤详细度加工（操作对象 + 动作 + 数据 + 等待 + 本步检查点）→ 预期可判定加工（具体文案/数值/状态/接口返回）→ 截图点标注 → 规模与完整度自检。
4. 产出 02-测试用例.md 写入工作目录，更新 state.json（phase=case-design、case_count）。

交付标准：

5. 用 present_files 呈现 02-测试用例.md，暂停等待用户确认（用户说"继续/执行/OK"后进入 Phase 4）。

跳过确认的条件：同上（--quick / --skip-confirm）。

Phase 4 — 测试执行（Round 1）

加载参考文件：references/03-test-execution.md

执行方式：

1. 读取 02-测试用例.md，解析全部用例；同时读取 01-测试分析.md 的场景清单用于报告的场景覆盖总览。
2. 读取并遵循 references/03-test-execution.md 中的全部指令。
3. 该模块会完成：环境准备 → 逐条执行用例 → 逐步截图 → 记录结果 → 结果回写到场景 SC-nn → 失败分析。
4. 产出文件写入工作目录（03-执行报告-round1.md）。

报告呈现要求（强制）：

• 报告第一部分必须是场景覆盖总览：场景ID、场景名称、核心路径、优先级、关联功能、对应用例、执行结果（✅/❌/⚠️/⛔）、截图链接。
• 报告第二部分是详细用例执行记录：每步「截图」列写可点击相对路径链接，用例下方内嵌每步截图（点击可查看原图）。
• 成功与失败用例都要有完整记录与截图，不允许只记录失败的。

执行策略：

• 核心路径用例（CP-nn 关联的 P0）必须全部执行，这是本次验证的最低保证。
• P0 用例必须全部执行。
• P1 用例在时间允许时全部执行，否则标记 跳过（原因）。
• P2 用例仅在有明确风险时执行。
• 用例总量被限制在 30 条以内，正常情况下应全量执行完毕，不允许以"时间不够"为由大面积跳过。
• 如果用例涉及后台数据验证（非前端可验证），标记为 需后台验证 并给出验证步骤，不阻塞其他用例。

截图要求（强制）：

• 逐步截图：用例的每一个执行步骤操作完成后立即截图，不允许只截首末两张。
• 目录：screenshots/round<N>/TC-<维度>-<序号>/
• 命名：TC-<维度>-<序号>_步骤<N>-<动作>.png，失败步骤额外加 -fail 并截完整页。
• 执行报告每一步的「截图」列必须填可点击的相对路径链接，并在用例下方内嵌每一步截图；报告末尾附「截图索引」表（步骤数 = 截图数）。
• 缺失截图的步骤视为未执行，该用例不得判 PASS。

Round 1 完成后判断：

• 如果全部 PASS → 跳过 Phase 4.5 和 Phase 5，直接进入 Phase 6。
• 如果存在 FAIL → 进入 Phase 4.5。

Phase 4.5 — 问题修复

当 Round 1 发现 FAIL 用例时，AI 必须进入修复阶段：

修复流程

1. 归因分析：逐条分析 FAIL 用例的失败原因，确定是代码 Bug、环境问题还是用例问题。
2. 定位代码：找到需要修改的源文件和相关代码位置。
3. 修复代码：直接修改源代码修复 Bug。
4. 记录修复：将修复内容写入 04-修复记录.md。

修复记录格式（04-修复记录.md）

# <活动名> 修复记录

## 修复轮次：Round 1 → Round 2

### BUG-01: <Bug 标题>

| 项 | 内容 |
|---|---|
| 关联失败场景 | SC-03 |
| 关联失败用例 | TC-B-03 |
| 失败原因 | <具体描述> |
| 根因分析 | <代码层面的根因> |
| 归因类型 | 前端逻辑错误 / 接口异常 / 配置问题 / 环境问题 |
| 修改文件 | <文件路径> |
| 修改内容 | <具体改了什么> |
| 修复验证 | 预期修复后 SC-03 / TC-B-03 将通过 |

（对每个 Bug 重复上述结构）

## 修复汇总
- 修复 Bug 数：x
- 涉及文件：x 个
- 预期 Round 2 重跑：x 条用例（场景 SC-xx、SC-xx）

修复约束

• 只修 Bug，不改测试用例的预期结果 —— 预期是分析阶段定的，不能为了让测试通过而降低标准。
• 修复必须是实际代码修改 —— 不能只记录问题不修。
• 每次修复记录必须关联失败用例 —— 可追溯。
• 如果判断是用例问题而非代码问题 —— 在修复记录里标注"用例问题"，说明原因，不修改代码。

Phase 5 — 回归验证（Round 2）

修复完成后，重跑测试验证修复效果：

执行策略

1. 默认只重跑失败的用例（节省时间）。
2. 如果用户要求全量重跑，则重跑全部用例。
3. 使用相同的测试用例和执行方式。
4. 产出 05-回归报告-round2.md（同样含场景覆盖总览 + 每步截图）。

回归报告格式

# <活动名> 回归验证报告（Round 2）

## 一、回归概览
- 重跑用例数：x
- 通过：x
- 仍失败：x
- 修复验证通过率：xx%

## 二、场景覆盖总览（本轮重跑场景）

| 场景ID | 场景名称 | 优先级 | 对应用例 | Round 1 | Round 2 | 截图 |
|---|---|---|---|---|---|---|
| SC-03 | 分享唤起与分享链接 | P0 | TC-B-02 | ❌ FAIL | ✅ PASS | [查看](screenshots/round2/TC-B-02/) |

## 三、修复验证结果

| Bug | 关联场景 | 关联用例 | Round 1 结果 | Round 2 结果 | 修复是否生效 |
|---|---|---|---|---|---|
| BUG-01 | SC-03 | TC-B-02 | FAIL | PASS | ✅ 已修复 |

## 四、详细执行记录
（每用例：步骤表 + 每步截图链接 + 步骤截图内嵌）

## 五、仍失败项（如有）
| 场景ID | 用例ID | 失败原因 | 与 Round 1 差异 | 建议 |
|---|---|---|---|---|

循环控制

• 最多循环 2 次（Round 1 → 修复 → Round 2 → 修复 → Round 3）。
• 如果 Round 2 仍有 FAIL，可以再修一轮，但最多到 Round 3。
• 超过最大轮次仍有 FAIL，停止循环，在最终报告中标记为"遗留问题"。

Phase 6 — 最终汇总（输出 HTML 报告）

加载参考文件：references/06-report-html.md

合并所有轮次的结果，生成单文件 HTML 最终报告 99-最终报告.html。报告开头必须给出明确的测试结论（通过 / 不通过 / 有条件通过）及判定依据，不允许只罗列数据。

报告章节顺序（固定）

结论判定规则（严格执行）：

• ✅ 通过：P0 场景全部通过，且无 BLOCKED、无未修复的遗留问题。
• ⚠️ 有条件通过：仅 P1/P2 场景失败，风险已知且已明确说明影响范围与跟进计划。
• ❌ 不通过：存在任一 P0 场景失败、或存在 BLOCKED、或存在未修复的遗留问题。

> 结论必须在报告第一段；覆盖总览必须紧跟结论，放在第二部分——先让人一眼看清"该测的是不是都测了"。

「覆盖总览」的呈现方式（强制）

不复述平铺的场景列表，按 01-测试分析.md 的分组口径给出两张表：

2.1 通用功能覆盖（按 F-nn 分组）

2.2 核心路径覆盖（按 CP-nn 分组）

• 结果标记：✅ PASS ｜ ❌ FAIL ｜ ⚠️ 需人工/后台验证 ｜ ⛔ BLOCKED ｜ ➖ SKIP
• 组内判定：全 ✅ → ✅；含 ❌/⛔ → ❌；仅含 ⚠️ → ⚠️
• 上传图片 / 保存图片 / 分享 若"涉及但未覆盖"，必须用醒目提示块标为覆盖缺口

HTML 报告硬性要求

1. 单文件自包含：CSS/JS 内嵌，不依赖 CDN，双击即可离线打开。
2. 截图相对路径：HTML 放工作目录根，截图引用 screenshots/round<N>/...（与 screenshots/ 同级）。
3. 截图可点击查看：每条用例下横向排列该用例全部步骤截图（成功失败都要），点击弹出灯箱看原图，支持 ←/→ 切换与 ESC 关闭；失败截图红色描边。
4. 覆盖总览在第二部分，且必须同时有通用功能与核心路径两张表。
5. 浅色主题、打印友好。

生成后用 present_files 呈现 99-最终报告.html（可直接预览）。

异常处理

与已有 Skill 的关系

• 本 skill 是编排层，不做具体分析或执行。
• 需求 Spec 模块（references/00-requirement-spec.md）负责需求事实收敛，是所有下游阶段的输入基线。
• 测试分析模块（references/01-test-analysis.md）产出核心路径 + 测试场景 + H5 通用功能定义（上传/保存/分享等），方法论与 aigc-h5-test-design skill 一致；其需求输入固定为 00-需求Spec.md。
• 用例生成模块（references/02-test-case-design.md）把场景 1:1 转写为详细可执行的用例，输入固定为 01-测试分析.md。
• 活动特性模块按玩法类型拆分，供分析阶段叠加加载（内含该玩法下的上传/保存/分享具体功能定义）：
• references/04-activity-quiz.md —— 纯答题生图类（预置题目+答案 → 上传图片 → 按答案组装 prompt 生图）
• references/05-activity-team.md —— 组队邀请生图类（预置剧情 → 邀请好友组队 → 各方传图 → 按剧情+类型组装 prompt 生图）
• 测试执行模块（references/03-test-execution.md）依赖浏览器自动化能力（Playwright / browser-use skill），报告按场景展示且每步截图可点击查看。
• HTML 报告模块（references/06-report-html.md）负责把各轮结果整合成可交互的单文件 HTML 最终报告。

快速命令

用户可以在触发 workflow 时附加以下指令：