脚本单次回放正常，改成多次迭代后却跳回登录页，这种问题经常与脚本分段、会话设置有关。登录放在初始化段，意味着它不会跟着每轮业务重复；登录放在动作段，又会改变认证请求的数量。安排脚本前，需要明确模拟的是同一用户连续操作，还是每轮重新登录。以下以VuGen中的Web HTTP/HTML协议C脚本为例，说明分段方式及检查方法。

集合点用于让多名虚拟用户在脚本中的同一位置等待，满足人数或超时条件后再继续执行，从而形成集中请求。它适合验证登录、下单等瞬时高并发业务，但配置不一致时，目标请求仍可能分散发送。

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

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

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

加压已经结束，服务器CPU曲线还在上升；采样间隔改成了一秒，结果中却仍然隔几秒才有一个点。遇到这些情况，需要检查采集端和分析端各自用了什么设置。LoadRunner中的资源采样、事务数据发送和图表汇总都有时间间隔，改错位置，曲线看起来变细了，实际采集的数据却没有增加。以下以LoadRunner Professional的Controller和Analysis为例说明。

LoadRunner中的IP欺骗并不是伪造任意网络地址，而是让一台负载机使用已经配置并可正常路由的多个IP，使不同虚拟用户以不同源地址访问被测系统。该功能可减少服务器、代理设备和网络组件因大量请求来自同一地址而产生的缓存或连接复用影响。围绕“LoadRunner怎么配置IP欺骗LoadRunner启用IP欺骗后地址没有变化如何排查”，需要同时检查负载机地址池、控制器分配方式和网络回程。

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

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

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

录制时能登录、能查询，回放却提示会话失效，或者停在某个请求上。LoadRunner脚本遇到这类问题，往往要回到请求内容和服务器响应中找原因。下面介绍“LoadRunner怎么创建性能测试脚本LoadRunner脚本运行失败怎么排查”。操作以VuGen 26.1英文界面的Web-HTTP/HTML协议为例，录制一个登录后查询的流程。

做性能测试时，脚本录制往往是比较容易出现问题的环节。测试人员按照正常流程操作系统，但LoadRunner生成的脚本可能没有记录有效请求，或者录制完成后回放结果和实际操作存在差异。尤其是在接口调整、系统升级或者测试环境变化后，之前能够运行的脚本也可能出现异常。处理这些情况时，单纯重新录制并不能解决所有问题，还需要了解脚本生成方式以及错误出现的位置。

LoadRunner的思考时间怎么配置，回放的时候它又为什么会被忽略掉，这里头的重点，并不是脚本里面有没有写lr_think_time这一句，而是运行时的设置，到底有没有让它真正起作用。思考时间这个东西，是用来模仿真实用户的那种操作间隔的，像是页面之间的停顿、阅读里头的内容、填写一些信息，还有做选择的这些过程。在调试脚本的那个阶段，可以暂时不管它，可是一旦到了正式去压测的时候，要是还一直把它给忽略掉，那些虚拟的用户就会一个接一个不停地发请求，这样一来，压力的模型就很容易跑偏，跟真实业务的节奏对不上了。

做性能测试时，把脚本录制下来之后，如果从头到尾只留着一整段Action，等拿到测试报告，就很难一眼看出来到底是登录的时候慢了，还是提交订单那一步卡住了。所以，搞清楚LoadRunner VuGen里的脚本该怎么去合理地拆分事务，关键就是要把一条完整的业务流程，切成好几个可以独立观察的动作。在VuGen里面，用来标记事务开始的函数叫lr_start_transaction，用来标记结束的叫lr_end_transaction，这一前一后包起来的范围里，每一步消耗的时间都会被单独记录下来。

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

给业务系统做性能测试时，附件提交、图片上传、批量导入都可能涉及文件传输。浏览器里能正常上传的文件，放到LoadRunner脚本中回放，却可能出现找不到文件、提交失败，或者本机通过、换一台负载机就报错的情况。这类问题既与请求内容有关，也涉及文件在执行机器上的存放位置。下面以VuGen的Web HTTP/HTML协议、C语言脚本为例，说明普通表单上传的处理方法。

性能测试中，脚本录制完成后，固定数据往往无法满足多用户并发场景。比如多个虚拟用户同时登录、查询或者提交业务时，如果一直使用同一个账号或编号，测试结果可能和真实访问情况存在差异。LoadRunner参数化就是为了让脚本在执行过程中使用不同数据。不过实际调整时，也容易出现参数没有生效、虚拟用户使用重复数据、测试结果和预期不一致等情况。处理这些问题时，需要结合业务数据和脚本执行过程进行检查。

LoadRunner集合点怎么设置，集合点导致并发不稳定又要怎么排查，做秒杀、批量提交、登录峰值、支付确认这类场景时经常会碰到。集合点的作用，是让一批虚拟用户在某个关键步骤前等着，等满足了释放条件再一起往下执行，它适合拿来制造某个业务动作的瞬时压力，不适合拿来替代正常的并发模型，要是设置得太随意，反而会出现用户卡住不动、释放的时候凑不齐、并发峰值忽高忽低这样的情况。

LoadRunner关联的参数怎么去找，LoadRunner关联参数保存使用，很多人一遇到脚本回放失败，就先去改请求体里的动态值，结果越改越乱。真正有效的处理方式，不是盯着报错行死改，而是先把“动态值从哪里来、在哪一步被返回、在哪一步被再次提交”这一条链路找出来。

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