你最近一次做性能测试，从接到需求到输出报告，花了多长时间？
我上个月帮一个业务团队做了一次完整的性能回归验证。完整记录时间后，发现了一个有意思的数字分布：
压测执行本身只占 8%。剩下 92% 的时间，全部花在准备、沟通、整理和写文档上。
这还不是最要命的。真正要命的是这些环节环环相扣，前面一步没踩实，后面全得返工。
踩过的坑
做性能测试这些年，我整理了一个「返工清单」， 每次压测前都会拿出来看一遍，提醒自己别在同一个地方栽两次：
需求阶段
- SLA 没和业务方书面确认，压测完说”响应时间要求不是 500ms 是 200ms”，重跑
- 并发数直接拍脑袋定了 1000，结果是日活用户的 10 倍，测试结论完全失真
- 测试环境数据库是 1C2G，生产是 8C32G，环境差异没评估，结果无法折算
计划阶段
- 场景参数全写的 X，实际填的时候并发数、Ramp-up、持续时间全是凭感觉
- 目标并发 800，单机 JMeter 压到 600 时压测机 CPU 已经 95%，结果失真还不知道
- 100 个测试账号支撑 500 并发跑了 15 分钟，数据耗尽后缓存命中率 100%，TPS 虚高 3 倍
执行阶段
- 没做数据预热，冷缓存下第一次压测 RT 是 warmed-up 状态的 3~5 倍
- 压测写到测试库，污染了其他测试团队的数据
- 第三方接口没做 Mock，对方服务波动导致 RT 抖动，判断不出是自己的问题还是外部问题
报告阶段
- 报告结构每次都不一样，领导问”和上次的报告对比呢”，发现口径不统一
- 容量评估不会写，领导问”现在能支撑多少用户”，答不上来
- 基线对比漏掉，本次优化后到底提升多少、有没有退化，没数据支撑
这些坑的共同点是：和压测工具本身无关，全部是流程和决策层面的问题。
JMeter 你肯定会用。但需求怎么澄清、场景怎么设计、数据量怎么评估、瓶颈怎么定位、容量怎么写，这些才是决定一次压测有没有价值的关键。
这套 Skill 能解决什么
我把性能测试全流程拆成 7 个环节，每个环节做了一个 Skill，用 AI 辅助完成标准化输出。
不是替代你做决策，而是把重复性、模板化的工作压缩到最小，让你把时间花在真正需要专业判断的地方。
7 个 Skill 全景图
这些 Skill 支持的平台
这套 Skill 最初在 WorkBuddy 中开发，但每个 Skill 都提供了跨平台通用 Prompt 模板，你可以直接在以下平台使用：
| 平台 | 使用方式 |
|---|---|
| WorkBuddy | @skill:perf-requirement-clarifier 直接调用，最完整的文件输出和自动化能力 |
| Cursor | 复制 Skill 内置的 Prompt 模板，粘贴到 Chat 或 .cursorrules 文件 |
| Trae | 复制 Prompt 模板到侧边栏 AI 助手，直接对话使用 |
| Claude / ChatGPT / DeepSeek | 新建对话，粘贴 Prompt 模板，继续输入具体需求 |
核心设计：一个文件，多平台使用。
每个 Skill 文件同时包含两部分内容：
- WorkBuddy 专用格式：YAML frontmatter + 完整执行规则，供 WorkBuddy 识别和自动化调用
- 跨平台 Prompt 模板：提取核心流程、SLA 推荐值、负载默认值、验收标准等关键规则，压缩成各平台通用的 Prompt，复制粘贴即可使用
这意味着你不需要为了换平台而重写一套 Prompt。无论在哪个工具里，拿到的输出质量是一致的。
每个 Skill 都有明确的输入、输出和边界，串起来就是完整的性能测试工作流。下面逐个展开每个 Skill 具体能解决什么、输入输出是什么。
P01 需求澄清 — perf-requirement-clarifier
第二节需求阶段的坑，SLA 没书面确认、并发数拍脑袋、环境差异没评估，就是 P01 要解决的。
先说一个真实场景。
周四下午 4 点，你收到消息：明早 10 点压测。
你打开需求文档，发现只有一句话：「对订单接口进行压测，并发 1000。」
你挨个问：
• 开发：「1000 并发是哪里来的？」开发：「业务方说的。」
• 业务方：「1000 是我们峰值，行吗？」你：「峰值持续多久？」业务方：「就…峰值啊。」
• 运维：「测试环境数据库是生产的一半规格，结果要折算吗？」你：「……」
• 开发：「这个接口还调了库存服务和支付网关，你们压吗？」你：「……」晚上 9 点，你还在微信上追着三个人要信息。明早的压测，SLA 没定、环境差异没评估、链路范围没对齐、数据没准备好。
P01 做的事，就是把这种混乱局面，变成一份所有人事前签字确认的标准化需求文档。
怎么使用
触发词：在 WorkBuddy 中输入以下任意一个，Skill 自动启动：
性能需求澄清
压测需求确认
perf requirement clarifier
确认压测目标
三步完成需求澄清：
第一步：把你手里的材料直接扔给它
不用提前整理格式，直接把接口文档、PRD、或者业务方的话复制进去：
「我想对 AIO 平台的用例查询接口做压测，大概有 200 个并发用户，要求 P95 在 500ms 以内」
这就够了。P01 会自动解析接口信息，提取业务场景，识别链路关系，发现缺失字段。
第二步：回答 P01 的补充问题
Skill 会先做前置条件检查，确认 7 项基本条件是否就绪：
任何一项不满足，P01 直接建议暂停，不让你在一个有问题的基础上继续往下走。
检查通过后，P01 会追问几个关键问题：
第三步：拿到输出文件，直接用
P01 不再强制输出 4 个文件，而是根据场景自动判断输出数量：
输出文件说明：
① 需求澄清文档（主文档）
模块固化成 10 大固定章节，编号 ①~⑩，不得遗漏、不得调换顺序：
① 项目基本信息（含 plan_id 命名规范）→ ② 压测目标分类（4 类目标说明）→ ③ 压测范围（接口清单 + 链路拓扑 + 参数场景 + 异常场景）→ ④ 负载模型（按目标类型自动选择）→ ⑤ 全量 SLA 指标 → ⑥ 环境说明（含差异折算）→ ⑦ 验收标准 → ⑧ 前置风险 & 待确认项 → ⑨ 业务约束 → ⑩ 历史基线
文档里最有价值的三个地方：
SLA 推荐值表，业务方说不出 SLA 时，把这个表甩过去。
| 场景类型 | 测试环境 P95 | 生产环境 P95 | 错误率 |
|---|---|---|---|
| 简单查询（单条） | ≤ 300ms | ≤ 200ms | ≤ 0.1% |
| 列表查询（普通分页） | ≤ 800ms | ≤ 500ms | ≤ 0.1% |
| 列表查询（大数据分页） | ≤ 1500ms | ≤ 1000ms | ≤ 0.5% |
| 游标分页 / 深度分页 | ≤ 2000ms | ≤ 1500ms | ≤ 1% |
| 写入操作 | ≤ 800ms | ≤ 500ms | ≤ 0.1% |
| RPC 跨服务调用 | ≤ 1000ms | ≤ 800ms | ≤ 0.5% |
| MQ 异步回调 | ≤ 5000ms | ≤ 3000ms | ≤ 1% |
| 文件上传/下载（<10MB） | ≤ 3000ms | ≤ 2000ms | ≤ 1% |
测试环境阈值比生产放宽 30%~50%，避免直接把测试指标当生产 SLA 用。
环境差异折算公式：测试环境 2C4G，生产环境 4C8G
→ CPU ×1.8，内存 ×1.2
→ 测试环境 TPS=500 → 预估生产 TPS ≈ 500 × 1.8 × 1.2 ≈ 1080负载默认值规则——业务方只给并发不给时长时，P01 自动填充：
| 压测类型 | 默认持续时长 | Ramp-up 默认规则 |
|---|---|---|
| 基线测试 | 5 分钟 | ramp-up = 并发数 / 5（秒），最低 60 秒 |
| 容量规划 | 每阶梯 5~10 分钟 | 每阶梯 ramp-up = 阶梯并发增量 / 5 |
| 稳定性测试 | 12 小时 | ramp-up = 总并发 / 5，最低 5 分钟 |
② 待确认项清单（防甩锅专用，P0/P1 分级）
P01 自动扫描文档里所有「假设/默认值/未验证」的字段，按风险等级分级：
| 序号 | 待确认问题 | 风险等级 | 建议确认人 |
|---|---|---|---|
| 1 | 并发数的数据来源？峰值还是均值？ | P0 | 产品经理 |
| 2 | P95/P99 及错误率是否与业务方书面确认？ | P0 | 产品经理 |
| 3 | 吞吐量目标 QPS/TPS 是否已确定？ | P0 | 产品经理 |
| 4 | 测试环境数据库/中间件是否与生产同规格？ | P0 | 运维 |
| 5 | 压测是否涉及写操作？数据清理方案？ | P0 | 开发 |
| 6 | 写接口幂等性、事务回滚是否已实现？ | P0 | 开发 |
| 7 | 依赖的外部系统是否参与压测？Mock 方案？ | P1 | 架构师 |
| 8 | 压测时间段是否有业务限制？ | P1 | 运维 |
| 9 | 监控大盘是否已覆盖资源类指标？ | P1 | 运维 |
| 10 | 分页/批量/文件等特殊参数场景是否已对齐？ | P1 | 开发/产品 |
P0 项为阻塞项：任何一项未确认，压测不得启动。 这张清单是 P01 最有价值的输出——它把「还没定下来的事」强行暴露出来，不让你带着盲区启动压测。
③ 业务方确认函（可直接转发）
我们计划对 [订单接口] 进行压测，预计 [下周五] 执行，核心接口包括：POST /api/order/create 等 3 个。
需要你确认：
1. 并发数 1000 及吞吐量目标 [X QPS] 是否合理？是否等于业务峰值流量？
2. 响应时间要求 P95 ≤ 500ms / P99 ≤ 1000ms 是否可接受？
3. 压测范围是否完整？参数场景（分页/批量/文件）是否已对齐？
4. 写接口验收标准是否可接受？（库存最终一致性、幂等性、事务回滚正确性）
5. 是否接受测试环境结果作为参考？（测试环境性能约为生产的 60-70%，结果需折算）请回复：✅ 确认以上内容，可按计划执行 / ❓ 有以下修改意见：[请填写]
确认函有回复记录，压测完不会有人跳出来说「我当初没同意这个方案」。
④ 需求摘要（一页纸版本）
只保留核心指标，给领导或跨团队同事看，一页 A4 能打完。
版本管控：需求变更怎么办？
plan_id 命名规范：{项目}-{模块}-{接口}-{压测类型}-{日期}-{版本}
示例：aio-testcase-query-baseline-20260605-v1
| 变更类型 | 版本规则 |
|---|---|
| 首次澄清 | v1.0 |
| 需求变更（并发/SLA/范围调整） | v1.1 → v1.2 |
| 重大变更（压测目标类型改变） | v2.0 |
每次变更保留历史版本，plan_id 同步更新。如果下游 perf-readiness-checker 就绪检查失败，发现是需求理解偏差，可以回流 P01 重新澄清，版本号自动递增。
完整示例：AIO 平台用例查询接口
你的输入：我想对 AIO 平台的用例查询接口做压测，大概有 200 个并发用户，要求 P95 在 500ms 以内perf-requirement-clarifier会根据需求复杂度输出2个文档或者4个文档。
以上实操案例需求摘要文档如下：
需求澄清文档：
业务方确认函：
典型节省：3.5h（主要是来回沟通的时间）
P02 测试计划 — perf-test-planner
第二节计划阶段的坑——场景参数凭感觉、压测机资源没估算、数据量没评估，P02 逐一解决。输入：P01 的需求澄清文档 / 直接提供的压测参数输出：
• 场景参数推导规则：根据目标并发和 QPS 自动推导线程数、Ramp-up、持续时间
• 场景组合推荐：单接口基线 → 混合场景 → 极限容量 → 稳定性，四段式递进
• 压测机资源估算：根据目标并发和协议类型估算需要的 JMeter 节点数
• 数据量风险评估：计算并发 × 持续时间需要消耗多少数据，提前预警数据耗尽
• 数据预热环节：明确是否需要数据预热，避免冷缓存导致 RT 虚高
• 基线对比计划：本次压测和哪个版本对比，口径提前对齐
P03 数据构造 — perf-data-builder
P03 解决的是第二节里没展开的问题：造数据慢、参数化 CSV 手工拼、数据量不足导致压测中途数据耗尽。输入：数据库表结构 / 接口文档 / 数据量需求输出：
• DDL 模式：直接生成 INSERT SQL，按表依赖顺序批量造数据
• 接口模式：生成 CSV 参数化文件 + 配套请求体模板，直接喂给 JMeter
• 数据量计算公式：按并发 × 持续时间 × 去重系数自动计算需要造多少条数据
P04 就绪检查 — perf-readiness-checker
P04 解决的是第二节执行阶段的前置问题：环境不稳定、监控没配、脚本跑不通，导致压测中途中断或结果失真。输入：环境信息 / 脚本文件 / 监控配置 / 数据准备状态输出：
• 4 大维度 34 项检查清单：环境维度（服务状态、数据库连接、网络连通）/ 脚本维度（参数化、断言、关联提取）/ 监控维度（JMeter 监听器、服务器监控大盘、日志采集）/ 数据维度（数据量、数据分布、脏数据）
• 环境问题排查思路：检查项不通过时，给出具体的排查步骤和常见根因
P05 JMX 脚本 — perf-jmx-generator
P05 解决的是工具层面最耗时的事：在 JMeter GUI 里手动配置场景、断言、参数化，一个场景配半小时，还容易配错。输入：接口列表 / 参数化需求 / SLA 指标输出：
• 场景模板库：查询类、下单类、登录类、搜索类——每类带推荐的线程组配置
• 完整 JMX 文件：包含线程组、HTTP 请求、断言（响应码 + 业务码 + 响应时间）、参数化、监听器
• 参数化配置：CSV Data Set Config + 变量引用，直接可用
• 跨平台 Prompt 模板：复制到 Cursor / Trae 也能生成同样质量的脚本
P06 报告分析 — perf-report-analyzer
P06 解决的是压测完成后最头疼的事：JMeter 报告 20 多列指标不知道先看哪个，瓶颈定位靠猜，优化建议写不具体。输入：JMeter 聚合报告 / 服务器监控数据 / 应用日志输出：
• JMeter 报告解读：哪些指标异常、异常程度、优先级排序
• 瓶颈定位决策树：按 TPS/RT/错误率/资源占用四象限定位，缩小到具体组件
• 根因分析：数据库慢查询、GC 停顿、线程阻塞、连接池耗尽——给出具体判断依据
• 优化建议：每个瓶颈给出 2~3 个优化方向，带预期收益估算
P07 报告生成 — perf-report-writer
第二节报告阶段的三个坑——报告结构不统一、容量评估不会写、基线对比漏掉——P07 逐一解决。输入：P02 测试计划 / P06 分析结论 / 压测原始数据 / 监控数据输出：
• 10 大模块标准结构：基本信息 → 测试概述 → 环境 → 场景 → 结果 → 瓶颈 → 容量 → 基线对比 → 结论 → 附件
• 三种报告类型：标准性能测试报告 / 性能回归报告 / 性能验收报告，按需选择
• Pass/Fail/Pass with risk 判定：基于 SLA 自动判定，不模棱两可
• 容量评估：当前配置下最大支撑并发数、建议扩容方案
• 基线对比表格：本次 vs 历史版本，TPS/RT/错误率变化一目了然
• HTML 可视化报告：暗色主题、指标卡片、趋势图表，直接发邮件或贴 Wiki
Skill协作链路
这 7 个 Skill 不是孤立的工具，它们构成一条完整的协作链路：
核心设计逻辑：前 5 项聚焦压测前置筹备，后 2 项负责压测后数据分析，压测执行环节始终由人操控 JMeter。压测流量直连业务服务，启停、监控、终止必须人工决策；AI 只负责标准化产出，不接管实操。
专栏内容
这个专栏共 10 篇，结构如下：
专栏特色
- 工具导向，摒弃空谈原理：不讲空洞性能理论，聚焦落地提速、避坑实操；
- 量化数据，落地可算 ROI：每篇附带工时、产出数据，方便测试团队核算投入收益；
- 轻量化 AI 落地：无浮夸 AI 营销话术，全部依托真实项目沉淀方案与模板。
总结
性能测试是测试工程师进阶的必经之路，也是最容易被低估的环节。
很多团队的做法是：开发说”压一下”，测试就随便写个 JMX 跑一跑，出了个 TPS 数字就交差。但这种做法的产出只有一个数字，对系统能撑多少、瓶颈在哪、怎么优化——没有回答。
好的性能测试应该输出三个东西：
1. 能不能撑住：在当前配置下，目标并发能不能稳定跑完，SLA 是否达标
2. 瓶颈在哪：CPU、内存、IO、网络、数据库、代码，到底哪个是短板
3. 怎么优化：针对瓶颈给出具体的优化方向和预期收益
这 7 个 Skill 就是围绕这三个输出设计的：P01~P02 确保「能不能撑住」有客观依据；P03~P06 确保「瓶颈在哪」能定位到具体组件；P07 确保「怎么优化」能写进正式报告交付给业务方。
Skill 不能替代你对业务的理解和技术判断，但能把 92% 的准备工作时间压缩到 30% 以下，让你把时间集中在真正有价值的事情上。
下一篇我们讲讲如何用skill做性能测试的测试计划。
声明：来自AI应用案例库，仅代表创作者观点。链接：https://eyangzhen.com/8521.html
