Qa Test Reporting

SKILL.md

---
name: qa-test-reporting
version: 1.6.0
description: >-
  输出面向不同受众的测试报告——日报给团队同步进度、周报给项目经理、质量报告给管理层决策。当测试执行完成需要汇总结果、或者上级问"质量怎么样"的时候使用此技能。不同角色关心的数据不同：开发关心Bug明细，经理关心通过率和趋势，老板关心风险和发版决策。报告内容适配受众，关键指标量化呈现，风险区域必须醒目标注。

when_to_use: 用户说"测试报告"、"日报"、"周报"、"迭代报告"、"报告模板"、"质量汇报"、"进度汇报"、需要编写测试报告、向管理层汇报测试进展时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-quality-metrics         # 输入：质量度量数据
    - qa-bug-lifecycle        # 输入：缺陷数据
    - qa-execution-observation   # 输入：执行观察结果
  downstream:
    - qa-stakeholder-communication # 输出：报告用于干系人沟通
    - qa-retrospective           # 输出：报告数据用于复盘
input_format:
  required:
    - name: 测试执行数据
      type: object
      description: 测试执行结果和统计
    - name: 缺陷数据
      type: object
      description: 缺陷统计和分析数据
  optional:
    - name: 质量度量
      type: object
      description: 来自qa-quality-metrics的质量数据
output_format:
  traceability:
    - 每份测试报告带唯一ID（RPT-XXXX）
    - - 聚合用例ID、缺陷ID、需求ID
  structure:
    - executive_summary: 执行摘要
    - test_results: 测试结果统计
    - defect_analysis: 缺陷分析
    - risk_assessment: 风险评估
    - recommendations: 改进建议
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
  reference_value: "根据受众调整报告深度：简单×1/中等×2/复杂×3"
  minimum: "至少包含进度、质量、风险、下一步4个核心章节"
error_recovery_guidance:
  on_failure: "报告遗漏受众关注点时回退到质量度量补充数据"
  retry_behavior: "补充数据后重新生成报告"
---
> **⚠️ 安全警告**：本技能的示例可能涉及发布建议和延期结论字段。
> 这些是报告字段不是直接操作；请勿未经授权即执行发布或延期决策。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 测试报告编写

## 核心原则

测试报告不是数据堆砌，而是决策支持——让读者快速了解质量状态和风险。

## 报告类型

### 1. 日报

```text
用途：每日测试进展同步
受众：测试团队、开发
频率：每日

内容结构：
├─ 今日完成
│   ├─ 用例执行：XX条
│   ├─ 缺陷发现：XX个
│   ├─ 缺陷修复：XX个
│   └─ 遗留问题：XX个
│
├─ 问题与风险
│   ├─ 阻塞问题：[描述]
│   ├─ 风险提示：[描述]
│   └─ 需要支持：[描述]
│
└─ 明日计划
    ├─ 测试重点：[描述]
    └─ 预计产出：[描述]
```

### 2. 周报

```text
用途：每周测试进展总结
受众：测试负责人、项目经理
频率：每周

内容结构：
├─ 本周概览
│   ├─ 用例执行率：XX%
│   ├─ 用例通过率：XX%
│   ├─ 缺陷发现数：XX个
│   ├─ 缺陷修复率：XX%
│   └─ 质量状态：[绿/黄/红]
│
├─ 详细数据
│   ├─ 按模块统计
│   ├─ 按严重程度统计
│   ├─ 按类型统计
│   └─ 趋势分析
│
├─ 问题与风险
│   ├─ 本周问题：[列表]
│   ├─ 遗留风险：[列表]
│   └─ 需要决策：[列表]
│
└─ 下周计划
    ├─ 测试重点：[描述]
    ├─ 资源需求：[描述]
    └─ 预计产出：[描述]
```

### 3. 迭代报告

```text
用途：迭代测试总结
受众：项目团队、管理层
频率：每个迭代结束

内容结构：
├─ 执行摘要
│   ├─ 迭代目标：[描述]
│   ├─ 测试范围：[描述]
│   ├─ 质量结论：[通过/有条件通过/不通过]
│   └─ 发布建议：[建议发布/建议延期]
│
├─ 质量数据
│   ├─ 用例统计
│   │   ├─ 总用例数：XX
│   │   ├─ 执行用例数：XX
│   │   ├─ 通过用例数：XX
│   │   ├─ 执行率：XX%
│   │   └─ 通过率：XX%
│   │
│   ├─ 缺陷统计
│   │   ├─ 新增缺陷：XX个
│   │   ├─ 已修复：XX个
│   │   ├─ 遗留缺陷：XX个
│   │   ├─ 严重缺陷：XX个
│   │   └─ 缺陷修复率：XX%
│   │
│   └─ 质量指标
│       ├─ 需求覆盖率：XX%
│       ├─ 代码覆盖率：XX%
│       ├─ 缺陷密度：XX/功能点
│       └─ 漏测率：XX%
│
├─ 风险评估
│   ├─ 高风险区域：[列表]
│   ├─ 遗留问题：[列表]
│   └─ 修复建议：[列表]
│
├─ 改进建议
│   ├─ 流程改进：[建议]
│   ├─ 工具改进：[建议]
│   └─ 能力提升：[建议]
│
└─ 附件
    ├─ 用例执行明细
    ├─ 缺陷清单
    └─ 质量趋势图
```

### 4. 专项报告

```text
类型：
├─ 性能测试报告
├─ 安全测试报告
├─ 兼容性测试报告
├─ 接口测试报告
└─ 探索测试报告

内容结构：
├─ 测试目标
├─ 测试范围
├─ 测试环境
├─ 测试方法
├─ 测试结果
│   ├─ 通过项
│   ├─ 失败项
│   └─ 风险项
├─ 问题分析
└─ 结论建议
```

## 报告模板

### 测试日报模板

```markdown
# 测试日报

**日期**：YYYY-MM-DD
**报告人**：[姓名]
**项目**：[项目名称]

## 今日完成
| 项目 | 数量 | 备注 |
|------|------|------|
| 用例执行 | XX条 | |
| 缺陷发现 | XX个 | |
| 缺陷修复 | XX个 | |
| 遗留问题 | XX个 | |

## 问题与风险
- [ ] 阻塞问题：[描述]
- [ ] 风险提示：[描述]
- [ ] 需要支持：[描述]

## 明日计划
- 测试重点：[描述]
- 预计产出：[描述]
```

### 迭代报告模板

```markdown
# 迭代测试报告

## 执行摘要
| 指标 | 结果 | 目标 | 状态 |
|------|------|------|------|
| 用例执行率 | XX% | ≥95% | ✅/❌ |
| 用例通过率 | XX% | ≥90% | ✅/❌ |
| 缺陷修复率 | XX% | ≥95% | ✅/❌ |
| 严重缺陷 | XX个 | 0 | ✅/❌ |

## 质量结论
[通过/有条件通过/不通过]

## 发布建议
[建议发布/建议延期]
```

## 输出示例

**编写迭代结束的测试报告**
→ 日报：今日完成XX条用例/发现XX个Bug/阻塞项XX
→ 周报：本周进度XX%/新增Bug趋势/风险预警
→ 迭代报告：执行摘要→质量结论→数据图表→风险分析→发布建议
→ 关键数据：测试通过率90%、遗留Bug12个（P0:0 P1:2 P2:10）、代码覆盖率75%

**用户说"质量到底行不行"**
→ 迭代报告一句话结论：质量良好，建议发布（P0/P1 Bug已全部修复，P2 Bug已评估无风险）

## 检查清单

测试报告完成后检查：
- [ ] 报告类型是否正确？
- [ ] 数据是否准确？
- [ ] 结论是否清晰？
- [ ] 风险是否识别？
- [ ] 建议是否可行？
- [ ] 格式是否规范？