JMeter正则提取值存储与跨采样器使用及REST API吞吐量并发测试

我来帮你一步步解决这两个JMeter的问题，都是实际测试中很常见的场景：

一、如何在JMeter中存储正则表达式提取的值并在后续采样器使用 #

这是接口关联测试的核心操作，步骤很清晰：

• 第一步：给目标采样器添加正则表达式提取器
  找到返回需要提取值的采样器（比如你的第一个POST采样器），右键它 → 选择「添加」→ 「后置处理器」→ 「正则表达式提取器」。

• 第二步：配置提取器的关键参数
  在提取器的配置界面，重点设置这几个选项：

  • 引用名称：就是你要存储值的变量名，比如uniqueId1，后续直接用${uniqueId1}调用即可。
  • 正则表达式：根据接口返回的内容写匹配规则，比如如果返回JSON是{"id": "abc-123-xyz"}，那正则可以写"id": "(.+?)"——这里(.+?)是捕获组，专门用来提取中间的ID值。
  • 模板：填$1$，表示取第一个捕获组的内容（如果有多个捕获组，就用$2$、$3$对应）。
  • 匹配数字：填1表示取第一个匹配到的结果；如果返回多个结果，0是随机取一个，-1是取所有结果（变量会变成数组形式，比如uniqueId1_1、uniqueId1_2）。
  • 缺省值：可选，当提取失败时用这个值代替，比如NOT_FOUND，方便后续排查问题。

• 第三步：在后续采样器中直接调用变量
  比如你的第二个GET采样器，路径可以直接写成/path to REST API/${uniqueId1}，JMeter会自动把变量替换成实际提取到的ID值。

  👉 注意：提取器必须挂在对应的采样器下面，不要把它放在线程组层级，不然会尝试提取所有采样器的返回结果，很容易出错。

二、测量每个采样器的响应吞吐量与并发量的对应关系 #

你的测试计划结构已经有了基础，接下来可以按下面的方法落地：

1. 通过线程组控制并发量 #

调整线程组的核心参数来模拟不同并发场景：

• 线程数：就是并发用户数，比如你要测试10、20、50、100并发，就分别设置这个值。
• Ramp-Up时间：设置线程启动的间隔时间，比如线程数100，Ramp-Up设10秒，就是每秒启动10个线程，避免瞬间给服务器造成过大压力。
• 循环次数：设置每个线程执行测试计划的次数，比如设10次，保证有足够的样本数据来计算吞吐量。

2. 添加监听器记录吞吐量数据 #

右键线程组 → 「添加」→ 「监听器」，推荐这两个实用的监听器：

• Summary Report：会清晰显示每个采样器的请求数、平均响应时间、吞吐量（默认单位是请求/分钟，也可以在JMeter的user.properties里改成请求/秒）。重点看「Throughput」列，就是每个采样器的吞吐量。
• Aggregate Report：和Summary Report类似，但会给出更多统计指标（比如中位数、90%响应时间），同时也包含吞吐量数据，适合更细致的分析。

3. 测试与数据整理 #

• 每次设置一个固定并发数（比如10线程），运行测试，保存对应的监听器结果。
• 更换不同的并发数重复测试，把每个并发数下两个采样器的吞吐量记录下来，最后整理成表格或者折线图，就能直观看到吞吐量随并发量变化的趋势。

几个关键注意点 #

• 你添加的10秒暂停，如果接口生成ID的实际耗时不需要这么久，可以调小时间；或者用「Constant Timer」代替「测试动作」，把作用域限定在POST采样器之后，效果是一样的，还能更灵活控制。
• 正则提取的uniqueId1是线程局部变量，每个线程都会生成自己的独立ID，完全符合真实用户的操作场景，不用担心冲突。
• 测试时尽量保证服务器状态稳定，比如每次测试前等待服务器恢复，避免前一次测试的残留影响导致数据不准。

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