企业官网建设流程全解析

我最早是在物理机上折腾LoadRunner的，结果被折腾得够呛。Win10上装12.60，各种兼容性设置、补丁来回试，两天都没稳定跑起来；换成Win7倒是能装，可公司配的新电脑连Win7驱动都找不齐。后来索性把LoadRunner彻底搬进虚拟机和LoadRunner配套的系统环境里，用一台虚拟机专门承载这套性能测试工具，从安装到录制脚本再到压测，一步到位，问题全消。这篇就把从零搭建虚拟机、安装LoadRunner，到完成一次可参考的真实性能测试的全过程拆开讲清楚，顺便把我在虚拟机场景下踩过的那些坑也一并交代了。

这套流程适合谁？不管是刚入行想学性能测试的新人，还是被老旧LoadRunner版本兼容性折磨的在职测试/开发，又或者需要临时搭一套性能测试环境做验证的运维，照着这篇走，基本都能在半天内把环境拉起来，并且完成第一个可用的压测脚本。读完你会清楚为什么推荐虚拟机方案、虚拟机里如何规划资源、安装时哪些地方容易翻车、以及录制和压测阶段最可能遇到的几个拦路虎怎么处理。

1. 为什么把LoadRunner装在虚拟机上

很多人第一反应是：LoadRunner直接装本机不就行了，为什么要绕一道虚拟机？这个问题的答案，要分三个层面说清楚。如果你也经历过装到一半报错、录制时浏览器“不听使唤”、换电脑就要重新折腾环境这些问题，你会理解虚拟机方案并不是多此一举，而是性价比最高的解法。

1.1 兼容性问题才是真正的导火索

LoadRunner这工具年头不短，从LoadRunner 11、11.5到12.x、12.60，再到后来的2021、2023版本，迭代节奏不算快。但问题是，很多公司现在跑的还是12.50或12.60，甚至还有用11.5的老项目。这些老版本对操作系统非常“挑剔”：

• 官方支持列表里写的是Windows Server 2012/2016、Win7这些老系统，并不太欢迎Win10 1903之后的版本。
• 录制脚本时老版本默认依赖IE内核，Win10里连IE都被主动藏起来，更别提Edge接管之后，录制经常直接失败。
• UAC权限控制、Windows Defender实时扫描、系统补丁强制更新，都会在安装或运行中突然跳出来捣乱。

我在物理机上装12.60时遇到最典型的状况：安装进度到80%左右，一个关于Vuser组件库的报错弹出来，说无法注册某个DLL；查了半天，是系统安全策略把安装程序生成的临时文件拦截了。这种问题不是不能解决，但要反复调整系统策略，代价很高。虚拟机里用Win10 LTSC 2019或Windows Server 2016镜像，干净、可控、更新少，老版本工具在这种环境里表现反而比新系统稳定得多。

1.2 虚拟机方案的核心优势：隔离、快照、可复制

虚拟机方案真正的价值，不只在解决兼容性，更在环境管理上。

第一是隔离。性能测试工具装起来会写入大量系统组件、环境变量、服务注册项，如果跟日常开发环境混在一起，很可能污染其他工具链。我在一台物理机上同时装过LoadRunner和某个微服务开发环境，之后发现项目的Maven构建偶尔会莫名报错，排查到最后就是LoadRunner安装时改动的系统路径冲突。分一台虚拟机专门跑LoadRunner，这类问题几乎不会发生。

第二是快照。这个对压测场景尤其重要。你压测前系统是干净状态，压完可能产生大量日志、临时文件，甚至某些组件状态被改坏。直接在虚拟机管理软件里打个快照，测试完一键恢复，环境立刻回到初始态。很多资深的性能测试老手都是这么干的，省去重复安装的时间。

第三是可复制。虚拟机文件说到底就是一整个文件夹，你在这台机器上配好了完整环境，拷贝到另一台电脑上导入就能用。团队里要多人协作做性能测试，完全可以一个人装好，其他人复制镜像即可，不用各自踩一遍安装坑。

1.3 虚拟机配置规划：别拍脑袋，按这套建议来

刚开虚拟机时，配置规划很关键。给少了卡成幻灯片，给多了宿主电脑受不了。根据我多次实际使用的经验，按下面的规格来相对稳妥：

宿主机这边，建议物理内存不低于16GB，CPU 8核以上，磁盘建议SSD。虚拟机不是把资源吃满就好，你还要给宿主系统留出余量，否则压测时宿主卡死，测试结果一样废。给虚拟机分配的内存不要超过物理内存的一半，这一点我在后面会再提一次，真的很重要。

2. 虚拟机搭设与系统准备

方案定好了，就进入实操。虚拟机软件的选择、Windows系统镜像的选用、虚拟机参数的设置，每一步都影响后续LoadRunner安装和使用是否顺利。这个环节我尽量把“选哪个、为什么、怎么设”一次说透。

2.1 虚拟机软件选型：VMware还是VirtualBox

目前最主流的虚拟机软件就两个：VMware Workstation Pro和Oracle VirtualBox。前者在企业里占有率极高，后者因为免费开源，个人用户和教学场景用得多。我把两者的典型差异列在下面：

如果你目标是快速稳定地跑LoadRunner，我建议直接用VMware Workstation Pro。17版本比较新，装Win10/Server系统都顺利；社区里教程最多，遇到问题好查。VirtualBox也不是不行，就是安装扩展包、配置USB、调整网络这些环节经常需要多花点时间，对追求“装完就安心压测”的场景不够省心。至于现在网上经常有人提到“VMware 17没有配置和打开选项”，那多半是安装包不是完整版，或者界面语言版本导致的菜单名称差异，后面我会单独说。

2.2 创建Windows虚拟机：关键设置一次到位

虚拟机软件装好后，创建虚拟机的基本流程不复杂，但有几个关键点容易被忽略，直接影响LoadRunner后续表现。

第一步是准备系统镜像。LoadRunner要装在Windows里，我建议选Windows 10 LTSC 2019或Windows Server 2016。前者没有应用商店和一堆预装应用，干净且稳定；后者更贴近服务器环境，跑压测场景也合适。不要用最新版Win11，老版本LoadRunner在Win11上问题更多。

第二步是创建虚拟机。以VMware为例，新建虚拟机向导里选择“典型”就可以，客户机操作系统选“Microsoft Windows”和“Windows 10 x64”，不要选错32位或64位。虚拟磁盘选“将虚拟磁盘存储为单个文件”更方便迁移，大小设置为60GB，勾选“立即分配所有磁盘空间”会占用物理磁盘但性能更好，不勾选则是动态增长，更省空间，推荐不勾选。

第三步，进入虚拟机设置，有两处必须调整：

• 处理器设置里勾选“虚拟化Intel VT-x/EPT或AMD-V/RVI”，这是嵌套虚拟化支持。LoadRunner的某些性能监控组件和Vuser进程调度会依赖这类CPU指令，不开启的话安装时可能不报错，但后续Controller运行场景时容易异常。
• 内存设置建议6GB。前面表格也说了，4GB是底线，但VuGen录制、Controller场景、Analysis分析这几个环节有时会同时跑，内存给足能省去很多卡顿烦恼。

网络模式这里多说一句。如果你压测的是局域网里的服务器，选择“桥接模式”，让虚拟机像一台独立物理机一样出现在网络里，访问目标服务器走的是纯二层网络，跟物理机没区别；如果你只是为了自己练手，被测系统也跑在同一台虚拟机上，那NAT模式也可以。但注意，NAT模式下如果目标服务器有IP白名单限制，或者需要基于MAC地址做认证，就会比较麻烦。我自己的习惯是默认桥接，省事。

2.3 系统装完后的必要环境优化

Windows系统装完、VMware Tools也安装好之后，先别急着装LoadRunner，花十分钟做几项优化，后面会省出几个小时。

第一，关闭UAC。用户账户控制UAC会在安装程序想写系统目录时弹权限提示，LoadRunner安装过程中要弹好几回，而且弹窗时机不稳定，容易让人以为安装卡住了。控制面板→用户账户→更改用户账户控制设置，把滑块拉到“从不通知”。

第二，关闭Windows Defender实时保护。安装LoadRunner时它会在后台扫描所有解压出来的文件，导致安装速度骤降，有时还把破解文件或注册机直接隔离了。设置里把实时保护临时关掉，等装完再开。杀毒软件也同理，安装阶段建议暂时退出。

第三，关闭系统休眠和睡眠功能。压测有时要跑几十分钟甚至数小时，虚拟机一旦进入睡眠，虚拟网卡可能重连失败，LoadRunner场景可能意外中断。电源选项里把“睡眠”设为“从不”，然后关掉休眠文件。

第四，安装完成后打个快照。这是最容易忽略但最值钱的步骤。我现在每次搭好一个新的LoadRunner环境，装完系统、装好工具、验证能正常跑脚本之后，一定会打一个快照命名“初始干净环境”。之后无论怎么折腾，都能一键回到这个状态。别小看这个习惯，它能帮你节省大量重复安装的时间。

3. LoadRunner安装全流程拆解

虚拟机环境准备好，重头戏就来了。LoadRunner本身安装步骤不算太复杂，但两个关键决策——版本选择、安装顺序——搞错的人非常多。这一节我把整个安装阶段的要点按顺序讲到位。

3.1 安装前的环境检查清单

磨刀不误砍柴工，很多安装失败其实在系统准备阶段就埋下隐患了。我在虚拟机里装之前，会先过一遍下面这份清单：

• 确认当前登录账户是管理员，并且右键安装程序选择“以管理员身份运行”，而不是双击。
• 确认C盘剩余空间不小于20GB，LoadRunner默认装到C盘，安装解压过程还会额外占用空间。
• 确认Windows系统补丁已更新到较新状态，特别是一些老版本LoadRunner依赖的VC++运行库，系统补丁没装全时经常装不上去。
• 确认虚拟机的网络连通正常，LoadRunner安装时需要向许可证服务器做本地认证，虽然不强制联网，但网络环境乱会造成不必要的注册问题。
• 确认杀毒软件和Defender实时保护处于关闭状态，这个前面提过，安装阶段务必关闭。

这份检查清单花不了几分钟，但每次装LoadRunner前都过一遍，能避免大量“安装到一半报错，查半天发现是环境问题”的情况。

3.2 版本选择与安装包获取

版本问题直接关系到后面的稳定性和学习成本。现在大家用的LoadRunner版本大概分几类：

• LoadRunner 12.50/12.60：目前网上教程、各类经验贴里用得最多的版本，参考资料丰富，虚拟机场景下表现稳定。新手入门建议优先考虑这个系列。
• LoadRunner 2021/2023：OpenText收购后的新版本，界面有变化，对Win10/11的支持更好，但网上基于老版本的教程可能部分不符合，需要自己多摸索。
• LoadRunner Community Edition：社区版，可以从官方网站申请，注册一个账号就能拿到试用许可，功能有一定限制，但学习完全够用。

版本上我的建议很直接：如果你是自学、看教程为主，选12.60，问题少、答案多；如果你是公司项目要求、必须用新版，那选2023，但要有点心理准备，新版的菜单和配置路径变动不小。

安装包获取方面，官方路径是注册OpenText账号后下载试用版。网上也能找到很多安装包资源，但我不建议从不知名渠道下载，里面的文件可能被植入广告甚至恶意程序。正规途径下载后，安装包一般在4GB到5GB左右，先确认下载文件完整再开始装，不要解压到一半卡住。

3.3 安装主程序与License配置要点

安装包解压后，目录里有几个文件夹，关键的是setup.exe和Install Manager。步骤拆开看：

1. 右键以管理员身份运行setup.exe，安装器会先检查系统环境，自动弹出安装Management Server、安装Prerequisites等选项。
2. 先点“Install Setup Prerequisites”，这一步会自动安装VC++运行库、.NET Framework等一系列依赖组件。第一次装的时候，这一步可能耗时较长，耐心等待即可。
3. 依赖装完，再选择“Install LoadRunner”进入主程序安装。组件默认全选即可，一般包括LoadRunner Agent、Controller、Analysis、VuGen、LoadRunner Professional核心组件。
4. 安装模式选择Standalone（独立模式），不要选Server模式，也不用连接共享数据库，除非你要做大规模集中式压测。
5. 安装路径建议保持默认，不推荐改到中文路径或空格路径，LoadRunner对路径敏感，这是老毛病。
6. 安装完成后，启动界面会让你选择License类型。如果用的是社区版，直接填Community版许可；如果用企业版试用，填官方申请到的试用序列号。License状态可以在“Help → About LoadRunner / License”里确认，注意有效期限和最大虚拟用户数。

安装顺序上有个教训想多提醒一句：永远先装Prerequisites再装主程序。很多人图省事直接跳过了Prerequisites，结果主程序安装过程反复报缺少系统组件，最后还是要回头补装，白白浪费时间。另外，安装完主程序后如果提示重启虚拟机，重启前先把杀毒实时保护重新打开，免得后续下载补丁或测试时系统裸奔。

4. 虚拟机里的功能验证与脚本录制

装完之后，先别急着拿真实项目开压。先把LoadRunner各组件启动一遍，确认在虚拟机环境下都能正常工作，特别是VuGen的录制功能，这里最容易暴露问题。录制脚本是性能测试的入口，脚本质量直接影响压测结果的可信度。

4.1 首次启动：确认各个组件正常

LoadRunner装好后，开始菜单里会出现多个组件入口，新手容易搞混。简单梳理下这些组件的分工：

• Virtual User Generator（VuGen）：用于录制脚本、编辑脚本、参数化和调试，是性能测试中最常用到的组件。
• Controller：设计和执行压力场景，指定使用哪些脚本、多少虚拟用户、多长时间，监控整个测试过程。
• Analysis：分析测试结果，生成各类图表和报告，是看体检测结论的地方。
• Agent Process：代理进程，在压测执行时负责把虚拟用户“灌”到被测系统。

首次启动建议按“VuGen → Controller → Analysis”这个顺序各打开一遍，确认没有报错。我见过不少人在虚拟机上装完LoadRunner，一跑VuGen就提示缺少某个系统组件，就是因为前置依赖没装全。如果遇到这种情况，先回去补装Prerequisites，再不行就把Visual C++运行库整个装一遍。

启动时还有一个常见问题：老版本LoadRunner在某些Windows更新后的系统上，启动时提示“组件未正确注册”，甚至弹错后界面直接消失。这时候先在控制面板里修复安装一次LoadRunner，一般能解决；实在不行，卸载干净重装，注意卸载后要把安装目录残留文件夹和注册表相关项清理掉，再装成功率才高。

4.2 录制第一个脚本：以登录场景为例

脚本录制是上手LoadRunner的关键步骤。以最简单也最常见的Web登录场景为例，完整走一遍录制流程：

1. 打开VuGen，选择“File → New Script and Solution”，在协议选择里选“Web - HTTP/HTML”，这是最常用的Web协议，适合大多数B/S架构应用。
2. 创建后，点击工具栏中的“Record”按钮，弹出录制设置框。在“Application Type”选“Internet Applications”，浏览器选择IE或者本机安装的Chrome。如果你用Chrome，注意老版本LoadRunner需要配套的录制插件，选IE通常最省事。
3. 在“URL Address”里输入被测系统的登录页地址，设置好工作目录，点击“Start Recording”，浏览器会自动打开并开始录制。
4. 正常进行一次登录操作：输入用户名密码、点击登录、进入首页、退出登录。每一步操作都会实时被录制为脚本代码。
5. 点击“Stop Recording”，VuGen会把刚才的操作转换成脚本。保存脚本，命名清晰一些，比如“login_test”。

录制完成后的脚本，看起来是一大堆类似web_submit_data、web_url的函数调用。新手往往觉得难懂，其实只需要把握核心：登录操作对应的通常是web_submit_data函数，函数里包含了表单参数。这里先不要求完全读懂代码含义，能跑通最重要。点击“Run”按钮运行一次脚本，在“Replay Log”里看到执行成功的记录，说明录制流程基本没问题。

4.3 录制环节最常见的几个坑

录制时翻车是最打击人的，我把踩过的坑集中列一下，你对照着排查比自己瞎试快得多：

• 浏览器打不开，或者打开了不加载信天网站。这多半是系统默认浏览器设置的问题。LoadRunner默认调用IE模块，老版本必须保证IE可用；设置里把IE设为默认浏览器，并把IE的“启用第三方浏览器扩展”选项关掉。
• 录制的脚本是空的，只有几个无关请求。检查浏览器有没有弹窗拦截、代理设置是否异常；另外录制时不要点浏览器里的“停止”按钮，有时会中断录制会话。
• HTTPS页面录制时证书报错。在录制设置里勾选“Enable HTTPS recording”，并在系统里把LoadRunner的根证书先导入受信任证书列表。
• 页面在虚拟机上打开特别慢。先确认虚拟机内存和CPU分配，然后检查VMware Tools是否已安装，没装的话鼠标体验和浏览器渲染都会明显卡顿。
• 录制过程中动一下鼠标就产生了大量不相关事件。在录制设置中把“Recording Level”从“Extended Services”改为“Basic Recording”，可以过滤掉很多无用的JS脚本和动态元素请求。

录制不是一蹴而就的，多录几次、对比不同录制的差异，才能慢慢理解LoadRunner对脚本的处理逻辑。如果录制反复失败，还有一个备选方案：手动编写脚本，不过学习曲线陡得多，新手还是先解决录制问题更实际。

5. 在虚拟机上完成一次真实的性能测试

环境通、脚本录好，就可以直奔主题跑一次真实压测了。这一节我会从性能测试的准备步骤、Controller场景设计、Analysis报告解读三个环节展开，让你看完就能独立做一轮“脚本优化 → 压测设计 → 结果分析”的完整链路。

5.1 脚本优化：参数化、关联与检查点

录制下来的原始脚本一般情况下不能直接用于压测，原因很简单：脚本里写死了你刚才登录用的用户名、密码、访问的URL。压测时几十上百个虚拟用户都使用同一个账号，不仅不符合真实场景，还可能触发被测系统的安全限制。所以上压测之前，脚本要做三个基本优化。

第一个是参数化。把脚本里的用户名、密码、查询关键词等数据，从固定值替换成数据源。操作方式是，在VuGen的脚本编辑器里右键选中需要参数化的字符串，选择“Replace with a parameter”，名称设为“username”，类型选“File”，然后把准备的测试账号数据写到一个.dat文件里，指定文件路径和列号即可。LoadRunner的虚拟用户每次迭代时，会按设定的方式（顺序、随机、唯一）从文件中取值，这样每个用户都是不同的身份。

第二个是关联。很多系统登录后，服务器会返回一个token或session ID，后续请求必须携带这个动态值才能真正访问成功。录制脚本时这个值被固定写入了，压测时会因为token过期或无效而报错。处理方式是使用web_reg_save_param函数：把服务器响应中动态变化的部分先捕获到参数里，然后在后续请求中用{token}引用。我见过不少新人脚本跑手动一遍通，一压测就大量失败，多半就是关联没做。

第三个是检查点。压测不仅要看响应时间，还要确认业务是否真正成功。用web_reg_find函数可以在服务器响应中搜索一个代表“登录成功”的文本，比如“欢迎，admin”，如果找不到，脚本会将这个请求标记为失败。这样压测结束后，你可以明确区分“服务器响应慢”和“业务逻辑报错”两类问题，而不是被一堆HTTP 200欺骗。

另外，事务和集合点也是两个常用工具。关键操作建议加事务，lr_start_transaction("login")和lr_end_transaction("login", LR_AUTO)包住登录请求，这样Analysis报告里能直接看到登录操作的平均耗时；并发尖峰测试时用lr_rendezvous("ready")可以让所有虚拟用户同时汇集在登录按钮处，实现真正的并发点击。

5.2 Controller中的场景设计：从冒烟到阶梯加压

脚本在VuGen里单独跑通后，就该交给Controller压测了。Controller的界面看起来复杂，其实核心就三件事：选择脚本、配置虚拟用户数、设置运行策略。

打开Controller，选择已保存的脚本，然后在“Scenario Groups”区域设定虚拟用户数量。新手建议分三轮进行，不要一上来就1000用户：

• 第一轮冒烟测试：5个虚拟用户，运行5分钟，目的是验证脚本在压测状态下能否稳定执行。
• 第二轮基准测试：50个虚拟用户，运行15到20分钟，观察系统在中等负载下的响应时间、错误率。
• 第三轮压力测试：逐步增加到200甚至500个虚拟用户，观察系统在什么时候开始出现明显性能拐点。

还有一个容易被忽略的选项是“Initialize Users”和“Ramp Up”时间设置。在场景设计里，把虚拟用户设置为渐变加载，比如每10秒加载10个用户，比让所有用户同一秒启动温和得多。原因很简单：瞬间涌入大量用户会把被测系统打懵，也会让虚拟机的CPU瞬间打满，结果可能既不是系统的真实极限，还容易导致Controller自身卡死。我在虚拟机上就遇到过，500个Vuser同时启动，虚拟机直接假死，最后只能强制恢复快照重来。

运行期间，Controller的仪表盘会实时展示活动用户数、响应时间、吞吐量、错误率等指标。务必跑完预定的完整时间段再停止，不要手动点停，否则Analysis里部分统计可能缺失，影响结果完整性。

5.3 Analysis报告解读：别只会看平均响应时间

压测结束后，Controller会提示“View Results”，跳转到Analysis工具。Analysis生成报告时，新手最容易做的事情是：只看Avg Response Time，然后说“系统平均響應时间1.2秒，性能不错”。这个结论往往是错误的，因为平均响应时间掩盖了真实问题。

正确的读图顺序是这样的：

• 先看Running Vusers曲线：确认虚拟用户是否按照设定逐步加载、平稳运行、按计划退出。
• 再看Transaction Summary：这是事务成功率和响应时间的总表，关注Failed事务数量，确认有没有业务失败。
• 然后看Average Transaction Response Time曲线：响应时间随着用户数增加而上升是正常的，重点关注它是否出现突然的陡升点，这个拐点就是系统的性能瓶颈位置。
• 最后看Throughput曲线和Hits per Second：吞吐量在某个点停止增长了，说明系统已到处理上限，这时候即使响应时间还在可接受范围内，也要警惕。

我在实际操作中，特别看重一条经验：压测结果不能只看平均值，要看90%用户的响应时间。Analysis报告里有个Percentile图，可以看到90th percentile的响应时间，这个值远比平均值能代表真实用户体验。如果一个系统的平均响应时间是1.2秒，但90%用户响应时间是4.5秒，说明有大量请求被某一个慢接口拖住了，需要进一步拆分事务数据定位原因。

虚拟机环境下跑出来的分析数据，要记住它反映的是虚拟机的资源情况，不是纯粹的被测系统性能。比如虚拟机本身CPU被打满，压测结果必然失真。所以Analysis报告要结合虚拟机宿主的监控数据一起看，这也是为什么我建议压测时在宿主上也打开任务管理器，确认虚拟机的CPU、内存没有成为瓶颈。

6. 虚拟机环境下最容易踩的坑

LoadRunner在虚拟机上跑通不难，但整个使用周期中，有几个坑几乎是高频出现的，有些是LoadRunner老版本的“历史遗留问题”，有些是虚拟机和性能测试工具之间的“化学反应”。我把它们集中整理在下表，方便你快速对照排查。

6.1 常见问题速查表与排查路径

这张表基本覆盖了我在虚拟机里用LoadRunner遇到的大部分问题。如果偶然遇到表里没有的怪现象，通用排查思路很固定：先看系统日志（事件查看器→Windows日志→应用程序），再看LoadRunner安装目录下的日志文件。老经验是，LoadRunner的日志虽然长，但真正有价值的错误信息往往就在弹出的对话框里，别直接把对话框点掉，先截图再关。

6.2 关于虚拟化嵌套和性能损失的一点体会

把LoadRunner放进虚拟机，会有人担心性能损失影响压测结果。实测下来，性能损失真实存在，但没有想象中可怕。CPU密集型的脚本处理，虚拟机比物理机慢10%到20%，这是虚拟化层带来的损耗；网络IO在桥接模式下基本可以忽略，内存访问瓶颈则不明显。

真正要注意的反而是两个容易忽略的问题。

第一，嵌套虚拟化必须开启。虚拟机里运行LoadRunner这种会调用CPU性能计数器的工具，需要在VMware里勾选VT-x/EPT支持，以及在虚拟机操作系统中把Hyper-V彻底关掉。如果你装了WSL、Docker Desktop这类依赖Hyper-V的组件，它们会抢占虚拟化层，导致VMware的嵌套虚拟化失效，这种情况下LoadRunner的Controller运行场景时经常莫名其妙报“无法获取系统性能计数器”。

第二，不要在虚拟机里做极限容量测试。如果你的目标是测试系统能否扛住5000个并发用户，不应该指望一台虚拟机里跑满5000个Vuser。大胆的估值是，跑5000个Vuser大致需要多台客户机或一台高配置物理机作为负载生成器。虚拟机上跑三五百个Vuser用来练习、做日常回归、做中小规模压测没有问题，但极限并发测试还是要把Agent拆到多台机器上，这也是LoadRunner本身支持分布式Agent部署的原因。

6.3 快照、备份与环境复用的实操心得

这篇文章讲了系统搭建和测试流程，最后想特别说一个贯穿始终的习惯——环境复用。每次装好环境、验证脚本能跑通、压测结果正常，这三个节点我都建议各打一个快照。快照名称要清楚，比如“装好系统”“装好LoadRunner”“初始干净环境”“压测前状态”，不要全叫“快照1”“快照2”，否则过两个月你就分不清哪个是哪个。

具体使用场景举例：我这周要做一次针对某内部系统的压测，从“初始干净环境”快照恢复，系统干干净净，磁盘和内存都是最佳状态，直接开始压测，测完再恢复快照，虚拟机文件夹大小和状态都回到初始。这样既避免了时间长了虚拟机磁盘膨胀，也避免了上一次压测残留的日志和临时文件影响下一次结果。

如果你需要把LoadRunner环境分享给同事，直接在虚拟机软件里使用“管理→克隆”功能，生成一个克隆副本。克隆时选“创建完整克隆”，这样副本完全独立，不会跟原虚拟机产生冲突。同事拿到克隆文件后，在VMware里“打开虚拟机”，选择“我已复制该虚拟机”，等VMware Tools重新生成唯一标识后就能正常用。这个方法比让同事重新下载安装包、走一遍安装流程高效太多了。

我在虚拟机里用LoadRunner的时间长了，最大的感受是：环境本身不是目的，可靠可复现才是性能测试的底牌。每次压测结果出来，如果环境状态都是干净、一致、可追溯的，那么不管这个结果是好的还是坏的，它都有说服力。这也是为什么我花了大量篇幅在环境搭建和管理上——性能测试这个领域，数据和环境可信度，往往比工具玩得花不花更决定项目成败。

最后再分享一个小技巧：虚拟机上跑压测脚本之前，去Controller的“Tools→Options→Execution”里，把虚拟用户启动的间隔时间稍微调宽一点，比如默认可能是1秒，你改成5秒，几十个Vuser同时启动时，虚拟机的磁盘IO和CPU负载会平滑很多。这个坑，我踩过不止一次，调整后再也没出现过压测开始时虚拟机假死的情况。