推荐语
性能报告撰写不再头痛，一份数据自动生成四类视图，5类冲突自动拦截。
核心内容：
1. 性能测试报告自动生成的痛点与解决方案
2. 工具的核心功能：4类受众视图与5类冲突拦截
3. 标准化的输入输出契约与交付流程
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
性能测试工程师的痛点
凌晨 4 点，业务方要 1 页结论、研发要完整瓶颈、运维要容量方案、领导要 1 行字定生死。
4 份完全打架的需求，写 4 份独立文档，4 小时起步，最怕的是写完了发现”前后矛盾”被业务方追着对质。
报告”难写”不是能力问题，是工具问题。
答案很简单：**一份数据 + 4 套裁剪视图 + 5 类冲突自动拦截**。
今天这篇，我们用**perf-report-writer skill 把 4 份报告的活儿压到 30 分钟。**
* * *
## **一、这个 Skill 是什么：性能测试报告生成器**
`perf-report-writer`是性能测试闭环的**交付阶段 Skill,**位于`perf-report-analyzer`（报告分析）之后、风险台账与压测计划回流之前，是**把”原始压测数据”变成”标准化交付物”的核心枢纽**。
**定位**：
把”原始压测数据”变成”4 类受众 × 3 种报告类型 = 12 种组合”的标准化交付物生成器，配套 5 类数据冲突自动拦截 + Pass with risk 二级判定。
**触发时机**（最常踩的几个）：
* 性能测试闭环的**交付阶段**，`perf-report-analyzer`输出之后
* **上线评审会议前 24 小时**
* **大促 / 发布前 1 周**（618、双 11、年货节）
* **领导汇报前 1 天**（突然被点名要材料）
**与`perf-report-analyzer`的边界**：
* `perf-report-analyzer`：负责**数据 → 结论**（瓶颈定位 + 根因 + 优化建议）
* `perf-report-writer`（本篇主角）：负责**结论 → 文档**（结构化报告 + 受众视图 + 交付物）
**输入契约**：
* 必填：analyzer 输出结论 + JMeter 原始指标 + SLA 阈值 + 报告类型 + 受众视图
* 选填：历史基线报告、生产环境配置、容量预估、上下游监控数据
**输出契约**：
* 10 大模块标准报告 + 4 类受众视图（HTML / Markdown）
* 5 件套交付物：报告 + 指标汇总表 + 缺陷清单 + Checklist + 数据附件说明
* JSON 协议`perf-reports/standard/v1`，上下游 Skill 可直接消费
* * *
## **二、核心亮点：4 件硬通货**
### **亮点 1：4 类受众视图自动裁剪（4 × 3 = 12 种组合）**
**3 种报告类型**（总结 / 回归 / 发布验收） ×**4 类视图**=**12 种组合**，每种都对应真实工作场景。
**核心设计思路**：不是”一份报告分发给 4 个人”，而是”同一份数据，4 套裁剪逻辑”。
图1：4 类受众视图 × 3 种报告类型 = 12 种组合 裁剪逻辑
### **亮点 2：5 类数据冲突自动拦截**
性能报告最怕”前后矛盾”，analyzer 说”CPU 不是瓶颈”，但监控显示 CPU 95%，业务方拿着两份结论互相对质。
这个skill在生成前**自动跑 5 类冲突检测**，触发即标红 / 标黄 / 追加备注，**禁止裸出报告**：
| | **冲突类型** | **检测逻辑** | **触发后** |
| — | — | — | — |
| 1 | 资源-瓶颈不一致 | 监控 CPU > 80% 且瓶颈分析未提及 | 强制人工确认 |
| 2 | 指标-结论矛盾 | 错误率 > SLA 但结论写 Pass | 直接标红，禁止生成 |
| 3 | 基线-数据矛盾 | 声称指标提升但实际下降 | 强制要求说明 |
| 4 | 容量-环境矛盾 | 容量评估无环境差异说明 | 标黄，强制补全 |
| 5 | 优化-数据缺失 | 优化建议无预期收益数据 | 标黄，提示补全 |
图2：跨 Skill 数据一致性校验 5 类冲突拦截流程
### **亮点 3：Pass with risk 二级判定矩阵**
这个skill把”能不能带病上线”这件事彻底工程化：
核心 / 非核心接口 SLA 分离：核心接口（支付 / 订单 / 库存）不达标**直接 Fail**；非核心接口（日志 / 统计 / 推送）轻微超标（< 20%）**归为 Pass with risk 低风险**。 **只要风险可量化、可兜底、可监控，就敢明确说”可带病上线”,**这是性能工程师背书能力的分水岭。
图3：Pass / Fail 二级判定矩阵决策树
### **亮点 4：性能专项双向联动 + 统一 JSON 协议**
* **接收**`perf-report-analyzer`瓶颈结论 +`perf-test-planner`测试策略 +`perf-jmx-generator`场景配置 +`perf-data-builder`数据量配置
* **反向输出**到`perf-test-planner`（下轮压测场景）、`perf-requirement-clarifier`（新发现的性能需求）、`bug-report-writer`（性能 Bug 模板）
* **统一JSON协议**`perf-reports/standard/v1`——perf 全链路 7 个 Skill 标准化数据交换格式，**报告不是”写完就完”，是”下一个动作的起点”**
* **链路容错**：上游 analyzer 无输出时，自动切换”纯指标推理模式”，基于 TPS / CPU / RT 数据做简易瓶颈描述，**不会空白**
* * *
## **三、能解决什么问题：4 个真实工作场景**
### **场景 1：凌晨 4 点 4 个受众同时催报告**
**痛点**：业务方要 1 页结论、研发要完整瓶颈、运维要容量方案、领导要 1 行字定生死，4 份独立文档写 4 小时起步。
**perf-report-writer 解法**：1 份原始数据 → 4 套裁剪视图，30 分钟出 4 份定制报告。
### **场景 2：报告”前后矛盾”，业务方质疑数据真实性**
**痛点**：analyzer 说”CPU 不是瓶颈”，但监控显示 CPU 95%，业务方拿着两份结论互相对质。
**perf-report-writer 解法**：5 类冲突自动拦截，生成前直接标红”CPU 高负载未纳入瓶颈分析”，强制人工确认后才能生成。
### **场景 3：性能工程师不敢背书”带病上线”**
**痛点**：SLA 全部达成但有 P1 风险，老板问”能不能上”，工程师不敢说”能”，业务方不敢说”上”，最后靠拍脑袋决定。
**perf-report-writer 解法**：Pass with risk 二级细分 + 核心 / 非核心接口 SLA 分离，**只要风险可量化、可兜底、可监控，就敢明确说”可带病上线”**。
### **场景 4：报告交完就”断链”，优化建议和下轮压测脱节**
**痛点**：报告里的优化建议写在 PPT 第 30 页，研发看一眼就关掉了，下轮压测和上轮的瓶颈完全是两回事。
**perf-report-writer 解法**：报告自动反向输出到 perf-test-planner 生成下轮压测计划、反向输出到 perf-requirement-clarifier 追加性能需求，**报告 → 计划 → 下轮压测，链路闭环**。
* * *
## **四、怎么使用：5 步跑完一份 4 视图报告**
**1****准备输入数据**
按 perf-report-writer 的”输入契约”准备，**缺失信息按 P0 / P1 / P2 三级问询**：
**2****选择报告类型 + 受众视图**
* 报告类型：**总结 / 回归 / 发布验收**（3 选 1）
* 受众视图：**技术 / 产品 / 运维 / 高管**（4 选 1，可同时输出 4 份）
**3****自动生成 + 冲突拦截**
perf-report-writer 在生成过程中**自动跑 5 类冲突检测**，任何一类冲突触发都会**自动标红 / 标黄 / 追加备注**，**禁止裸出报告**。
**4****导出 5 件套交付物**
* 标准化 Markdown 报告
* HTML 4 视图（技术 / 产品 / 运维 / 高管）
* 指标汇总表（可复制 Excel）
* 缺陷清单
* 上线 Checklist 6 层
* 数据附件说明
**5****双向联动**
报告交付后，自动识别”下一轮回归压测场景”和”新发现的性能需求”：
* **回流到 perf-test-planner**：下轮压测场景 + 验证目标
* **回流到 perf-requirement-clarifier**：新发现的性能需求追加到下季度需求池
* **回流到 bug-report-writer**：性能 Bug 一键生成模板
* * *
## **五、电商案例讲解：30 分钟交 4 份报告**
### **5.1 背景**
* 项目：电商订单
* 版本：v6.18.0
* 测试周期：2026-06-11 ~ 2026-06-15
* 报告类型：**发布验收**
* 受众视图：4 类同时输出
生成文件如下：
### **5.2 准备输入**
* analyzer 输出：2 条 P1 风险（库存表全表扫描、分布式锁粒度过粗）
* JMeter 原始数据：8,287,867 请求 / 6000 并发 / 23 分钟
* SLA 阈值：订单 P95 ≤ 800ms、错误率 ≤ 0.5%、TPS ≥ 5000
* 选填：生产环境配置表 + 历史基线报告（v6.11.0）
### **5.3 跑 perf-report-writer 生成 4 份报告**
**给业务方的”精简验收版”**（6 分钟阅读）：
**结论：可上线（带 2 条 P1 风险）**
核心指标达成情况：
* 订单提交 P95：720ms（**SLA 800ms**）
* 支付接口 P95：480ms（**SLA 500ms**）
* 错误率：0.31%（**SLA 0.5%**）
**2 条 P1 风险（建议下个迭代修复，本次可带病上线）**：
* 库存表全表扫描，并发 6000 时 RT 飙升至 720ms（建议加索引）
* 分布式锁粒度过粗，错误率 0.31% 接近 SLA 上限（建议细化锁粒度）
**上线 Checklist**：6 项已勾选 4 项，2 项待运维确认（监控告警 + 限流阈值）
**给研发的”完整技术版”**（30 分钟阅读）：
10 大模块全量，附原始监控曲线、慢 SQL 列表、GC 日志摘录、JVM 内存时序、瓶颈证据链 3 条、优化建议带工时预估和验收指标。
**给运维的”运维汇报版”**（20 分钟阅读）：
聚焦资源容量、扩容方案、监控阈值配置建议、线上风险点、压测数据 vs 生产环境对标表。
**给领导的”高管摘要版”**（30 秒阅读）：
**结论：可上线，带 2 条 P1 风险，下个迭代修复**
**核心风险：库存接口在 6000 并发下 P95 720ms 接近上限，618 峰值预计 8000 并发，需加索引**
### **5.4 冲突拦截演示**
perf-report-writer 在生成前**自动跑 5 类冲突检测，**本次触发了一类：
**【数据冲突提醒】**
perf-report-analyzer 输出的瓶颈分析中**未提及 CPU 瓶颈**，但服务器 CPU 监控峰值 95.3%；
建议核对 perf-report-analyzer 输入是否完整（应用服务器 CPU 时序数据缺失）；
当前报告已自动在第 6 章「瓶颈分析」追加「CPU 高负载风险待核实」备注。
核对后发现，**CPU 监控数据没传进 analyzer**。重新导入后发现：14:08 那一波库存服务 CPU 短暂飙到 97%，刚好是订单 RT 飙到 720ms 的同一时间点。
**库存表全表扫描不仅拖慢了 SQL，也把应用服务器的 CPU 吃满了**
### **5.5 双向联动演示**
报告交付后，perf-report-writer 自动识别”下一轮回归压测场景”和”新发现的性能需求”：
**回流到 perf-test-planner**：
场景 1：库存表加索引后，验证订单 RT 是否从 720ms 降至 400ms 以下
场景 2：分布式锁细粒度化后，验证错误率是否从 0.31% 降至 0.1% 以下
场景 3：618 实际峰值 8000 并发下的真实压测验证
**回流到 perf-requirement-clarifier**：
库存锁失败时的重试机制（当前无重试，6000 并发下失败率 1.2%）
限流阈值需在 6.20 前压测验证（建议阈值：单接口 200 QPS）
**4 份报告共用 1 套原始数据，1 份原始分析结论，1 份冲突拦截日志，3 条回流接口**。
| **维度** | **perf-report-writer （1 份数据 + 4 套视图）** |
| — | — |
| 耗时 | 30 分钟 |
| 数据一致性 | 同一份源数据 + 5 类冲突拦截，绝对自洽 |
| 判定能力 | Pass with risk 二级细分 + 核心/非核心分离 |
| 下轮联动 | 自动回流到 planner / clarifier / bug-writer |
* * *
## **六、总结**
### **价值 1：把 4 份报告的活儿压到 30 分钟**
**”按需出菜”不是抽象理念，是具体的工程能力**：4 类受众视图 × 3 种报告类型 = 12 种组合，每种组合都对应真实工作场景。**报告”长得全”和”读得懂”是两回事**，perf-report-writer 把这两件事彻底分开。
### **价值 2：让性能报告”数据自洽”，不是”格式自洽”**
5 类冲突自动拦截 + 缺失信息分级问询 + 核心 / 非核心接口 SLA 分离 + Pass with risk 二级细分，**让性能工程师敢于背书”带病上线”，只要风险可量化、可兜底、可监控**。
### **价值 3：把报告从”断链”变成”闭环”**
报告 → perf-test-planner（生成下轮压测计划） + 报告 → perf-requirement-clarifier（追加性能需求） + 报告 → bug-report-writer（性能 Bug 模板），**报告不是”写完就完”，是”下一个动作的起点”**。
* * *
## **跨平台通用 Prompt 模板（复制即用）**
### **完整版（正式交付场景）**
`你是资深性能测试报告生成专家，专精 4 类受众视图裁剪、跨 Skill 数据一致性校验、Pass / Fail 二级判定矩阵。# 任务基于我提供的 perf-report-analyzer 输出结论 + JMeter 原始数据，生成 4 类受众视图（技术 / 产品 / 运维 / 高管）的标准化性能报告，自动校验数据自洽性，按核心 / 非核心接口分离判定 SLA，输出 Pass / Pass with risk / Fail 结论。# 我会提供（按需勾选）## 【必填】- [ ] perf-report-analyzer 输出结论- [ ] JMeter 原始数据（CSV / HTML Dashboard / statistics.json）- [ ] SLA 阈值清单- [ ] 报告类型（总结 / 回归 / 发布验收）- [ ] 受众视图（4 选 1，可同时输出 4 份）## 【选填（推荐提供）】- [ ] 历史基线报告（用于多版本对比）- [ ] 生产环境配置表（用于容量对标）- [ ] 容量预估数据（618 / 双 11 峰值）- [ ] 服务器监控 + JVM + 中间件监控- [ ] 上下游监控（DB / Redis / MQ）# 强制输出（缺一不可）1. 跨 Skill 数据一致性校验：5 类冲突自动拦截，输出冲突清单2. 4 类受众视图：技术版（10 模块全量）+ 验收版（SLA + 风险 + 排期）+ 运维版（容量 + 监控）+ 高管版（1 页极简）3. 10 大模块标准结构4. Pass / Fail 判定矩阵：核心 / 非核心接口 SLA 分离 + Pass with risk 二级细分5. 缺失信息分级问询：P0 强制 / P1 可选 / P2 仅标注6. 上下游双向联动接口：报告 → perf-test-planner / perf-requirement-clarifier / bug-report-writer 反向输出7. 5 件套交付物8. JSON 协议（perf-reports/standard/v1）# 触发词性能报告、压测总结、回归报告、发布验收、性能交付、报告生成、Pass with risk、受众视图、性能评审、上线 checklist、perf-report-writer`
### **简易版（快速生成场景）**
你是性能测试报告生成助手。给定 JMeter 报告 + SLA + 报告类型（总结/回归/发布验收），按 4 类受众（技术/产品/运维/高管）各生成 1 份标准化报告，自动校验 5 类数据冲突，输出 Pass/Fail 判定 + 上线 Checklist 6 层。
* * *
专栏目录：
| **篇号** | **主题** | **Skill** |
| — | — | — |
| 第 1 篇 | 需求澄清 | perf-requirement-clarifier |
| 第 2 篇 | 测试计划 | perf-test-planner |
| **第 3 篇** | **数据构造** | **perf-data-builder** |
| 第 4 篇 | 就绪检查 | perf-readiness-checker |
| 第 5 篇 | JMX 脚本 | perf-jmx-generator |
| 第 6 篇 | 报告分析 | perf-report-analyzer |
| 第 7 篇 | 报告生成 | perf-report-writer |
* * *
如果这篇对你有帮助，欢迎随手转发～
开源测试平台Testhub官网地址（内测中）
地址：https://testhub.aisky.cloud/
