基于Ultimate Thread Group配置执行RPS及负载测试配置咨询

测试背景 #

需对若干API执行8小时负载测试，测试目标为：以较低RPS执行，每小时增加15个线程，启动时长5分钟（300秒），保持负载50分钟，关闭时长5分钟（300秒），循环执行；第二轮将提升RPS，配置暂未给出。

现有配置 #

Ultimate Thread Group配置 #

Shapping Timer配置 #

每小时预期请求数 #

技术疑问解答 #

1. 当前配置是否正确？ #

整体逻辑贴合测试目标，但存在几个关键细节需确认：

• 时间对齐：每个线程组的初始延迟+启动+保持+关闭总时长为3600秒（1小时），8个阶段刚好覆盖8小时，这部分没问题。但要确保Shapping Timer的生效时间与对应线程组的保持负载阶段完全同步，否则会出现RPS控制和线程启动不同步的情况。
• 请求数匹配：每小时预期请求数与保持阶段的RPS×时长完全对应（如3RPS×3000秒=9000），说明预期请求数仅计算保持阶段的量，这部分配置对齐。但启动和关闭阶段也会产生请求，实际总请求数会比预期总和多。
• 线程叠加问题：需确认Ultimate Thread Group的每个阶段是替换线程而非新增。如果是新增，第8小时活跃线程数会是各阶段线程数累加，与“每小时增加15个活跃线程”的目标不符，需配置为每个阶段结束后关闭之前的线程，再启动新的线程数。

2. RPS是仅在Hold Load时长内生成，还是启动和关闭阶段也会生成？ #

Shapping Timer默认作用于整个线程组生命周期，包括启动、保持、关闭阶段。也就是说，启动和关闭线程的300秒内，Timer也会按设置的RPS控制请求发送速率。如果仅需在Hold Load阶段控制RPS，可通过JSR223前置处理器设置生效条件，或结合Test Action Sampler限定Timer的作用范围。

3. 如何生成按小时统计的请求量及对应活跃线程数的图表或表格？ #

可通过以下步骤实现：

• 数据收集：在JMeter中添加Summary Report、Active Threads Over Time监听器，勾选“Save Data to File”，将测试数据保存为CSV格式。
• 数据处理：
  • 用Excel：读取CSV后，通过数据透视表按每3600秒（1小时）分组，统计每个小时的总请求数，对活跃线程数取平均或最大值。
  • 用Python：借助pandas库读取CSV，设置时间索引后按resample('H')进行小时级聚合，统计请求数总和与线程数统计值。
• 图表生成：Excel中直接基于透视表生成柱状图（请求数）和折线图（活跃线程数）；Python用matplotlib或seaborn绘制组合图表，直观展示小时级数据变化。

内容的提问来源于stack exchange，提问作者Islam