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

　　一、LoadRunner压力测试主要步骤

　　做LoadRunner压力测试，最稳妥的方式不是一上来就堆并发，而是先把业务流程、脚本可靠性、场景编排和监控目标逐项定清。因为Controller负责把脚本、运行时设置和负载发生器统一调度，任何一个环节前置不清，后面的响应时间、吞吐量和错误率都会失真。

　　1、先明确业务流程和测试目标

　　（1）开始做LoadRunner压力测试前，先把登录、查询、提交、支付这类核心业务拆成独立事务，不要把整站流程混成一段脚本；

　　（2）同时要先定清本次测试到底是看峰值承载、持续稳定性，还是看容量拐点，不同目标决定后面的加压曲线和持续时长；

　　（3）如果目标都没定清，后面即使跑出一堆图表，也很难判断这场LoadRunner压力测试到底测到了什么。

　　2、再用VuGen把脚本跑稳

　　（1）脚本录制后先在VuGen里单独回放，确认关联、参数化、检查点和事务边界没有问题；

　　（2）官方说明里写得很清楚，运行时设置可以在VuGen中配置，也能在Controller场景中修改，但Controller里的修改只对当前场景生效，不会反写原脚本；

　　（3）所以这一步的重点，不是录完就算完成，而是先把单脚本的可回放性和可重复性做扎实。

　　3、然后在Controller里建立场景

　　（1）把脚本加入场景后，要先按业务组拆分，再分配每组虚拟用户数量和对应的负载发生器；

　　（2）官方帮助中心对load generator的说明强调，Controller会将脚本分发到不同发生器上运行，因此场景设计本身就是负载设计；

　　（3）如果负载机数量不够、分配不均或发生器本身不稳定，LoadRunner压力测试很可能先卡在测试环境侧，而不是被测系统侧。

　　4、最后配好监控再开压

　　（1）LoadRunner压力测试不能只看事务时间，还要同步监控服务器和中间件资源；

　　（2）官方监控文档列出了监控配置与监控概览，说明性能测试本来就要求把应用、系统和资源数据一起纳入观察范围；

　　（3）先把监控布好，再启动场景，后面分析时才知道问题出在应用逻辑、数据库资源，还是负载机本身。

　　二、LoadRunner压力测试参数设置

　　LoadRunner压力测试参数设置，关键不在于参数越多越专业，而在于每个参数都要服务于真实负载模型。官方运行时设置页把Think Time、Pacing、Run Logic、Log等分成独立配置项，这说明参数设置本质上是在模拟真实用户节奏，而不是机械地把并发数调高。

　　1、并发用户数和加压节奏要分开设

　　（1）虚拟用户数量决定压力规模，但真正影响系统波峰的，往往是加压方式是一口气拉满，还是按阶梯逐步爬升；

　　（2）如果只盯总用户数，不控制启动速率，LoadRunner压力测试结果很容易偏激，系统可能被瞬时打爆，却不能反映真实高峰表现；

　　（3）因此并发数和加压曲线必须一起设计，不能把它们当成同一个参数。

　　2、Think Time不能一律忽略

　　（1）官方文档明确给出了Ignore、Recorded、Multiply、Random等think time方式；

　　（2）Think Time的本质是模拟用户操作间隔，完全忽略会让请求密度远高于真实用户；

　　（3）只有在明确做极限压测时，才适合谨慎压缩think time，否则多数LoadRunner压力测试都应该保留合理停顿。

　　3、Pacing决定每轮迭代的压强

　　（1）官方运行时设置说明里写到，Pacing用来控制迭代之间的时间间隔；

　　（2）如果Pacing太短，同一个虚拟用户会高频重复业务动作，系统承受的就不只是用户规模，而是循环密度；

　　（3）所以LoadRunner压力测试参数设置里，Pacing往往和并发数一样重要，它直接决定压力是不是贴近真实业务节奏。

　　4、日志和迭代设置要按阶段控制

　　（1）官方运行时设置页把Log和Run Logic单独列出，说明日志级别和迭代次数本来就是独立控制项；

　　（2）脚本调试阶段可以适当开细日志，但正式LoadRunner压力测试阶段日志过重会拖慢执行效率，也会放大结果文件体量；

　　（3）更稳妥的做法，是调试时开细、压测时收敛，同时让迭代次数和测试时长与目标场景保持一致。

　　三、LoadRunner压力测试结果监控与瓶颈判断

　　很多人把注意力都放在脚本和参数上，真正决定结论是否可信的，往往是结果阶段的监控与判断。LoadRunner压力测试不是看到响应时间升高就算发现问题，而是要把事务、并发、系统资源和负载发生器状态放在一起看，才能判断瓶颈到底落在哪里。

　　1、先看事务曲线和并发曲线是否同步

　　（1）如果并发上升时事务响应也同步恶化，通常说明系统已经接近容量边界；

　　（2）如果并发还没到目标值，响应曲线就提前大幅波动，就要先怀疑脚本、负载机或环境配置；

　　（3）这一步能先判断问题更像是系统瓶颈，还是测试链路本身不稳定。

　　2、再看服务器和数据库资源

　　（1）性能测试里最怕只盯前台结果，不去看后台资源；

　　（2）如果CPU、内存、磁盘、网络或数据库资源在同一时间段同步异常，瓶颈位置通常就更容易缩小；

　　（3）因此LoadRunner压力测试的监控价值，不只是记录资源曲线，而是让你知道响应变慢到底是应用层、数据库层还是基础设施层引起的。

　　3、最后把参数回扣到测试结论

　　（1）一份可靠的结论，必须交代本次使用了多少并发、什么加压节奏、怎样的think time、怎样的pacing和多长持续时间；

　　（2）否则同一套系统换一组参数，测出来的表现可能完全不同；

　　（3）真正成熟的LoadRunner压力测试报告，不能只给结果数字，还要把步骤、参数和监控结论放在同一逻辑里解释。

　　总结

　　LoadRunner压力测试主要步骤，LoadRunner压力测试参数设置，真正高效的做法不是录完脚本就直接堆用户，而是先把业务流程、脚本可靠性、Controller场景、负载发生器、监控范围和运行时参数一项项定清，再用Think Time、Pacing、并发和资源曲线去还原真实压力模型。