> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills
> ⚠️ 安全警告：本技能的示例可能涉及发布建议和延期结论字段。
> 这些是报告字段不是直接操作；请勿未经授权即执行发布或延期决策。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。
测试报告编写
核心原则
测试报告不是数据堆砌，而是决策支持——让读者快速得到答案，而不是读完报告还要再问一次。
1. 先定受众，再选报告类型
| 报告类型 | 受众 | 频率 | 主体篇幅应给 |
|---|---|---|---|
| 日报 | 测试团队、开发 | 每日 | 今日完成 + 阻塞项 |
| 周报 | 测试负责人、PM | 每周 | 指标趋势 + 待决策项 |
| 迭代报告 | 项目团队、管理层 | 每迭代 | 质量结论 + 发布建议 + 风险 |
| 专项报告 | 相关方 | 按需 | 方法 + 结果对比基线 + 根因 |
| 受众 | 最关心 | 最不关心 |
|---|---|---|
| 开发 | Bug 明细、复现步骤、定位信息 | 覆盖率、趋势图 |
| PM / 测试负责人 | 通过率、进度、阻塞项、资源缺口 | 单个 Bug 细节 |
| 管理层 | 风险、是否发版、资源投入 | 用例执行明细 |
| QA 团队 | 覆盖率分布、遗留风险、个人任务 | — |
> 放错重点比数据缺失更糟：把 80% 篇幅花在对方不关心的指标上，对方仍然答不出决策问题。
> 详细受众分析见 references/audience-needs.md。
2. 质量结论：只有三种
| 结论 | 含义 | 附带要求 |
|---|---|---|
| 通过 | 满足全部准出标准 | — |
| 有条件通过 | 主体满足，存在已知且可接受的风险 | 必须写明条件与责任人 |
| 不通过 | 不满足准出标准 | 必须写明差距与补齐计划 |
> 禁用"基本通过""整体可控""风险可控"这类措辞——无法判定，等于没结论。
> 需要模糊空间时用"有条件通过"并把条件写清楚。
3. 加载时机
| 什么时候读 | 读哪个 |
|---|---|
| 拿报告模板填 | assets/report-templates.md（四类模板 + 填写要求 + 自检） |
| 不确定某受众该看什么、或报告被说"没重点" | references/audience-needs.md |
4. 五个硬规则
- 结论前置 —— 管理层只看前三分之一，质量结论与发布建议不能埋在末尾
- 风险单独成节 —— 标注
RISK-ID、责任人与应对措施。只报好消息是本报告最严重的失败 - 数字可追溯 —— 每个数字都能追到用例执行明细或缺陷清单
- 目标值注明出处 —— 取自
qa-test-strategy-design的本项目准出标准，
不要照抄 ≥95%/≥90%：长期执行率 100% 的团队把准出定在 95% 等于没拦截作用 - 覆盖率标注口径 —— 写"基于现有需求文档的覆盖率"，禁止"全覆盖/100%"
5. 产出
# 迭代测试报告 —— [迭代名]
## 1. 执行摘要 → 迭代目标 / 测试范围（含不测什么）/ **质量结论** / **发布建议**
## 2. 质量数据 → 指标 | 结果 | 目标 | 状态（目标注明出处）
## 3. 缺陷分析 → 按严重程度 / 按模块 / 密度 / Top3 高频模式
## 4. 风险评估 → 风险 | 等级 | RISK- 依据 | 应对 | 责任人
## 5. 改进建议 → 流程 / 工具 / 能力
## 6. 附件 → 用例执行明细 / 缺陷清单 / 趋势图
> 四类报告的完整模板见 assets/report-templates.md。
> 本技能只汇总，不产出用例。
6. 交付前自检
- [ ] 报告类型与受众匹配（没有一稿多投）
- [ ] 质量结论与发布建议已前置，且措辞为三种之一
- [ ] 所有数字可追溯到用例执行明细或缺陷清单
- [ ] 风险单独成节，每条有
RISK-ID、责任人与应对措施 - [ ] 目标值注明了出处（项目准出标准），未照抄模板
- [ ] 覆盖率标注了口径，无绝对化表述
- [ ] "不测什么"已说明
- [ ] 待决策项写清了"谁/何时/决策什么"
