企业官网建设流程全解析

1. 项目概述：性能测试的“老将”与新手的“敲门砖”

LoadRunner，这个名字在性能测试领域，几乎等同于一个时代的代名词。即便在云原生和微服务架构大行其道的今天，LoadRunner 12.02 作为一款经典的商业性能测试工具，依然是许多企业，特别是金融、电信、大型制造业等传统核心业务系统进行性能压测的“标配”。它就像一位经验丰富的老将，虽然界面可能不如一些新兴的开源工具那么“酷炫”，但其强大的协议支持、精准的资源监控和成熟的测试分析体系，依然是构建可靠性能基准的利器。对于刚入行的测试工程师，或者需要接手维护既有性能测试脚本的团队来说，掌握 LoadRunner 12.02 的基本使用，不仅是完成工作的必备技能，更是理解性能测试完整生命周期——从脚本录制、场景设计到结果分析——的绝佳路径。

很多人一听到 LoadRunner，可能会被其庞大的功能和略显复杂的界面吓退。但事实上，它的核心使用流程是高度结构化和清晰的。本次分享，我将以一个从业者的视角，带你拆解 LoadRunner 12.02 从安装配置到完成一次基础性能测试的全过程。我们会聚焦于最常用的 Web（HTTP/HTML）协议，因为这是互联网应用最普遍的交互方式。通过这个具体的例子，你将不仅学会“点哪里”，更能理解每个操作背后的意图，比如为什么参数化是必须的，集合点该如何设置才有效，以及如何从纷繁的测试结果图表中，一眼揪出系统的性能瓶颈。无论你是需要快速上手完成一个紧急的压测任务，还是想系统性地打好性能测试的基础，这篇内容都将提供可直接“抄作业”的步骤和避坑指南。

2. 环境准备与工具核心组件解析

在真正开始录制脚本之前，我们必须先理解 LoadRunner 12.02 的“五脏六腑”。它不是一个单一的程序，而是一个由多个组件协同工作的套件。盲目地点击安装包，很可能导致后续使用中各种组件连接失败。因此，我们先来理清它的核心架构。

2.1 核心三大组件：VuGen、Controller、Analysis

LoadRunner 的核心工作流由三个主要组件驱动，理解它们的分工是高效使用的前提。

1. Virtual User Generator (VuGen)：这是我们的“脚本工厂”。它的唯一任务就是录制和开发虚拟用户（VUser）脚本。你可以把它想象成一个高度专业化的浏览器（或其他客户端模拟器），它能记录下你与服务器应用的所有交互（请求与响应），并生成对应协议的脚本代码（默认是C语言）。VuGen 工作的产出物就是一个.usr文件（项目文件）和其关联的脚本文件。

2. Controller：这是性能测试的“指挥中心”和“压力发生器”。在 Controller 中，我们设计测试场景（Scenario）：决定用多少个 VUser（虚拟用户）来跑脚本、以什么样的节奏（如每隔15秒启动5个用户）加压、这些 VUser 运行在哪些负载生成器（Load Generator）上。Controller 负责将 VuGen 生成的脚本分发给各个负载生成器，指挥它们同时执行，并在这个过程中收集全局的性能数据。

3. Analysis：这是我们的“数据分析中心”。压测结束后，Controller 会生成一个结果文件。Analysis 组件则负责打开这个结果文件，将海量的原始数据（事务响应时间、吞吐量、点击数、系统资源计数器等）进行汇总、关联和可视化，生成各种图表和报告。我们性能瓶颈定位、出具测试报告，主要就依赖这个工具。

注意：很多新手容易混淆 VuGen 和 Controller。简单记：VuGen 管“单个用户怎么操作”，Controller 管“成千上万个用户怎么一起操作”。你绝不会在 Controller 里编辑脚本细节，也绝不会在 VuGen 里设置500个用户并发。

2.2 安装部署要点与避坑指南

LoadRunner 12.02 的安装过程本身并不复杂，但有几个关键点一旦忽略，就会导致后续步骤失败。以下是基于大量实战安装经验总结的清单：

• 操作系统兼容性：LoadRunner 12.02 对 Windows 7 SP1 和 Windows 8.1 的支持相对较好。在 Windows 10 或 Windows 11 上安装，可能会遇到一些兼容性问题，尤其是 Controller 和 Analysis 组件。强烈建议：如果条件允许，为性能测试专门准备一台 Windows 7 SP1 或 Windows Server 2008 R2 的纯净虚拟机作为负载机。这能避开绝大多数莫名的错误。
• 安装包获取与完整性：确保你拥有完整的安装包。通常它包含一个主安装程序和一个巨大的“安装包”文件夹。安装时，主安装程序会从这个文件夹中提取所需文件。如果文件夹缺失或路径不对，安装会卡住。
• 安装路径：绝对不要安装在包含中文或空格的路径下。使用默认的C:\HP\LoadRunner或类似D:\LoadRunner的纯英文路径是最安全的选择。这是很多脚本回放失败和组件启动异常的根源。
• 防火墙与杀毒软件：在安装和后续使用过程中，暂时关闭 Windows 防火墙和第三方杀毒软件（特别是那些带有“主动防御”功能的）。它们可能会拦截 LoadRunner 的某个进程通信，导致负载生成器（Load Generator）无法连接。
• 以管理员身份运行：无论是安装程序，还是后续启动 VuGen、Controller，都请右键选择“以管理员身份运行”。这能避免因权限不足导致的文件写入或注册表修改失败。
• 安装后重启：安装完成后，按照提示重启计算机。这不仅仅是形式，而是为了让一些底层驱动（如网络数据包捕获驱动）和系统环境变量生效。

实操心得：我个人的习惯是，在安装完成后，首先单独打开 VuGen，尝试创建一个空白 Web 脚本并编译（F7），确保脚本引擎工作正常。然后再打开 Controller，创建一个指向本地负载生成器的简单场景。这两步自查能提前发现80%的环境问题。

3. 脚本录制与开发：从用户操作到可执行代码

一切就绪后，我们进入核心环节——脚本开发。录制脚本看似简单（点一下“录制”按钮），但录出一个“健壮”、“可复用”、“能真实模拟用户”的脚本，需要很多技巧。

3.1 协议选择与录制配置

启动 VuGen，首先面临的是协议选择。LoadRunner 支持上百种协议，选错协议会导致根本录不到任何内容。对于绝大多数基于浏览器的 Web 应用，选择“Web - HTTP/HTML”协议即可。除非你的应用大量使用 WebSocket、Ajax 长轮询等，才需要考虑多协议或更底层的选择。

创建脚本后，进入录制配置界面。这里有几个关键参数：

• Application type：选择“Internet Applications”，即浏览器应用。
• URL Address：填入你要测试的网站起始地址，如http://www.example.com。
• Working directory：脚本工作目录，保持默认或指定一个英文路径。
• Record into action：选择将录制的操作放到哪个部分。通常我们把登录等初始化操作放到vuser_init，核心业务操作放到Action，退出清理操作放到vuser_end。首次录制可以全放到Action。

点击“Start Recording”，VuGen 会启动一个内置浏览器。之后你在该浏览器中的所有操作（点击、输入、提交）都会被捕获并生成对应的脚本函数。

3.2 脚本增强：让脚本“活”起来

直接录制的脚本是“死”的，它只是忠实地记录了你的一次操作。要用于模拟大量用户，必须进行“增强”，主要涉及三个方面：

3.2.1 事务（Transaction）事务用来衡量一个或多个操作的响应时间。比如，我们将“用户登录”这个操作定义为一个事务。 在脚本中，在登录操作开始前插入lr_start_transaction("Login");，在登录操作结束后插入lr_end_transaction("Login", LR_AUTO);。这样，Analysis 报告中就会单独统计“Login”事务的平均响应时间、通过率等关键指标。关键点：事务的命名要有业务意义，如“Login”、“SearchProduct”、“SubmitOrder”。

3.2.2 参数化（Parameterization）这是性能测试脚本的灵魂。如果100个用户都用同一个账号“test”登录，系统可能会因为缓存、锁等原因导致测试结果失真，更可能触发业务逻辑错误（如“用户已登录”）。参数化就是将脚本中的常量（如用户名、密码、搜索关键词）替换为从数据源读取的变量。 操作步骤：选中脚本中的常量值（如“test”），右键选择“Replace with a Parameter”。创建一个新的参数文件（如username.dat），编辑该文件，每一行就是一个参数值（如 user1, user2, ... user100）。在参数属性中，设置“Select next row”为“Unique”，“Update value on”为“Each iteration”。这样，每个虚拟用户每次迭代都会取一个唯一的用户名。避坑技巧：参数文件务必保存为 ANSI 编码，放在脚本目录下。UTF-8 编码可能导致中文参数乱码。对于需要关联使用的参数（如登录后产生的 Session ID），要确保其获取和更新的逻辑正确。

3.2.3 集合点（Rendezvous）集合点用于制造“瞬间并发”的压力。比如，你想测试100个用户同时点击“提交订单”按钮时系统的表现。你需要在提交订单的脚本前插入集合点：lr_rendezvous("SubmitOrder");。在 Controller 中设置集合点策略后，虚拟用户运行到这里时会暂停，直到所有用户都到达这个点，再一起释放，从而形成真正的并发压力。注意事项：集合点不是越多越好。滥用集合点会使得测试场景变得不真实（现实中用户操作不可能完全同步），并且会极大增加测试的复杂度和耗时。通常只在最核心、最可能产生瓶颈的业务点（如秒杀、抢购的提交瞬间）设置集合点。

3.2.4 检查点（Checkpoint）检查点用于验证服务器返回的内容是否正确，是判断业务是否成功执行的关键。通过web_reg_find或web_find函数，在请求之前注册一个文本检查点，比如检查返回页面中是否包含“登录成功”字样。如果检查失败，该次迭代可以被标记为失败。这能确保我们压测的是正确的业务流，而不是一堆错误的请求。

3.3 脚本调试与回放验证

脚本增强后，绝不能直接拿到 Controller 去压测。必须在 VuGen 中先进行单用户回放调试。

1. 语法检查（F7）：确保脚本没有语法错误。
2. 单次回放（F5）：观察回放日志（Replay Log）。务必切换到“Extended log”模式，并勾选“Data returned by server”。这样你能看到服务器返回的所有数据，对于调试参数化和关联至关重要。
3. 验证业务逻辑：通过检查点日志和肉眼观察回放摘要，确认脚本完整地走通了业务流，并且关键检查点都通过了。
4. 迭代回放：在“Run-time Settings”中设置迭代次数为3-5次，模拟一个用户重复操作，进一步验证参数化数据在多次迭代中是否正确轮询。

只有单用户回放完全成功且符合业务预期，这个脚本才算初步合格，可以交付给 Controller 用于场景设计。

4. 场景设计与执行：构建真实的压力模型

脚本准备好后，我们来到 Controller，这里是将脚本转化为实际压力的地方。场景设计的目标是模拟真实用户的使用模型。

4.1 负载生成器管理

如果你的压力很大（比如需要模拟上万用户），一台机器可能无法生成足够的负载，或者会先于被测系统成为瓶颈。这时就需要使用多台机器作为“负载生成器”（Load Generator）。 在 Controller 的“Load Generators”界面，可以添加其他机器的 IP 地址。前提是那些机器上也安装了 LoadRunner 的负载生成器组件并启动了magentproc.exe进程。添加后，状态必须显示为“Ready”才能使用。常见问题：连接失败通常是因为目标机器的防火墙未关闭、magentproc进程未启动，或网络不通。

4.2 场景计划设置

这是场景设计的核心，主要设定两部分：虚拟用户组和调度计划。

• 虚拟用户组：将 VuGen 脚本加载进来，形成一个 VUser 组。你需要设定这个组总共使用多少个虚拟用户。这些用户可以被分配到不同的负载生成器上。
• 调度计划（Schedule）：定义压力如何随时间施加。这是模拟真实场景的关键。
  • 初始化（Initialize）：所有虚拟用户以多快速度被初始化（加载到内存中）。通常选择“同时初始化所有虚拟用户”或“每隔一段时间初始化一部分”。
  • 启动（Start Vusers）：压力如何上升。例如，“每15秒启动2个VUser”，这模拟了用户逐渐进入系统的过程。
  • 持续时间（Duration）：压力达到峰值后，持续运行多长时间。例如，稳定并发100个用户，运行30分钟。这个阶段的性能数据最具有分析价值。
  • 停止（Stop Vusers）：压力如何下降。例如，“每30秒停止5个VUser”。

一个典型的压力模型是：“缓步加压 -> 稳定压力 -> 缓步减压”。避免“瞬间拉到最大并发”和“瞬间停止所有用户”这种不真实的暴力模式。

4.3 运行时设置与监控器配置

在场景中，可以统一修改 VUser 组的“Run-time Settings”，比如思考时间（Think Time）、迭代次数、日志级别等。对于压力测试，通常需要忽略或按比例缩短思考时间，因为我们的目标是考察服务器处理能力，而不是模拟用户发呆。

另一个重点是配置监控器（Monitors）。Controller 可以连接到被测系统（服务器）上，监控其资源使用情况。这通常需要在服务器上安装监控代理（如 Windows 的PerfMon计数器，Linux 的rstatd或SSH监控）。 你需要添加计数器，例如：

• Windows：%Processor Time（CPU使用率）、Available MBytes（可用内存）、Avg. Disk Queue Length（磁盘队列）、Network Interface\Bytes Total/sec（网络流量）。
• Linux：通过rstatd监控类似指标。

实操心得：场景执行前，务必先“试跑”一下。设置一个很小的负载（如5个用户，跑1分钟），目的是验证整个链路是否通畅：脚本能否在所有负载生成器上成功启动？监控计数器能否正常获取数据？这能提前发现脚本路径错误、依赖文件缺失、监控权限不足等问题，避免长时间压测跑到一半才失败。

5. 结果分析与瓶颈定位：从数据到结论

压测执行完毕后，Controller 会自动调用 Analysis 组件打开结果文件。面对几十张图表，新手很容易眼花缭乱。分析的关键是关联分析和趋势分析。

5.1 核心性能指标解读

首先关注几个最核心的指标：

1. 事务响应时间：这是用户体验的直接体现。在“Analysis Summary”或“事务摘要”图中，查看每个事务的平均响应时间、最小/最大响应时间，以及是否满足预设的性能需求（如登录事务<2秒）。更重要的是看“事务性能摘要图”，它按时间轴展示响应时间变化，能清晰看到系统何时开始变慢。
2. 每秒事务数（TPS）：系统处理能力的核心指标。它表示系统每秒成功完成的事务数。TPS 曲线应该与施加的并发用户数曲线有合理的对应关系。当用户数增加而 TPS 不再增长甚至下降时，说明系统达到了瓶颈。
3. 虚拟用户数：正在运行的 VUser 数量。用于确认场景是否按计划执行。
4. 错误率：失败事务或 HTTP 错误的比例。一个健康的系统在压力下错误率应该极低（如<0.1%）。错误率飙升往往是系统崩溃或资源耗尽的先兆。
5. 系统资源利用率：来自服务器的监控数据。
   • CPU使用率：持续高于80%可能成为瓶颈。
   • 内存使用率：关注可用内存是否持续减少，是否存在内存泄漏。
   • 磁盘I/O：磁盘队列长度持续过高，说明磁盘读写成为瓶颈。
   • 网络带宽：检查是否达到网络带宽上限。

5.2 关联分析与瓶颈定位流程

Analysis 提供了“合并图”功能，这是定位瓶颈的利器。一个标准的分析流程是：

1. 确定性能拐点：在“运行 Vuser”图中，找到系统开始出现大量错误或响应时间急剧上升的时间点（T）。
2. 关联资源图：将“运行 Vuser”图与“事务响应时间”图、“TPS”图合并。确认响应时间和 TPS 的恶化是否与用户数增加同步。
3. 关联系统资源图：将上述合并图再与“Windows 资源”或“UNIX 资源”图合并。观察在时间点 T，是否有某项系统资源（CPU、内存、磁盘、网络）达到了瓶颈（如CPU持续100%，内存耗尽，磁盘队列激增）。
4. 钻取分析：如果资源未达瓶颈，但性能下降，则可能是应用层或中间件瓶颈。此时需要查看 Web 服务器（如 Apache、Nginx）、应用服务器（如 Tomcat、WebLogic）或数据库的监控指标（如连接池使用率、慢查询日志）。LoadRunner 本身可能无法直接监控这些，需要结合其他工具（如服务器日志、APM工具）进行分析。

常见瓶颈模式速查表：

5.3 报告生成与解读

Analysis 可以生成丰富的报告，从简单的摘要到详细的 Word/PDF 报告。对于内部团队沟通，我通常直接使用 Analysis 的“报告”功能生成一个包含关键图表的 HTML 报告。对于正式的交付物，则需要整理出结构化的 Word 报告，至少包含：测试目标、测试环境、场景设计、核心结果摘要（事务响应时间、TPS、错误率、资源利用率）、瓶颈分析与建议、测试结论。

最后再分享一个小技巧：在分析结果时，不要只盯着“平均值”。“90百分位响应时间”这个指标往往更能反映大多数用户的体验。比如，平均响应时间是1秒，但90%的用户响应时间在3秒以内，这意味着有10%的用户体验很差。这个指标对于评估系统的稳定性至关重要。在 Analysis 的“事务性能摘要”图中，可以很方便地看到各个百分位的数值。