企业官网建设流程全解析

1. LoadRunner 2020能解决什么问题，我应该用它吗

做性能测试的朋友应该都绕不开LoadRunner这个名字。不管是在金融、电商还是政府项目里，只要涉及压测、容量评估、并发摸底，LoadRunner几乎是行业里用得最广的一套工具。我对它的评价是：学习曲线不算平缓，但一旦吃透，它能覆盖从脚本编写、压力注入到结果分析的全链路，这是很多开源工具比不了的。2020版本出来之后，License模型、组件安装方式都有不小的变化，很多老用户第一次上手反而有点懵，所以我这篇文章就专门围绕LoadRunner 2020的下载、安装和简单使用来写，尽量把过程中容易踩的坑提前说清楚。

老规矩，先聊清楚这个工具到底适合谁。如果你是一个刚接触性能测试的测试工程师，想快速在本地模拟几百个用户同时登录的场景，LoadRunner 2020的社区版（Community Edition）完全够用，官方限制是50个虚拟用户，但功能本身没有阉割，VuGen脚本录制、Controller场景调度、Analysis报告都在。如果你是在企业内部做常态化压测，预期并发不低，那你需要企业版License，不过用法和社区版是一致的。还有一类人是做接口压测或全链路压测的，LoadRunner 2020也能通过协议级脚本（比如HTTP/HTTPS、Web Services）实现比较灵活的请求构造。

再说一下它和JMeter这类工具的区别。JMeter胜在开源免费、插件生态好、上手快，但遇到复杂的关联、动态参数、多协议混合场景时，LoadRunner的VuGen录制能力、引擎稳定性和分析模型的成熟度还是要更胜一筹。LoadRunner 2020版本也补上了对较新Web技术（比如Ajax、WebSocket部分场景）的支持，整个界面也比老版本现代化了不少，不再是那种给人巨大压力的老式Windows界面。

2. 下载与安装：实操步骤全记录

2.1 下载前需要搞清楚的事情

LoadRunner 2020的官方下载渠道是Micro Focus官方网站（现在归OpenText），搜索“LoadRunner 2020 Community Edition Download”就能找到入口。下载前有几件事建议你先确认，不然可能白忙活半天。

第一，操作系统。LoadRunner 2020对Windows系统的要求是Windows 10（64位）、Windows Server 2016或Windows Server 2019。我实测下来，Windows 11也能跑，但官方没有明确支持，建议主力环境还是按官方要求来。如果你的机器是Windows 7，别试了，装不上。

第二，磁盘空间。安装文件（ISO镜像）大概2GB左右，解压出来再加安装后的文件，建议预留至少10GB。安装过程中会安装很多VC++运行库、.NET组件，所以C盘空间最好也别太小。

第三，内存。单纯安装VuGen写脚本，8GB内存够用；但要同时开Controller跑场景、起多个Load Generator，建议16GB起步。毕竟你要在一台机器上模拟几十个用户，每个虚拟用户都有自己的进程和资源占用，内存太小容易导致压测结果失真。

第四，License策略。2020版本最大的变化之一就是引入社区版License，免费但限制50个虚拟用户。下载时你需要在官网填写邮箱，Micro Focus会把一份包含License文件的邮件发给你。我记得邮件里是一个类似license的附件，安装完成后用这个文件激活社区版即可。企业版则需要向销售申请试用License或者购买正式授权。

2.2 安装步骤：从ISO到可用的过程

拿到ISO镜像文件后，我建议用虚拟光驱或者直接右键“装载”，不要在Windows资源管理器里双击解压，那样有时候会触发路径长度问题，安装到一半报错。

第一步，运行安装程序。ISO装载后会看到setup.exe，右键选择“以管理员身份运行”。LoadRunner这玩意儿不管理员运行，后面装组件的时候大概率出问题，这是我在安装阶段踩过最多的坑。

第二步，选择安装方式。安装界面会让你选“LoadRunner 2020 Complete Installation”还是“Custom Installation”。如果是第一次装，直接选Complete，它会默认安装全部组件。如果你只想用VuGen或者已经装过Controller，可以自定义。我个人的做法是：第一次装就全部装上，后面熟悉了再按需精简。因为Controller和Analysis在后续测试中基本都要用，省不了多少空间。

第三步，选择安装路径。默认是C盘，但因为LoadRunner会生成大量日志和临时文件，我建议改到非系统盘，比如D:\LoadRunner。注意路径里不要有中文和空格，有些老的依赖组件对路径比较敏感，虽然大部分时候没事，但没必要冒险。

第四步，等待组件安装。这个过程比较长，可能会装20到30分钟。中间会有几次让你选择是否安装附加组件（比如HP Network Virtualization、SAP GUI等），默认下一步就好。注意观察是否有弹窗提示需要重启，如果系统提示需要重启，务必先重启再继续安装，否则可能出现注册表写入不完整的情况。

第五步，配置许可证。安装到后半段，安装程序会进入License配置页。社区版用户选择“LoadRunner Community Edition”，然后指向你邮箱里收到的License文件。企业版则输入License服务器地址或者License字符串。这里的要点是：如果安装时没配置License，后面通过开始菜单的“LoadRunner License Configuration”工具也能补，不用重新安装。

第六步，安装完成后重启系统。然后打开开始菜单里的“LoadRunner 2020”，建议初次启动时都右键“以管理员身份运行”。如果启动画面正常出现，说明安装成功。

2.3 安装后建议做的两件事

装好之后不要急着录脚本，先做两个基础检查。

第一，确认VuGen能否正常打开录制用的浏览器。LoadRunner 2020默认支持录制IE、Chrome和Firefox。录制功能在Chrome上需要安装一个扩展，理论上VuGen会自动注入，但实际中经常被Chrome的权限策略挡住。我的建议是：录制时优先用Firefox，它和LoadRunner的兼容性在2020版本中最稳定；Chrome也支持，但需要你手动确认扩展启用。

第二，检查Controller能否连接本机的Load Generator服务。打开Controller后，在场景设计页面里找到“Load Generators”区域，本机名称一般会显示为“localhost”。右键点击它，选择“Connect”，状态变为“Ready”代表正常。如果连接失败，很大概率是本机的Load Generator服务没启动，去Windows服务里确认“HP LoadRunner Load Generator Service”是否处于运行状态。

3. 简单使用：从录制脚本到跑出第一个压测报告

3.1 用VuGen创建你的第一个脚本

安装完只是万里长征第一步，日常使用频率最高的组件其实是VuGen（Virtual User Generator）。它负责把用户的操作行为转换成脚本，然后才能在Controller里被虚拟用户执行。

打开VuGen后，点击“Create/Edit Scripts”，选择“Web - HTTP/HTML”协议。这里我多说一句：如果你只是做HTTP接口压测，选这个协议没错，它能录制所有HTTP请求；如果你要压测的是数据库、消息中间件或者ERP系统，那需要对应的协议选项（比如Oracle、Web Services、SAP），这些在企业版里通常会有，社区版则主要覆盖Web场景。

创建脚本后，你会看到一个包含Start录制的界面。点击“Record”按钮，输入要压测的网址，比如我拿一个测试环境的登录页面来做演示。VuGen会自动打开浏览器并开始录制你的操作。

录制过程中，你需要在浏览器里完成一次完整的业务操作：输入用户名密码、点击登录、浏览页面、退出登录。每做一步，VuGen都会记录下对应的HTTP请求。这个过程中不需要太赶，脚本会自动记录事务之间的时间间隔，包括思考时间。

录制结束后，点击“Stop”按钮，VuGen会生成一个包含所有HTTP请求的脚本，用类似C语言的语法表示。你可以在左侧树形栏里看到Action、vuser_init、vuser_end这几个部分。登录这类操作应该放在Action里，静态资源的初始化可以放在vuser_init里，退出操作放vuser_end里。工具默认的分配大多时候是合理的，但我建议录制时尽量把业务动作都放在Action里，因为Controller运行场景时反复执行的就是Action部分；vuser_init只在虚拟用户启动时执行一次，vuser_end只在结束时执行一次。

3.2 参数化和关联：脚本能复用的关键

录制完成不等于脚本能直接用。真实业务里，100个用户不可能用同一个账号去登录，这就要做参数化。参数化的本质是把脚本里硬编码的值（比如用户名、密码、订单号）替换成变量，变量从外部数据文件或函数生成器中取值。

在VuGen里，选中脚本中要替换的内容，右键选择“Replace with a parameter”，输入参数名，然后在参数属性里选择数据源类型（File、Table、Generator等）。如果选择File方式，你需要准备一个包含所有测试账号的文本或Excel文件。注意参数取值的策略：Unique + Each iteration表示每次迭代取唯一值；Random + Each iteration表示每次迭代随机取值。做登录场景一般用Unique为主，避免并发时不同虚拟用户拿到相同账号造成数据冲突。

关联则更麻烦，但也是性能测试里躲不开的一环。现代Web应用大量使用动态Token、Session ID、CSRF令牌，每次请求都可能变化。如果脚本回放时发现请求参数一直是录制时那个值，大概率就是参数已经失效了。LoadRunner 2020提供自动关联扫描，录制完成后你可以在“Design Studio”里查看工具识别出的动态值，逐个确认后Apply。实践里我建议至少学会手动定位动态值：先回放一次脚本，查看回放日志中哪个请求的响应和录制时不一致，把对应的值替换成函数web_reg_save_param，通过正则表达式匹配并提取响应里的新值，再放到后续请求的参数里。

关联这块很多新手会卡住，我的心得是：先学会看响应内容。多数Token在响应HTML里都能找到一个规律性的格式，比如name="token" value="xxxxx"，你只要把这个正则匹配好，用web_reg_save_param拿到值，后续请求引用就行。

3.3 设计场景和运行压力测试

脚本准备好之后，在VuGen中先点击“Compile”检查语法，编译通过后保存。接下来打开Controller，这是LoadRunner的另一个核心组件，负责把编写好的脚本变成实际压力。

在Controller里选择“Create/Edit Scenarios”，添加刚才生成的脚本。你需要设置三个关键元素：

第一，虚拟用户数量。社区版最多50个，企业版按License来决定。不要一上来就猛加用户，建议按照梯度加压：比如先设10个跑5分钟，再逐步加。

第二，Load Generator。默认是本机，意味着所有虚拟用户都在你这台机器上运行。如果压测目标是一个远程服务器，本机压力注入机本身的性能瓶颈也要考虑到。机器条件有限时，可以开启多个Load Generator分配到多台机器上，但这需要额外安装负载生成器，社区版似乎不支持多机模式，所以这里不深入展开。

第三，场景计划。Controller支持多种计划方式：基于场景、基于会话、基于组。简单场景用“Scenario”即可，可以配置启动时逐步加载用户、持续运行时间、结束后逐步释放用户。我习惯设置成：每15秒增加5个用户，达到目标数后维持5分钟，然后每15秒减少5个用户，这样可以模拟比较自然的业务压力变化。

设置完成后点击“Start Scenario”按钮，Controller会启动所有虚拟用户，你可以实时看到每个用户的状态（Running、Passed、Failed等）、响应时间、吞吐量等指标。运行结束后，点击“Analysis Results”打开Analysis工具，LoadRunner会生成一份HTML格式的性能测试报告，包括平均响应时间、每秒事务数、错误率、吞吐量、并发用户数等关键指标。

3.4 一个完整的场景：登录业务压测

为了让你更直观地理解以上流程，我直接描述一个最简单的场景。假设我要压测一个后台管理系统的登录接口，目标是看50个并发用户同时登录时，系统的登录响应时间能不能控制在3秒以内。

第一步，用VuGen录制一遍登录流程，把用户名密码参数化，设置好关联Token。

第二步，编译脚本，确认无错误。

第三步，打开Controller，设置50个虚拟用户，计划为“每10秒启动5个用户，达到50后运行10分钟，结束后每10秒释放5个”。

第四步，在Graphs区域监控“Average Response Time (sec)”和“Hits per Second”，观察是否出现响应时间陡增。如果10分钟运行期间平均响应时间一直在2秒以内，且没有错误，基本可以认为系统能扛住50并发；如果出现错误率超过5%，就要进一步分析是服务器资源问题还是脚本参数问题。

第五步，运行结束，打开Analysis，查看详细图表，比如“Transaction Response Time under Load”，这个图能反应随着并发数增加，响应时间的变化趋势。

这个过程是LoadRunner最简单的玩法，也是所有复杂性能测试场景的基础。把这条路走通了，后面再扩展监控Windows/Linux服务器资源、和APM工具集成等就都是顺理成章的事。

4. 常见问题与排查技巧实录

4.1 安装环节经常踩的坑

我先说一个最典型的：安装过程中进度条走到一半弹出“setup failed”或者要求重启。这种情况多半是因为Visual C++运行库安装失败导致的冲突。解决方法是先把系统里所有Microsoft Visual C++相关的程序卸载干净，再重新运行安装程序。另外，有些安全软件会拦截注册表写入，安装时最好暂时退出。

还有一个常见问题：安装完成后双击LoadRunner图标，提示“License is invalid”或者“Cannot find license file”。这个大概率是你安装时没有正确配置License文件。解决方法是打开开始菜单里的“LoadRunner License Configuration”工具，添加License文件路径或者重新输入License服务器地址。社区版用户请注意，License文件是绑定绑邮箱的，不要把你的License分享给别人，可能会被官方收回。

安装路径也建议提前规划好。如果你之前装过旧版本LoadRunner，2020版本可能不会覆盖卸装干净，这会导致组件冲突，表现是新版本启动后功能缺失（比如没有Analysis或者Controller）。我遇到过一次，最后只能手动把所有HP/Micro Focus相关目录清理掉，再用安装程序修复。

4.2 录制失败或回放失败的正确排查思路

录制按钮按下去之后，浏览器一直没弹出，或者弹出了但页面不加载，这是新手最常遇到的问题。先检查网络代理设置。LoadRunner录制时会设置一个本地代理来捕获HTTP请求，如果你的系统已经设置了全局代理，或者IE里设置了代理脚本，录制就会冲突。解决办法是关闭系统代理和浏览器代理设置，让浏览器直连目标地址。

回放失败的情况就更多了，需要分类型排查。如果是HTTP 404/500错误，先确认你录制的目标服务器是否还能访问，很多测试环境在下班后会自动关闭。如果是登录成功但后续操作失败，几乎可以断定是关联没做对，动态Token没有在请求间正确传递。我的排查习惯是：回放时打开“Replay Log”，定位到第一个失败请求，看它的请求参数和录制时响应里的值是否一致，如果不一致，找到响应中该参数的来源，用web_reg_save_param进行提取。

还有一个容易忽略的点：思考时间。录制时你操作页面有停顿，VuGen会把停顿时间记录下来。回放时如果按原样保留思考时间，那么虚拟用户的实际请求频率会低于真实并发压力；如果你把思考时间设为0，会极大提高请求密度，导致过大的压力。一般性能测试需求中会明确要求是否保留思考时间，按需求来即可。

4.3 Controller运行中的异常处理

场景运行到一半，某个虚拟用户突然报错，错误类型常常是“Connection reset by peer”或者“Timeout”。如果是个别用户偶尔报错，可能是网络波动或者服务器端单连接异常；如果是大量用户同时报错，且响应时间图表呈现断崖式上升，那基本就是服务器已经扛不住了，连接被拒或超时。

遇到这种情况，先不要慌，不要把测试停了，让场景继续跑完，这样才能拿到完整的拐点数据。运行结束后，结合Analysis里的“Error Statistics”和“Web Server Resource Graphs”来判断是系统资源瓶颈还是应用代码问题。

还有一个小技巧，Controller里可以开启“Set Pacing”，让每个虚拟用户在两次迭代之间固定等待一段时间。这就避免了几十个用户刚启动时立刻发出大量请求，把服务器“打蒙”的情况。合理的Pacing能让压力分布更均匀，测出来的数据也更接近真实业务。

4.4 结果分析时容易被误解的数据

第一次用Analysis的时候，很多人会盯着“Average Response Time”看，但平均值往往会被极端值拉高或拉低。我更建议同时看“Percentile”图表，比如90%的响应时间是多少，仔细观察在哪个并发点开始恶化。

还有一个容易误解的地方是“Hits per Second”不等于“Transactions per Second”。Hits指所有HTTP请求的次数，Transactions仅指你脚本里定义的业务事务。一个页面请求很可能包含几十个Hits，但只算一个Transaction。分析时要以Transaction维度为准，否则你会以为自己压出了很大的TPS，其实只是静态资源请求比较多。

另外，Analysis里默认的图表比较单调，我习惯调整“Granularity”来聚合数据，比如把1秒钟的数据聚合成10秒或1分钟的平均值，曲线会更平滑，更容易看出趋势。这个操作很简单，在图表属性里修改即可。

5. 我的实操心得：从装好到真正用起来

最后分享几个我自己觉得比较有价值的使用心得。

第一个心得：LoadRunner 2020的社区版完全够用来学习和搭建企业内部的常规压测能力，50个虚拟用户对于大多数内网管理系统的接口压测来说已经能说明很多问题。你不用担心功能被阉割，我对比过，VuGen的脚本录制、参数化、关联、Controller场景调度、Analysis分析这些核心能力都在，真正限制的只是并发用户数。

第二个心得：如果有可能，尽量在攻破基础流程之后再考虑自动化。很多团队刚开始接触LoadRunner，上来就想把性能测试集成到CI流水线里，这个想法是好的，但如果你连手动操作VuGen和Controller都不熟练，自动化的收益会很有限。先把一次完整的压测跑通，理解了虚拟用户的概念，理解了响应时间和并发数之间的关系，再考虑用Maven插件、Jenkins调用命令行的方案。

第三个心得：养成保存和分析日志的习惯。LoadRunner的日志文件非常详细，但默认情况下日志级别可能比较低。在VuGen的Run-Time Settings里可以把日志级别调整为“Extended”，这样回放时能记录下每个请求和响应。定位问题时日志比肉眼盯着脚本要高效得多。不过正式压测时务必把日志级别调回普通，否则大量日志写入IO会拖慢压测本身。

第四个心得：备份脚本和场景。压测脚本是资产，尤其涉及复杂关联、参数化文件的时候，一旦环境变更，重建脚本的成本非常高。我每次完成一个相对完整的脚本，都会把关联表达式、参数文件路径、常见问题记录在一个本地文档里，下次遇到类似业务时能直接复用。

LoadRunner 2020不管是从功能完整度、稳定性还是学习资源的丰富度来说，都是性能测试领域一套非常值得花时间掌握的技能。个人建议新手在本地搭一套自己的环境，随便找一个自己熟悉的Web系统反复练录制、改脚本、跑场景、看报告这一套流程，练多了自然就有手感。等到需要处理高并发场景时，你也能准确判断瓶颈在应用、数据库还是压测工具本身，而不是一上来就怀疑工具出问题了。

最后再分享一个小技巧：如果安装或使用过程中报错，先别急着重装系统或删除重装，去C盘搜索LoadRunner相关日志文件，通常报错原因就藏在最后几十行日志里。我以前就是因为一个端口占用的问题卡了半天，最后打开日志才看到它提示8080端口被其他服务占用，改掉之后一切恢复正常。遇到问题多看一眼日志，能帮你省下不少时间。