一个 Skill 搞定99%测试报告重复工作,单份数据一键产出4套差异化压测(第七篇)

性能测试工程师的痛点

凌晨 4 点，业务方要 1 页结论、研发要完整瓶颈、运维要容量方案、领导要 1 行字定生死。

4 份完全打架的需求，写 4 份独立文档，4 小时起步，最怕的是写完了发现"前后矛盾"被业务方追着对质。

今天这篇，我们用 perf-report-writer skill 把 4 份报告的活儿压到 30 分钟。

一、这个 Skill 是什么：性能测试报告生成器

perf-report-writer 是性能测试闭环的交付阶段 Skill,位于 perf-report-analyzer（报告分析）之后、风险台账与压测计划回流之前，是把"原始压测数据"变成"标准化交付物"的核心枢纽。

定位：

触发时机（最常踩的几个）：

• 性能测试闭环的交付阶段，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 套裁剪逻辑"。

亮点 2：5 类数据冲突自动拦截

性能报告最怕"前后矛盾"，analyzer 说"CPU 不是瓶颈"，但监控显示 CPU 95%，业务方拿着两份结论互相对质。

这个skill在生成前自动跑 5 类冲突检测，触发即标红 / 标黄 / 追加备注，禁止裸出报告：

亮点 3：Pass with risk 二级判定矩阵

这个skill把"能不能带病上线"这件事彻底工程化：

核心 / 非核心接口 SLA 分离：核心接口（支付 / 订单 / 库存）不达标直接 Fail；非核心接口（日志 / 统计 / 推送）轻微超标（< 20%）归为 Pass with risk 低风险。

亮点 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 视图报告

按 perf-report-writer 的"输入契约"准备，缺失信息按 P0 / P1 / P2 三级问询：

• 报告类型：总结 / 回归 / 发布验收（3 选 1）

• 受众视图：技术 / 产品 / 运维 / 高管（4 选 1，可同时输出 4 份）

perf-report-writer 在生成过程中自动跑 5 类冲突检测，任何一类冲突触发都会自动标红 / 标黄 / 追加备注，禁止裸出报告。

• 标准化 Markdown 报告

• HTML 4 视图（技术 / 产品 / 运维 / 高管）

• 指标汇总表（可复制 Excel）

• 缺陷清单

• 上线 Checklist 6 层

• 数据附件说明

报告交付后，自动识别"下一轮回归压测场景"和"新发现的性能需求"：

• 回流到 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 分钟阅读）：

给研发的"完整技术版"（30 分钟阅读）：

给运维的"运维汇报版"（20 分钟阅读）：

给领导的"高管摘要版"（30 秒阅读）：

5.4 冲突拦截演示

perf-report-writer 在生成前自动跑 5 类冲突检测，本次触发了一类：

核对后发现，CPU 监控数据没传进 analyzer。重新导入后发现：14:08 那一波库存服务 CPU 短暂飙到 97%，刚好是订单 RT 飙到 720ms 的同一时间点。

5.5 双向联动演示

报告交付后，perf-report-writer 自动识别"下一轮回归压测场景"和"新发现的性能需求"：

回流到 perf-test-planner：

回流到 perf-requirement-clarifier：

4 份报告共用 1 套原始数据，1 份原始分析结论，1 份冲突拦截日志，3 条回流接口。

六、总结

价值 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 层。