1.2 核心概念与术语体系

1.2 核心概念与术语体系

本节摘要：JMeter 的脚本是一棵元件树，每种元件各司其职。本节讲线程组、采样器、监听器、配置元件、定时器、断言、前后置处理器——核心术语一次理清。

本节目标

阅读完本节，你应当能够：

1. 说清测试计划、线程组、采样器的作用
2. 区分监听器、配置元件、定时器、断言、前后置处理器
3. 理解元件的执行顺序

概念脉络

一、测试计划和线程组

• 测试计划（Test Plan）：脚本的根节点，包含所有元件，是整个测试的容器
• 线程组（Thread Group）：模拟一组用户。核心参数：线程数（用户数）、Ramp-up（启动时间）、循环次数

<!-- 线程组：100 用户，10 秒内启动，循环 1 次 -->
<ThreadGroup>
  <stringProp name="ThreadGroup.num_threads">100</stringProp>
  <stringProp name="ThreadGroup.ramp_time">10</stringProp>
  <stringProp name="LoopController.loops">1</stringProp>
</ThreadGroup>
​

二、采样器

采样器（Sampler）向目标发请求。最常用 HTTP 请求采样器，还有 JDBC、JMS、TCP 等。

图 1-2 核心概念关系

三、其他核心元件

四、元件执行顺序

一次采样器请求，元件按固定顺序执行：

配置元件 → 定时器 → 前置处理器 → 采样器 → 后置处理器 → 断言 → 监听器
​

理解这个顺序很重要——比如后置处理器提取的数据，断言里才能用；定时器在采样器前生效控制间隔。

五、作用域

元件的作用域取决于它在树里的位置：挂在采样器下只对该采样器生效，挂在线程组下对组内所有采样器生效。配置元件和监听器的作用域同理。

⚠️ 常见坑：把断言挂在线程组下，对组内所有请求都校验——可能误伤不该校验的请求。断言尽量挂在具体采样器下，作用域要明确。

💡 关键直觉：JMeter 脚本是一棵元件树，各元件按"配置→定时器→前置→采样器→后置→断言→监听器"顺序执行。作用域看挂的位置，挂采样器下只对该采样器生效。

一节小结

• 测试计划/线程组：计划是根容器，线程组模拟用户（线程数、Ramp-up、循环）。
• 采样器：发请求的核心，HTTP/JDBC/JMS 等。
• 其他元件：配置（默认值）、定时器（间隔）、前后置处理器（准备/提取）、断言（校验）、监听器（记录展示）。
• 执行顺序：配置→定时器→前置→采样器→后置→断言→监听器。
• 作用域：挂采样器下对该采样器生效，挂线程组下对组内全部生效。

下一节讲 JMeter 适合什么场景、能力边界在哪。

概念辨析

JMeter 的核心概念围绕"模拟用户发请求"展开：线程组是并发的来源，每个线程代表一个虚拟用户；采样器是具体的请求动作；逻辑控制器控制执行顺序与条件；断言校验响应正确性；监听器收集与展示结果。理解这些元件的关系是搭建测试计划的第一步：线程组在最外层，采样器与控制器挂在其下，断言与监听器作为子节点作用于采样器。

术语速查表

易混点提醒

配置元件与采样器的作用范围不同：配置元件影响其所在层级及其子层级的所有采样器，而定时器、断言只作用于同层级采样器。理解作用域规则是避免脚本行为异常的关键，建议通过小实验验证作用域后再设计复杂测试计划。

作用域实验

作用域规则建议通过小实验验证：在一个线程组下挂两个 HTTP 请求，再在其中一个请求下挂定时器，运行后观察定时器是否只影响其所在分支。类似地，在测试计划根节点添加用户定义变量，观察其如何被所有线程组共享。亲手验证作用域规则，比死记文档更牢固，也能避免脚本行为与预期不符时的困惑。

元件关系图

测试计划
├── 用户定义变量（全局配置）
├── 线程组
│   ├── HTTP 请求
│   │   ├── 断言（校验该请求）
│   │   └── 定时器（作用于该请求）
│   ├── 逻辑控制器（分支/循环）
│   └── 监听器（收集该组结果）
└── 监听器（全局结果）
​