测试报告（Test Report）

参考来源：ISTQB Test Summary Report (IEEE 829)、Google Test Reporting Best Practices、SonarQube Quality Reports。

适用场景

• 版本发布前的测试总结
• 阶段性测试报告（每周 / 每迭代）
• 缺陷分布分析
• 上线决策依据
• 给 PM / Tech Lead / 业务方看的"是否能放行"结论

核心原则

1. 报告是给决策者看的
   首页必须有"建议是否放行"

2. 数字 + 趋势 + 结论
   不只是列数字，要给意见

3. 风险透明
   "已知问题"必须明示，不藏

4. 一页纸总结 + 详细附录
   忙人看一页，关心人看附录

5. 可对比
   与上版本 / 基线对比

6. 数据不撒谎
   覆盖率高 ≠ 质量好
   覆盖率是"测试了多少"，不是"测对了多少"

报告结构（5 段式）

1. 执行摘要（1 段）

本次测试：[范围]
执行：[X 条用例 / Y 小时]
结论：建议放行 / 有条件放行 / 不建议放行
关键风险：[1-2 条]

2. 测试范围

- 必测：✅ 100%（X/X）
- 选测：✅ 80%（Y/Z）
- 不测：[列表 + 原因]

3. 缺陷分析

- 总数：X 个
- 严重度分布：S0:0 / S1:2 / S2:5 / S3:8
- 修复率：X%
- 待修：[ID 列表]

4. 覆盖度

- 用例覆盖：100% 验收标准
- 代码覆盖：[%（如有）]
- 风险覆盖：C 级 100% / H 级 100% / M 级 80%
- 性能基线：✅ 达标 / ⚠️ 退化 X%

5. 放行建议

□ 必测用例 100% 通过
□ 高风险 Bug = 0
□ 性能 SLO 达标
□ 验收 UAT 通过
→ 建议：放行 / 不放行

关键指标

用例指标

计划用例数：
执行用例数：
通过：✅ X 条
失败：❌ Y 条
跳过：⏭️ Z 条
执行率：执行/计划
通过率：通过/(通过+失败)

缺陷指标

新增 Bug：X 个
修复 Bug：Y 个
关闭 Bug：Z 个
未修复 Bug：W 个
  - S0：0
  - S1：1（已知问题）
  - S2：3（已知问题）

平均修复时间（MTTR）：X 小时
缺陷逃逸率（生产 / 测试）：X%

覆盖率指标

验收标准覆盖：100%
代码行覆盖：80%（仅供参考）
分支覆盖：65%
风险覆盖：
  - C 级：100%
  - H 级：100%
  - M 级：80%
  - L 级：30%

性能指标（如有）

P99 响应时间：[实测] vs [SLO]
QPS：[实测] vs [目标]
错误率：[实测] vs [SLO]
对比上版本：[退化 / 持平 / 改善]

缺陷分布分析

按模块：
  订单 ████████ 8
  支付 ████ 4
  用户 ██ 2
  → 重点：订单模块

按发现阶段：
  单元测试 ███ 3 (修复成本：低)
  集成测试 ████ 4
  E2E ██ 2
  探索式 █████ 5
  生产 0 (好)
  → 大部分缺陷在测试期发现，符合预期

按根因：
  需求理解错 ███ 3
  设计缺陷 ██ 2
  编码错误 █████ 5
  配置错 ██ 2
  数据问题 █ 1
  第三方 0
  → 编码错误占大头，建议加强 code review

按严重度：
  S0 ░ 0
  S1 █ 1
  S2 ███ 3
  S3 ██████████ 10
  → 严重 Bug 少，主要是细节

趋势对比

本版本 vs 上版本：

| 指标 | 上版本 | 本版本 | 趋势 |
|---|---|---|---|
| Bug 总数 | 15 | 13 | ↓ |
| S0/S1 数 | 3 | 1 | ↓ |
| 修复时间 | 6h | 4h | ↓ |
| 用例数 | 120 | 145 | ↑（覆盖增强）|
| 通过率 | 95% | 98% | ↑ |
| 性能 P99 | 350ms | 380ms | ⚠️ 轻退化 |

报告自动化

推荐自动化项：
- 用例执行结果：CI 集成（Allure / TestRail）
- 代码覆盖率：自动收集（JaCoCo / Coverage.py）
- 性能数据：自动从压测工具拉
- Bug 趋势：从跟踪系统 API

人工撰写项：
- 风险结论
- 放行建议
- 已知问题影响分析
- 改进建议

一页纸总结模板

# v1.2.3 测试报告

## 一句话结论
✅ 建议放行（或 ⚠️ 有条件放行 / ❌ 不建议放行）

## 关键数据
- 用例 145/145 通过率 98%
- Bug 13 个：S0:0 / S1:1 / S2:3 / S3:9
- 性能：达标
- UAT：通过

## 关键风险
1. 多币种汇率刷新偶发延迟（S2 已知，不阻塞）

## 已知问题（业务方已知悉）
- BUG-XXX：[简述 + 影响 + 缓解]

## 放行 Checklist
✅ 必测 100% 通过
✅ S0/S1 = 0
✅ 性能 SLO 达标
✅ UAT 通过
✅ 监控告警就绪

工作流程

1. 收集数据
   - 用例结果（自动）
   - 缺陷数据（自动）
   - 性能数据（自动）
   - 覆盖率（自动）
   ↓
2. 分析
   - 趋势对比
   - 缺陷分布
   - 风险评估
   ↓
3. 撰写报告
   - 一页纸总结
   - 详细附录
   ↓
4. 评审
   - 与 PM / Tech Lead 评审结论
   ↓
5. 发布
   - 项目群 / 邮件 / Wiki
   ↓
6. 决策
   - 放行 / 修复 / 推迟
   ↓
7. 沉淀
   - 经验进 field-journal
   - 缺陷模式更新 pitfalls

质量自检

□ 一句话结论清晰
□ 数据有上下文（对比基线）
□ 缺陷按多个维度分布
□ 风险透明（已知问题列出）
□ 放行 Checklist 明确
□ 性能数据完整（如有）
□ 改进建议具体可执行
□ 自动化数据 + 人工分析结合
□ 报告可读（图表 / 表格）
□ 决策者看 1 分钟能决定

常见坑

1. 只列数字不给结论——决策者还是不知道能不能放行
2. 覆盖率代表质量——80% 行覆盖不等于 80% 业务覆盖
3. 隐藏已知问题——上线后爆出"为什么不告诉我"
4. 不与基线对比——P99 350ms 是好是坏不知道
5. 缺陷只看总数——10 个 S3 vs 1 个 S0 完全不同
6. 报告太长——决策者不看
7. 报告太短——没法追溯
8. 不做趋势分析——单点数据无意义
9. 不沉淀经验——下次还是从零写
10. PM 不看——格式不对路（用 Markdown 给只看 Excel 的）

配套模板

• templates/test-report-template.md — 完整测试报告（一页纸总结 + 详细附录 + 缺陷分布 + 趋势对比 + 放行 Checklist）

与其他 skill 的协作

上游：
  test-strategy → 测试范围基线
  test-case-design → 用例数据
  bug-reporting → 缺陷数据
  regression-testing → 回归结果
  performance-testing → 性能数据
  acceptance-testing → UAT 结论

下游：
  quality-gate → 报告作为放行依据
  项目经理工作流 → 进度纳入项目报告
  技术文档工作流 → 已知问题进发布说明
  field-journal → 经验沉淀