测试报告怎么写才有决策价值¶
一、三页报告换不来一个决定¶
一份真实报告的开头（原文照抄）：
一、测试概述
本次测试于 9 月 8 日开始，9 月 13 日结束，参与人员 3 人，共设计用例 336 条。
二、测试执行情况
执行用例 328 条，执行率 97.6%，通过 316 条，通过率 96.3%。
三、缺陷情况
共发现缺陷 47 个，其中严重 2 个，一般 25 个，轻微 20 个，已修复 43 个。
四、总结
本次测试基本完成，系统功能基本可用，建议后续持续关注。
发出去之后，群里第一个问题不是「哪个缺陷没修」，而是：
报告写了三页，没有回答「能不能上线、风险是什么、需要谁决定」。这就是流水账：只有过程数据，没有判断。
测试报告的本质是风险说明书：用数据支撑一个可执行的建议，并让读的人知道要做什么决定。
二、结论先行：一页纸结构¶
第一屏只放四件事（BLUF：Bottom Line Up Front）：
| 要素 | 回答什么 | 示例 |
|---|---|---|
| 结论 | 可上线 / 有条件上线 / 不可上线 | 有条件上线 |
| 依据 | 3 条以内硬数据 | P0/P1 已清零；核心用例通过率 99.2%；压测 P95 1.82s 优于基线 |
| 剩余风险 | 具体到场景与影响 | 导出任务在 1 万行以上偶发超时（3/50），影响运营导出，不影响用户下单 |
| 决策请求 | 谁、在什么时间前、决定什么 | 请 @pm-zhang 在 9-14 18:00 前确认是否接受该 P2 上线后修复 |
决策只有三档，写清楚就不容易被反复追问：
| 档位 | 判定条件 | 必须附带 |
|---|---|---|
| 可上线 | P0/P1=0，准出项全绿，无已知高风险 | 灰度与观察计划 |
| 有条件上线 | P0/P1=0，但存在 P2 或有明确限制 | 条件、责任人、验证方式、兜底开关 |
| 不可上线 | 存在未关闭 P0/P1，或核心指标不达标 | 阻塞项、修复预估、复测条件 |
「基本可用」「持续关注」不属于任何一档，属于没结论。
三、三段式摘要：同一份报告，三种读者¶
管理者、研发、产品关注点不同，摘要要分开写，每段 3~5 行。
给管理者（成本、风险、决策）¶
结论：建议 9-15 有条件上线（灰度 10% → 50% → 100%）。
依据：P0/P1 已全部关闭；336 条用例执行 328 条，末次通过率 96.3%；
压测 P95 1.82s（基线 2.0s），错误率 0.02%。
风险：2 个 P2 遗留（导出超时、券列表分页重复），均有开关可降级，不影响交易主链路。
需要决策：是否接受 P2 上线后 48 小时内修复；若要求上线前清零，发布需顺延 1 天。
给研发（改了什么、哪里没测、遗留项）¶
本次覆盖：退款全链路（含部分退款、审批、回调幂等）、订单状态新增 PARTIAL_REFUNDED、券分摊计算。
未覆盖：IE11 兼容（环境不具备）、第三方支付沙箱的退款到账时延（依赖方限制）。
遗留缺陷：QALAB-231 导出任务 1 万行以上超时（P2，超时阈值 30s，建议先调到 60s）；
QALAB-245 券列表第 2 页重复 1 条（P2，前端分页游标问题）。
回归建议：退款相关改动集中在 RefundCalculator，建议发布后重点观察退款失败率与对账差异。
给产品（用户可见变化、文案、运营影响）¶
用户可见：订单详情新增「部分退款」状态；退款到账文案改为「1-3 个工作日」。
运营影响：后台新增退款审批入口，客服额度 10000 元，超出需财务审批。
已知问题：导出 Excel 超过 1 万行会超时，运营建议分批次导出（每批 5000 行）。
上线节奏：9-15 10:00 灰度 10%，观察 30 分钟后放量至 50%，16:00 全量。
三段摘要不是把正文复制三遍，而是同一组事实的不同切面，数字必须一致。
四、真实版本报告骨架¶
| 章节 | 目的 | 必填内容 | 建议篇幅 |
|---|---|---|---|
| 1 结论与决策请求 | 让人 10 秒内知道能不能发 | 档位、3 条依据、风险、决策人与截止时间 | 半页 |
| 2 测试范围 | 界定「测了什么、没测什么」 | 覆盖模块、变更点、未覆盖项及原因 | 半页 |
| 3 执行情况 | 证明测试做完了 | 计划/执行/通过/跳过、自动化占比 | 1/3 页 |
| 4 缺陷分析 | 证明风险可控 | 级别分布、模块分布、遗留项、重开率 | 1 页 |
| 5 专项结论 | 性能、安全、兼容 | 指标 vs 基线、漏洞等级、兼容矩阵 | 半页 |
| 6 风险与依赖 | 说明不确定性 | 环境差异、第三方依赖、数据限制 | 半页 |
| 7 发布方案 | 怎么发、怎么退 | 灰度比例、观察指标、回滚步骤与耗时 | 半页 |
| 8 附录 | 可下钻 | 用例清单、缺陷清单、日志与报告链接 | 不限 |
4.1 结论段（节选）¶
结论：有条件上线（Conditional Go）
版本：order-service v2.3.0 / web 2.18.0
发布窗口：2026-09-15 10:00
依据
1. P0/P1 缺陷 0 条未关闭（QALAB-201、QALAB-207 已复验通过）。
2. 核心交易链路用例 118/118 通过；全量末次通过率 96.3%（316/328）。
3. 压测 P95 1.82s、错误率 0.02%，均优于基线（2.0s / 0.1%）。
剩余风险
- QALAB-231：导出任务超过 1 万行时超时（3/50 次），运营功能，有分批导出绕过方案。
- QALAB-245：券列表第 2 页重复 1 条，展示问题，不影响领券与核销。
条件（缺一不可）
1. QALAB-231 的上限由 30s 调整为 60s，并在灰度环境回归通过 —— @dev-li，9-14 18:00 前。
2. 灰度 10% 观察 30 分钟，退款失败率 >0.5% 立即回滚 —— @ops-wang。
3. P2 修复版本 2.3.1 于 9-17 前发布 —— @pm-zhang 确认。
4.2 范围段（节选）¶
| 类型 | 内容 | 说明 |
|---|---|---|
| 覆盖 | 退款全链路、订单状态、券分摊、后台审批 | 对应变更点 12 个 |
| 覆盖 | 接口 46 个（新增 3、变更 9） | 含契约测试 |
| 未覆盖 | IE11 兼容 | 测试环境无 IE11，按流量 0.3% 接受风险 |
| 未覆盖 | 第三方退款到账时延 | 沙箱不支持，改为生产灰度观察 |
| 不适用 | 性能容量 | 本版本无容量变化，复用 2.2.0 压测结论 |
「未覆盖」必须写原因和替代验证手段。只写「未覆盖」三个字，等于把风险藏起来。
4.3 执行段（节选）¶
| 指标 | 数值 | 口径 |
|---|---|---|
| 计划用例 | 336 | 用例基线 v3 |
| 已执行 | 328 | 不含跳过 8 条 |
| 执行率 | 97.6% | 328 / 336 |
| 末次通过 | 316 | 重跑通过按末次计 |
| 末次通过率 | 96.3% | 316 / 328 |
| 跳过 | 8 | IE11 2 条、第三方沙箱 6 条 |
| 自动化用例 | 128 | 占 38.1% |
| 自动化执行占比 | 39.0% | 128 / 328 |
4.4 缺陷段（节选）¶
| 级别 | 发现 | 关闭 | 遗留 | 遗留说明 |
|---|---|---|---|---|
| P0 | 2 | 2 | 0 | - |
| P1 | 6 | 6 | 0 | - |
| P2 | 20 | 17 | 3 | 导出超时、分页重复、通知延迟 |
| P3 | 19 | 18 | 1 | 文案 |
| 合计 | 47 | 43 | 4 | 均有 owner 与目标版本 |
补充三个数：
- 缺陷密度：
47 / 23.1 KLOC = 2.03 条/KLOC（未加权；加权口径见质量度量篇）。 - 重开率：
3 / 43 = 7.0%，重开的 3 条均为「修复未覆盖相邻分支」。 - 缺陷发现阶段：提测前 11 条（23.4%）、提测后 30 条（63.8%）、回归期 6 条（12.8%）。
4.5 性能段（节选）¶
| 场景 | 并发 | TPS | P95 | P99 | 错误率 | 基线 | 结论 |
|---|---|---|---|---|---|---|---|
| 下单预览 | 200 | 412 | 182 ms | 310 ms | 0.00% | P95 ≤300 ms | 通过 |
| 提交订单 | 100 | 186 | 1.82 s | 2.94 s | 0.02% | P95 ≤2.0 s | 通过 |
| 退款申请 | 50 | 96 | 640 ms | 1.21 s | 0.01% | P95 ≤800 ms | 通过 |
| 退款查询 | 200 | 520 | 210 ms | 402 ms | 0.00% | P95 ≤300 ms | 通过 |
压测环境：4C8G × 2 实例，MySQL 8.0 主从，Redis 7.2 单节点。环境与生产不同构的部分要写在表下，否则性能结论不可信。
4.6 发布方案段（节选）¶
灰度：10%（按用户 ID 尾号 0-9）→ 观察 30 分钟 → 50% → 观察 30 分钟 → 100%
观察指标：退款失败率（阈值 0.5%）、下单 P95（阈值 2.0s）、5xx 率（阈值 0.1%）、
退款单量（同比昨日 ±40%）
回滚：开关 refund.partial.enabled=false（5 分钟生效）；镜像回滚
kubectl rollout undo deploy/order-service -n prod（实测 3 分 40 秒）
数据：refund_item 表只增不删，回滚不回删数据
五、指标口径：分母不写清，数字就是噪音¶
| 指标 | 公式 | 口径细节 | 常见错误 |
|---|---|---|---|
| 用例执行率 | 已执行 / 计划 | 跳过是否计入计划？本例计入计划、不计入已执行 | 把跳过算作已执行，执行率虚高 |
| 通过率 | 末次通过 / 已执行 | 必须声明「末次执行」 | 用「任一次通过」，重跑刷通过率 |
| 缺陷密度 | 缺陷数 / KLOC | 是否加权、代码范围 | 分母混入生成代码 |
| 遗留缺陷 | 未关闭数 | 按级别 + 影响 + owner + 目标版本 | 只报总数，不报级别 |
| 重开率 | 重开单数 / 关闭数 | 一单多次重开算 1 | 按次数算，指标虚高 |
| RT | P95 / P99 | 场景、并发、数据集必须一致 | 只报平均值 |
| 错误率 | 失败请求 / 总请求 | 区分业务失败与系统错误 | 把 4xx 业务校验算成错误 |
「通过率 96.3%」这句话本身不完整。完整的表述是：
两个数都写，避免被追问时临时换算。
性能指标同理，必须带「场景 + 并发 + 数据集 + 环境」四要素：
只写「响应时间 1.8 秒」，无法判断是否达标。
六、图表选择¶
报告里至少要有一张「趋势」和一张「分布」，其余按需。选择原则：看趋势用折线，看构成用堆叠，看对比用条形，看收敛用双轴。
| 目的 | 用什么 | 不要用 | 原因 |
|---|---|---|---|
| 8 周缺陷/逃逸趋势 | 折线图（双线：发现、关闭） | 饼图 | 饼图无法表达时间 |
| 缺陷按模块分布 | 横向条形图 | 3D 饼图 | 条形长度可直接比较 |
| 缺陷按级别构成 | 100% 堆叠柱 | 分离饼图 | 看占比随版本变化 |
| 执行进度 | 累计曲线（计划 vs 实际） | 仪表盘 | 仪表盘没有过程信息 |
| 收敛判断 | 双轴：柱状新增/关闭 + 折线累计未关闭 | 单一总量折线 | 总量掩盖新增与关闭的差 |
| 性能分布 | P50/P95/P99 表格 + 箱线图 | 平均值折线 | 平均值掩盖长尾 |
| 用例执行/通过 | 分组条形（计划/执行/通过） | 词云 | 无信息量 |
三条硬规则：
- 一张图只回答一个问题，标题写成结论，例如「2.3.0 提测后新增缺陷连续 4 天下滑」，而不是「缺陷趋势图」。
- 图上标出阈值线，例如 P95 基线 2.0s、CFR 15%。
- 图必须能下钻，附录里给出对应的用例 ID 或缺陷 key，否则无法行动。
七、怎么写「不建议上线」¶
结构固定六段：结论 → 硬依据（≥3 条）→ 影响量化 → 备选方案 → 复测条件 → 决策请求。
结论：不建议按原计划 9-15 上线，建议延期至 9-18。
依据
1. P1 未关闭 3 条：QALAB-301 部分退款金额少退（必现 5/5）、QALAB-305 退款回调重复核销、
QALAB-309 审批通过后状态不再流转。三者均在核心资金链路。
2. 提交订单压测 P95 从 1.82s 升至 2.63s（+44%），超过基线 2.0s；错误率 0.02% → 0.31%。
定位到 RefundService 同步调用对账接口，阻塞主线程 380ms。
3. 回滚未验证：refund_item 表新增外键，回滚脚本执行失败（ERROR 1217: Cannot delete
or update a parent row），预计回滚耗时 >30 分钟，超过 10 分钟红线。
影响量化
- 若带上述问题上线：预计每万笔退款出现 3~5 笔金额错误，按日均 1400 笔估算，日影响 0.4~0.7 笔，
单笔平均 90 元；重复核销可能导致券二次使用，资损不可逆。
- 若延期 3 天：市场活动 9-16 的退款承诺无法兑现，预计客诉 200+。
备选方案
A. 延期至 9-18，修完 3 个 P1 + 修回滚脚本（推荐）。
B. 9-15 只上线查询类改动，退款写路径用开关关闭（需产品确认活动文案）。
C. 带开关上线，但把退款入口仅开放给内部账号 24 小时（可验证真实流量）。
复测条件
- 3 个 P1 关闭并在 2.3.1-rc1 复验通过；
- 压测 P95 ≤2.0s、错误率 ≤0.1%；
- 回滚演练 ≤10 分钟，脚本在预发环境实际执行成功。
决策请求
请 @cto-liu 在 9-14 20:00 前选择 A/B/C；若选 A，需市场同步调整 9-16 的活动文案。
写法要点：
| 要点 | 差写法 | 好写法 |
|---|---|---|
| 依据 | 「存在较多问题」 | 具体 key + 复现率 + 指标数值 + 阈值 |
| 影响 | 「影响用户体验」 | 影响笔数/金额/客诉量，给计算过程 |
| 方案 | 「建议延期」 | A/B/C 三个方案及各自代价 |
| 请求 | 「请领导决定」 | 指定人、时间点、决定内容 |
不要用「风险较大」这种无法反驳也无法执行的表述。每一个「风险」后面必须跟一个数字或一个可验证事实。
八、流水账反例与改写¶
| 段落 | 流水账原文 | 问题 | 改写 |
|---|---|---|---|
| 概述 | 「本次测试从 9 月 8 日到 9 月 13 日」 | 时间不是结论 | 「结论：有条件上线，2 个 P2 不影响主链路」 |
| 执行 | 「执行 328 条，通过 316 条」 | 没有分母口径与跳过原因 | 「执行率 97.6%（328/336），跳过 8 条：IE11 2、沙箱 6」 |
| 缺陷 | 「发现 47 个，修复 43 个」 | 不区分级别与遗留风险 | 「P0/P1 清零；遗留 4 条 P2/P3，均有 owner 与目标版本」 |
| 性能 | 「性能测试通过」 | 没有指标与基线 | 「提交订单 P95 1.82s，基线 2.0s，错误率 0.02%」 |
| 风险 | 「存在一定风险，建议关注」 | 无法行动 | 「导出 >1 万行超时，3/50，建议阈值 30s→60s，@dev-li 9-14 前」 |
| 总结 | 「系统基本可用」 | 不是决策 | 「建议灰度 10%，退款失败率 >0.5% 回滚」 |
同一份数据，改写后页数更少，但每个数字都能支撑一个动作。
九、可直接复制的 Markdown 模板¶
# 订单 v2.3.0 测试报告
> 结论：有条件上线 ｜ 报告人：@qa-wang ｜ 日期：2026-09-14 ｜ 版本：v2.3.0
## 1. 结论与决策请求
- **结论**：有条件上线（灰度 10% → 50% → 100%）
- **依据**
1. P0/P1 未关闭 0 条
2. 核心链路用例 118/118 通过；全量末次通过率 96.3%（316/328）
3. 提交订单 P95 1.82s（基线 2.0s），错误率 0.02%
- **剩余风险**：QALAB-231 导出超时（P2，有绕过）；QALAB-245 分页重复（P2，展示层）
- **决策请求**：@pm-zhang 于 9-14 18:00 前确认 P2 上线后修复
## 2. 测试范围
| 类型 | 内容 | 说明 |
| --- | --- | --- |
| 覆盖 | 退款全链路、订单状态、券分摊、审批 | 变更点 12 个 |
| 未覆盖 | IE11 兼容 | 环境不具备，流量 0.3%，接受风险 |
| 未覆盖 | 第三方到账时延 | 沙箱限制，改为灰度观察 |
| 不适用 | 容量 | 无容量变化，复用 2.2.0 结论 |
## 3. 执行情况
| 指标 | 数值 | 口径 |
| --- | --- | --- |
| 计划 / 执行 / 跳过 | 336 / 328 / 8 | 跳过：IE11 2、沙箱 6 |
| 执行率 | 97.6% | 328 / 336 |
| 末次通过率 | 96.3% | 316 / 328 |
| 自动化占比 | 38.1% | 128 / 336 |
## 4. 缺陷
| 级别 | 发现 | 关闭 | 遗留 |
| --- | --- | --- | --- |
| P0 | 2 | 2 | 0 |
| P1 | 6 | 6 | 0 |
| P2 | 20 | 17 | 3 |
| P3 | 19 | 18 | 1 |
- 缺陷密度：2.03 条/KLOC（47 / 23.1 KLOC，未加权）
- 重开率：7.0%（3/43）
- 遗留清单：见附录 B，含 owner 与目标版本
## 5. 性能与安全
| 场景 | 并发 | P95 | 错误率 | 基线 | 结论 |
| --- | --- | --- | --- | --- | --- |
| 提交订单 | 100 | 1.82 s | 0.02% | ≤2.0 s | 通过 |
| 退款申请 | 50 | 640 ms | 0.01% | ≤800 ms | 通过 |
- 安全：高危 0，中危 2（已有豁免单 SEC-11、SEC-12）
## 6. 风险与依赖
| 风险 | 等级 | 影响 | 措施 | Owner |
| --- | --- | --- | --- | --- |
| 导出超时 | P2 | 运营导出失败 | 阈值 30s→60s，分批导出 | @dev-li |
| 分页重复 | P2 | 展示重复 | 2.3.1 修复 | @dev-chen |
## 7. 发布方案
- 灰度：10% → 30 分钟 → 50% → 30 分钟 → 100%
- 观察：退款失败率 <0.5%、下单 P95 <2.0s、5xx <0.1%
- 回滚：开关 refund.partial.enabled=false（5 分钟）；镜像回滚（实测 3 分 40 秒）
- 数据：refund_item 只增不删
## 8. 附录
- A 用例清单：<链接>
- B 缺陷清单：<链接>
- C 压测报告：<链接>
- D 安全扫描：<链接>
模板里所有 <链接> 都必须是可访问地址，发外发版本时替换为脱敏后的静态页。
十、发布后回填¶
报告不是发布即结束，24 小时和 72 小时要回填两段：
## 9. 上线观察（回填）
### 24 小时
- 灰度 100% 完成时间：9-15 16:20
- 退款失败率：0.12%（阈值 0.5%）
- 下单 P95：1.74s（基线 2.0s）
- 5xx 率：0.01%
- 新增线上缺陷：1 条（QALAB-260，券列表分页重复未完全修复，P3）
### 72 小时
- 退款量：4210 笔，失败 5 笔（0.12%），均为渠道超时，已自动重试成功
- 对账差异：0
- 结论：风险可控，QALAB-260 并入 2.3.1
逃逸缺陷按统一口径登记，否则季度统计无法复用：
project = QALAB AND type = 缺陷 AND environment = "prod"
AND created >= "2026-09-15" AND created < "2026-10-15"
AND fixVersion = "2.3.0"
归档命名固定为 {版本}-测试报告-{发布日期}.md，并附一个 metrics.json（执行率、通过率、遗留数、逃逸数），方便季度汇总时直接读取，而不是再从文档里抠数字。
十一、检查清单¶
- 第一屏有结论、3 条依据、剩余风险、决策人与截止时间
- 结论是三档之一，没有「基本通过」「持续关注」
- 执行率与通过率都写了分子分母，跳过原因已列
- 通过率注明「末次执行」口径
- 遗留缺陷按级别列出，每条有 owner 与目标版本
- 未覆盖项写了原因与替代验证手段
- 性能指标带场景、并发、数据集、环境、基线
- 安全结论区分高危与中危豁免
- 回滚方案有开关名与实测耗时
- 每个风险都能量化到笔数/金额/耗时
- 「不建议上线」给出了 A/B/C 备选方案与复测条件
- 发布后 24h/72h 已回填，逃逸缺陷已登记