真正容易做偏的地方，不是脚本会不会录，而是很多人把“并发测试”等同于“把用户数调大”。实际上，OpenText官方资料把Running Vusers、事务响应时间、Think Time、Pacing、负载发生器分配和在线监控都拆成独立模块管理，这说明LoadRunner并发测试不是单纯堆用户，而是在受控节奏下持续制造可解释的业务压力。

　　一、LoadRunner如何进行并发测试

　　做LoadRunner并发测试，最稳妥的顺序不是先在Controller里把用户数拉满，而是先把业务流程拆清，再把脚本跑稳，再做场景调度和监控配置。因为官方文档已经说明，Controller会把脚本分发到不同的负载发生器上运行，而运行中的表现会通过Running Vusers、Error Statistics、Throughput等图表实时显示出来，所以并发测试本质上是一套“脚本、场景、负载机、监控”联动执行的过程。

　　1、先把并发测试对象拆成业务事务

　　（1）不要把整站动作录成一段大脚本，应该先拆成登录、查询、提交、支付这类关键事务；

　　（2）事务拆得清楚，后面才知道是哪一步先慢、哪一步先报错；

　　（3）LoadRunner并发测试看的是核心业务在压力上升时如何变化，不是只看整段脚本能不能跑通。

　　2、再把脚本在VuGen里先跑稳

　　（1）脚本录完后先做关联、参数化和检查点处理，再单用户回放；

　　（2）如果单脚本都不稳定，后面并发一拉高，错误会被误判成系统瓶颈；

　　（3）并发测试的第一前提，不是用户多，而是脚本本身可重复、可执行。

　　3、然后在Controller里设计并发场景

　　（1）把脚本按业务组放入场景，再分配每组Vuser数量和负载发生器；

　　（2）如果多组业务同时跑，还要控制各组启动顺序和爬升节奏；

　　（3）这一步决定的不是“有没有压力”，而是“压力是不是接近真实用户行为”。

　　4、最后配监控再开压

　　（1）并发测试不能只看事务时间，还要同时看Running Vusers、Throughput、Errors和资源监控；

　　（2）如果并发没涨上去，响应却先抖动，就要优先怀疑脚本或负载机；

　　（3）如果并发、吞吐、错误和资源在同一时间段一起恶化，才更接近真实瓶颈。

　　二、LoadRunner并发用户数怎么计算

　　LoadRunner并发用户数怎么计算，不能只靠一句“系统平时有多少在线用户”去拍脑袋。因为在LoadRunner里，真正形成压力的不是名义用户数，而是虚拟用户在单位时间内以什么节奏反复执行事务。官方运行时文档对Think Time和Pacing的定义很清楚：Think Time是用户在业务步骤之间的停顿，Pacing是迭代与迭代之间的等待时间。也正因为这两个参数会直接改变请求密度，所以并发用户数的计算一定要结合业务操作间隔一起看。

　　1、先按真实在线用户做第一层估算

　　（1）如果业务侧能给出高峰在线人数，可以先把它当作上限参考，而不是直接等同为压测并发；

　　（2）真正要进场景的并发用户数，还要乘上目标业务渗透率，例如只有部分在线用户会同时执行下单或查询；

　　（3）这样算出来的数字，才更接近某个事务的真实并发规模。

　　2、再按事务节奏做第二层换算

　　（1）工程上常把并发近似理解为“单位时间内正在执行该业务的人数”；

　　（2）如果某事务每秒期望到达量较高，而单次业务完成时长又较长，那么同一时刻挂在系统里的活跃用户自然会增加；

　　（3）所以LoadRunner并发用户数怎么计算，不能脱离响应时间、Think Time和Pacing单独看。

　　3、参数设置会反过来改变并发结果

　　（1）Think Time如果完全忽略，同一批Vuser会更快重复动作，等效压力会被放大；

　　（2）Pacing如果设置过短，同一用户会高频迭代，系统承受的就不只是“用户数量”，还是“循环密度”；

　　（3）因此同样500个Vuser，在不同参数下，LoadRunner并发测试的真实压强可能完全不同。

　　4、最终要用Running Vusers回头验证

　　（1）算出来的并发用户数只是预估值，不是最终结论；

　　（2）正式运行后要看Running Vusers曲线是否按预期爬升，并和事务响应时间做相关分析；

　　（3）如果曲线和预估差异很大，就要回头调整用户数、加压节奏、Think Time或Pacing，而不是盲目继续加人。

　　三、LoadRunner并发模型怎么设计更合理

　　很多测试结果不可信，不是因为工具不准，而是并发模型设计得太粗。真正合理的LoadRunner并发测试，不是把所有Vuser同时压上去，而是把预热、爬升、稳定、峰值和回落分段设计出来，再结合事务、吞吐、错误和资源变化判断系统在哪个点开始失稳。

　　1、先做分段加压

　　（1）先预热，再逐步加压，再保持稳定一段时间，最后再冲峰值；

　　（2）这样更容易分清系统是冷启动慢，还是高负载下才出问题；

　　（3）比起一步到位拉满用户，分段加压更适合定位容量拐点。

　　2、把并发和指标放在同一时间轴上

　　（1）看Running Vusers的同时，要同步看事务响应时间和错误数；

　　（2）如果并发上升而事务还能稳住，说明系统还有余量；

　　（3）如果并发略增就伴随错误和吞吐波动，说明瓶颈更早出现。

　　3、最后把结果回扣到业务目标

　　（1）不要只写“本次并发1000用户”，还要说明这是哪类业务的并发；

　　（2）也不要只写“系统通过”，还要说明在什么节奏、什么事务组合下通过；

　　（3）这样整理出来的LoadRunner并发测试结论，才真正能支撑容量评估和后续优化。

　　总结

　　LoadRunner如何进行并发测试，LoadRunner并发用户数怎么计算，真正高效的做法不是先录完脚本再把用户数拉高，而是先把业务事务拆清，再把脚本跑稳，再在Controller里设计场景、配置Think Time和Pacing，最后用Running Vusers、事务时间、吞吐和错误去验证并发模型是否成立。把“怎么测”和“怎么算”连起来之后，LoadRunner并发测试才不会停留在单纯堆压的层面，而会真正变成判断系统容量边界和业务承载能力的分析方法。