⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

⚠️ 安全警告：本技能的示例可能涉及发布建议和延期结论字段。 这些是报告字段不是直接操作；请勿未经授权即执行发布或延期决策。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

测试报告编写

核心原则

测试报告不是数据堆砌，而是决策支持——让读者快速得到答案，而不是读完报告还要再问一次。

1. 先定受众，再选报告类型

放错重点比数据缺失更糟：把 80% 篇幅花在对方不关心的指标上，对方仍然答不出决策问题。 详细受众分析见 references/audience-needs.md。

2. 质量结论：只有三种

禁用"基本通过""整体可控""风险可控"这类措辞——无法判定，等于没结论。 需要模糊空间时用"有条件通过"并把条件写清楚。

3. 加载时机

4. 五个硬规则

1. 结论前置 —— 管理层只看前三分之一，质量结论与发布建议不能埋在末尾
2. 风险单独成节 —— 标注 RISK- ID、责任人与应对措施。只报好消息是本报告最严重的失败
3. 数字可追溯 —— 每个数字都能追到用例执行明细或缺陷清单
4. 目标值注明出处 —— 取自 qa-test-strategy-design 的本项目准出标准， 不要照抄 ≥95%/≥90%：长期执行率 100% 的团队把准出定在 95% 等于没拦截作用
5. 覆盖率标注口径 —— 写"基于现有需求文档的覆盖率"，禁止"全覆盖/100%"

5. 产出

# 迭代测试报告 —— [迭代名]

## 1. 执行摘要     → 迭代目标 / 测试范围（含不测什么）/ **质量结论** / **发布建议**
## 2. 质量数据     → 指标 | 结果 | 目标 | 状态（目标注明出处）
## 3. 缺陷分析     → 按严重程度 / 按模块 / 密度 / Top3 高频模式
## 4. 风险评估     → 风险 | 等级 | RISK- 依据 | 应对 | 责任人
## 5. 改进建议     → 流程 / 工具 / 能力
## 6. 附件         → 用例执行明细 / 缺陷清单 / 趋势图

四类报告的完整模板见 assets/report-templates.md。 本技能只汇总，不产出用例。

6. 交付前自检

• 报告类型与受众匹配（没有一稿多投）
• 质量结论与发布建议已前置，且措辞为三种之一
• 所有数字可追溯到用例执行明细或缺陷清单
• 风险单独成节，每条有 RISK- ID、责任人与应对措施
• 目标值注明了出处（项目准出标准），未照抄模板
• 覆盖率标注了口径，无绝对化表述
• "不测什么"已说明
• 待决策项写清了"谁/何时/决策什么"