1. LoadRunner认证失败问题解析当你在LoadRunner中遇到{msg:请求访问/getInfo认证失败无法访问系统资源,code:401}这样的错误时这通常表示你的脚本在执行过程中遇到了认证问题。401状态码在HTTP协议中代表Unauthorized即未经授权的访问。1.1 401错误的常见原因在性能测试场景中401错误通常由以下几种情况导致Token缺失或过期现代Web应用普遍采用Token-based认证机制如果你的脚本中没有正确获取或传递Token就会触发401错误。认证信息配置错误在录制脚本时捕获的认证凭据可能已过期或者在回放时没有正确更新。会话超时某些系统的会话有效期较短在长时间的性能测试中可能导致会话过期。CORS(跨域)问题虽然CORS问题通常会返回403状态码但在某些配置下也可能表现为401错误。API密钥无效如果目标系统使用API密钥进行认证而你的脚本中配置的密钥不正确或已撤销。2. LoadRunner脚本中的认证机制2.1 Token-based认证处理现代Web应用最常见的认证方式是JWT(JSON Web Token)或OAuth Token。在LoadRunner中处理这类认证需要以下步骤获取Token通常通过登录接口获取web_reg_save_param_ex( ParamNameaccess_token, LB\access_token\:\, RB\, SEARCH_FILTERS, LAST); web_submit_data(login, Actionhttps://api.example.com/auth/login, MethodPOST, EncTypeapplication/json, Body{\username\:\{username}\,\password\:\{password}\}, LAST);在后续请求中使用Tokenweb_add_header(Authorization, Bearer {access_token}); web_custom_request(get_info, URLhttps://api.example.com/getInfo, MethodGET, LAST);2.2 基本认证(Basic Auth)处理对于使用Basic Auth的系统LoadRunner提供了专门的函数web_set_user(username, password, example.com:443);或者在请求头中直接添加char auth[100]; lr_save_string(lr_eval_string({username}:{password}), credentials); web_convert_param(credentials, ENCODING, BASE64, LAST); web_add_header(Authorization, Basic {credentials});3. 常见问题排查与解决方案3.1 Token过期问题症状脚本刚开始运行正常但一段时间后开始出现401错误。解决方案在脚本中添加Token刷新逻辑设置合理的Think Time模拟真实用户行为检查服务器设置的Token过期时间适当调整测试场景持续时间// Token刷新示例 if (strstr(lr_eval_string({response}), token_expired)) { web_reg_save_param_ex(ParamNamenew_token, ...); web_submit_data(refresh_token, ...); lr_save_string(lr_eval_string({new_token}), access_token); }3.2 认证信息未正确传递症状所有请求都返回401错误。排查步骤检查是否在所有需要认证的请求前添加了认证头使用LoadRunner的日志功能验证Token是否正确生成和传递对比录制脚本和实际请求的差异// 调试输出Token内容 lr_output_message(使用的Token是: %s, lr_eval_string({access_token}));3.3 动态认证参数处理很多系统会在登录时返回动态的CSRF Token或类似的防伪参数这些也需要捕获并在后续请求中使用web_reg_save_param_ex(ParamNamecsrf_token, LBinput type\hidden\ name\csrf_token\ value\, RB\, LAST); web_submit_form(login, ITEMDATA, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, Namecsrf_token, Value{csrf_token}, ENDITEM, LAST);4. 高级认证场景处理4.1 OAuth 2.0流程实现对于使用OAuth 2.0的系统需要在脚本中实现完整的授权码流程获取授权码用授权码交换访问令牌使用访问令牌访问资源必要时刷新令牌// 获取授权码 web_add_auto_header(Referer, {referer_url}); web_url(authorize, URLhttps://auth.example.com/authorize?response_typecodeclient_id{client_id}redirect_uri{redirect_uri}scope{scope}, Resource0, RecContentTypetext/html, LAST); // 从重定向URL中提取code web_reg_save_param_ex(ParamNameauth_code, LBcode, RB, LAST); // 交换Token web_submit_data(get_token, Actionhttps://auth.example.com/token, MethodPOST, EncTypeapplication/x-www-form-urlencoded, Bodygrant_typeauthorization_codecode{auth_code}redirect_uri{redirect_uri}client_id{client_id}client_secret{client_secret}, LAST);4.2 证书认证处理对于需要客户端证书的HTTPS服务需要在运行时设置证书web_set_certificate_ex(CertFilePathclient.pem, CertFormatPEM, KeyFilePathkey.pem, Password123456, LAST);5. 性能测试中的认证优化在长时间运行的性能测试场景中认证处理需要考虑以下优化Token缓存避免每次迭代都重新获取Token连接复用保持HTTP连接活跃减少握手开销合理的认证频率根据业务场景设计认证频率// 使用lr_user_data_point实现Token缓存 if (lr_user_data_get(cached_token) NULL) { // 获取新Token get_new_token(); lr_user_data_put(cached_token, lr_eval_string({access_token})); } else { lr_save_string(lr_user_data_get(cached_token), access_token); }6. 调试技巧与工具6.1 使用Fiddler辅助调试配置LoadRunner使用Fiddler作为代理web_set_proxy(localhost:8888);在Fiddler中检查实际发送的请求和接收的响应对比成功和失败的请求差异6.2 LoadRunner日志分析启用详细日志记录web_set_option(Log, ALL, LAST);在日志中搜索HTTP/1.1 401Authorization:WWW-Authenticate:6.3 使用web_get_int_property检查状态码web_url(api_call, URLhttp://example.com/api, LAST); int http_status web_get_int_property(HTTP_INFO_RETURN_CODE); if (http_status 401) { lr_error_message(认证失败HTTP状态码: %d, http_status); // 处理认证失败逻辑 }7. 最佳实践与经验分享认证信息参数化永远不要在脚本中硬编码用户名密码lr_save_string(lr_eval_string({vuser}_user), username);错误处理为认证失败添加专门的错误处理逻辑环境隔离确保测试环境与录制环境一致定期维护随着系统认证机制升级更新测试脚本一个健壮的认证处理框架示例vuser_init() { // 初始化认证信息 if (do_authentication() ! LR_PASS) { lr_exit(LR_EXIT_VUSER_FAIL, 初始化认证失败); } return 0; } action() { // 主业务逻辑 if (call_protected_api() 401) { // 尝试刷新Token if (refresh_token() ! LR_PASS) { // 刷新失败重新认证 if (do_authentication() ! LR_PASS) { lr_exit(LR_EXIT_VUSER_FAIL, 重新认证失败); } } // 重试原始请求 call_protected_api(); } return 0; } int do_authentication() { // 实现认证逻辑 // 返回LR_PASS或LR_FAIL } int refresh_token() { // 实现Token刷新逻辑 // 返回LR_PASS或LR_FAIL }在实际项目中认证问题往往是性能测试脚本中最常见的故障点之一。掌握这些认证处理技巧可以显著提高脚本的稳定性和可靠性。 1. LoadRunner认证失败问题解析当你在LoadRunner中遇到{msg:请求访问/getInfo认证失败无法访问系统资源,code:401}这样的错误时这通常表示你的脚本在执行过程中遇到了认证问题。401状态码在HTTP协议中代表Unauthorized即未经授权的访问。1.1 401错误的常见原因在性能测试场景中401错误通常由以下几种情况导致Token缺失或过期现代Web应用普遍采用Token-based认证机制如果你的脚本中没有正确获取或传递Token就会触发401错误。认证信息配置错误在录制脚本时捕获的认证凭据可能已过期或者在回放时没有正确更新。会话超时某些系统的会话有效期较短在长时间的性能测试中可能导致会话过期。CORS(跨域)问题虽然CORS问题通常会返回403状态码但在某些配置下也可能表现为401错误。API密钥无效如果目标系统使用API密钥进行认证而你的脚本中配置的密钥不正确或已撤销。2. LoadRunner脚本中的认证机制2.1 Token-based认证处理现代Web应用最常见的认证方式是JWT(JSON Web Token)或OAuth Token。在LoadRunner中处理这类认证需要以下步骤获取Token通常通过登录接口获取web_reg_save_param_ex( ParamNameaccess_token, LB\access_token\:\, RB\, SEARCH_FILTERS, LAST); web_submit_data(login, Actionhttps://api.example.com/auth/login, MethodPOST, EncTypeapplication/json, Body{\username\:\{username}\,\password\:\{password}\}, LAST);在后续请求中使用Tokenweb_add_header(Authorization, Bearer {access_token}); web_custom_request(get_info, URLhttps://api.example.com/getInfo, MethodGET, LAST);2.2 基本认证(Basic Auth)处理对于使用Basic Auth的系统LoadRunner提供了专门的函数web_set_user(username, password, example.com:443);或者在请求头中直接添加char auth[100]; lr_save_string(lr_eval_string({username}:{password}), credentials); web_convert_param(credentials, ENCODING, BASE64, LAST); web_add_header(Authorization, Basic {credentials});3. 常见问题排查与解决方案3.1 Token过期问题症状脚本刚开始运行正常但一段时间后开始出现401错误。解决方案在脚本中添加Token刷新逻辑设置合理的Think Time模拟真实用户行为检查服务器设置的Token过期时间适当调整测试场景持续时间// Token刷新示例 if (strstr(lr_eval_string({response}), token_expired)) { web_reg_save_param_ex(ParamNamenew_token, ...); web_submit_data(refresh_token, ...); lr_save_string(lr_eval_string({new_token}), access_token); }3.2 认证信息未正确传递症状所有请求都返回401错误。排查步骤检查是否在所有需要认证的请求前添加了认证头使用LoadRunner的日志功能验证Token是否正确生成和传递对比录制脚本和实际请求的差异// 调试输出Token内容 lr_output_message(使用的Token是: %s, lr_eval_string({access_token}));3.3 动态认证参数处理很多系统会在登录时返回动态的CSRF Token或类似的防伪参数这些也需要捕获并在后续请求中使用web_reg_save_param_ex(ParamNamecsrf_token, LBinput type\hidden\ name\csrf_token\ value\, RB\, LAST); web_submit_form(login, ITEMDATA, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, Namecsrf_token, Value{csrf_token}, ENDITEM, LAST);4. 高级认证场景处理4.1 OAuth 2.0流程实现对于使用OAuth 2.0的系统需要在脚本中实现完整的授权码流程获取授权码用授权码交换访问令牌使用访问令牌访问资源必要时刷新令牌// 获取授权码 web_add_auto_header(Referer, {referer_url}); web_url(authorize, URLhttps://auth.example.com/authorize?response_typecodeclient_id{client_id}redirect_uri{redirect_uri}scope{scope}, Resource0, RecContentTypetext/html, LAST); // 从重定向URL中提取code web_reg_save_param_ex(ParamNameauth_code, LBcode, RB, LAST); // 交换Token web_submit_data(get_token, Actionhttps://auth.example.com/token, MethodPOST, EncTypeapplication/x-www-form-urlencoded, Bodygrant_typeauthorization_codecode{auth_code}redirect_uri{redirect_uri}client_id{client_id}client_secret{client_secret}, LAST);4.2 证书认证处理对于需要客户端证书的HTTPS服务需要在运行时设置证书web_set_certificate_ex(CertFilePathclient.pem, CertFormatPEM, KeyFilePathkey.pem, Password123456, LAST);5. 性能测试中的认证优化在长时间运行的性能测试场景中认证处理需要考虑以下优化Token缓存避免每次迭代都重新获取Token连接复用保持HTTP连接活跃减少握手开销合理的认证频率根据业务场景设计认证频率// 使用lr_user_data_point实现Token缓存 if (lr_user_data_get(cached_token) NULL) { // 获取新Token get_new_token(); lr_user_data_put(cached_token, lr_eval_string({access_token})); } else { lr_save_string(lr_user_data_get(cached_token), access_token); }6. 调试技巧与工具6.1 使用Fiddler辅助调试配置LoadRunner使用Fiddler作为代理web_set_proxy(localhost:8888);在Fiddler中检查实际发送的请求和接收的响应对比成功和失败的请求差异6.2 LoadRunner日志分析启用详细日志记录web_set_option(Log, ALL, LAST);在日志中搜索HTTP/1.1 401Authorization:WWW-Authenticate:6.3 使用web_get_int_property检查状态码web_url(api_call, URLhttp://example.com/api, LAST); int http_status web_get_int_property(HTTP_INFO_RETURN_CODE); if (http_status 401) { lr_error_message(认证失败HTTP状态码: %d, http_status); // 处理认证失败逻辑 }7. 最佳实践与经验分享认证信息参数化永远不要在脚本中硬编码用户名密码lr_save_string(lr_eval_string({vuser}_user), username);错误处理为认证失败添加专门的错误处理逻辑环境隔离确保测试环境与录制环境一致定期维护随着系统认证机制升级更新测试脚本一个健壮的认证处理框架示例vuser_init() { // 初始化认证信息 if (do_authentication() ! LR_PASS) { lr_exit(LR_EXIT_VUSER_FAIL, 初始化认证失败); } return 0; } action() { // 主业务逻辑 if (call_protected_api() 401) { // 尝试刷新Token if (refresh_token() ! LR_PASS) { // 刷新失败重新认证 if (do_authentication() ! LR_PASS) { lr_exit(LR_EXIT_VUSER_FAIL, 重新认证失败); } } // 重试原始请求 call_protected_api(); } return 0; } int do_authentication() { // 实现认证逻辑 // 返回LR_PASS或LR_FAIL } int refresh_token() { // 实现Token刷新逻辑 // 返回LR_PASS或LR_FAIL }在实际项目中认证问题往往是性能测试脚本中最常见的故障点之一。掌握这些认证处理技巧可以显著提高脚本的稳定性和可靠性。