测试计划与线程组：核心概念与属性配置
测试计划（Test Plan）是 JMeter 脚本的根节点，它定义了整个压测任务的全局行为。线程组（Thread Group）则是脚本中真正的“施压引擎”，所有虚拟用户（VU）的启动、运行和停止逻辑都由线程组控制。理解这两者的关系与配置参数，是编写可重复、可量化的容量压测脚本的基础。
2.1 测试计划概念
测试计划是一个容器，它包含所有与本次压测相关的元素：线程组、配置元件、取样器、监听器等。测试计划本身不执行任何测试，但它提供了全局级别的设置，影响所有子元素的行为。
| 属性 | 说明 | 典型值 / 建议 |
|---|---|---|
| 名称 | 测试计划的标识，建议按项目+场景命名 | order-api-200tps |
| 注释 | 描述本次压测的目的、环境、版本 | v2.1 订单接口 200TPS 容量验证 |
| 独立运行每个线程组 | 勾选后线程组按顺序执行，否则并行 | 多场景串联时勾选 |
| 函数测试模式 | 调试用，会记录每个请求的详细信息 | 压测时关闭 |
| 添加目录或jar包到classpath | 引入外部依赖（如 JDBC 驱动） | 按需配置 |
2.2 线程组属性配置
线程组是压测脚本的核心施压单元。以下三个参数直接决定了压测的负载模型：线程数、Ramp-Up 时间、循环次数。调度器配置则提供了更精细的时间控制能力。
2.2.1 线程数（Number of Threads）
线程数即并发虚拟用户数。每个线程独立运行完整的取样器逻辑。线程数并非越高越好，需要结合目标 TPS 和单线程吞吐量计算。
- 计算公式： 线程数 = 目标 TPS × 单请求平均响应时间（秒）
- 示例： 目标 200 TPS，平均响应时间 50ms → 线程数 = 200 × 0.05 = 10
- 注意： 线程数过多会导致上下文切换开销，建议通过阶梯压测找到拐点。
2.2.2 Ramp-Up 时间（秒）
Ramp-Up 定义了从第一个线程启动到所有线程启动完毕所需的时间。合理的 Ramp-Up 可以模拟真实用户逐步涌入的场景，避免瞬间冲击导致服务雪崩。
- 推荐值： Ramp-Up = 线程数 × (1~2) 秒，或根据预热时长设定
- 极端情况： Ramp-Up = 0 表示所有线程同时启动，用于测试瞬间并发极限
- 巡检场景： 自动化巡检建议 Ramp-Up 不低于 10 秒，便于监控系统捕捉指标变化。
2.2.3 循环次数（Loop Count）
循环次数控制每个线程执行取样器的次数。结合线程数，决定了总请求量。
- 固定次数： 适用于容量验证，如每个线程循环 100 次
- 永远（Forever）： 配合调度器使用，由时间控制停止条件
- 总请求量： 线程数 × 循环次数 = 总请求数（不含前置/后置逻辑）
2.3 调度器配置
调度器（Scheduler）提供了基于时间的启停控制，适用于长时间稳定性压测和自动化巡检场景。启用调度器后，线程组会忽略循环次数（如果勾选了“永远”），或达到时间后强制停止。
| 参数 | 说明 | 使用场景 |
|---|---|---|
| 持续时间（秒） | 线程组启动后持续运行的时间 | 稳定性压测（如 30 分钟） |
| 启动延迟（秒） | 线程组延迟启动的时间 | 等待依赖服务就绪 |
| 结束时间 | 指定时间停止（如 2025-12-31 23:59:59） | 定时任务、夜间巡检 |
2.4 线程组配置流程与参数关系
下图展示了线程组配置的核心流程与参数之间的依赖关系，帮助理解从线程数设定到调度器控制的完整链路。
2.5 自动化巡检场景下的参数配置策略
在自动化容量压测巡检中，线程组参数通常由外部配置文件或环境变量驱动，而非硬编码在脚本中。以下为推荐配置策略：
- 线程数： 从配置中心读取，支持按环境（dev/staging/prod）差异化设置
- Ramp-Up： 固定为线程数 × 1.5 秒，最小不低于 10 秒
- 循环次数： 勾选“永远”，由调度器持续时间控制
- 调度器持续时间： 从参数文件读取，默认 300 秒（5 分钟），稳定性场景 1800 秒（30 分钟）
# user.properties 或命令行 -J 参数
thread.count=50
ramp.up.seconds=75
test.duration.seconds=3002.6 常见配置误区与验证方法
| 误区 | 后果 | 正确做法 |
|---|---|---|
| Ramp-Up 设为 0 | 瞬间并发冲击，可能触发限流或雪崩 | 根据线程数设置合理梯度 |
| 循环次数与调度器同时使用 | 逻辑冲突，可能提前停止或超时 | 二选一：固定次数或调度器时间 |
| 调度器持续时间小于 Ramp-Up | 线程未全部启动即停止，负载不足 | 持续时间 ≥ Ramp-Up × 3 |
| 线程数过大未做预热 | 响应时间飙升，结果失真 | 使用阶梯线程组或 Ramp-Up 预热 |
验证配置是否正确，可在运行前通过“查看结果树”监听器观察线程启动日志，或使用“jp@gc - Active Threads Over Time”插件实时监控线程数曲线，确保 Ramp-Up 阶段线程线性增长，并在调度器结束时平稳停止。