场景

用loadrunner11录制脚本，处理后回放，加上检查点，报错找不到检查点对应的内容，去掉检查点，没有报错，但是打开页面没有该操作的痕迹。手动在页面上操作没有问题。

解决过程

1. 怀疑是脚本中请求有问题或者没有作关联。在页面上通过开发者工具（F12）查看几个关键请求，都没有问题，顺序和内容都能对得上。使用到的参数和返回值，都是固定的，无须关联。
2. 查看应用日志，看是否有报错信息。应用有十几个中心，通过dubbo调用，然而由于使用的docker容器，日志没有做改造，无法进行采集查看，而且启用的容器数量比较多，还有其他人使用，查看入口的web容器日志（6个），跑loadrunner脚本，无法看清日志内容，只能作罢。
3. 使用postman模拟loadrunner中报错的请求。将loadrunner中的请求转换在postman中实现，发现报错用户没有登录。这次采用的架构与之前不同，后端为java应用，前端为react，通过接口和后端交互，所以其实loadrunner中的请求与前端和后端交互的请求基本一致，但是loadrunner没有保存接口要求的验证信息token，同时，token经过一定时间要求更新，所以出现该问题。

解决方案

知道了问题为loadrunner请求时没有在header中加入token，就简单了很多。在登录步骤，获取token，然后，在需要token认证的步骤的header中加入token。

// token长度较长，web_reg_save_param默认长度为256，不够存储，所以需要该函数设置其长度（1024字节）
web_set_max_html_param_len("1024");
// 获取token函数，第一个参数为存储的变量名，LB和RB为左边界和右边界，ORD为第几位，NotFound为找不到时的响应
web_reg_save_param("token",
    "LB=\"token\":\"",
    "RB=\"",
    "ORD=1",
    "NotFound=warning",
    LAST);
// 打印
lr_output_message("token is %s\n",lr_eval_string("{token}"));
// 为接下来的请求header添加内容
web_add_header("token","{token}");

总结

压测相关的东西，现在是在边实战边学（主要是之前搞压测的同事离职了），之前看着同事弄，感觉很简单，就是录制，然后参数化，关联，就完事了，只要懂业务就行了，自己上手了才发现，好多loadrunner方面的东西很多都不懂，还有业务方面也有很多不懂，还是要多动手多学习。