录制时能登录、能查询，回放却提示会话失效，或者停在某个请求上。LoadRunner脚本遇到这类问题，往往要回到请求内容和服务器响应中找原因。下面介绍“LoadRunner怎么创建性能测试脚本LoadRunner脚本运行失败怎么排查”。操作以VuGen 26.1英文界面的Web-HTTP/HTML协议为例，录制一个登录后查询的流程。

做性能测试时，脚本录制往往是比较容易出现问题的环节。测试人员按照正常流程操作系统，但LoadRunner生成的脚本可能没有记录有效请求，或者录制完成后回放结果和实际操作存在差异。尤其是在接口调整、系统升级或者测试环境变化后，之前能够运行的脚本也可能出现异常。处理这些情况时，单纯重新录制并不能解决所有问题，还需要了解脚本生成方式以及错误出现的位置。

LoadRunner的思考时间怎么配置，回放的时候它又为什么会被忽略掉，这里头的重点，并不是脚本里面有没有写lr_think_time这一句，而是运行时的设置，到底有没有让它真正起作用。思考时间这个东西，是用来模仿真实用户的那种操作间隔的，像是页面之间的停顿、阅读里头的内容、填写一些信息，还有做选择的这些过程。在调试脚本的那个阶段，可以暂时不管它，可是一旦到了正式去压测的时候，要是还一直把它给忽略掉，那些虚拟的用户就会一个接一个不停地发请求，这样一来，压力的模型就很容易跑偏，跟真实业务的节奏对不上了。

做性能测试时，把脚本录制下来之后，如果从头到尾只留着一整段Action，等拿到测试报告，就很难一眼看出来到底是登录的时候慢了，还是提交订单那一步卡住了。所以，搞清楚LoadRunner VuGen里的脚本该怎么去合理地拆分事务，关键就是要把一条完整的业务流程，切成好几个可以独立观察的动作。在VuGen里面，用来标记事务开始的函数叫lr_start_transaction，用来标记结束的叫lr_end_transaction，这一前一后包起来的范围里，每一步消耗的时间都会被单独记录下来。

真正容易做偏的地方，不是脚本会不会录，而是很多人把“并发测试”等同于“把用户数调大”。实际上，OpenText官方资料把Running Vusers、事务响应时间、Think Time、Pacing、负载发生器分配和在线监控都拆成独立模块管理，这说明LoadRunner并发测试不是单纯堆用户，而是在受控节奏下持续制造可解释的业务压力。

做性能测试时，思考时间往往不是最显眼的设置，但它会直接改变脚本发请求的节奏。LoadRunner官方把Think Time定义为Vuser在动作之间等待的时间，用来模拟真实用户在点击、阅读和输入之间的停顿；同时，Pacing又单独控制迭代之间的间隔，这说明思考时间和并发模型本来就是两层不同的控制项。要是这一步设得太激进，请求密度会被放大；设得太保守，又可能把系统压力压低，最后并发结果和真实使用场景偏差很大。

做并发压测时，集合点的作用不是把脚本写复杂，而是把原本分散到不同时间发出的请求，尽量压到同一时刻打出去。OpenText官方文档对这个机制说得很直接，集合点就是让多个Vuser在脚本里的某个位置停住，等达到指定人数或满足释放条件后再一起继续执行；而且集合点只在【Action】段有效，不能放在【vuser_init】和【vuser_end】里。也正因为这样，集合点放得对，才能测到真正的峰值冲击，放得不对，结果就很容易失真。

在LoadRunner里做参数化，真正影响脚本可用性的，不是把固定值替换成参数这一步，而是参数类型、取值方式、更新时机和数据文件引用路径有没有一次配对。VuGen官方文档明确说明，参数可以直接从脚本步骤里创建，也可以通过参数属性窗口设置成File或Table类型，再决定按顺序、随机还是唯一值去取数。

LoadRunner压测一旦出现Controller连不上负载机，优先按解析、连通、端口、服务、版本五步查，不要先改脚本。把问题拆成可验证动作，能快速判断是负载机端口没开，还是中间网络把连接拦掉。

做性能调优最怕一上来就堆并发，脚本不稳、节奏不真、口径不清，跑出来的数据再漂亮也很难指导改进。更稳的做法是先把脚本正确性和测量边界打牢，再逐步把负载节奏拉到接近真实用户，最后才进入定位瓶颈与对比验证。