3.1 测试计划组织结构
3.1 测试计划组织结构
本节摘要：JMeter 脚本是一棵树，组织得好才好维护。本节讲测试计划的树结构、线程组怎么分、元件怎么挂——搭出清晰的脚本骨架。
本节导读
阅读完本节，你应当能够：
- 组织测试计划的树结构
- 合理划分线程组
- 理解元件挂载位置的作用域
概念脉络
一、树形结构
JMeter 脚本是一棵元件树，根是测试计划，下挂线程组，线程组下挂采样器和辅助元件。
图 3-1 测试计划树结构
二、线程组怎么分
- 按场景分：登录、下单、查询等不同场景用不同线程组
- 按负载分：不同用户群体（如 80% 浏览 20% 下单）用不同线程组按比例配
- 按协议分：HTTP 和 JDBC 测试分线程组
勾选"独立运行每个线程组"可让线程组串行跑，默认并行。
三、元件挂载位置与作用域
- 挂线程组下：对组内所有采样器生效（如 HTTP 默认值、聚合报告）
- 挂采样器下：只对该采样器生效（如断言、提取器）
- 挂测试计划下：对所有线程组生效
例：HTTP 默认值挂线程组下，组内所有 HTTP 采样器继承服务器地址；断言挂登录采样器下，只校验登录响应。
四、典型脚本骨架
测试计划 ├ 线程组-登录（100 线程） │ ├ HTTP 默认值（服务器、端口） │ ├ CSV 数据文件（用户名密码） │ ├ HTTP 采样器-登录 │ │ ├ 响应断言（校验成功） │ │ └ JSON 提取器（提取 token） │ ├ 常数定时器（间隔 1 秒） │ └ 聚合报告 └ 线程组-下单（50 线程） └ ...
⚠️ 常见坑：把所有元件都挂线程组下，作用域太大——断言误伤、提取器对错采样器。元件尽量挂到合适的层级，作用域要精确。
💡 关键直觉：脚本是棵树，线程组按场景/负载/协议分，元件挂载位置决定作用域。共享配置挂线程组下，专属元件（断言/提取器）挂采样器下。
要点速记
- 树结构：测试计划→线程组→采样器+辅助元件，根是计划。
- 线程组划分：按场景/负载比例/协议分，可串行或并行。
- 作用域：挂线程组下对组内全部生效，挂采样器下只对该采样器生效。
- 骨架：HTTP 默认值+CSV 数据+采样器+断言+提取器+定时器+聚合报告。
- 元件挂到合适层级，作用域要精确，别都挂线程组下。
下一节讲核心元件怎么配置。
测试计划结构
一个完整的测试计划（Test Plan）层级：测试计划根节点 → 线程组 → 采样器/逻辑控制器 → 断言/监听器/定时器。配置元件（用户定义变量、CSV 数据集、HTTP 请求默认值）挂在与采样器同级或上级位置，通过作用域规则生效。
组织规范
建议按以下规范组织测试计划：测试计划命名清晰（含被测系统与场景）；用户定义变量集中管理环境信息（域名、端口、账号）；HTTP 请求默认值设置公共头与超时；按业务场景拆分多个线程组；监听器集中放在测试计划末尾统一查看。
示例结构
Test Plan ├── 用户定义变量（环境配置） ├── 线程组：登录用户 │ ├── HTTP 请求：登录 │ ├── JSON 提取器：token │ └── 断言：登录成功 ├── 线程组：业务操作 │ ├── HTTP 请求：查询列表 │ └── 断言：响应正常 └── 监听器：聚合报告
规范的组织结构让脚本可维护、可复用、可交接，是工程化测试的基础。
完整示例：用户登录场景
Test Plan（名称：电商登录压测） ├── 用户定义变量 │ ├── HOST = api.example.com │ └── PORT = 443 ├── HTTP 请求默认值 │ └── 协议 https / 服务器 ${HOST} / 超时 5000 ├── 线程组：登录用户（100 线程，Ramp-Up 30s） │ ├── HTTP 请求：POST /login │ │ ├── 参数：username/password（CSV 数据） │ │ └── JSON 提取器：提取 token │ ├── 响应断言：状态码 200 │ └── 监听器：聚合报告
按此结构搭建的脚本层次清晰、便于维护，也符合工程规范：配置集中、数据外置、断言明确。
测试计划的复用技巧：用模板文件保存公共部分（环境配置、公共头、通用断言）；通过 include controller 或模块化脚本组合复用；参数化环境地址使同一脚本适配开发、测试、预发多环境。好的组织结构让一套脚本多环境复用，显著降低维护成本。
常见组织错误
常见错误：所有内容堆在一个线程组（无法区分业务比例）；监听器挂在每个采样器下（结果冗余且拖慢）；变量散落各处（维护困难）；无注释说明（交接困难）。对照规范组织，能让脚本质量显著提升。