告别手动编写JMeter脚本，一个 Skill搞定99% 脚本配置，自动生成分布式压测脚本，7大性能测试 Skill(第五篇)

一个被低估的问题：

测试计划写得清清楚楚：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 大防护：

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

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

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

4. 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 个文件）

适用场景：本地单接口调试，1 小时压测以内，1 台机器跑。

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

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

示例 3：完整输出（11 个文件 + 10 分片）

京东订单案例（见上文），含 10 Slave 分布式、长稳防 OOM、写接口幂等事务、55 项校验。

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

怎么用

1. WorkBuddy 中直接使用

触发词

三步使用流程

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：

1. 复制 Prompt 模板

2. 粘贴到对话框

3. 补充自己的 plan_id 和压测信息

4. AI 自动生成完整脚本包

Claude / ChatGPT / DeepSeek（网页版）：

1. 复制 Prompt 模板

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

3. 补充自己的压测信息

使用前 vs 使用后

总结

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

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

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

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

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

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

专栏目录（持续更新）：