JMeter 测试计划（Test Plan）与脚本结构详解

JMeter 的所有性能脚本，都以 测试计划（Test Plan） 为根节点组织和管理。

理解 Test Plan 的结构，等同于看懂整个 JMeter 脚本的"工程结构"，是学习 JMeter 的第一步。

本章将从 Test Plan 的概念 → 基础结构 → 运行机制 → 变量管理 → 示例结构图 全面讲解。

1. 什么是 Test Plan（测试计划）？

Test Plan 是 JMeter 中所有测试组件的最顶层容器，相当于：

一个项目工程（Project）
一个完整的压测方案（Test Scenario）
一个脚本的执行入口（Execution Root）

它定义了：

执行哪些线程组
每个线程组怎么运行
使用什么取样器发送请求
用哪些定时器控制等待
用哪些断言判断正确性
用哪些监听器收集结果
用哪些配置元件提供参数或环境变量

一句话：Test Plan = JMeter 脚本的根骨架。

2. Test Plan 的核心任务

Test Plan 主要承担 5 个核心职责：

① 组织所有测试组件

所有逻辑控制器、取样器、断言、定时器等都必须挂载在测试计划的树形结构中。

② 管理运行方式

包括：

是否循环运行
是否独立运行每个线程组（Run each Thread Group separately）
是否按顺序运行线程组

③ 定义全局变量（User Variables）

你可以在 Test Plan 中定义全局参数，例如：

变量名	值
host	api.example.com
timeout	5000
token	xxxx

这些变量可以通过 ${变量名} 在整个脚本中使用。

④ 管理脚本编码与保存方式

Test Plan 为脚本保存提供设置：

脚本编码（UTF-8 强烈推荐）
在保存时是否删除结果（推荐开启）

⑤ 管理插件加载与执行资源

如 JMeter-Plugins、JDBC 驱动等，都依赖测试计划加载执行。

3. JMeter 脚本的标准结构

一个典型的 JMeter 测试计划包含如下结构：

复制代码

Test Plan
 ├── User Defined Variables（用户自定义变量）
 ├── Thread Group（线程组 1）
 │     ├── Config Elements（配置元件）
 │     ├── Logic Controllers（逻辑控制器）
 │     │      ├── Sampler（取样器）
 │     │      ├── Pre-Processor（前置处理器）
 │     │      ├── Post-Processor（后置处理器）
 │     │      ├── Assertions（断言）
 │     ├── Timers（定时器）
 │     ├── Listeners（监听器）
 │
 ├── Thread Group（线程组 2）
 │      └──（与线程组1结构类似）
 │
 └── Non-Test Elements（非测试组件，如 TCP Sampler 配置等）

这就是 JMeter Test Plan 的标准树形结构。

4. Test Plan 的属性详解

打开测试计划，右侧会出现一些基础属性。

下面逐项解释。

4.1 Name（名称）

脚本的名称，可以写成描述性文字，例如：

"用户登录压测计划"
"订单系统接口性能测试"

4.2 User Defined Variables（用户自定义变量）

提供全局变量功能，例如：

复制代码

host = 192.168.1.10
port = 8080
protocol = http
env = test

所有取样器可以通过 ${host} 引用。

推荐用途：

环境切换（test / pre / prod）
全局超时时间
公共参数
公共 Header

4.3 Run Thread Groups consecutively（按顺序执行线程组）

默认：并行（同一 Test Plan 下）

开启后：线程组按顺序串行执行

用途示例：

适合场景	示例
场景依赖顺序	先注册 → 再登录 → 再下单
场景式压测	先 Warm up → 再 Ramp up → 再稳定压测

4.4 Run tearDown Thread Groups after shutdown of main threads（关闭后执行回收线程组）

shutdown 正常关闭 → teardown 执行
stop 强制关闭 → teardown 不执行

用于：

清理测试数据
发送关闭请求
打印最终日志

4.5 Functional Test Mode（功能测试模式）

不推荐用于性能压测。

开启后：

保存更多信息
显著降低性能

4.6 Add directory or jar to classpath（扩展 classpath）

用于加载：

JDBC 驱动
扩展插件
自定义 Java 代码

实际场景：使用 JDBC Sampler 一定要加载数据库驱动（mysql-connector.jar）。

5. JMeter 脚本的执行机制（重点）

理解执行顺序有助于正确设计脚本结构。

执行顺序（组件优先级）

一个取样器执行时，各组件按如下顺序运行：

复制代码

逻辑控制器 → 前置处理器 → 定时器 → 取样器（Sampler） → 后置处理器 → 断言 → 监听器

必须记住的顺序：Pre → Timer → Sampler → Post → Assertion → Listener

6. 一个完整测试计划示例（结构化展示）

复制代码

Test Plan: 电商系统下单性能测试
 ├── User Defined Variables
 │       ├── host = api.shop.com
 │       ├── token = ABC123
 │
 ├── Thread Group：用户登录 + 加载首页
 │      ├── HTTP Header Manager
 │      ├── Once Only Controller
 │      │       └── HTTP Sampler：登录接口 /login
 │      ├── Loop Controller（循环 10 次）
 │      │       └── HTTP Sampler：访问首页 /index
 │      ├── Regular Expression Extractor（提取 sessionId）
 │      ├── JSON Assertion（判断响应 code=200）
 │      ├── Constant Timer（500ms）
 │      └── Aggregate Report
 │
 ├── Thread Group：用户创建订单
 │      ├── CSV Data Set Config（读取商品ID）
 │      ├── Transaction Controller（下单事务）
 │      │       ├── HTTP Sampler：加购物车 /cart/add
 │      │       └── HTTP Sampler：提交订单 /order/create
 │      ├── User Parameters（个性化参数）
 │      ├── JSR223 PostProcessor（输出日志）
 │      ├── Response Assertion
 │      └── Summary Report

7. Test Plan 设计最佳实践

① 脚本参数统一放在 Test Plan → User Variables

避免分散 hardcode 参数。

② 一个线程组只做一类场景

例如：

登录场景
下单场景
商品浏览场景

便于调优和扩容。

③ 避免在 Test Plan 顶层放取样器或监听器

应放在线程组内部。

④ 使用逻辑控制器分段管理脚本

便于阅读和调试。

⑤ 大规模压测不要加入过多监听器

推荐仅保留：

Summary Report
Backend Listener（InfluxDB + Grafana）

📌 结语

Test Plan 是 JMeter 脚本的核心，它不是一个简单的容器，而是整个压测方案的组织者。

理解它的结构，有助于你更好地设计、扩展和维护脚本。