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

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

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

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

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

LoadRunner命令行怎么启动场景，LoadRunner在Jenkins里怎么自动运行，核心是把场景运行、结果落盘、日志留痕三件事一次固定。

在性能测试中，LoadRunner脚本的录制与回放环节至关重要。然而实际操作过程中，很多用户常常遇到脚本回放失败、执行中断或结果异常的问题，这类问题一旦出现，将严重影响测试进度与数据可信度。回放异常的根源往往不在脚本逻辑本身，而是出现在变量设置、依赖环境或服务器响应方面，因此，分析回放失败的原因与规范环境配置成为提升测试质量的关键一步。

在进行并发性能测试时，如果用户请求的发起时机过于分散，可能无法准确模拟高并发下的真实业务压力。此时，使用LoadRunner的“集合点”功能可以强制多个虚拟用户在某一时刻同时执行指定操作，从而提升测试的真实性和控制力。很多新手在使用集合点时要么设置无效，要么导致触发时机不当，因此理解其使用方法和触发机制显得尤为重要。

在性能测试中，脚本录制是整条链路的起点。只要录制不稳，回放与压测都会受影响。下面给出可直接执行的排查清单与环境配置方法，并补充提升稳定性的做法，帮助快速恢复录制效率。

在使用LoadRunner进行压力测试之后，生成的测试报告包含了大量指标和图表，其中TPS与响应时间是评估系统性能的核心参考值。然而，许多初学者在面对这份报告时往往感到困惑，不知道该如何解读这些数据，也无法准确判断性能瓶颈所在。本文将围绕“LoadRunner测试报告怎么看不懂”以及“LoadRunner报告中TPS和响应时间怎么解释”这两个关键问题展开，帮助你建立起对测试结果的分析能力。