当压力测试的并发用户数逐渐增加时，负责产生负载的机器有时会先成为性能瓶颈。LoadRunner的负载机应该如何分配才能更合理，分配不均匀又会导致哪些问题，这需要结合脚本所用的协议、虚拟用户的数量、负载机的硬件配置以及网络位置等条件来综合判断。在LoadRunner中，Controller会把Vuser分派到各个负载机上执行，一台负载机能够同时运行多个不同类型的Vuser脚本，所以在正式测试开始之前，应当确保每台负载机都留有足够多的处理能力。

LoadRunner录制脚本步骤，LoadRunner录制脚本时无法打开网页，很多人一碰到这类问题，第一反应就是重装VuGen，或者反复换浏览器重试。真正容易出问题的地方，往往不在软件有没有装好，而在录制协议、录制方式、浏览器启动方式、系统权限和网络代理没有对齐。

很多人做性能测试时，习惯先录脚本、再拉并发，最后盯着响应时间看系统有没有变慢。真正有效的LoadRunner性能测试并不是只看一两个数字，而是先把“指标”与“参数”分开理解：指标负责说明系统在压力下表现成什么样，参数负责决定这股压力是怎样被制造出来的。

很多人看LoadRunner结果时，第一眼只盯TPS，看到曲线上下起伏就觉得系统不稳。其实TPS只是现象，真正有用的是先把曲线调出来，再和并发、响应时间、错误和资源类图一起对着看。OpenText官方说明里已经把这条路写得很清楚，Analysis里可以手工打开事务图，也可以把多张图做关联分析；而事务监控图本身就区分了成功事务每秒数、失败停止事务每秒数和总成功事务每秒数。

LoadRunner做并发爬升时，真正要控制的不是“多久把人加满”这一件事，而是让并发增长速度与系统承载能力、登录链路、负载机资源三者保持一致。官方资料对调度器的定位很明确，Scheduler用于在一定时间范围内安排Vuser启动和停止，并且最佳实践明确提醒，爬升过快会让大量Vuser进入pending之类的等待状态，这通常就是爬升速度过头的信号。

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

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

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

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

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

做性能测试时，把脚本录制下来之后，如果从头到尾只留着一整段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关联的参数怎么去找，LoadRunner关联参数保存使用，很多人一遇到脚本回放失败，就先去改请求体里的动态值，结果越改越乱。真正有效的处理方式，不是盯着报错行死改，而是先把“动态值从哪里来、在哪一步被返回、在哪一步被再次提交”这一条链路找出来。

很多人一提到性能测试，第一反应就是把脚本录完、把并发拉高、把结果图导出来，好像这样就已经完成了测试。真正有价值的LoadRunner性能测试，并不是只看系统有没有慢下来，而是先搞清楚性能测试到底在测什么，再把运行过程中的事务、虚拟用户、吞吐量、命中率、错误率和资源曲线放到同一套逻辑里解释。

LoadRunner里所谓动态Token，核心不是把值改成参数这么简单，而是先找到它出现在哪一次响应里，再决定用边界、正则还是JSON方式去提取。VuGen官方文档把这条线说得很清楚，Design Studio里的【Correlation】页可以先扫描脚本里的动态值，再按定义应用关联；而真正落到代码里，常见提取函数主要就是基于边界的`web_reg_save_param_ex`、基于正则的`web_reg_save_param_regexp`和基于JSONPath的`web_reg_save_param_json`。

LoadRunner结果整理最好分成两步做，先把分析结果导成正式报告，再按需要生成图表和明细数据。官方帮助写得很清楚，Analysis支持把分析结论发布为HTML报告或Word报告，离线结果页里的HTML Report本质上也是Analysis Summary Report，里面会带测试概要、统计信息和图表链接。

做LoadRunner脚本时，关联最容易出问题的地方，不是函数不会写，而是动态值还没找全就急着回放。VuGen官方说明里已经把路径写得很清楚，【Design Studio】里的【Correlation】页就是专门用来扫描、关联和管理动态值的，而且它支持规则扫描、录制后扫描和回放后扫描三种方式。实际处理时，先把动态值找准，再决定是直接关联，还是沉淀成规则，脚本会稳很多。