一个被低估的问题
测试计划写得清清楚楚：5000 并发、23 分钟、P95 ≤ 500ms。

2000 万条数据造好了，缓存预热完了，就绪检查 59 项全过。

接下来就剩一件事，配 JMX 脚本。

3.5 小时后，业务方问：还没好？

你回头看 JMeter：线程组配了 1 小时，5 个 HTTP 请求配了 1.5 小时，断言补 bug 修了 1 小时。10 台 Slave 路径全不一致，因为本地写的绝对路径，Slave 上没有。开压 3 分钟 TPS 只有 200，看报错：限流没关。

业务方催第三次：”再给我半天。”

你很委屈：不是 JMX 难，是 JMeter 太”工程师友好”了，每一个选项都要你点，每一处配置都要你填。

不是 JMeter 难用，是我们在错误地使用 JMeter。

测试计划已经把”做什么”写得明明白白，工程师不该再把时间耗在”怎么做”的配置上，JMX 脚本就不该是手工配出来的，它该是从测试计划驱动生成的。

perf-jmx-generator 是什么
perf-jmx-generator 是一键生成 JMeter JMX 脚本的 Skill：

输入：plan_id（一行字，关联上游 P01/P02/P03）+ 压测目标 + 环境信息

输出：调试版 JMX + 正式版 JMX + 分布式配置 + 启动脚本 + 10 个分片 CSV + 脚本校验报告

核心能力：从测试计划（5000 并发 / 23 分钟 / 11 台 Slave）→ 完整可执行 JMX 脚本包，15 分钟出活，0 项手工配置。

能解决什么问题
6 个手工配置 JMX 的经典翻车

以前 vs 现在

核心能力一览
能力 1：上游 plan_id 自动联动（11 项参数 0 手动）
以前：测试计划改了并发数，JMX 脚本里 8 个地方要改；数据构造改了路径，CSV 配置要重写；就绪检查发现 SLA 错了，断言阈值要重算。

现在：输入一行 plan_id，自动从 P01/P02/P03 加载：

能力 2：分布式压测脚本（10 Slave 自动拆分）
核心特性：

多 Slave 分片 CSV 加载：每个 Slave 节点绑定独立数据分片（user_id 区间切分），避免热点 Key 和缓存击穿

远程执行 shell 脚本：run_distributed.sh 自动生成 jmeter -r 远程启动命令

结果聚合说明：merge_results.sh 自动生成多 CSV 合并 + 95% 置信区间计算

统一远程主机配置：jmeter.properties 远程主机 IP 列表自动填充

京东案例验证：10 Slave × 600 线程 = 6000 并发，10 个分片 CSV 自动按 user_id 区间切分（每个 200 万用户）。

能力 3：业务开关 Header 矩阵（5 场景自动适配）

京东案例：容量击穿模式，7 个 Header 自动配置（限流/熔断/降级全 disabled + X-Perf-Tag=capacity + 唯一请求 ID + 影子流量隔离）。

能力 4：写接口幂等 + 事务 + 业务断言

京东案例：加购/提交/支付 3 个写接口 100% 带 UUID 幂等 Key，事务级 P95=480ms（业务级 SLA 合规）。

能力 5：长稳测试防 OOM（jmeter.sh 启动脚本）
4 大防护：

JVM 堆内存配置：12h 测试用 4G，24h 测试用 6G，48h+ 用 8G

禁用内存型监听器：View Results Tree、查看断言结果、Debug Sampler 全部移除

强制 CSV 落地：聚合报告 → CSV 文件，配置滚动写入（每 60s 一个文件）

60 分钟自动重登录：登录态链路定时清理 Cookie + 重新登录，避免 Token 失效

示例启动脚本：

run_test.sh

!/bin/bash

HEAP=”-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m”
jmeter -n -t jd-order-perf-20260611-JMX.jmx \
-Jheap_size=4g \
-Jduration=82800 \
-l results/result-$(date +%Y%m%d-%H%M%S).jtl \
-e -o results/html-report \
$HEAP
能力 6：三层断言体系（HTTP + 业务码 + 业务字段）

能力 7：监听器场景化过滤（自动适配场景）

实战案例：京东订单 2000 万数据，JMX 一键生成
用 v1.1.0 给京东订单 2000 万数据案例做完整 JMX 脚本生成，15 分钟出活。

输入：一行 plan_id 启动
@skill:perf-jmx-generator

plan_id = jd-order-perf-20260611
压测目标 = 容量击穿
压测环境 = 预发布
接口列表 = 5 个核心接口（登录/加购/提交/支付/查询）
Step 0：上游自动加载报告（0 项手动）
自动从 P01/P02/P03 加载 11 项参数：

加载耗时：3 秒。人工配置原本需要 30 分钟。

Step 1~6：自动生成 JMX 脚本包（11 个文件）

核心 JMX 组件（11 大能力全部落地）
调试版 JMX 关键节点（30KB XML）：

1. 线程组：L3全链路-5000并发-23min
2. 事务控制器：下单全链路事务
3. CSV 数据文件配置：./data/…shard-${__P(slave_id,1)}.csv
4. 用户定义变量：域名/环境/接口超时/Token有效期
5. HTTP 信息头管理器：7 个 Header（容量击穿 + 影子流量隔离）
6. HTTP Cookie 管理器
7. HTTP 请求默认值
8. 步骤 1：登录（HTTP 请求 + 响应断言 + JSON 提取器）
9. 步骤 2：加购（写接口 + UUID 幂等 Key + 库存断言）
10. 步骤 3：提交订单（写接口 + UUID + 业务断言 + 事务内）
11. 步骤 4：支付（写接口 + UUID + 状态断言）
12. 步骤 5：查询订单（读接口 + 状态=PAID 断言）
13. 响应断言：HTTP 200
14. 业务码断言：code = 0
15. 业务字段断言：订单号非空且不重复
16. SLA 断言：P95 ≤ 500ms
17. 错误率拦截：> 5% 终止线程
18. ThinkTime：1000~3000ms 随机
19. 监听器：聚合报告 + Summary Report + Debug Sampler
    脚本校验报告（55 项 100% 通过）

0 项 P0 阻塞、0 项 P1 警告、0 项未通过 — 脚本可直接开压。

总结
15 分钟出活，55 项校验 100% 通过，0 项手工配置，1 行 plan_id 启动。

以前写脚本 2~4 小时 + 改脚本 1 小时 + 排查问题 1 小时 = 半天没了。
现在 15 分钟，还顺便把 10 台 Slave、10 个分片 CSV、7 个 Header、3 个写接口的幂等、5 步骤的事务、3 层断言、4 类监听器、55 项校验全配齐。
输出物示例
示例 1：最简输出（单机单接口，3 个文件）
文件 作用
plan_001-JMX.jmx
单线程组 + 单 HTTP 请求 + 1 个断言
plan_001-data.csv
单文件参数化
plan_001-脚本校验报告.md
12 项校验
适用场景：本地单接口调试，1 小时压测以内，1 台机器跑。

示例 2：标准输出（分布式多接口，8 个文件）

适用场景：标准 5 Slave 分布式压测，1~3 小时。

示例 3：完整输出（11 个文件 + 10 分片）
京东订单案例（见上文），含 10 Slave 分布式、长稳防 OOM、写接口幂等事务、55 项校验。

适用场景：容量规划、稳定性压测（12h+）、秒杀大促备战。

怎么用

1. WorkBuddy 中直接使用
   触发词
   类别 触发词
   主触发
   生成 JMX、生成压测脚本、JMeter 脚本生成、写 JMX
   口语化
   压测脚本一键生成、JMX 模板生成、JMeter 配置生成
   三步使用流程
   Step 1：输入 plan_id（最简 1 行启动）

@skill:perf-jmx-generator

plan_id = jd-order-perf-20260611
压测目标 = 容量击穿
压测环境 = 预发布
Skill 会自动从 P01/P02/P03 加载 11 项参数，跳过重复问询。

Step 2：确认场景信息（10 项差异化配置）

Step 3：自动生成完整 JMX 包

15 分钟出活

11 个文件 + 10 个分片 CSV

55 项脚本校验 100% 通过

0 项手工配置

2. 跨平台使用（Cursor / Trae / Claude / ChatGPT / DeepSeek）
   Prompt 模板（直接复制）
   你是一位资深性能测试工程师，专精于 JMeter JMX 脚本生成。

任务

根据我提供的测试计划，帮我一键生成完整可执行的 JMeter JMX 脚本包，
支持分布式压测、长稳测试、读写接口差异化配置、自动化校验。

前置必填（缺失则拒绝启动）

• plan_id（关联上游测试计划 + 数据构造）
• 压测目标（基线/容量击穿/稳定性/影子/极限）
• 压测场景类型（L1 原子/L2 混合/L3 全链路）
• 压测模式（阶梯/脉冲/浪涌/恒定 QPS）
• 并发模式（单机/分布式 + Slave 数量）
• 压测环境（测试/预发布/生产）
• 写接口列表（需幂等的接口名）
• ThinkTime 规则（L1=0/L2=500ms/L3=1000-3000ms）
• 是否长稳测试（12h/24h/48h+）
• 接口鉴权方式（Token/签名/Cookie）

11 大生成能力

能力 1：上游 plan_id 自动联动

从 P01 需求澄清自动加载：SLA P95/P99、错误率阈值、接口列表
从 P02 测试计划自动加载：目标并发、ramp-up、持续时间、Slave 数量
从 P03 数据构造自动加载：CSV 路径、冷热分片、字段映射

能力 2：分布式压测脚本

• 10 Slave 分片 CSV 自动加载（避免热点 Key）
• 远程执行 shell 脚本（jmeter -r）
• 结果聚合（merge_results.sh + 95% 置信区间）
• 统一 jmeter.properties 远程主机配置

能力 3：业务开关 Header 矩阵

按压测目标自动配置 7 个 Header：

• 容量击穿：限流/熔断/降级全 disabled
• 影子压测：X-Perf-Source=shadow
• 稳定性：保留生产默认配置

能力 4：写接口幂等 + 事务 + 业务断言

• UUID v4 前置处理器（X-Idempotent-Key）
• 事务控制器包裹完整写链路
• Groovy 业务断言：订单号非空/不重复、状态=PAID、库存≥0

能力 5：长稳防 OOM

• jmeter.sh 内置 4G/6G/8G 堆内存
• 60 分钟自动重登录
• 禁用内存型监听器
• 强制 CSV 滚动写入

能力 6：三层断言

• 第 1 层：HTTP 200
• 第 2 层：业务码 = 0
• 第 3 层：Groovy 业务字段校验
• SLA：P95/P99 自动从 P01 加载
• 错误率 > 5% 自动终止线程

能力 7：监听器场景化过滤

• 调试版：保留 View Results Tree
• 正式版：自动移除内存型监听器
• 长稳版：强制 CSV 滚动写入

能力 8：参数化能力

• 多 CSV 分片自动加载
• 用户定义变量（域名/环境/超时）
• 加密签名前置处理器（MD5/AES/RSA/时间戳）
• JSON Path 自动提取业务字段

能力 9：中间件压测模板

• JDBC：连接池复用 + 批量查询 + 超时配置
• WebSocket：心跳 + 自动重连
• Kafka/RabbitMQ：完整采样器模板

能力 10：流量模型匹配

• 混合场景按上游接口权重分配线程数
• 恒定吞吐量计时器（容量规划锁 QPS）
• 阶梯脉冲加压控制器（秒杀瞬时流量）

能力 11：脚本校验报告（55 项量化）

• 上下游参数一致性（10 项）
• 写接口差异化（5 项）
• 分布式配置（6 项）
• 业务开关（4 项）
• 监听器合规（4 项）
• 断言完整性（6 项）
• CSV 有效性（5 项）
• 启动脚本（4 项）
• 数据隔离（3 项）
• 文件命名（8 项）

输出要求（完整脚本包）

• 调试版 JMX（30KB）
• 正式版 JMX（25KB）
• 分布式配置说明
• 启动脚本（run_test.sh + .bat）
• 分布式启动（run_distributed.sh）
• 结果聚合（merge_results.sh）
• 分片 CSV（10 个 Slave）
• 脚本校验报告（55 项）
• 自动加载报告
• jmeter.properties

6 项防呆校验

1. 单机并发 > 5000 → 强制建议分布式
2. 写接口无幂等 Key → 拒绝生成
3. 长稳测试无 jmeter.sh → 自动补全
4. 正式版有 View Results Tree → 自动移除
5. 容量击穿有业务限流 → 强制关闭
6. 生产影子无流量标识 → 拒绝生成

关键原则

• 一行 plan_id 启动，0 项手工配置
• 写接口必须幂等 + 事务 + 业务断言
• 分布式必须分片 CSV + 远程执行 + 聚合
• 长稳必须防 OOM + 重登录
• 脚本必须 55 项校验 100% 通过
  Cursor / Trae：

复制 Prompt 模板

粘贴到对话框

补充自己的 plan_id 和压测信息

AI 自动生成完整脚本包

Claude / ChatGPT / DeepSeek（网页版）：

复制 Prompt 模板

在对话开头加「请按照以下角色和要求执行任务：」+ Prompt

补充自己的压测信息

使用前 vs 使用后

总结
JMX 脚本的本质是机械配置，线程数、HTTP 请求、Header、Cookie、CSV、断言、监听器、事务，这些配置项和上游测试计划一一对应。

既然测试计划已经确定了 5000 并发、23 分钟、6 阶阶梯、5 个接口、3 个写接口要幂等、11 台 Slave、10 个分片 CSV。

JMX 脚本就不该是”工程师一行一行配出来的”，而是”测试计划驱动生成的”。

P05 perf-jmx-generator 把”手工配置 JMX”工程化、自动化、校验化，让你 15 分钟拿到一份能直接开压的脚本包，中间没有任何手工配置。

它不是替代你写脚本，而是让你从机械的 JMeter 配置里解放出来，去做真正需要工程师判断的事，分析结果、调优参数、设计场景。

下一篇，我会介绍 P06 perf-report-analyzer ，压测报告分析 Skill。JMX 跑完后，从 JMeter 结果里自动挖出瓶颈点，告诉你”哪个接口慢了， 哪条 SQL 卡了，哪个中间件打满了，哪个连接池爆了”。