dsh-qa-skills/skills/core/report-template.md

DeepSeek Harness (dsh) plugin: 10 testing skills (requirement analysis, test strategy, case writing/review, E2E/API automation, exploratory, regression, bug analysis) + shared core knowledge base — a full QA pipeline as agent skills.

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

> 全框架唯一的测试报告模板。`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 清单

> **严重程度口径（2026-08-23 R6 消歧）**：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 报了但永远关不掉"的断链

## 引用方式

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