LoadRunner负载测试中如何处理Token过期与再生问题

你的核心问题是依赖固定迭代次数刷新Token，但负载测试中实际运行时长和预期不符，导致Token提前过期。以下是几种实用的解决思路：

一、基于实际运行时长动态刷新Token #

放弃固定迭代次数的逻辑，改为每次迭代前检查Token的已使用时长，接近有效期时主动刷新：

1. 首次登录获取Token后，记录当前时间戳：

// 登录成功并提取Token后，记录时间（毫秒级）
long token_start = lr_get_current_time();
lr_save_int(token_start, "TokenStartTime");

2. 每次业务迭代前，计算Token已使用时长，达到阈值（比如9分30秒，留缓冲）时重新登录：

long now = lr_get_current_time();
long elapsed_sec = (now - lr_eval_int("{TokenStartTime}")) / 1000;

// 当已使用时长超过570秒（9分30秒），触发Token刷新
if (elapsed_sec > 570) {
    // 执行登录流程，重新获取Token
    web_url("Login", 
        "URL=http://your-login-endpoint",
        // 其他登录参数
        LAST);
    // 关联提取新Token
    web_reg_save_param("AuthToken", 
        "LB=\"token\":\"", 
        "RB=\"", 
        SEARCH_FILTERS,
        LAST);
    // 重置Token起始时间
    lr_save_int(now, "TokenStartTime");
}

二、加入Token有效性前置校验 #

在每次业务请求前，调用一个轻量的Token验证接口（比如用户信息查询接口），如果返回Token无效，则立即执行登录刷新：

// 调用验证接口
web_custom_request("ValidateToken",
    "URL=http://your-validate-endpoint",
    "Headers=Authorization: Bearer {AuthToken}",
    LAST);

// 检查响应是否包含Token无效标识
if (web_reg_find("Text=Token expired", LAST) == LR_FAIL) {
    // 执行登录流程刷新Token
    // ...（同上述登录逻辑）
}

三、场景级Token共享刷新（多用户场景） #

如果是高并发场景，可以单独配置一个维护虚拟用户组，专门每隔9分钟登录一次获取最新Token，写入共享参数文件；业务用户组每次从该文件读取Token。注意要处理参数文件的读写锁，避免冲突：

1. 维护用户脚本：定时登录，将Token写入共享CSV文件
2. 业务用户脚本：每次请求前读取CSV文件中的最新Token

关键注意事项 #

• 永远不要依赖固定迭代次数或预期时长来刷新Token，负载测试中服务器响应、网络延迟都会导致实际耗时波动，这是你之前失败的根本原因
• 刷新阈值要留足够缓冲（比如有效期的90%），避免刚好到过期时间时因网络延迟导致请求失败
• 多用户场景下，每个用户最好维护自己的Token生命周期，避免共享Token带来的并发问题

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