压力测试跑完以后，工具里往往会生成好多张图表，如果只是顺着顺序一张一张往下翻，通常很难一下子抓到真正有用的信息，所以要弄清楚LoadRunner Analysis里的图表到底该怎么看，又该怎么从这些图表里面判断出系统的瓶颈到底卡在了哪里，比较合理的思路是先关注用户负载和各个事务的响应时间，接着再把吞吐量、请求数量、错误数量以及服务器那边的资源数据结合起来一起分析，光是看到响应时间变长了，只能说明系统处理变慢了，并不能直接断定问题就是出在数据库、网络或者应用程序本身。

LoadRunner脚本乱码怎么解决，LoadRunner脚本只显示添加事务，很多人第一次碰到这类问题时，习惯先去重装VuGen，或者到处找补丁文件，结果折腾半天还是没解决。真正麻烦的地方往往不在软件有没有装好，而在脚本编码、录制协议、录制选项和当前显示方式没有对齐。

真正决定一场性能测试有没有价值的，往往不是脚本会不会录，而是脚本、场景、负载、监控和参数有没有被放进同一条执行链里。OpenText官方帮助把VuGen运行时设置、Controller场景控制、负载发生器分配和监控能力分开管理，这本身就说明LoadRunner压力测试不是“录完脚本直接开压”这么简单，而是一套从业务建模到结果判断的完整流程。

做WebSocket压测时，很多人前面不是录不到流量，而是录出来以后脚本能生成，回放却总是握手失败、连接断开，或者连上以后消息发不出去。这类问题往往不是某一行代码单独写错，而是录制入口、握手头、代理链路和回放协议边界没有放在同一套思路里看。OpenText官方文档里已经把这件事拆开了，DevWeb的Proxy Recorder支持WebSocket录制，脚本里也有专门的`web_websocket_connect`和`web_websocket_send`这类步骤，所以要把问题收住，关键是先把录制链路和握手层站稳。

在LoadRunner里，事务不是随便给一段脚本起个名字，而是用开始和结束函数把一段可分析的业务步骤圈出来。官方帮助把事务定义得很直接，事务要用开始函数和结束函数成对标记，后续分析才会把这段时间当成可统计的业务响应时间来看。

LoadRunner Analysis打不开结果怎么办，LoadRunner结果文件损坏怎么修复，现场最常见的不是软件突然失灵，而是结果目录不完整、汇总未完成、路径权限与区域设置触发解析异常，或结果索引在中断时写坏。

做Web脚本时，LoadRunner常见卡点是VuGen录制HTTPS抓不到包，或录完回放因证书校验报错中断。多数不是脚本写错，而是录制代理没接管流量、根证书未被信任、或网络安全设备在TLS握手阶段拦截。按“先代理后证书、先录制后回放”的顺序拆解，定位会快很多。

同一套脚本、同一套场景，压测结果却一会儿高一会儿低，通常不是某个参数“没调对”，而是测试链路里有不稳定因素在反复叠加，比如数据复用、调度曲线抖动、环境抢占、监控口径不一致。想把波动压下去并定位瓶颈，需要先把可控项收紧，再用场景调度把系统推到可复现的稳态，最后把响应时间与资源曲线对齐，找出是服务器饱和、数据库阻塞、网络瓶颈，还是压测机自身在拖后腿。

在进行Web或API接口性能测试时，LoadRunner作为业界广泛使用的负载测试工具，其关联参数功能是确保脚本运行稳定、场景真实还原的关键一环。尤其在处理动态请求参数（如session、token、GUID等）时，参数关联的提取与传递直接影响脚本是否能持续运行。在复杂系统中，如果脚本在执行过程中出现“参数未找到”“值为空”等提示，很可能就是关联机制失效，影响了整体测试链路的还原效果。因此，理解其失效原因与应对方法是性能测试人员的基本功。

在使用LoadRunner进行性能测试时，“思考时间”是一个容易被忽略却对结果影响巨大的参数。所谓思考时间，指的是模拟用户在操作系统时每两个动作之间的停顿时间。合理设置思考时间有助于模拟更真实的用户行为，避免测试结果过于理想化或与实际使用场景偏差太大。本文将围绕“LoadRunner思考时间如何设置”和“LoadRunner思考时间对吞吐影响应怎样评估”两个方面，详细说明其配置步骤和评估方法。