如何在JMeter 24小时耐力测试中处理OAuth令牌过期与重生成

针对你遇到的令牌12小时有效期、24小时耐力测试需中途刷新，且令牌接口无生成时间返回的问题，提供两个可行的JMeter实现方案：

方案一：基于时间间隔的条件刷新（精准控制） #

1. 初始化令牌与时间戳

   • 将API1（令牌生成请求）放入仅一次控制器，确保测试启动时执行一次。
   • 在API1后添加JSR223 PostProcessor，执行代码记录当前时间戳到全局变量：

     synchronized(this) {
         props.put("token_generated_time", String.valueOf(System.currentTimeMillis()))
     }
     

   • 同时提取令牌值存入全局变量（比如access_token），供API2调用。

2. API2请求前的刷新判断

   • 在API2请求前添加If控制器，条件设置为：

     ${__jexl3(${__time(,)} - ${__P(token_generated_time,0)} >= 42900000,)}
     

     （注：42900000为11小时55分钟的毫秒数，提前5分钟刷新避免过期风险）
   • 在If控制器内嵌套API1请求和更新时间戳的JSR223 PostProcessor，满足条件时自动重新获取令牌并更新时间戳。

3. 多线程适配

   • 所有令牌相关变量用全局属性props存储，避免线程各自维护令牌，减少不必要的令牌请求。

方案二：定时全局刷新（简单易维护） #

1. 创建令牌刷新测试片段
   • 新建测试片段，内部包含API1请求和更新时间戳的JSR223 PostProcessor（同方案一代码）。
2. 添加定时触发器
   • 在测试计划根节点添加固定定时器，设置延迟时间为42900000毫秒（11小时55分钟）。
   • 定时器下添加测试片段控制器，选择刚才创建的令牌刷新片段。
3. API2调用令牌
   • API2直接引用全局变量${__P(access_token,)}即可，无需额外判断，定时任务会自动刷新令牌。

兜底容错机制 #

在API2的响应断言中添加对令牌过期错误码（如401）的检查，一旦触发错误，立即执行一次令牌刷新逻辑：

• 添加响应断言，匹配响应中的401状态码或"token expired"等提示信息。
• 断言失败时，通过JSR223 PostProcessor调用API1刷新令牌并更新全局变量。

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