# 用例格式规范（case-format）

> 框架级用例格式硬约束全集（`test-case-writing` 编写、`test-case-review` 修订、`bug-analysis` 建议新增用例时统一遵守），编写与定稿自检时**逐条执行本文件**，不是可选参考。从零拼装用例文件的起点模板（含详细格式范例）由 test-case-writing skill 的 templates 目录提供。

## 1. 文件头部导读区（硬性产出，任何模式）

用例正文（第一个模块）之前必须有导读区，标准是**零上下文新人**（新入职、没读过需求文档、没人讲解、只拿到这一份文件）能直接开工。四件套：

1. **功能简介 + 角色表**：一两句话说清这是什么功能；每个角色一行「角色 → 用它做什么」
2. **环境与账号表**：后台入口地址、App/客户端获取方式、每个角色的测试账号。信息未知时**不省略**——列占位行标注「TODO：向 {谁} 索取」，让读者开工前知道要找谁拿什么
3. **术语表**：正文用到的内部系统名（如风控系统代号）、英文字段名、状态代号，逐条「术语 → 中文名 → 一句话解释」。判定标准：正文出现的每个非通用词，术语表可查
4. **图例**：P0/P1/P2 含义与未标注时的默认级别、`SMOKE-` 前缀、`[需Mock]` 等标签含义

## 2. 正文零代码内部（硬约束，最重要）

用例正文是给**测试工程师看和执行**的，必须用业务语言。正文禁出现：

- 代码位置：`文件:行`（如 `set.go:35`、`create.tsx:42`）
- 代码符号：SDK/库的类与函数（如 `srchbase.StringColumn`、`PlatformCli`、`json.Marshal`）
- 错误码与控制流：`resp.Code != 0`、`SetAbort`、`return nil`、`fmt.Errorf`
- 实现术语：`Qualifiers 下推`、`nil 守卫`、`OptionType 分支`

一律改业务语言：`文件:行` → 不出现（落附录）；`resp.Code != 0` → "服务端返回业务错误"；`SetAbort` → "任务进错误文件"；`Qualifiers 下推` → "只返回请求的字段"。

**允许保留**（这些是测试要用的业务/配置事实，不是代码内部）：功能/接口/stage 名（如 `hbase.set`）、配置项 key（如 `fields`）、业务字段名（如 `lr_label_top`）、业务枚举值（如 `DataType=图片`）、可观察的日志原文（作为判定标准时引用，如错误信息含 `is required`）。

> 判定标准：随机挑一条用例，让一个**不读代码**的测试工程师复述"我要验证什么、给什么数据、怎么算通过"。复述不出 → 违反本约束，改写。

## 3. 用例编号（硬性，供交叉引用）

- 每条用例唯一编号 `TC-{模块号}-{序号}`（如 `TC-02-03` = 模块 2 第 3 条），写在名称前：`- **TC-02-03 {用例名称}** [P1]`
- 模块号对应正文一级模块编号（`## 2.` 模块的用例为 TC-02-xx）
- P0 冒烟用例在名称后追加冒烟序号标注（如 `（SMOKE-1）`），便于快速抽取冒烟集
- 附录交叉引用（代码证据清单、风险点 Dn 覆盖用例、改动文件映射）与增量更新的变更标记，一律引用 TC 编号

## 4. 详细格式（默认）

**有 UI 功能**用四段式（优先级标注在名称行）：

```markdown
- **TC-{模块号}-{序号} {用例名称}** [P0/P1/P2]
  - 前置条件: {该条特有的前置；无特有时可省略此行}
  - 操作步骤: 1. 进入{页面} 2. 填写{字段} 3. 点击{按钮}
  - 预期结果: {页面上能观察到的明确现象}
```

**无 UI 后端功能**用协作五段式（优先级同样标注在名称行，不单列字段）：

```markdown
- **TC-{模块号}-{序号} {用例名称}** [P0/P1/P2]
  - 前置条件: {已准备的数据，如测试编号/账号}
  - 操作步骤（请开发执行）: 1. 用{功能名}处理{具体数据} 2. {触发方式}
  - 预期结果（请开发反馈）: {明确唯一的可观察结果}
  - 验证方式: {开发查库/查日志的具体位置与反馈内容}
```

只有用户明确要求紧凑格式、或信息密度优先（冒烟清单、快速审查）时，才使用紧凑格式：

```markdown
- TC-{模块号}-{序号} 操作条件，预期结果 [P0/P1/P2]
```

> 代码模式下 `代码依据: 文件:行` **不写在每条用例里**；若需溯源，在附录「代码证据清单」统一列表（用例编号 ↔ `文件:行`）。

## 5. 步骤与判定细则

- **前置条件去冗余**：同一子模块下多数用例共享的前置（如"已登录管理员""已创建项目X"），在该子模块标题下方用引用块统一声明一次（`> 前置：...`）；单条用例的「前置条件」行只写该条额外需要的条件，没有额外前置时可省略该行
- **嵌入具体数据**：操作步骤里用具体的测试数据（真实编号、字段名、字段值），不要写占位符 `{xxx}`，让测试能直接照着执行或整包发给开发
- **页面可达性**：每个被测页面/入口在文件中首次出现时，写清从哪里到达（如「后台 → 营销中台 → 券工场 → 活动列表」）。入口在输入源中未说明时，不得只写「打开 XX 页」蒙混——列入澄清问题，并在导读区环境表标注「TODO：入口待确认」
- **异步行为必含判定时限**：预期结果含「自动变为 / 稍后更新 / 异步生效」时，必须写明等待多久不发生即判失败（如「到达结束时间后 5 分钟内自动变为已结束，超过 5 分钟未变判失败」）。时限无依据时按输入源指标推算或列入澄清问题，不得留白让执行者自定
- **断言范围不超出验证强度**：用例名称的断言不得大于步骤实际能证明的范围——两个样本证不了「全局唯一」，名称应改为「不同活动的编号互不相同」；确需全局断言时改为协作用例（请开发查库确认约束）
- **一条用例只测一个点**：预期结果明确唯一，不写"或 A 或 B"——应拆分为两条

## 6. 可测试性标注

- `[需真机]` → 替代：模拟器 + Mock 数据，标注为 P2
- `[需Mock]` → 替代：写 Mock 脚本并记录在附录中
- `[需专业环境]` → 替代：改为单元测试或标记"需专项测试"
- 类型域轴标签：`[并发]` / `[可靠]` / `[安全]` / `[兼容]` / `[迁移]` / `[集成]` / `[国际化]`——来自测试策略 type_scope 的 include 轴（消费方式映射见 `test-type-matrix.md` 第 12 节），与 Schema 的 type 字段配套

带标注的用例，附录「可测试性说明」必须落到**可行动**：具体平台/工具名与操作入口，未知则写「TODO：向 {谁} 确认 {什么}」。只写「需 Mock 平台配置」而不说平台是什么、找谁，等于没写。

## 7. Markmap 层级规范

```markdown
# 项目名 测试用例

## 1. 模块名
### 1.1 子模块名
#### 1.1.1 细分类别
- TC-01-01 具体测试点 [P0]
```

附录内容（数据模型、参数定义等）放在文件末尾，不影响思维导图渲染。

## 8. 测准声明（代码模式必加，文件顶部）

代码模式下，用例文件顶部必须加测准声明：

> **测准声明**：本文件以 `{仓库} {分支}` 实际实现为唯一功能基线；需求/设计文档降为背景对照（偏离见附录）。代码级证据（`文件:行`、缺陷记录、接口对照）统一放文件末尾附录，**不写进用例正文**（见「正文零代码内部」）。

## 9. 附录区规范（代码模式必含，与正文 `---` 物理隔离）

代码模式的用例文件，除功能用例外，必须含以下产出——**全部放在文件末尾的附录区**，附录顶部标注"开发技术核查清单（非测试执行项）"。Cx/Dn 记录的 evidence 字段格式见 `evidence.md`，Dn 评级见 `risk-model.md`：

- **附录：缺陷记录 Cx**：编号（C1、C2…）+ 现象描述 + `文件:行` 证据 + 证据等级（E0–E4）+ 置信度 + 处置（主线验证 / 专项验证 / 待实测确认 / 已证伪 / 后端范围）
- **附录：高风险点 D1-Dn**：编号 + 风险描述 + 等级（Critical/High/Medium/Low，Impact × Likelihood 评分）+ `文件:行` 证据 + 覆盖用例编号 + 通过判据
- **附录：代码证据清单**（可选）：用例编号 ↔ `文件:行` 对照，供开发溯源（Schema 的 `code_refs` 由此抽取）
- **附录：文档偏离对照**：表格列「设计点 / 文档描述 / 实际实现 / 偏离类型」
- **附录：改动文件映射**：表格列「改动文件 / 影响模块 / 回归用例 / 分类（🆕 新建 · ✏️ 修改 · 🗑️ 删除 · 💀 死代码——与阶段一「改动盘点」四类一致，`regression-testing` 沿用同一枚举）」
- **附录：可测试性说明**（任意模式，存在带标注用例时）：按 TC 编号逐条列出，替代方案落到可行动

> 这些代码级内容是给**开发/评审**核查用的，测试工程师不执行、也不应被其干扰。Cx/Dn 中映射的"覆盖用例"指向正文中的业务语言用例。**正文与附录物理隔离是本规范的核心要求**——不要把 Cx/Dn/`文件:行` 当作正文的一个模块穿插在功能用例之间。

> 纯文档模式（无代码）不产出以上内容，降级时已提示用户准确性受限。

## 10. 审查记录与变更报告格式

审查记录（追加在文件末尾，附录之后）。**适用范围**：本节模板供 `test-case-writing` 写时自审（阶段四）使用；`test-case-review` 独立审查的审查记录以其 SKILL.md 模板为唯一来源（含基准可信度 / 缺失 / 冗余 / 错误 / 高风险未覆盖字段，标题带「test-case-review {日期}」落款以便与写时自审节区分）。两节各自追加、不互相覆写：

```markdown
## 审查记录
- 审查前：XX 条用例，XX 个模块
- 审查后：XX 条用例，XX 个模块
- 新增：XX 条（{简述补充了哪些场景}）
- 调整：XX 条（{简述调整内容}）
- P0/P1/P2 分布：XX/XX/XX
```

变更报告（增量更新时追加在审查记录之后）：

```markdown
## 测试用例变更报告 — {日期}

- 变更来源：{需求文档版本 / Bug 单号}
- 影响模块：{模块列表}
- 新增用例：XX 条 | 修改用例：XX 条 | 废弃用例：XX 条
```

# 统一澄清与确认格式（clarify-pattern）

> 全框架唯一的"向用户提问"格式。`requirement-analysis`（需求澄清）、`test-case-writing`（阶段二澄清）、`automated-e2e-testing` / `api-testing`（执行中确认）、`exploratory-testing`（异常定性）统一使用，用户看到的问题卡片跨 skill 长一个样。

## 核心规则

**不确定就问，宁可多问不要瞎猜；问了就等答复，不自行假设。** 用户在澄清环节的明确答复具有最终裁决力（语义见 `evidence.md` 第 2 节裁决规则），必须落盘到产物（需求模型 `open_questions` / 澄清记录 / Bug 定性标注），后续阶段不得推翻。

## 统一格式

```markdown
🔍 {场景}：{一句话问题概述}

- **问题来源**: {文档名+章节 / `文件:行` / 页面或接口 / 用例 TC 编号}
- **具体问题**: {一句话提问，不嵌套多个问题}
- **影响**: {影响哪些模块 / 用例 / 判断}
- **建议选项**: A) ... B) ...（如有依据才给；无依据则留空，不要编选项）
```

- **场景** 取值：`需求澄清`（规则/边界/状态/权限模糊）、`执行确认`（定位失败/路径不通/预期歧义/环境索取）、`Bug 定性`（"预期行为还是缺陷？"）
- 多个问题逐条独立成卡，不合并成一段叙述；单条简单问题可用紧凑单行：`🔍 需求澄清：**来源** {文档/位置}｜**问题** ...｜**建议** ...`

## 何时必须问（命中即问）

1. 功能/规则/流程描述模糊，或边界条件（最值、上限、超时）未定义
2. 状态流转缺失转换路径、角色权限未说明
3. 文档间 / 文档与代码不一致（列两边原文与位置，问"以哪个为准"）
4. 异步/延迟行为无判定时限
5. 元素定位失败、操作入口不存在、预期与实际二义（执行类）
6. 发现异常行为，无法自判"预期还是缺陷"（定性类）

## 需求歧义九类漏网模式（扫描矩阵；本文件为单一权威源）

> 需求类澄清（requirement-analysis / test-case-writing 阶段二）在「何时必须问」之上，
> **逐类过筛材料**，命中的必须进澄清清单。评测实测：无此矩阵时模型对隐蔽歧义的命中率反低于裸模型；
> 补入矩阵后澄清维度命中率 25%→50%。

| # | 模式 | 扫描问题 |
|---|------|---------|
| A | 时间口径 | 每个"X 天/小时/年/每天 N 次"：起算点？自然单位还是滚动窗口？含否当日/时区？ |
| B | 数值边界含否 | 每个"1–20/N 以内/不超过"：端点含否？非整数/取整方向？ |
| C | 规则冲突与叠加 | 同一对象多处规则（正文 vs 活动页 vs FAQ）：替代还是叠加？冲突以谁为准？ |
| D | 术语一致性 | 同一概念多个名字（"商城/兑换中心"类）？是否同一入口/模块？ |
| E | 异步时限 | 每个异步/延迟/自动行为：多久不发生判失败？无时限即不可测，必须问 |
| F | 部分场景 | 退款/部分支付/部分失败：按比例还是全额？负数/欠额如何处理？ |
| G | 并发与顺序 | 并发到达以谁为准？用户操作与定时任务/自动流程的竞态？ |
| H | 未定义的判定口径 | "异常账号""高风险"等判定标准；历史数据保留期限与可查范围 |
| I | NFR 指标空缺 | 性能/容量/可靠性/兼容性只有定性主张无指标：吞吐、并发数、响应时间阈值各是多少？兼容基线（系统/版本/分辨率/浏览器）？SLA 与其测量方法？——无指标即不可测：要么问到数值，要么用户显式裁定"本版不验证"进 scope 非目标 |

## 何时不问

- 代码可静态裁决的事实（以代码为准，偏离记录后统一提交，不逐条打断）
- 产物内部组织、格式、命名等不影响正确性的自由度

# 覆盖度检查表（coverage）

> 编写完测试用例后，逐维度检查。分为**核心维度**（所有项目必检）和**扩展维度**（按项目类型选取）。
> 对每个维度问一个核心问题——**"这个维度上是否有遗漏？"**，而非"这个维度是否覆盖了？"
>
> 本文件同时承载**代码审查发现模式清单**（第 7.1 节），供阶段一代码探索与阶段四覆盖审查共用。`test-strategy` 制定范围、`test-case-review` 独立审查时同样引用本清单。
> 类型性维度（11 / 13–16 / 18 / 19）的**纳排与深度决策已上收**至 `test-type-matrix.md`（test-strategy 产出 type_scope）——本文件的类型性维度仅作用例设计提示，不是范围决策来源。
>
> **执行强度按消费方分流**（防"全部检查项"被误读为 19 维机械全检）：
> - **编写流程**（`test-case-writing`）：核心维度**部分内联**为其阶段三交付核对——维度核对仅三项硬核对（主流程 / 时间双侧 / 负向底数）；其余核心维度不设编写流程内强制核对（设计期靠方法选择覆盖，本文件仅为按需参考），由独立审查全检兜底；阶段四仅固定抽查 5 项（主流程复查 / 单一职责 / FAQ 非目标 / 二阶交叉 / 跨模块重复），不从本清单取点；
> - **独立审查**（`test-case-review`）：核心 7 维逐项全检 + 横切可执行性，扩展维度按下方「维度选取速查」按项目类型选取；
> - 任何场景都不做扩展维度的机械全检。

---

## 核心维度（7 个）

> 1-6 所有项目必检；**7 代码审查发现**为代码模式必检（无代码仓库则跳过该维度）。

### 1. 功能主流程
每个功能点的正向路径是否走通？每个功能选项是否有对应用例？

**典型遗漏**：只测了"创建成功"，没测"创建后数据是否正确持久化"。

### 2. 输入校验
必填缺失、格式非法、边界值（空/最大/最小/零值）、多值分隔符，是否都有对应的拦截用例？**每条校验规则是否在所有写入路径（创建/编辑/重新提交/导入）上都验证过，而不是只挂在创建？**（方法见 `methods/boundary.md`）

**典型遗漏**：创建时验了"门槛须大于面额"，驳回后编辑重提时没验——编辑路径绕过校验是真实系统的高发 bug。

### 3. 逆向操作与生命周期
创建→删除、分配→释放、导入→撤销、修改→恢复，每对操作是否都有验证？删除/释放后关联数据是否级联清理？**每种失败/拦截场景之后，重试恢复是否有用例（失败 → 再试 → 成功）？**

**典型遗漏**：只测了"领取成功"，没测"领取后释放任务，记录是否恢复"；测了"风控拦截提示"，没测"拦截过的用户之后正常领取是否放行"。

### 4. 状态流转
完整状态机的每一条边（A→B）是否覆盖？非法转换是否拒绝？并发状态变更是否有竞态条件？（方法见 `methods/state-machine.md`）

**典型遗漏**：只测了"待领取→标注中→已提交"，没有覆盖完整状态机。

### 5. 数据一致性
级联操作后关联数据是否一致？重复操作是否幂等？数据清理/归档后是否有残留？**名称/编号等标识字段重复提交时的唯一性行为是否验证？**

**典型遗漏**：只测了正常写入，没有测试重复导入时的幂等行为；没测"创建两个同名活动"系统是允许还是拦截。

### 6. 文档隐含需求
FAQ 每个问答是否转化了至少 1 条用例？"非目标"声明的限制是否有验证用例？注释、脚注中的约束条件是否被遗漏？

**典型遗漏**：FAQ 明确"复审队列就是普通队列"，但没有设计用例验证。

### 7. 代码审查发现（代码模式必检；无代码则跳过）
全面代码审查发现的每个潜在 bug 是否都有验证用例？高风险点 D1-Dn 是否每条都有回归用例？死代码是否确认可忽略（不写用例）？文档偏离是否已确认（记入附录）？证伪项是否已核实（避免伪用例）？**每个发现的验证用例本身是否用业务语言编写、代码证据（`文件:行`）是否隔离到了附录（不污染正文）？**

**典型遗漏**：只测功能，未验证代码中的 null 未兜底 / 边界未防护（NaN/负数/空数组）/ 状态死锁等潜在 bug；或把已证伪的风险点（无下游消费）当成真 bug 写了用例；或把 `文件:行`/SDK 符号直接写进用例正文，导致测试工程师看不懂。

#### 7.1 代码审查发现模式清单（阶段一代码探索逐项查找）

每条发现附 `文件:行` 证据并标注确信度，evidence 格式见 `evidence.md`：

| # | 模式 | 查找要点 |
|---|------|---------|
| 1 | null/undefined 未兜底 | `.map`/`.length`/`.width` 直接作用于可能为空的值 |
| 2 | 可选链断裂 | 链式取值中间层可能为空，后半段未防护 |
| 3 | 边界未防护 | NaN / 负数 / 空数组 / 超大值 / 0 直接进入计算 |
| 4 | 状态死锁 | 改了状态却被门控条件拦截，流转不出去 |
| 5 | 副作用泄漏 | 全局 state / 缓存修改后未 cleanup |
| 6 | 并发竞态 | 检查-后-使用（TOCTOU）、并发写覆盖 |
| 7 | 硬编码 | project_id / 环境 / 魔法数固定写死 |
| 8 | 权限遗漏 | 只在入口鉴权，内部路径/接口未二次校验 |
| 9 | 异步未 await | Promise 未等待、错误未捕获 |
| 10 | 错误静默吞掉 | 空 catch / 只打日志不反馈用户 |
| 11 | 文档 vs 实现不一致 | 字段名/类型、流程顺序、字段是否真提交、默认值 |
| 12 | 死代码/死声明 | 未挂载路由的模块、声明未解构的 props、未调用的 API |
| 13 | 证伪项 | 看似高风险实则无下游消费的字段/状态（核实后降级，避免伪用例） |

### 横切必检：可读性与可执行性（所有项目，定稿前必做）

以**零上下文新人**（没读过需求文档、没人讲解）为标准，逐项执行 `executability.md` 的定稿自检清单：文件头部有无导读四件套？每条用例**看得懂**（正文零代码内部、内部系统名与英文字段名可在术语表查到）？能否**开工执行**（页面入口写明、前置状态有制造方法、异步预期有判定时限、Mock 依赖写明找谁）？独立执行（有 UI）或协作执行（无 UI，标注请开发执行/反馈）？嵌入的是具体数据还是占位符？

**典型遗漏**：用例堆满 `文件:行`/SDK 符号/错误码常量；"风神""coupon_batch_no"裸用不解释；几十条用例第一步"打开活动页"但入口全文未说明；"自动变为已结束"没写等多久算失败；环境地址与测试账号只字未提，新人第一步登录就卡住。

---

## 扩展维度（按项目类型选取）

### 8. 技术实现细节（有设计文档的项目）
数据库约束是否生效？缓存加载时机和一致性？异步任务状态追踪和失败恢复？消息格式和向后兼容？

**典型遗漏**：设计方案提到"一次性加载缓存"，但没有测试导入过程中缓存数据变化的场景。

### 9. 权限与角色（多角色系统）
普通用户、管理员、无权限用户的操作是否验证？角色变更后权限是否即时生效？（方法见 `methods/permission.md`）

**典型遗漏**：FAQ 明确"管理员可浏览全部"，但没有设计管理员在绑定模式下的测试用例。

### 10. 错误处理与反馈（所有项目推荐）
错误信息是否清晰且包含定位信息？部分失败时成功部分是否保留？错误恢复后系统状态是否一致？

**典型遗漏**：只测了"报错"，没有验证错误信息的具体格式和可操作性。

### 11. 并发与性能（有性能要求的项目）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 1 性能效率 / 轴 4 并发一致性）。

多用户并发操作同一资源？批量操作性能基线？查询延迟上限？高并发下无重复无遗漏无死锁？

**典型遗漏**：设计方案明确给出"P99 < 50ms"的性能指标，但没有转化为具体的性能测试用例。

### 12. 链式/复杂流程（有多阶段操作的项目）
多阶段端到端验证？跨阶段数据传递完整性？多轮操作（>2 轮）累积正确性？中断后恢复/重试？

**典型遗漏**：只测到第 2 轮复审，没有验证第 3 轮、第 4 轮时历史数据是否正确累积。

### 13. 安全性（Web/API 项目必选）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 2 业务安全；越权功能正确性归功能域 permission）。

未认证/越权访问拦截？注入攻击防护？多租户数据隔离？敏感数据保护？接口限流？

**典型遗漏**：只测了功能正确性，没有测试用户 A 能否访问用户 B 的数据。

### 14. 兼容性（有前端的项目必选）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 5 兼容性）。

目标浏览器兼容？移动端适配？不同屏幕尺寸/分辨率？

**典型遗漏**：Chrome 上正常，Safari 上日期选择器无法弹出。

### 15. 国际化（多语言/海外项目）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 8 国际化）。

语言切换、时区处理、货币格式、RTL 布局、文案溢出/截断？

**典型遗漏**：时间戳在 UTC+8 正确，在 UTC-5 显示错误。

### 16. 网络与连接（移动端/实时系统）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 3 可靠性）。

弱网环境、断网重连、请求超时、离线模式？

**典型遗漏**：正常网络下提交成功，弱网下用户点击两次导致重复提交。

### 17. 通知/消息（有通知功能的项目）
消息发送正确性、失败重试、去重、模板变量渲染？

**典型遗漏**：只测了"消息发出"，没有测试消息内容中变量替换是否正确。

### 18. 第三方集成（调用外部服务）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 10 契约与集成）。

正常/超时/失败/降级？回调/Webhook 处理？异常数据容错？

**典型遗漏**：只测了第三方 API 正常返回，没有测试超时后的重试和降级。

### 19. 数据迁移/升级（存量系统迭代）

> 类型纳排与深度决策以 `test-type-matrix.md` 为准（轴 9 迁移与升级）。

Schema 变更后老数据兼容？迁移完整性？新旧版本共存？回滚后数据可用？

**典型遗漏**：新版本上线后，历史数据的展示格式异常。

---

## 维度选取速查

| 项目类型 | 核心维度 | 额外必选维度 |
|---------|---------|------------|
| Web 应用（前后端） | 1-7 | 8, 9, 10, 13, 14 |
| 纯 API 服务 | 1-7 | 8, 10, 11, 13 |
| 移动端应用 | 1-7 | 10, 14, 16 |
| 多端项目 | 1-7 | 按端分别选取 + 跨端一致性检查 |

> 编号说明：1-7 为核心维度，其中 **7 代码审查发现**为代码模式必检（无代码仓库跳过）。所有项目类型在有代码仓库时均必选维度 7。

---

## 自查结果模板

> 此表供人工评审或团队复盘时填写。AI 执行按 test-case-writing 阶段四的**抽查口径**执行（逐维度全检已废除），抽查结果并入用例文件末尾的「审查记录」，**不单独产出此表**（SKILL.md 规定不产出中间文件）；本清单作为抽查选点与按需加深的维度索引。

| 维度 | 适用 | 覆盖状态 | 缺失场景 | 补充用例编号 |
|------|------|---------|---------|-------------|
| 1. 功能主流程 | 核心 | | | |
| 2. 输入校验 | 核心 | | | |
| 3. 逆向操作与生命周期 | 核心 | | | |
| 4. 状态流转 | 核心 | | | |
| 5. 数据一致性 | 核心 | | | |
| 6. 文档隐含需求 | 核心 | | | |
| 7. 代码审查发现 | 核心（代码模式） | | | |
| 横切：可读性与可执行性 | 核心（所有项目） | | | |
| 8. 技术实现细节 | 扩展 | | | |
| 9. 权限与角色 | 扩展 | | | |
| 10. 错误处理与反馈 | 扩展 | | | |
| 11. 并发与性能 | 扩展 | | | |
| 12. 链式/复杂流程 | 扩展 | | | |
| 13. 安全性 | 扩展 | | | |
| 14. 兼容性 | 扩展 | | | |
| 15. 国际化 | 扩展 | | | |
| 16. 网络与连接 | 扩展 | | | |
| 17. 通知/消息 | 扩展 | | | |
| 18. 第三方集成 | 扩展 | | | |
| 19. 数据迁移/升级 | 扩展 | | | |

# 统一证据体系（Evidence System）

> 全框架唯一的证据规范，所有 Skill 统一引用本文件，不得各自发明证据语言。
> 本文件位于 `core/` 共享引用层（core 仅以 SKILL.md 作为安装依赖单元存在，本文件不会被独立触发）。

## 1. 证据强度等级

```text
E0  用户初始陈述    ← 未经核实的用户描述（最低）
E1  文档证据        ← PRD / 设计文档 / API 文档 / FAQ
E2  代码证据        ← 文件:行、接口签名、数据结构
E3  运行/执行证据   ← 实际运行结果、测试执行结果、日志、截图
E4  交叉验证        ← 多来源互相印证（最高）
```

## 2. 三类裁决规则

证据等级解决"信什么"，裁决规则解决"冲突时听谁的"：

| 问题类型 | 裁决规则 |
|---------|---------|
| **静态问题**（代码是怎么写的） | E2 为王。E1 与 E2 冲突 → 默认以代码为准（测准声明），偏离记入附录并提交澄清 |
| **动态问题**（系统实际怎么表现） | E3 为王。E2 与 E3 冲突（代码与运行不符）→ 这本身就是发现（死代码 / 路径未覆盖 / 环境差异），转澄清或缺陷记录 |
| **意图问题**（应该是什么行为） | **用户在澄清环节的明确答复具有最终裁决力**，可推翻任何证据等级。裁决记入产物（澄清记录），后续 Skill 不得再用代码推翻已裁决项 |

> 注意：E0（用户初始陈述）是低证据，但用户**在澄清环节的裁决**不是证据、是决策——两者必须区分。前者可被代码推翻，后者不可。

## 3. 结论的状态标注

所有 Skill 的输出必须区分：

```text
Fact        事实（有证据支撑的确定结论）
Inference   推断（由证据合理推出，未直接验证）
Risk        风险（可能出问题，尚无证据）
Hypothesis  假设（待验证的猜想）
Verified    已验证（有 E3 及以上证据）
```

## 4. 标注格式

```yaml
finding:
  title: 删除用户后可能存在数据残留
  evidence:
    level: E2                    # E0–E4
    source: user_service.go:124  # 来源：文件:行 / 文档名+章节 / 截图路径 / 运行日志
  confidence: medium             # high / medium / low
  status: hypothesis             # fact / inference / risk / hypothesis / verified（待实测确认=hypothesis）
```

**禁止不加标注直接输出"这里存在 Bug"**——这是证据体系要消灭的幻觉式结论。

## 5. 与各 Skill 产出的对齐约定

不同 Skill 的产出物按各自的自然形态携带上述标注，不要求改变文件结构，只要求字段齐全：

| 产出物 | 标注方式 |
|--------|---------|
| `test-case-writing` 附录缺陷记录 Cx | 每条 Cx 含：现象 + `evidence.level`（E0–E4，代码审查发现通常为 E2）+ `evidence.source`（`文件:行`）+ confidence + status（待实测确认 / 已证伪等处置语义映射到 fact / hypothesis / verified） |
| `test-case-writing` 附录高风险点 Dn | 每条 Dn 按 `risk-model.md` 评级，证据字段同上 |
| `test-strategy` Risk Map | 每条风险（R1、R2…）强制带 evidence（level + source）与 confidence；**没有证据的风险评级视为无效评级** |
| `bug-analysis` Root Cause | 根因结论标注 status（Inference → 读代码推断；Verified → 已复现验证 E3）；影响范围逐条给来源 |
| `requirement-analysis` 需求模型 rules | 每条业务规则标注 evidence（文档章节或 `文件:行`）；用户裁决记入 open_questions 的裁决字段 |

## 6. 引用方式（双形态）

各 SKILL.md 的工作流步骤中标注"此时加载本文件"并给出相对路径，例如：`../core/evidence.md`。
该标注按部署形态有双重语义：

- **真实宿主（按需加载形态）**：渐进披露——用到时才读，不预加载；
- **注入式形态（评测/预注入部署）**：全部文件已在指令中，"此时加载"仅指示**执行时机**
  （该步骤开始执行本文件的规则），不触发任何读取动作，也不要因"文件已全文在场"而提前执行后续阶段的规则。

> 适配声明：skill 集的设计假设（qa 的上下文隔离、活跃指令 ≤ 1–2 个 skill）只对真实宿主成立；
> 注入形态下全部规则同时在场，**靠阶段顺序而非加载机制防串扰**——执行时只服从当前所处阶段的指令。

# 用例可执行性标准（Executability）

> "看似专业但不可执行"是当前最大质量问题。本标准是**框架级硬标准**，所有产出用例的 Skill（`test-case-writing`、`test-case-review`、`bug-analysis` 的回归用例建议）统一遵守。
>
> 本标准同时是评测的一票否决指标：不可执行的用例，覆盖再全也计零分。

## 1. 失败模式——AI 为什么会生成不可执行的用例

| # | 失败模式 | 典型表现 |
|---|---------|---------|
| 1 | 凭空想象系统 | 没见过真实页面 / 接口，凭 PRD 与通用经验虚构入口、字段、文案 |
| 2 | 写给评审者而非执行者 | 追求覆盖矩阵漂亮，不关心执行者下一步能不能操作 |
| 3 | 前置不可得 | 默认环境 / 账号 / 数据随手就有，不交代从哪获得 |
| 4 | 判定不可操作 | 预期结果写"功能正常"这类模糊判定；异步行为无判定时限 |
| 5 | 断言超出验证强度 | 两个样本就断言"全局唯一"；UI 操作就断言数据库约束 |

## 2. 八条硬标准

1. **代码优先**——有代码必读代码，以实现为行为基线，杜绝凭文档想象（失败模式 1 的根治手段）
2. **执行模型判定**——有 UI 独立执行 / 无 UI 转"测试-开发协作清单"，开工先判定
3. **具体数据**——操作步骤嵌真实编号 / 字段值，禁止占位符（`{xxx}`、`<xxx>`、`某某`）
4. **页面可达性**——每个入口写清从哪里到达；未知 → 澄清 + TODO
5. **判定时限**——异步行为必须写"多久不发生即判失败"
6. **断言范围 ≤ 验证强度**——用例名称与实际能证明的范围一致
7. **前置可得性**——环境 / 账号未知时列"TODO：向谁索取"，不省略
8. **零上下文新人复述**——定稿自检：没读过需求、没人讲解的人只拿这份文件能开工

## 3. 定稿自检清单（逐条执行）

以"零上下文新人"（没读过需求文档、没人讲解、只拿到这份文件）为标准：

- [ ] 随机抽 3 条用例复述：验证什么、从打开什么系统开始怎么操作、怎么算通过——任何一步卡住（不认识某个词 / 不知道页面在哪 / 不知道怎么造前置状态 / 不知道等多久算失败）→ 修复正文或补导读区，而不是降低标准
- [ ] 导读四件套齐全：功能简介+角色表 / 环境与账号表（未知列 TODO 指明找谁）/ 术语表 / 图例
- [ ] 正文零代码内部：无 `文件:行`、SDK 符号、错误码常量、函数名（代码证据隔离在附录）
- [ ] 操作步骤嵌具体数据，无占位符
- [ ] 每个被测入口首次出现时写明到达路径
- [ ] 含异步预期的用例逐条有判定时限
- [ ] 用例名称断言不超出步骤实际验证强度
- [ ] 每条用例可独立执行（有 UI）或可整包交开发协作执行（无 UI）

## 4. 违反即不可执行的红线（Eval 判分依据）

以下任一命中，该条用例在 Eval 中判为不可执行：

1. 操作步骤或预期结果包含占位符（`{xxx}`、`<xxx>`、"某数据"）
2. 第一步操作指向不存在的入口（虚构页面 / 未说明到达路径且无 TODO）
3. 预期结果为"功能正常 / 正常显示"等无判定信息的表述
4. 异步预期无判定时限
5. 前置条件不可获得且无 TODO 指引（需要不存在的账号 / 数据却未说明来源）
6. 用例名称断言超出步骤能证明的范围

## 5. 引用方式

各 SKILL.md 的用例产出 / 审查 / 定稿步骤标注"此时执行本文件全部检查项"，相对路径 `../core/executability.md`。

第二个消费场景是**执行型 skill 的转换闸门**：`automated-e2e-testing`、`api-testing` 把存量用例转为自动化脚本前，对待转用例逐条过第 4 节红线——不可执行的用例直接翻译成脚本只会产出"幻觉自动化"（脚本能跑，测的不是真实系统行为）；命中红线的用例先补齐再转，补不了的明确暂缓进遗留清单，不静默硬转。

# 流水线集成与非交互运行约定（Pipeline Integration）

> 全框架唯一的 CI/CD 与无人值守运行规范。qa-skills 各工作流默认为人机对话场景设计
> （⏸ 检查点等待用户裁决），本文件定义同一套工作流进入流水线（PR 冒烟 / 夜间回归 /
> 发布卡点）与 headless 非交互模式时的降级约定：检查点怎么处置、产物落到哪里、
> 退出码如何区分基建故障与真实缺陷。
>
> 三条设计约束：
> 1. **人不在线，裁决不得虚构**——所有 ⏸ 检查点转为显式未决项，禁止 agent 代答
> 2. **基建失败 ≠ 测试失败**——两者分开编码为不同退出码，环境抖动不应半夜呼叫测试责任人
> 3. **产物必须可机读**——下游消费方（G 级预扫描 / 分流表 / 报告聚合）依赖稳定落盘形态

## 1. 触发分层

| 层级 | 触发时机 | 范围 | 特征 |
|------|---------|------|------|
| PR 冒烟 | 每次 push / PR 更新 | P0 清单（变更基线关联用例） | 快失败，<10 分钟，失败量小 |
| 夜间全量 | 定时调度（如每日 02:00） | P1 全量 + P2 抽样 | 批量失败常态化，分流主战场 |
| 发布卡点 | release tag / 发版前置 | 全量 + 类型矩阵 full 档轴 | 门禁式：失败即阻断发布 |

P0/P1/P2 清单本身的编制归属 `regression-testing` / `test-strategy`；本文件只约定
「哪一层触发跑哪个档」，不重复定义清单内容。

## 2. 非交互三约定

### 约定一：⏸ 检查点全部降级为未决项

clarify-pattern.md 定义的统一澄清提问卡片在人机对话场景等待用户答复；headless 场景
没有这轮对话，按以下优先序降级：

1. **有保守默认值的决策** → 采用最保守分支，并在未决项记录「默认采用 X，依据 Y」。
   保守的定义：宁多报不漏报（扩大验证范围）、宁标 U 不硬编类别（分流口径）、
   断言宁严勿松（放宽 catch 是把通过建立在侥幸上）
2. **无默认可言的意图问题**（需求歧义、A/B 定性分歧、Severity 争议）→ 记入未决项，
   该项相关断言按**待验证**处理而非通过；产出物中逐条列出等用户回填
3. 未决项统一落盘 `{项目}/流水线状态.md` 的未决区（与各阶段跳过标记同一文件——
   续跑凭据与人工回流入口单点化），逐条沿用 clarify-pattern 卡片四要素
   （问题来源 × 具体问题 × 影响 × 建议选项）；人工回到线上后的第一个动作是在未决区
   回填裁决，流水线续跑时按 qa 编排的断点规则增量消费这些裁决（见 qa/SKILL.md 断点检查）
4. **带留痕要求的裁决类产物**（如 test-strategy 的 `budget_review`）：headless 下如实记
   「headless 未决：采用保守裁剪/保留，依据 X」——不得写成用户已批准（铁律 1）；
   校验器只校验留痕存在与轴名出现，语义真伪由本条约束；人工回流后在原行补
   `approved_by: 用户` 批注

> 铁律：非交互模式下 agent 给出的任何「用户裁决」都是伪造。evidence.md 第三类裁决
> 规则（用户答复具最终裁决力）在无人值守场景整体失效——裁断层保持空缺，由未决项承接，
> 这是它与交互模式的唯一差异点。

### 约定二：产物落盘规范

| 产物 | 路径 | 形态 | 主要消费方 |
|------|------|------|-----------|
| 结构化结果 | `{项目}/results/results.xml` | JUnit XML（reporter 配置见各执行 skill 工程约定） | G 级信号聚合、CI 展示层 |
| 失败现场 | `{项目}/artifacts/{TC编号}/` | trace / 截图 / console log | S 级复核 |
| 失败分流表 | `{项目}/失败分流_{日期}.md` | 分流表模板第 6 节 | 回流闭环（本文件第 4 节） |
| 测试报告 | `{项目}/测试报告_{日期}.md` | report-template.md 全节 + 机读摘要节 | 人读 + 报告聚合系统 |
| 未决项 | `{项目}/流水线状态.md` 未决区 | clarify-pattern 卡片格式 | 用户回填 → 续跑增量消费 |

两条命名纪律：① 日期后缀追加式留存，不清除历史（与分流表同一哲学：它是 D 类跨轮
追踪的最小数据形态）；② 首个路径段固定为项目目录名，保证 CI 工件上传规则可以用
单一 glob 通配。

### 约定三：退出码语义（基建与缺陷分离）

进程退出码是流水线分支判断的唯一机器接口，四值语义：

| 退出码 | 含义 | 下游动作 |
|--------|------|---------|
| 0 | 全部通过（含 B1/B2 修订后的复验轮通过） | 绿灯归档 |
| 1 | 存在 A 类真缺陷 | 告警开发 + 测试责任人，分流表随告警附上 |
| 2 | C 类环境故障主导（≥50% 失败同因）或基建自身异常 | 自动原样重跑一次；再次为 2 则告警 DevOps，**不通知测试责任组** |
| 3 | U 类未闭环超阈（U 类条数 / 本轮用例总数 > 10%）或产物自校验失败 | 告警测试责任人修流程/资产——属流程债，非产品缺陷 |

判定顺序 **2 > 1 > 3 > 0**：先排环境再谈缺陷，与分流判定树第 0 步同构。
退出码必须与分流表「结论分布」字段自洽——不允许出现退出码 1 但表中无 A 类、
或表内 A≥1 却退出码 0 这类矛盾（出现即按 3 处理）。

## 3. host agent headless 调用范式

执行主体是安装了本套 skills 的 coding agent 以无头模式运行；两个 CI 平台的差异
只在编排语法，退出码语义与产物路径约定完全一致：

```yaml
# GitHub Actions 夜间全量（GitLab CI 仅有 rules/artifacts 语法差异，语义相同）
on:
  schedule:
    - cron: '0 18 * * *'   # UTC 18:00 ≈ 东八区 02:00
jobs:
  nightly-regression:
    runs-on: ubuntu-latest        # GitHub Actions 必填字段；GitLab CI 对应 image + script 段
    steps:
      - run: |
          claude -p "$(cat .github/prompts/nightly-qa.md)" \
            --allowedTools "Bash,Read,Write,Glob,Grep" \
            --dangerously-skip-permissions
          # claude 非零退出码直接透传为本 step 退出码，供流水线按四值语义分支路由；
          # 切勿写成 "--dangerously-skip-permissions || EXIT=$?" 收尾——|| 后是赋值语句，
          # step 退出码恒为 0，四值语义整体失效。退码 2 的自动原样重跑：
          # 用独立 retry step 或外层包裹脚本实现，再按重跑结果取最终退码
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: qa-artifacts, path: '{项目}/' }
```

三条 headless 纪律：
1. 非交互标志在命令行显式传入（`-p` / `--non-interactive` 等按宿主文档），
   不允许依赖 TTY 探测猜测模式
2. 工件上传永远 `if: always()` / `when: always`——失败现场的产物比成功日志有价值得多
3. prompt 模板中显式写入「遵循 core/pipeline-integration.md 非交互约定」，
   弱模型靠这句话找到三约定，而不是临场发挥

### 3.1 大套件分片与门禁汇聚

全量套件超出单机时长预算（>30 分钟量级）时按文件分片并行，汇聚后统一进门禁：

```yaml
# 分片：matrix 3 台 runner 各跑 1/3（GitLab CI 用 parallel:3，语义相同）
jobs:
  e2e-shard:
    strategy:
      matrix:
        shard: [1, 2, 3]
    steps:
      - run: npx playwright test --shard=${{ matrix.shard }}/3
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: blob-report-${{ matrix.shard }}, path: playwright/test-results/ }
  e2e-gate:                       # required checks 只指向这个 job——分片 job 名带序号不稳定
    needs: [e2e-shard]
    if: always()
    steps:
      - uses: actions/download-artifact
        with: { path: blob/ }
      - run: npx playwright merge-reports --reporter=html,junit blob/
      # 汇聚后退出码仍按约定三（2>1>3>0）判定；分片内部红绿不直接进门禁
```

三条分片纪律：
1. 分片运行时 config reporter 增补 `['blob', { outputFileDir: 'blob/' }]`；
   本地开发永远单机不分片——收敛反馈环
2. gate job 必须 `if: always()` 收齐全部分片再汇聚——任一分片被取消不能静默绿灯
3. 不为分而分：夜间套件 <15 分钟不分片，省 runner 也省汇聚开销

## 4. 失败回流闭环

夜间/卡点的批量失败不是终点，回流分流完成「红墙 → 少量根因」的坍缩
（140 条失败常是 6 个根因穿马甲）：

```text
夜间构建 fail
  → 失败分流（triage.md，失败 ≥3 条必走；退码 2 已先行吸收纯 C 批次）
     ├─ A 真缺陷 → bug-analysis 五字段 → 开发修复 → 修复关联回归（regression-testing）
     ├─ B1 预期变更 → 资产修订（附变更依据，条款一红线）
     ├─ B2 用例自身错误 → 就地修正脚本
     ├─ C 环境残留 → 退码 2 重跑通道；仍红升级 DevOps
     └─ D flaky → 隔离标记 + 跨轮追踪，≥3 轮升级修根因
```

两条回流纪律：
- 白天 PR 冒烟失败量小（通常 <3 条），按执行 skill 单条流程走，不付分流开销；
  只有夜间/卡点批量失败才进分流
- 回流产生的资产修订（B1/B2）最迟下一工作日人工检视——防止绿灯建立在
  过时资产上，也防止自动化修订本身引入新错误

## 5. Common Mistakes

| 错误 | 后果 | 正确做法 |
|------|------|---------|
| 非交互模式下代答检查点继续跑 | 伪造用户裁决污染证据链，结果不可信 | 三约定降级：保守默认 or 未决项，绝不代答 |
| 所有失败统一退码 1 | 夜间环境抖动呼叫测试组，triage 声誉损耗 | 退码分离 2/1；C 主导批先进重跑通道 |
| 只在 success 时上传工件 | 失败现场丢失，S 级复核无从做起 | 工件永远 always 上传 |
| 结果仅打印在 stdout 日志 | G 级聚合无法进行，逐页翻日志的坑又回来了 | JUnit XML + 固定产物路径落盘 |
| 夜间红了直接全员告警 | 告警疲劳，真缺陷淹没在一堆噪音短信里 | 先分流坍缩为根因，按退码定向路由接收人 |

# 测试报告模板（唯一来源）

> 全框架唯一的测试报告模板。`qa` 收尾生成完整报告时引用本模板；`automated-e2e-testing` / `api-testing` 的执行报告、`bug-analysis` 的 Bug 条目均按本模板对齐格式，保证各阶段产物能直接拼装进最终报告。
>
> 文件命名：`{项目}/测试报告_{日期}.md`（执行分报告可用 `测试报告_{来源}_{日期}.md` 区分）。

## 模板正文

```markdown
# {项目名} 测试报告 — {日期}

## 1. 概览

- **测试范围**：{本次覆盖的功能 / 模块，对应需求模型与测试策略的 scope}
- **测试环境**：{环境地址 / 版本 / 账号角色，未知项列 TODO 及索取对象}
- **测试方式**：{手动 / E2E 自动化 / API 自动化 / 探索式，对应执行策略裁决}
- **范围假设**：{系统级黑盒结论以单元/集成层（开发侧职责）已有保障为前提——已验证〔依据〕/ 未验证（列入 §6 未闭环事项）}
- **总体结论**：{通过 / 有条件通过 / 不通过}——{一句话依据：P0 通过率、遗留 Critical 风险、未闭环澄清项}

## 2. 执行统计

| 优先级 | 用例数 | 通过 | 失败 | 阻塞 | 未执行 |
|--------|--------|------|------|------|--------|
| P0     |        |      |      |      |        |
| P1     |        |      |      |      |        |
| P2     |        |      |      |      |        |

> 失败用例逐条给出 Bug 编号；阻塞说明阻塞原因（环境 / 依赖 / 前置不可得）。

## 3. Bug 清单

> **严重程度口径（与用例优先级消歧）**：Bug 严重程度用 **S0/S1/S2**（缺陷影响等级，见 `bug-analysis` 定级规则），与 §2 的**用例优先级** P0/P1/P2（冒烟/常规/边界）词汇彻底分离——"P0 用例失败"与"S0 Bug"不再有同词歧义。
> （同名区分：此处 S 系指 Bug 严重程度分级；类型决策矩阵的「S 级信号」〔semantic，语义信号复核〕是另一概念，见 `test-type-matrix.md`——两者同名不同义。）

### BUG-{序号}: {简要描述}

- **严重程度**: S0（数据丢失/资损/安全、核心主路径不可用）/ S1（核心旁路不可用、部分降级）/ S2（体验问题）
- **状态**: 新建 / 已修复待验证 / 已验证关闭 / 不予修复（附依据）——发现时标"新建"，随回归结果同步（使用约定 6）
- **复验轮次**: {整数，默认 0——仅状态为"已修复待验证"时填写，回归每失败一次 +1；其他状态省略此行}
- **发现方式**: 自动化测试 / 探索性测试 / 业务熟悉探索 / 手动执行 / 代码审查（Cx 转）
- **复现步骤**:
  1. {以什么角色登录 / 准备什么数据}
  2. {进入什么页面或调用什么接口}
  3. {具体操作}
- **预期行为**: {依据：需求文档章节 / 测试用例 TC 编号}
- **实际行为**: {观察到的现象}
- **证据**: 截图 `bug-{序号}-*.png` | API: `{METHOD} {URL} → {状态码}` | 控制台: `{错误}` | 日志: {文件与行}
- **环境**: {URL} / {账号角色} / {浏览器或客户端版本}
- **根因分析**: {bug-analysis 产出时填写：Root Cause + `文件:行` + evidence 等级；未分析则标 TODO}
- **影响范围**: {bug-analysis 产出时填写：受影响功能/数据/用户/安全/修复波及五面（各面口径见 bug-analysis 影响分析）；可选}
- **Severity 依据**: {bug-analysis 产出时填写：后果 → S 级对照（S0/S1/S2，见 §3 口径注）；可选}
- **修复建议**: {bug-analysis 产出时填写：修复方向；可选}
- **回归建议**: {bug-analysis 产出时填写：修复后应回归的用例编号或场景；未分析则标 TODO}

## 4. 风险与残留

| 风险编号 | 等级 | 状态 | 说明 |
|---------|------|------|------|
| R1 | High | 已验证 / 待验证 | {对应 Risk Map，注明验证用例 TC 编号} |

## 5. 回归摘要

- 本次回归范围：{必须回归 P0：…；建议回归 P1：…；可选 P2：…}（对应 `回归清单_{日期}.md`）
- 回归结果：{通过率与遗留}

## 6. 未闭环事项

- {澄清未决项 / TODO（向谁索取什么）/ 遗留风险，逐条列}

## 7. 专项测试结果（类型域）

> 类型域 handoff / 外部执行器 / blocked 轴的结果回收（决策见测试策略 type_scope，协议见 `test-type-matrix.md`）。无类型域专项时本节整体省略。

| 轴 | 决策/深度 | 执行方 | 结果摘要 | 证据等级 | 产物路径 |
|---|---|---|---|---|---|
| performance | include / full | k6 | P99 420ms（阈值 500ms，通过） | E3 | 压测报告_20260823.md |
| i18n | exclude（无信号） | — | 未纳入，scanned 见策略 | — | — |

> blocked 轴在此展示 TODO（向谁索取什么）——未回收前不得标"已覆盖"；外部工具结果由 agent 归一化填入（发现 × 证据等级 × 阈值判定），消灭"策略写了移交、报告永远空白"的断链。

## 附录：证据索引

- {截图 / 日志 / trace / API 抓包的文件路径与说明}
```

## 使用约定

1. **qa 收尾**：按本模板生成完整报告，汇总各阶段落盘产物（需求模型 / 策略 / 用例 / 执行结果 / Bug / 回归清单的路径与结论）
2. **执行类 Skill**（automated-e2e-testing / api-testing）：执行分报告至少包含 §2 执行统计 + §3 Bug 清单（Bug 条目字段与本模板一致，状态初始标"新建"），根因分析等五个扩展字段（§3 后五行）留 TODO 由 bug-analysis 补；api-testing 分报告可附结构覆盖摘要（零覆盖/低覆盖接口清单，见其运行结果纪律）
3. **bug-analysis**：Bug 条目的"根因分析 / 影响范围 / Severity 依据 / 修复建议 / 回归建议"为本 Skill 的填写范围（字段结构以本模板 §3 为唯一来源，bug-analysis 只补填写语义），结论按 `evidence.md` 标注 status
4. **报告是落盘产物**：追加不覆盖——新版本报告另存，历史报告保留（文件名含日期）
5. **专项结果回收**：qa 收尾汇总类型域专项状态（handoff / 外部执行 / blocked / exclude）；执行结果按 §7 表归一化回收，exclude 轴以"未纳入 + scanned 见策略"呈现——类型范围决策在报告里可见、可审计
6. **Bug 状态同步**：状态随回归结果更新——回归通过 → 已验证关闭；回归失败 → 已修复待验证（附失败证据）；裁决不修 → 不予修复（附依据）。qa 收尾按最新回归结果逐条同步（衔接 `regression-testing` §4），无回归记录的保持"新建"——消灭"Bug 报了但永远关不掉"的断链
7. **机读摘要**：qa 收尾与执行类 skill 生成分报告时，将下方"机读摘要片段"（占位符替换后）追加为报告末节的固定内容；流水线聚合与质量门禁只解析此节，人读内容不受影响。字段口径见 `pipeline-integration.md` 约定二/三

## 机读摘要片段

```yaml
# 追加到报告末尾；与正文各节一一对应，冲突时以正文为准
meta:
  project: {项目名}
  date: {日期}
  source_run: {PR-smoke | nightly-full | release-gate}   # 触发分层对照 pipeline-integration 第 1 节
summary:                       # ← §2 执行统计
  total: {总数}
  passed: {通过数}
  failed: {失败数}
  blocked: {阻塞数}
triage_distribution:           # ← 失败分流表结论分布（未分流轮省略本节）
  A: 0
  B1: 0
  B2: 0
  C: 0
  D: 0
  U: 0
exit_code_hint: 0              # ← 对照 pipeline-integration 约定三（0/1/2/3）
open_items: {§6 未闭环条数}
bugs:                          # ← §3 Bug 清单一行一条（id / severity / status）
  - {id: BUG-001, severity: S1, status: 新建}
```

## 引用方式

各 SKILL.md 在报告产出步骤标注"此时加载本文件"，相对路径 `../core/report-template.md`。

# 统一风险模型（Risk Model）

> 所有 Skill 统一引用本文件。风险模型与证据体系（`evidence.md`）强制挂钩：**没有证据的风险评级视为无效评级**。

## 1. 风险评分

```text
Risk Score = Impact × Likelihood
```

- Impact（影响）、Likelihood（可能性）各取 1–5，乘积 1–25
- **Change Scope（变更范围）与 Complexity（实现复杂度）不是乘子**，它们是估计 Likelihood / Impact 的启发式输入（见下表）

## 2. 两个因子的估计方法

| 因子 | 取值锚点 | 估计输入 |
|------|---------|---------|
| Impact（1–5） | 5 = 数据丢失 / 资损 / 安全；4 = 核心功能不可用；3 = 部分功能降级；2 = 体验问题；1 = 几乎无感知 | 失败后果分级：数据丢失 / 资损 / 安全 > 核心功能不可用 > 部分功能降级 > 体验问题 |
| Likelihood（1–5） | 5 = 几乎必然触发；3 = 常规路径可触发；1 = 极端条件才触发 | 变更范围（diff 大小与涉及面）、实现复杂度、历史缺陷密度、代码证据（如边界未防护、事务不完整） |

## 3. 风险等级（与用例优先级是两套体系）

```text
Critical   20–25
High       10–19
Medium     4–9
Low        1–3
```

> **命名脱钩**：风险等级用 Critical / High / Medium / Low；用例优先级沿用 P0 / P1 / P2（`test-case-writing` 现行体系）。不用 P0–P3 给风险命名，避免同名歧义。

风险等级到用例优先级的**映射建议**（策略阶段可调整，但必须显式说明理由）：

| 风险等级 | 用例优先级要求 |
|---------|---------------|
| Critical | 必须有 P0 用例，且作为回归锚点 |
| High | P0 或 P1 |
| Medium | P1 |
| Low | P2 或按需 |

## 4. Risk Map 标注格式

```yaml
risk:
  id: R1
  feature: 用户删除
  dimension: 数据一致性          # 功能域维度：权限/数据一致性/边界/状态流转/资损；与策略 scope 六轴的对应：权限→permission、边界→boundary、状态流转→state、数据一致性→data_consistency、资损→functional 主干（业务正确性缺陷的财务后果面）；regression 轴的风险按回归触发的变更面（diff / Bug 修复）识别。类型域用矩阵轴名（并发/可靠/安全/性能/兼容/迁移/契约…），见 test-type-matrix.md
  impact: 5                      # 删除后残留导致隐私与合规问题
  likelihood: 3                  # user_service.go:124 删除事务未覆盖关联表
  level: High                    # 15 = 5 × 3
  evidence:
    level: E2
    source: user_service.go:124
  confidence: medium
  status: hypothesis             # 见 core/evidence.md 第 3 节状态标注（待实测确认=hypothesis）
  anchors: [TC-07-02]            # 覆盖此风险的用例编号（派生索引，主从规则见下）
```

**双向引用主从规则**：`case.risk_ref`（Test Case Schema 字段）为权威方向，只在用例侧维护；`risk.anchors` 仅为 Strategy 文档里给人读的概览视图，**机器消费一律通过 Schema 的 `risk_ref` 反查**（`test-case-review` / `regression-testing` 等下游按此执行），不保证与最新用例同步——需要最新映射时从 Schema 重新生成，不手工编辑 anchors。

## 5. 推导链

```text
Evidence（评级依据）
    ↓
Risk Map（每条风险：等级 + 证据 + 置信度）
    ↓
Test Strategy（风险决定测什么、测多深）
    ↓
Test Case（risk_ref 反向追溯到风险锚点）
```

## 6. 与 `test-case-writing` 高风险点 Dn 的关系

`test-case-writing` 代码模式产出的附录高风险点 D1–Dn 是 Risk Map 在用例编写阶段的**局部实例**（聚焦代码审查发现的回归风险）：

- Dn 评级对齐本模型：Impact × Likelihood 评分 → Critical / High / Medium / Low 等级（替代旧的"最高/中高/中/低"表述；旧文件增量更新时顺带换算）
- Dn 每条强制带 evidence（level + `文件:行` source）与通过判据
- 存在 `test-strategy` 产出的 Risk Map 时，Dn 优先映射到已有风险的 `risk_ref`，不另立编号体系

## 7. 引用方式

各 SKILL.md 在需要风险评级 / 风险翻译的步骤标注"此时加载本文件"，相对路径 `../core/risk-model.md`。

# Test Case Schema 抽取规则（唯一来源）

> markmap → `测试用例.schema.yaml` 的抽取规则全框架唯一定义处。`test-case-writing` 编写/增量更新后抽取，`test-case-review` 修订后重新抽取，`regression-testing` / 执行层（`automated-e2e-testing` / `api-testing`）消费其结构化字段。规则变更只改本文件，不改各 SKILL.md。

## 双轨原则

markmap 是给人的交付物与**唯一人工维护源**；Schema 是机器可读元数据层，由 skill 在加工时**从 markmap 单向抽取**，作为 Skill 间流转接口。**不要求人维护两份**，Schema 永远可由 markmap 再生。markmap 任何修改后必须重新抽取，两轨不一致以 markmap 为准。

## 文件整体形态（三层）

```yaml
meta:
  source_markmap: 测试用例_markmap.md   # ← 抽取来源文件名
  extracted_at: 2026-08-27             # ← 抽取日期（YYYY-MM-DD）
  strategy_ref: 测试策略.md             # ← 上游策略文件名；无策略时省略此键
modules:          # ← 一级模块表：module 字段的裁定依据 + 共享前置的唯一承载处
  - module: "2. 营销活动"
    shared_preconditions: []   # ← 该一级模块正文标题下的 `> 前置：` 引用块逐行摘录（见 case-format.md §5）
cases: []
```

- **cases 平铺**为列表（不是按模块嵌套树）——消费方全靠字段过滤，嵌套树徒增解析成本；模块归属由用例的 `module` 字段表达
- **`module` 字段裁定**：取用例所挂**一级模块标题原文**（`## 2. 营销活动` → `"2. 营销活动"`，含编号与名称）；子模块/细分类别不入该字段。TC 编号首段必须与一级模块编号一致（`TC-02-xx` 属于 module `"2. ..."`），校验器据此交叉核对
- **共享前置去重**：`modules[].shared_preconditions` 记各模块级共享前置一次；用例级 `preconditions` 只写该条额外需要的条件，与共享前置重复即违反去冗余规则（校验时若二者重复仅告警）

## 抽取规则（cases[] 逐字段）

```yaml
  id: TC-02-03                  # ← 用例编号
  title:                        # ← 名称行去编号与优先级
  module: "2. 营销活动"         # ← 所属一级模块标题原文（裁定规则见上节）
  priority: P0 | P1 | P2        # ← 名称行 [Px] 标注，缺省 P1
  type: functional | boundary | exception | permission | regression | state | data | reliability | concurrency | security | compatibility
                                # ← 按模块/子模块类别与用例内容判定；类型域四值（reliability/concurrency/security/compatibility）仅用于测试策略 type_scope 用例型轴产出的用例（映射见 test-type-matrix.md 第 12 节）
  execution_model: ui | dev-collab  # ← 执行模型判定结果（协作五段式 → dev-collab）
  smoke: SMOKE-1                # ← 名称后（SMOKE-n），非冒烟省略
  preconditions: []             # ← 该条特有的前置条件（共享前置在 modules 表，不在本字段重复）
  steps: []                     # ← 操作步骤；dev-collab 保留「请开发执行」标注
  expected: []                  # ← 预期结果（含判定时限原文）
  test_data: {}                 # ← 步骤中嵌入的具体测试数据，按步骤号组织 {step: 数据描述}（如 {2: "券码 NEW50-100"}）；expected 中的期望值不算 test_data。只用具体值（占位符是可执行性红线），多步骤共用一组入参时也拆到触发它的步骤号下
  risk_ref:                     # ← 关联风险编号：Risk Map 的 R1…（无策略时 Dn 的 D1…）
  code_refs: []                 # ← 附录「代码证据清单」中该 TC 的 文件:行 列表。**模式相关必填**：代码模式（markmap 有测准声明）应有非空列表——没有代码位置就没有被审查资格，确无一比一对应的实现可注明实现形态；纯文档模式一律空列表（编造指涉属幻觉证据）
  evidence:                     # ← 该用例依据的证据（level E0–E4 / source / confidence，见 core/evidence.md）。代码模式必填三件套；纯文档模式下 evidence 允许省略或值为 null（此时 level 上限 E1，准确性受限提示已由流程给出）
  tags: []                      # ← 两类合法值：可测试性标注 [需真机]/[需Mock]/[需专业环境]，以及类型域轴标签 [并发]/[可靠]/[安全]/[兼容]/[迁移]/[集成]/[国际化]（两组含义均见 case-format.md §6）；其余自由文本标签会在校验时收到告警
  automation:
    supported: yes | no | partial   # ← 按 execution_model + tags 推断（ui 无特殊标签→playwright；dev-collab→api 或 manual；[需Mock]/[需真机]/[需专业环境] 至多 partial）
    framework:                  # playwright / api / manual
  status: active | changed | deprecated  # ← 增量更新标记（[已变更]/[已废弃]）
```

## YAML 转义纪律（防空解析）

title / steps / expected 等字段值含引号或冒号时必须转义——双引号值内的 `"` 写成 `\"`，或整体改用单引号包裹（内部单引号双写 `''`）；禁止在双引号值内裸放引号（如 `"满100减20"券"` 是非法 YAML，一条解析失败会中断下游全部消费）。长文本建议用 `>-` 块标量。

## 抽取后校验（强烈建议）

抽取/修订重抽后运行 `../core/scripts/validate_schema.py`（无第三方依赖，路径相对消费本文件的 SKILL.md 所在目录）：

```bash
# 基础校验：YAML 可解析（转义纪律）+ TC 编号一致性 + 占位符检查
python3 ../core/scripts/validate_schema.py 测试用例_markmap.md 测试用例.schema.yaml

# 推荐：上游存在测试策略时叠加风险覆盖门禁——策略 Risk Map 中全部 Critical/High 风险
# 必须被至少一条用例的 risk_ref 反向覆盖（零覆盖 = 报错，证据链最后一环）；
# 有代码仓库时可叠加 --repo-root 抽查 code_refs 中 "文件.ext:行号" 指涉的真实性（缺失告警）
python3 ../core/scripts/validate_schema.py 测试用例_markmap.md 测试用例.schema.yaml \
  --strategy {项目}/测试策略.md --repo-root {被测仓库根}
```

校验说明：零依赖环境下 YAML 解析降级为基础 lint（引号配对 / 裸引号）。`--strategy` 同时核对 risk_ref 是否指涉 Risk Map 中存在的编号（未知名 → 告警提示疑似笔误）。

## 存量迁移

已有 markmap 用例文件按同规则抽取（TC 编号、优先级、模块结构都是现成锚点），不需要人工重写。历史上以 `test_case:` 为根的单对象 / 嵌套形态仍可被校验器解析（按 id 递归收集用例），但重新抽取时一律换成上文三层形态。

## 引用方式

各 SKILL.md 在抽取 / 重新抽取步骤标注"此时加载本文件"，相对路径 `../core/schema-extraction.md`。

---
name: core
slug: core
displayName: QA 共享知识库
version: 0.8.1
description: "qa-skills shared knowledge base — dependency, NOT triggerable: executability standards, evidence grading, risk model, type matrix, templates, scripts. Never invoke standalone; always install with the skills, or references break. 共享知识库（依赖单元，非触发 skill）：承载全系列引用的方法/模板/脚本。任何测试任务不要独立触发；装其他 skill 必须连装。"
---

# qa-skills 共享知识库（core）

本目录是框架的公共层：不定义工作流、不面向用户触发，仅被 `skills/` 下其余
12 个 skill（qa / requirement-analysis / test-strategy / …）以相对路径
`../core/<file>` 按需引用。单一维护源，多 skill 复用。

## 共享文档

| 文件 | 内容 |
|------|------|
| `evidence.md` | 证据分级标准（E0–E4）与状态标注 |
| `risk-model.md` | 风险评级模型（评级强制挂证据） |
| `executability.md` | 用例可执行性硬标准（8 条，一票否决项） |
| `testing-principles.md` | 测试原则 |
| `case-format.md` | 用例编号与格式规范 |
| `coverage.md` | 覆盖评估口径 |
| `schema-extraction.md` | schema.yaml 抽取规则 |
| `clarify-pattern.md` | 澄清检查点模式 |
| `test-type-matrix.md` | 类型决策矩阵（十轴全轴必答） |
| `triage.md` | 失败分流规范（四分类判定树 + G/S 信号 + 反吞没条款，失败 ≥3 条触发） |
| `pipeline-integration.md` | 流水线集成与非交互运行约定（⏸ 检查点降级、产物落盘、退出码语义、CI 触发分层与失败回流） |
| `report-template.md` | 测试报告模板 |
| `methods/*.md` | 设计方法细则（边界 / 数据驱动 / 权限 / 状态机）与执行层造数模式（数据工厂） |
| `scripts/*.py` | Schema 校验器、类型信号扫描器 |

## When NOT to Use

- 任何具体测试任务（写用例、定策略、查 Bug 等）**都不要触发本 skill**：
  它不包含工作流，独立使用没有产出。对应任务请用其余 12 个 skill 之一。
- 本 skill 仅在两种情况下被触及：① 其余 skill 工作流按需引用上述文件；
  ② 安装/校验场景（作为安装依赖单元被安装器识别）。

# 测试类型决策矩阵（test-type-matrix）

> 类型域测试决策的**唯一真相源**：test-strategy 全轴扫描时**按组加载**本文件对应小节，产出 type_scope；test-case-writing 消费 type_scope 时按第 12 节映射产出。决策原则（全轴必答 / include 挂信号 / exclude 挂理由 / depth 与 execution 分离 / 单一真相 / 弱模型优先）与工作流落地见 test-strategy 的 SKILL.md；type_scope 的 Schema 结构与 V1–V5 校验规则以 `../core/scripts/validate_schema.py` 的 docstring 与实现为权威定义。

**矩阵版本**：v1（2026-08-23）。轴集合增删必须升版本号。

## 0. 组索引（分轴组推进，按组加载）

| 组 | 轴（本组只加载这些小节） | 组内交付核对 |
|---|---|---|
| A 资金与正确性 | 轴 1 性能效率 · 轴 2 业务安全 · 轴 4 并发一致性 | 三轴全部有决策 |
| B 依赖与变更 | 轴 3 可靠性 · 轴 9 迁移与升级 · 轴 10 契约与集成 | 三轴全部有决策 |
| C 前端体验 | 轴 5 兼容性 · 轴 6 无障碍 · 轴 7 视觉一致性 · 轴 8 国际化 | 四轴全部有决策 |

## 1. 使用规程（每组开扫前执行）

1. **G 级扫描**（有代码仓库时，一次运行三组共用）：`python3 ../core/scripts/scan_signals.py <仓库路径>`（路径相对 test-strategy 的 SKILL.md 所在目录）→ 每轴 G 级信号（文件:行）+ 预填表。**预填仅基于 G 级；exclude 永不预填**（防橡皮图章）
2. **逐轴决策**（受限选择，不自由生成）：需求信号（需求模型 / PRD）→ G 级信号核对 → **S 级信号照单复核**（本轴代码信号清单中标〔S〕的项，逐项读代码确认）→ decision（include / exclude / handoff）→ depth（full / standard / light）
3. **exclude 门槛**：需求 + G 级 + S 级三路全灭才可 exclude；scanned 必须落盘 **G 级脚本输出 + S 级复核结论双清单**（V3 校验）——S 级未复核不得 exclude，否则脚本盲区被制度化为漏测
4. **组内交付核对**：本组全轴有决策再进下一组；十轴完成 → 第 13 节深度校准 + 预算排序
5. **无代码仓库**：跳过 G / S 级，仅需求信号决策；exclude 理由注明"无代码仓库，需求信号未命中"（决策可信度降级，报告标注）

**轴空间封闭**：类型域就是这十轴，不自行新增。可用性 / UX 主观体验、渗透测试、SAST / 依赖扫描、产品可维护性、功能安全（safety）**不设轴**——可用性与 UX 的判定主观性强，走探索测试与人工评审；渗透测试依赖专业人工与授权环境，右移到安全专项；SAST / 依赖扫描是开发侧 CI 工具，在本矩阵中只作轴 2 / 轴 10 的**信号来源**而非独立轴；产品可维护性与功能安全超出测试范畴。新增轴 = 矩阵升版本。

## 2. 域间裁决（重叠必裁决）

| 重叠 | 裁决 |
|---|---|
| 功能域 permission × 轴 2 业务安全 | permission 管授权功能正确性（有权限的人行为对不对，越权用例归它产）；业务安全管未授权视角防御（不该拿的拿不拿得到、敏感数据漏不漏、注入面、认证会话）。permission 轴 depth ≥ standard 是轴 2 的**内部纳入信号**；同一批越权用例不得两轴双计数 |
| 轴 4 并发一致性 × 轴 1 性能效率 | 正确性 bug（超卖 / 重复 / 丢更新）归轴 4；容量 / 延迟归轴 1。同一次并发执行可同时给两轴供 E3 证据（执行复用，决策分离） |
| 功能域 exception/boundary × 轴 10 契约与集成 | 功能域为主：异常 / 边界场景下的业务行为正确性（系统自身处理逻辑对不对）归功能域用例产出；轴 10 为辅：只产契约差异项（对外接口的错误码 / 响应结构 / 超时语义与契约不符的部分）。同一接口的同一路径不得两处双计数 |

## 3. 轴 1 性能效率（performance）

- **需求信号**：SLA / P95 响应时间承诺；大促、秒杀、抢购场景；预计并发用户数；性能验收指标
- **代码信号**：无分页全量查询；循环内远程调用（N+1）〔S〕；缓存依赖（Redis 命中率假设）；锁竞争热点〔S〕；消息积压消费逻辑〔S〕（积压 / 消费速率为语义判断项，扫描器不扫，照单读代码复核）
- **默认档**：软默认——无信号 exclude（记录扫描结果）；有 SLA 或容量信号 → include
- **档位语义**：full = 压测模型设计（用户旅程 × 到达率阶梯）+ 执行 + 瓶颈归因报告；standard = 核心接口基准（单接口阶梯加压）+ 阈值判定；light = 代码级性能审查（分页 / 缓存 / N+1 / 锁，逐项出 E2 证据清单）
- **执行归属**：三分——① agent 直接承接：executor 记 agent，standard 起步按 api-testing 的 k6-conventions 工程约定生成并运行压测脚本（light 代码级审查可闭环不变）；② 移交外部执行：executor 记 k6 / locust + handoff_ref（V5 强制），承接方可附脚本草稿；③ 执行前提不可得：R5 记 blocked + todo
- **成本因子**：独立压测环境、可重置数据、基准噪音控制
- **消费方式**：脚本型——standard 及以上不产手动用例，产压测模型与执行物进执行策略裁决；light 产代码审查清单条目（Cx 通道）

## 4. 轴 2 业务安全（security-business）

- **需求信号**：多角色 / 权限层级；隐私数据（手机号 / 身份证 / 地址）；资金操作；合规要求（个保法 / GDPR）；**内部信号**：功能域 permission 轴 depth ≥ standard
- **代码信号**：鉴权中间件覆盖面缺口〔S〕；对象级授权缺失模式〔S〕（user_id 来自请求参数而非会话）；可枚举 ID 直接引用；敏感字段明文返回或落日志；SQL 拼接
- **默认档**：**硬默认**——Web / API 系统一律 standard，无 R4 exclude 出口（成本极低 × 价值极高）；其余九轴均为软默认
- **档位语义**：full = 未授权视角全矩阵（匿名 + 低权角色对全部高危资源的可达性探测）+ 敏感数据流追踪 + 注入面；standard = 高危资源越权抽样 + 注入面 / 敏感暴露扫描；light = 设计层审查（Cx 记录）。**越权功能正确性用例归功能域 permission 轴产出**（第 2 节裁决），本轴不重复产
- **执行归属**：agent（复用 API 测试基建与测试账号矩阵；方法基线 `methods/permission.md`）
- **成本因子**：低——测试账号矩阵是唯一前置
- **消费方式**：用例型——standard 及以上产手动用例（type: security，标签 `[安全]`）；light 产 Cx 审查条目

## 5. 轴 3 可靠性（reliability）

- **需求信号**：可用性承诺（9x%）；降级预案；容灾要求；"不能丢消息"类硬约束
- **代码信号**：重试逻辑与重试上限；超时配置；消息队列消费与 ack；断路器；事务边界；补偿 / 回滚逻辑
- **默认档**：软默认——有异步 / 第三方依赖信号 → standard；无 → light
- **档位语义**：full = 故障注入矩阵（依赖宕机 / 超时 / 拒绝 / 脏数据）+ 恢复验证；standard = 超时 / 重试 / 幂等 / 降级专项用例（"失败 → 重试 → 恢复"原则的类型化落地）；light = 清单审查（超时有无 / 重试上限 / 幂等键 / 消息 ack 语义）
- **执行归属**：standard 及以下 agent；故障注入 = agent 设计 + 可控环境执行
- **成本因子**：故障注入需可控环境；standard 无特殊成本
- **消费方式**：用例型——standard 及以上产 type: reliability 用例（标签 [可靠]）；light 产清单条目

## 6. 轴 4 并发一致性（concurrency）

- **需求信号**：库存 / 名额 / 配额；抢购；"全局唯一"类约束；多人同时编辑
- **代码信号**：check-then-write 模式（先查后写无锁）〔S〕；共享可变状态〔S〕；扣减逻辑；依赖唯一约束兜底的写入路径
- **默认档**：软默认——有共享可变资源信号 → standard；无 → light
- **档位语义**：full = 竞争窗口分析 + 并发用例矩阵（同一资源 × 全部竞争写入路径）+ 真实并发执行；standard = 关键竞争点并发用例（衔接 api-testing 并发能力）；light = 竞态模式代码审查
- **执行归属**：agent
- **成本因子**：可重置数据
- **消费方式**：用例型——standard 及以上产 type: concurrency 用例（标签 [并发]）；light 产清单条目

## 7. 轴 5 兼容性（compatibility）

- **需求信号**：明确支持的浏览器 / 设备清单；企业客户旧环境（旧内核）；跨端一致性要求
- **代码信号**：有前端（前端源码文件计数 ≥3 即命中——扩展名清单与阈值以 `scripts/scan_signals.py` 实现为准，含 .vue/.jsx/.tsx/样式族等；package.json 前端依赖、移动端信号同计为有前端——pubspec.yaml(Flutter)、react-native/@tarojs/@dcloudio 跨端依赖、project.config.json 小程序配置）；浏览器特性 API 使用（IntersectionObserver 等）；UA 判断分支；响应式断点；多端平台分支（Platform.OS / kIsWeb / wx.getSystemInfo / `#ifdef MP-WEIXIN` 等）；系统版本门槛（minSdkVersion / deployment_target 等）
- **默认档**：软默认——有前端 → light；有明确支持清单 → standard
- **档位语义**：full = 支持矩阵逐格（浏览器 × 设备 × 分辨率 × P0 路径）；standard = 支持清单矩阵 × P0 路径；light = 最新 Chrome / Safari / Edge / Firefox 冒烟
- **执行归属**：agent + Playwright 项目矩阵（现成接入片段：automated-e2e-testing 工程约定第 14 节）
- **成本因子**：多浏览器 CI runner；真机（移动端超出 v1 范围）
- **消费方式**：用例型——standard 及以上产 type: compatibility 用例（标签 [兼容]）；light 产冒烟清单条目

## 8. 轴 6 无障碍（accessibility）

- **需求信号**：政企 / 教育政务客户；无障碍合规要求；投标条款
- **代码信号**：有前端即最低信号（语义化标签缺失、img 无 alt、键盘不可达、表单无 label——由 axe 扫描器核实）
- **默认档**：软默认——有前端 → light
- **档位语义**：full = WCAG 2.2 AA 逐页审计 + 键盘全路径 + 读屏抽样（读屏归人工）；standard = axe 全页扫描 + 违规分级 + 关键流键盘走查；light = axe 扫描 P0 页面
- **执行归属**：agent + axe-core（Playwright 集成；现成接入片段：automated-e2e-testing 工程约定第 12 节）
- **成本因子**：极低
- **消费方式**：审查 / 脚本型——任意档位产 axe 扫描任务与违规清单（客观违规项分级呈现）；full 的读屏抽样子项标注人工
- **边界**：主观判定类（对比度阈值争议、读屏体验）标人工复核，agent 只出客观违规清单

## 9. 轴 7 视觉一致性（visual）

- **需求信号**：品牌规范验收；设计稿交付（Figma）；视觉回归要求
- **代码信号**：有前端即信号；已有截图测试（toHaveScreenshot 等）
- **默认档**：软默认——有前端 → light
- **档位语义**：full = 全页面截图基线 + 逐变更 diff；standard = 关键页基线 + diff；light = P0 页面截图存档供人比对（不自动判）
- **执行归属**：agent + Playwright screenshot（现成接入片段：automated-e2e-testing 工程约定第 13 节）
- **成本因子**：低；基线维护与动态内容遮罩规则（时间 / 头像 / 随机推荐位）是主要复杂度
- **消费方式**：脚本型——standard 及以上产截图基线执行物；light 产截图存档任务
- **防 flaky 硬约束**：自动 diff 必须先声明遮罩规则，未声明遮罩的 diff 失败不判 Bug

## 10. 轴 8 国际化（i18n）

- **需求信号**：海外 / 多语言市场；RTL 语言；跨时区用户群；本地化交付
- **代码信号**：i18n bundle / locale 目录（扫描器探测）；日期货币格式化库；硬编码文案（S 级复核）；时区处理逻辑
- **默认档**：软默认——无信号 exclude（记录扫描结果）；有信号 → standard
- **档位语义**：full = 伪本地化全量 + RTL 布局走查 + 格式矩阵（日期 / 货币 / 电话 / 时区 / 复数规则）；standard = 目标语言集核心流 + 格式抽样；light = 硬编码文案扫描 + 代表性页面伪本地化
- **执行归属**：agent
- **成本因子**：翻译数据依赖（伪本地化不依赖）
- **消费方式**：用例型——standard 及以上产 type: functional 用例加标签 [国际化]；light 产扫描条目

## 11. 轴 9 迁移与升级（migration）

- **需求信号**：存量系统迭代；数据结构变更公告；灰度共存 / 版本升级
- **代码信号**：DB migration 文件（扫描器探测 migrations / alembic / flyway 目录）；数据回填脚本；双写逻辑〔S〕；API 多版本共存
- **默认档**：软默认——有 migration 文件 → standard；无 → 存量系统 light / 绿地项目 exclude（记录判断依据）
- **档位语义**：full = 升级路径矩阵（版本 × 数据形态）+ 回滚验证 + 新旧数据共存探测；standard = 代表性升级用例 + 回滚一例；light = migration 脚本审查（可回滚性 / 兼容性 / 回填幂等）
- **灰度共存专项（需求信号命中灰度时并入对应档位一并交付）**：新版本自身功能之外覆盖三条链路——① 灰度路由正确性：命中小流量规则的请求进新版、未命中留在旧版（用例各自验证一侧）；② **出界处置**：与用户确认哪些指标越界即触发暂停 / 回滚（错误率 / 资损告警阈值等），并对"越界 → 暂停 → 回滚 → 数据一致"至少演练一次；③ **出界留痕**：每轮灰度的范围、比例、指标快照与出界事件记录落盘，作为下一步扩大灰度的依据——禁止凭印象全量
- **执行归属**：agent
- **成本因子**：可重置的存量数据快照
- **消费方式**：用例型——standard 及以上产 type: functional 用例加标签 [迁移]；light 产脚本审查条目

## 12. 轴 10 契约与集成（contract-integration）+ 消费方式映射

### 轴 10 契约与集成

- **需求信号**：第三方依赖清单；对外 API 的消费方；微服务边界；webhook
- **代码信号**：外部 HTTP / gRPC 调用；消息契约；OpenAPI 定义变更；回调处理
- **默认档**：软默认——有外部依赖 → standard；无 → exclude（记录扫描结果）
- **档位语义**：full = 消费者驱动契约（Pact 式）+ 依赖故障矩阵（超时 / 错误码 / 格式变化 / 限流）；standard = 关键依赖 mock 与真实双跑 + 异常分支用例；light = 调用面清单 + 错误处理审查
- **执行归属**：agent（schema 一致性 / 负向 fuzzing 按 api-testing「契约与 schema 一致性」节）；契约测试框架（Pact 式多消费者场景）执行为移交候选
- **成本因子**：mock / 沙箱可用性
- **消费方式**：用例型——standard 及以上产 type: functional 用例加标签 [集成]；契约执行物进执行策略裁决

### 消费方式映射总表（test-case-writing 消费 type_scope 时执行）

| 消费方式 | 适用（standard 及以上；例外档位见格内标注） | 产出 |
|---|---|---|
| 用例型 | 轴 2（type: security，标签 `[安全]`）、轴 3（reliability）、轴 4（concurrency）、轴 5（compatibility）；轴 8 / 9 / 10（type: functional + 标签） | 手动用例进 markmap，type / 标签见左 |
| 脚本型 | 轴 1（压测模型 + 执行物）、轴 6（axe 扫描任务与违规清单，**任意档位**）、轴 7（截图基线） | 不产手动用例，产执行物进执行策略裁决 |
| 审查型 | 各轴 light 档 | 扫描 / 审查清单条目（Cx 通道），不进用例正文 |

> exclude 轴不产出；handoff 轴只产移交包。depth=light 的轴 2 / 3 / 4 / 5 也按审查型走 Cx 通道。

## 13. 深度校准与停止准则

### 升降档规则（R1–R6；唯一声明的冲突裁决：R6 > R1）

> 编号区分：本表 R1–R6 是**升降档规则**编号；Risk Map 中的 R1、R2… 是**风险条目**编号——两者同名不同义，以上下文为准。

| 规则 | 触发条件 | 动作 |
|---|---|---|
| R1 风险升档 | 该轴覆盖的场景挂 Critical 风险 → full；High → 至少 standard | 升档，rationale 挂风险编号 |
| R2 双源信号 | 同轴命中 ≥2 类独立信号（需求级 + 代码级） | 升一档 |
| R3 历史缺陷 | 该轴维度历史 Bug ≥3 或出过线上事故 | 升一档 |
| R4 无信号降档 | 需求 + G 级 + S 级扫描全灭（硬默认轴无此出口） | 可降至 exclude；G + S 双清单落盘 |
| R5 成本门 | 执行前提（环境 / 数据 / 工具）不可得 | **执行降级不决策降级**：depth 保持，execution_status 记 blocked + todo 向谁索取 |
| R6 预算约束 | full 轴数 > 3（两域合并计） | 按风险排序裁剪至 ≤3，记录排序依据。被裁剪的 Critical 轴触发**预算裁决检查点**（用户可扩预算，扩预算时 depth_budget 记 budget_review） |

### 停止准则

每轴的**档位语义就是停止准则**（§3–§12 各轴写死的动作清单勾完即停）；策略落盘时生成足够性声明：逐轴列档位动作清单与完成状态。禁止"再测测看"式开放式深挖——想加深必须升档并说明触发了哪条 R 规则。

## 14. 引用方式

test-strategy 工作流第 4 步按组加载本文件对应小节（`../core/test-type-matrix.md`）；test-case-writing 阶段一消费 type_scope 时加载第 12 节映射表。本文件不复制进任何 SKILL.md（单一真相红线）。

# 测试原则与设计方法选择

> 跨 Skill 共享的测试方法论。`test-strategy` 用它决定测什么类型 / 多深；`test-case-writing` 用它选设计方法与组织结构。方法级落地细节在 `methods/`，覆盖度检查表在 `coverage.md`。

## 1. 测试原则

1. **一条用例只测一个点**，预期结果明确唯一；"或 A 或 B"拆成两条
2. **风险驱动**：围绕风险设计测试，而不是机械生成——风险 → 策略 → 用例的推导链（见 `risk-model.md`）
3. **证据先行**：所有结论标注证据等级与来源（见 `evidence.md`）
4. **代码优先**：有代码必读代码，以实现为行为基线（测准声明）
5. **先澄清再动手**：模糊 / 矛盾之处向用户提问，不硬猜
6. **给人看、给人执行**：用例是给测试工程师执行的操作指令，不是覆盖度展示品（见 `executability.md`）
7. **失败之后要有重试**：每种失败 / 拦截场景，配"失败 → 再试 → 恢复"用例
8. **逆向操作成对验证**：创建↔删除、分配↔释放、导入↔撤销，每对都要有用例

## 2. 设计方法选择（按功能特征选方法，不强制状态机）

| 功能特征 | 设计方法 | 核心动作 |
|---------|---------|---------|
| 明显状态流转 | State Machine | 提取状态 → 事件 → 新状态；按状态节点分模块；每条边一个用例；非法转换配拦截用例 |
| 输入输出型功能 | Equivalence Partitioning + Boundary Value Analysis | 划分有效/无效等价类；边界取值：空 / 最小 / 最小-1 / 最小+1 / 最大 / 最大+1 / 超大 |
| 权限系统 | Role × Action × Resource | 行为权限矩阵逐格核对；资源级隔离（A 的数据 B 不可见）；角色变更后权限即时性 |
| API | Parameter Matrix | 参数 × 类型/必填/边界/默认值逐格；多参数组合显式降档（全组合 → 成对 → 风险挑选，见 `methods/data-driven.md` 第 2 节）；鉴权 / 幂等 / 并发 / 错误码 |
| 复杂业务流程 | Workflow | 端到端主链 + 每环节失败分支 + 中断恢复 + 多轮累积 |
| 数据转换 | Input → Transform → Output | 典型输入 / 畸形输入 / 空输入 → 逐类核对输出；转换保真（读回一致） |
| 历史 Bug 较多 | Regression-focused | 每个历史 Bug 一条回归用例；聚类找系统性薄弱区加防 |

各方法的落地细则（按需加载）：边界 / 等价类 → `methods/boundary.md`；参数矩阵 / 导入 / 数据转换 → `methods/data-driven.md`；权限矩阵 → `methods/permission.md`；状态机组织 → `methods/state-machine.md`。

## 3. 二阶交叉覆盖（一阶枚举的补漏公式）

一阶枚举（每条规则 / 每条状态边一个用例）做得再全，漏的通常是三类交叉：

1. **写入路径 × 校验规则**：同一条校验在创建 / 编辑 / 重新提交 / 导入等**每条写入路径**上是否都生效（校验常只挂在创建，编辑路径绕过校验的 bug 高发）
2. **失败 × 重试**：每种失败 / 拦截发生后，重试能否恢复正常
3. **标识 × 重复**：名称 / 编号等用户可见标识字段重复提交时的唯一性行为

## 4. 覆盖维度索引

覆盖度检查的完整维度清单（19 维 + 横切可执行性）由 `coverage.md` 维护，`test-case-review` 独立审查时同样引用该清单（`test-strategy` 的范围决策走 `risk-model.md` 的风险维度，不直接消费该清单）。

## 5. 引用方式

各 SKILL.md 在选择测试类型 / 设计方法的步骤标注"此时加载本文件"，相对路径 `../core/testing-principles.md`。

# 统一失败分流规范（Failure Triage）

> 全框架唯一的**批量失败首轮分流**规范。解决两个对称的时间黑洞：把 N 条自动化失败逐条当 Bug
> 全流程处理（误报淹没真问题），或重跑变绿全部放过（真回归漏网）。一轮执行的失败集合先按四类
> 归类、逐条给依据、路由去向，再进入各自下游。
>
> 失败处理的三层能力栈，本文件只占中间层：
>
> | 层 | 职责 | 归属 |
> |----|------|------|
> | 运行时技巧层 | 执行中单条失败的即时定性（first-run-flaky 规则、等待策略） | 各执行 skill 工程约定（如 playwright-conventions 第 11 节） |
> | **分流层（本文件）** | 一批失败的首轮分类 + 路由去向 | 消费方在失败 ≥3 条时加载本文件 |
> | 深挖层 | 已确认 Bug 的根因/影响/Severity/修复建议 | `bug-analysis` |

## 1. 触发条件与输入输出

- **何时使用**：一轮执行（自动化全量 / CI 夜间任务 / 回归清单执行 / 回归复验）结束后，失败条数 **≥3 条**。1–2 条失败不值得分流开销，直接按执行 skill 单条流程处置。
- **输入**：本轮结果清单（TC 编号 × 通过/失败）+ 失败现场产物（trace / 截图 / 控制台日志 / API 请求响应记录 / JUnit results.xml 等结构化输出）
- **输出**：`{项目}/失败分流_{日期}.md`（模板见第 6 节）——逐条给分类 + 依据 + 去向；其结论分别流向上游各 skill 与测试报告对应章节
- **追加式留存**：分流文件按日期累积不清除——它是 D 类跨轮追踪的最小数据形态（见第 5 节），不需要额外数据库

## 2. 四分类定义（+U）

| 类别 | 判定语义 | 典型形态 | 定类最低证据 | 去向 |
|------|---------|---------|-------------|------|
| **A 真缺陷** | 产品侧行为与预期不符且变更非预期；实现未变而结果变了同样归此 | 断言失败但预期仍有效；数据不一致；状态卡死 | E3 运行证据 + S 级复核通过（第 4 节） | 执行 skill 报告 §3 记 Bug 条目 → 根因五字段移交 `bug-analysis` |
| **B 资产问题** | 失败由**测试资产侧**原因造成，产品行为无缺陷：B1 产品变更属预期但用例预期未跟上；B2 用例自身写错（脚本选择器永久失效、断言抄错字段、步骤拼错） | expected diff 恰为新文案/新默认值；页面重构后选择器过期 | B1 必须附**变更依据**（commit / 需求文档章节或用户裁决）；B2 给出写错位置 | 更新用例或脚本：B1 → `test-case-writing` 增量修订并留变更依据；B2 → 就地修正脚本 |
| **C 环境与依赖故障** | 失败由被测系统之外的运行环境造成：服务不可达、证书/账号失效、部署进行中、共享数据被污染 | HTTP 5xx 密集、连接拒绝、登录态全挂、同批大面积同形态失败 | E3 错误形态聚集 + 单一环境事件定位 | 记环境事件（一条），修复后**受影响批次原样重跑**（见第 5 节反吞没条款二） |
| **D 不稳定（flaky）** | 同一输入结果不定：竞态等待不足、清理不彻底、时序敏感 | 首跑失败原样重跑通过；历史翻灯交替 | E3 重跑对照（重跑只用于定性，不算通过） | 按 owning skill 工程约定处置（短期 fixme + 排期修根因），分流表跨轮追踪（第 5 节） |
| **U 无法定类** | 证据不足或信号互相矛盾的显式未知 | 现场产物缺失无法复核；两类信号冲突 | — | 测试报告 §6 未闭环事项，人工判断；**不许硬编结论** |

> 与既有三分法的关系：`api-testing` 运行纪律的"系统 Bug / 环境问题 / 用例自身错误"三分对应
> 本表的 A / C / B2——本规范是其全框架统一化，并补充了业界标配的 B1（预期变更）与 D（flaky）。

## 3. 判定树（先全局，后个体）

```text
输入：失败集合 + 失败现场产物

第 0 步 · 全局扫描（C 类前置排除）
│   为什么先做：环境故障会污染整批判断——环境坏了之后个体分析全是噪音
├─ 同批失败率 ≥50%，且错误形态趋同（同一 error type / 同一错误消息占比过半）
│  或登录态统一报错 / 目标服务不可达 / 5xx 密集
│     → 疑似单一环境事件：先定位它（部署中？账号锁定？数据污染？依赖挂了？）
│     → 确认后整批标 C 待重验，直接跳第 4 步收尾
└─ 无全局形态 → 进入个体路径

第 0.5 步 · 个体聚簇（批量坍缩）
│   失败量大时先聚簇再定性：聚类键 = error message / 堆栈公共帧 / 选择器接口
│   （G 表「重复 error message」「错误密集形态」两组信号就是现成的聚类统计口径）
├─ 每簇只取证据最全的一条为代表进第 1 步定性
└─ 簇内其余条目继承代表的类别，evidence 必须引用代表行编号（零依据照抄视为无效行）

第 1 步 · 个体原样重跑（定性手段，不是通过手段；仅对簇代表执行）
├─ 稳定复现 → 进第 2 步
└─ 重跑通过 → D 候选（对照历史分流表翻灯记录可强化判 D，见第 4 节 G 表）

第 2 步 · A / B 区分（仅对稳定复现者）
│   该失败行为落在本次变更基线内吗？（git diff / 近期需求变更关联）
├─ 变更基线内 + 变更属预期（需求文档佐证或用户裁决）→ B1
├─ 变更基线内但变更不属预期 / 实现未变而结果变了 → A
├─ 疑似用例自身错误（选择器永久失效 / 断言明显抄错）→ B2
└─ 分歧拿不准 → ⏸ 呈现双方证据等用户裁决（意图问题：
    用户答复具有最终裁决力，evidence.md 三类裁决规则第三条）

第 3 步 · 收尾
└─ 以上全部未定 → U，进报告 §6 未闭环

第 4 步 · C 类收尾（反吞没条款二）
    环境修复后，受影响批次原样重跑
    ├─ 全部通过 → 该批次 resolved，事件单条归档
    └─ 仍有失败 → 失败者退出 C，回第 1 步重新个体定性
        （防止环境恢复把混入的真缺陷一并静默吞掉）
```

## 4. G/S 双级信号

> 口径声明：本节 G/S 与类型决策矩阵（`test-type-matrix.md`）同名同哲学，但**信号源不同**——
> 矩阵扫的是被测仓库代码（scan_signals.py），本表读的是**执行产物**（results.xml / 错误文本 /
> trace）。两者互不替代。

**G 级（机械可提取，聚合统计即可，无需 agent 语义理解）：**

| G 信号 | 提取来源 | 分类倾向 |
|--------|---------|---------|
| 同一 error message/type 重复 ≥3 条 | JUnit results.xml / 控制台文本聚合 | C |
| `HTTP 5xx` / `net::ERR_*` / `ERR_CONNECTION_REFUSED` / 超时类密集 | 错误文本分类统计 | C |
| 失败时间戳同秒级聚集 | results.xml timestamp 字段 | C |
| 登录/鉴权 helper 统一栈帧报错 | 失败堆栈公共帧比对 | C |
| assertion diff 中 expected = 文案/展示值，且近期有相关需求 commit | message 字段 × git log 对照 | B1（待补变更依据） |
| 本轮红上轮绿交替 / 条目曾标 fixme | grep 历史分流文件 | D |
| 选择器/元素不存在类错误且页面近期重构 | 失败消息 × git log | B2（待 S 级确认页面确已改版） |

**S 级（agent 读 trace / 截图 / API 日志做语义复核）：**

- 截图核对断言对象的实际语义：是时序未完成、还是数据真的错、还是页面结构确实变了
- API 响应体逐字段核对是否符合新需求（B1 变更依据的具体佐证）
- 自建数据残留检查（前序用例清理不彻底是 D 的常见根因）
- 用例步骤与实际页面动线比对（发现 B2 写错点）

**铁律：倾向 ≠ 结论。** G 级命中只产生预填候选；A 类定类必须过 S 级复核（E3 + 复核通过才允许记
Bug 条目）；B1 没有 G 表以外的独立变更依据不得判 B（见下节条款一）。这与矩阵 exclude 永不预填
是同一防橡皮图章原则。

## 5. 裁决规则与两条反吞没条款

- **A/B 分歧是意图问题**：按 `evidence.md` 第三类裁决规则，用户在澄清环节的明确答复有最终裁决力，
  后续阶段不得推翻；分歧呈现时给双方证据摘要，不自答（对齐 `qa` 编排 ⏸ Bug 定性检查点）。
- **条款一（防免检通道吞真 Bug）**：判 B1 必须给出具体变更依据——commit hash、需求文档章节、或
  用户裁决记录三者之一。给不出的一律回 A/U 处理。"看起来像需求变更了"不是依据。一次错误的 B 判定
  会让真缺陷以资产更新为名合法消失——这与"基准答案标错、整条质量链跟着走偏"是同一类方向性风险。
- **条款二（防环境恢复掩盖缺陷）**：C 类不是丢进回收站——环境修复后受影响批次强制原样重跑，
  仍失败者升 A 候选重新进判定树。禁止只说"环境问题已解决"就关闭整批。
- **D 类升级机制**：同一 TC 在历史分流文件中出现 ≥3 轮（`grep -l` 即可检索，这正是追加式留存的
  目的）→ 升级处置优先级：fixme 转为排期修复根因，不允许永久 fixme 化（覆盖虚减风险，口径同
  case-format 第 10 节对废弃用例的处理——可以废弃但必须留痕记数，不能静默消失）。

## 6. 产出物模板：失败分流表

落盘 `{项目}/失败分流_{日期}.md`，结论直接被下游引用（报告 §2 统计口径不变，§3 只收 A 类条目）：

```markdown
# 失败分流 — {日期}

- 来源：{哪轮执行：回归清单_20260827 / CI 夜间 full-run}
- 规模：{总数} 失败 {失败数}（分流阈值触发原因：≥3 条）
- 结论分布：A={n} B1={n} B2={n} C={n} D={n} U={n}

## 环境事件（C 类汇总，无则省略本节）
- EVT-1：{现象}｜定位：{单一根因}｜处置：{修复动作}｜重验：{批次与结果}

## 分流明细

| # | TC | 类别 | G 信号摘要 | S 级复核 | evidence | status | 去向 |
|---|----|------|-----------|---------|----------|--------|------|
| 1 | TC-02-03 | A | 断言 stable diff，无聚集 | 截图核对：优惠金额确实双扣 | level: E3, source: bug-001-02.png | fact | 报告§3 BUG-001 → bug-analysis 五字段 TODO |
| 2 | TC-04-01 | B1 | expected=新版文案；关联 commit a1b2c3 | 响应体字段与新需求一致 | level: E4, source: report.txt [5] + 需求 v2.3 §4.2（运行 + 文档双来源印证） | fact | test-case-writing 增量修订（附依据） |
| 3 | TC-05-02 | U | 无聚集 | trace 缺失无法复核 | level: E0, source: 仅用户口述 | hypothesis | 报告§6 未闭环，找{谁}要 {什么} |
```

- evidence 字段格式遵从 `evidence.md` 第 4 节；status 取值同其第 3 节（fact / inference /
  hypothesis…）——**没有证据支撑的分类行视为无效行**
- C 类事件单列汇总而非按 TC 展开：环境故障是一因多果，逐 TC 重复记录只会制造噪音
- 大批量轮次给簇编组号（CL-1 / CL-2…）：同簇继承行的类别照抄代表不算违规，但 **evidence 必须填「CL-x 代表 #n」格式的引用**——找不到所引代表行的继承行，同样按无效行处理

## 7. 加载约定与其他 skill 的边界

**加载时机**（消费方在工作流中的标注方式，遵循 core 引用双形态约定）：

| 消费方 | 挂载点 | 时机标注 |
|--------|--------|---------|
| `automated-e2e-testing` | 工作流二之前 | 一轮执行结束失败 ≥3 条时（此时加载本文件），A 类才进证据收集与报告条目 |
| `api-testing` | §4 运行与结果 | 失败 ≥3 条时改走批量分流，替换单条"先分辨"流程 |
| `regression-testing` | §4 结果衔接 | 回归多失败先分流再同步 Bug 状态，防把 B/C/D 误刷成复验轮次 +1 |

**边界速查：**

| 场景 | 归属 |
|------|------|
| 执行中发现单条失败的即时定性（first-run-flaky 判定、等待策略） | 各执行 skill 工程约定 |
| 一批失败的首轮分类与路由 | 本文件 |
| 已确认 Bug 的根因 / 影响 / Severity / 修复建议 / 回归建议 | `bug-analysis` |
| 修复合入后该跑哪些回归用例 | `regression-testing` |
| B1/B2 导致的用例与脚本修订 | `test-case-writing` / 执行 skill 的资产维护流程 |
| 类型域专项外部工具结果的回收 | 报告 §7（handoff 协议），与本文件无关 |

## 8. Common Mistakes

| 错误 | 后果 | 正确做法 |
|------|------|---------|
| 每条失败都当 A 记 Bug | 误报淹没报告，开发信任崩塌，triage 声誉归零 | 先全局扫描再个体定性；A 过 S 级复核才落条目 |
| 重跑变绿就放过（不标 D 不追踪） | flaky 混入绿灯名单，覆盖虚减，真回归夹杂其中随机漏网 | D 进分流表跨轮追踪；≥3 轮升级修根因 |
| 判 B1 却给不出变更依据 | 免检通道吞掉真缺陷，且以"资产更新"合法消失 | 条款一：无依据一律回 A/U；问用户 |
| C 类说一句"环境问题"就关整批 | 环境恢复后混入的真缺陷被静默吞掉 | 条款二：受影响批次强制原样重跑，仍失败者重新定性 |
| 把 G 级命中直接当结论报出 | 机械预判成为橡皮图章 | 倾向≠结论；A 必过 S 级复核（同矩阵 exclude 永不预填） |
| 分流行不给 evidence/status | 不可复核、不可续跑，后续阶段无从消费 | 无证据的分类行视为无效行 |
| U 类硬编一个类别交差 | 显式未知变隐性误导，人工兜底线索丢失 | U 进报告 §6 未闭环，注明缺什么证据、找谁要 |
| 大批量失败逐条独立定性 | 夜间数十条重复劳动到天亮，同类条目结论还互相矛盾 | 第 0.5 步先聚簇坍缩：每簇只定性代表，其余继承并引代表行编号 |