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连不上负载机，优先按解析、连通、端口、服务、版本五步查，不要先改脚本。把问题拆成可验证动作，能快速判断是负载机端口没开，还是中间网络把连接拦掉。

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

在使用LoadRunner进行性能测试时，经常会遇到事务响应时间波动剧烈的情况。即便是同一个事务，在不同虚拟用户、不同负载强度或测试阶段中，响应时间可能呈现毫无规律的跳跃变化。表面看似“网络不稳”或“系统偶发”，其实背后往往与资源瓶颈、测试策略、事务设计不合理密切相关。只有结合实际业务逻辑和指标分析，才能真正定位波动来源，提升测试价值。

在性能测试中，监控数据是判断系统健康与瓶颈位置的关键依据。LoadRunner既能在压测过程中实时展示曲线，也能在测试结束后回放分析。要看懂这些数据并让它稳定刷新，需要明确查看入口、理解常见指标，并为异常刷新准备可执行的修复步骤。