首页/资讯中心/详情

LoadRunner性能测试实战：从零开始完成飞机订票系统压力测试

LoadRunner性能测试实战：从零开始完成飞机订票系统压力测试
📅 发布时间：2026/6/24 4:54:30

1. 项目概述：为什么性能测试是项目交付前的“必考科目”？

刚入行那会儿，我总觉得性能测试是个“锦上添花”的活儿，功能跑通了不就行了？直到有一次，我们团队辛苦开发了三个月的电商系统，在上线大促时直接“趴窝”，页面加载慢如蜗牛，支付接口频频超时，用户投诉像雪片一样飞来。那次事故后，我才真正明白，性能测试不是选修课，而是项目上线前必须通过的“压力测试”，它直接关系到用户体验、业务收入和公司声誉。

而LoadRunner，就是这场“压力测试”中，历史最悠久、功能最强大的“主考官”之一。虽然现在开源工具如JMeter、Locust风头正劲，但LoadRunner在企业级复杂场景、协议支持深度和分析报告的专业性上，依然有着不可替代的地位。特别是对于银行、电信、航空这类核心交易系统，LoadRunner往往是性能测试团队的标配工具。

这个教程，就是带你从“零”开始，亲手用LoadRunner完成一次完整的性能测试实战。我们不谈空泛的理论，直接上手一个最经典的练手场景——飞机订票系统。你会学到如何录制脚本、模拟成千上万的虚拟用户、分析瓶颈在哪里，最终拿出一份有说服力的性能测试报告。无论你是刚接触测试的新人，还是想从JMeter等工具扩展到LoadRunner的工程师，这篇“从零开始”的指南都能让你获得立即可用的实战能力。

2. 环境准备与工具部署：搭建你的第一个性能实验室

工欲善其事，必先利其器。在开始“施压”之前，我们需要一个稳定、干净的测试环境。这里最容易踩坑的就是环境冲突和授权问题。

2.1 LoadRunner的获取与安装要点

首先明确一点，LoadRunner是Micro Focus公司的商业软件，个人学习可以通过其官网申请评估版（Trial Version），通常有30天或60天的完整功能使用期。绝对不要从任何非官方、来路不明的渠道下载所谓“破解版”，这不仅涉及法律风险，更可能捆绑恶意软件，导致你的测试环境甚至开发网络出现严重安全问题。

安装过程本身是图形化的向导，比较直接，但有三个关键决策点需要注意：

  1. 版本选择：目前主流版本是LoadRunner 2022或2024。对于新手，我建议选择稍早一点的稳定版（如2022 R2），因为网络上的教程和问题解决方案会更丰富。最新版可能引入了新特性，但也可能伴随未知的Bug。
  2. 组件选择：典型安装包括：
    • Virtual User Generator (VuGen)：用于录制和开发测试脚本的核心工具。
    • Controller：用于设计场景、管理和监控负载测试的控制中心。
    • Analysis：用于生成和分析测试结果报告的分析器。
    • Load Generator (LoadGen)：负载生成器，负责真正执行脚本、产生压力的机器。对于初学者，可以全部安装在一台性能较好的PC上（建议16GB内存以上）。在生产环境，Load Generator通常部署在独立的服务器上。
  3. 安装路径与权限：安装路径避免使用中文或带有空格的目录，例如D:\LoadRunner就比D:\性能测试工具\LoadRunner 2022要好得多。同时，最好以管理员身份运行安装程序，避免因权限不足导致某些服务（如监控代理）安装失败。

安装完成后，首次启动可能会要求你配置代理或输入许可证。评估版会自动配置临时许可证。如果遇到许可证错误，请检查系统时间是否正确，以及是否关闭了防火墙对LoadRunner通信端口的拦截（默认端口通常为54345、8080等，具体需查看文档）。

2.2 测试目标系统：飞机订票系统部署

为了实战，我们需要一个可以“折腾”的系统。HP（现Micro Focus）官方提供了一个经典的样例程序，叫做“HP Web Tours”，这是一个模拟飞机订票的Web应用。它通常作为LoadRunner安装包的一部分被一起安装。

你可以在开始菜单或安装目录下找到“HP Web Tours”的启动项。启动后，它会运行一个本地的小型Web服务器（默认端口通常是1080或8080）。在浏览器中访问http://localhost:1080/WebTours，你应该能看到一个航班订票网站的登录界面。

这里有个关键步骤：首次使用前，需要点击页面上的“sign up now”链接，注册一个新用户（比如，用户名：jojo，密码：bean）。这个操作会在后台初始化用户数据库。很多新手卡在第一步录制不到脚本，就是因为没注册用户，无法完成登录操作。

把这个Web Tours服务保持运行，它就是我们将要“攻击”的目标。把它想象成一个即将上线的小型航空公司官网，我们的任务就是模拟大量用户同时来查询航班、订票、付款。

2.3 基础概念扫盲：脚本、场景、虚拟用户与事务

在动手前，快速理解LoadRunner的四个核心概念，能让你后续操作不迷糊：

  • 脚本 (Script)：模拟单个用户的操作流程。比如，“打开首页 -> 登录 -> 查询航班 -> 选择航班 -> 输入乘客信息 -> 付款 -> 登出”这一系列HTTP请求，会被VuGen录制下来，生成一个脚本。脚本是性能测试的“原子单位”。
  • 虚拟用户 (VUser)：由LoadRunner模拟出来的、执行脚本的“机器人”。一个虚拟用户对应一个独立的线程或进程，执行一份脚本。当我说“模拟1000个用户”，就是指创建1000个VUser。
  • 场景 (Scenario)：定义性能测试如何执行的“剧本”。在Controller中，你告诉LoadRunner：用多少个VUser（负载模型），运行哪个脚本，在哪些负载生成器上运行，运行多久，要监控哪些服务器的指标（如CPU、内存）。
  • 事务 (Transaction)：为了衡量系统性能，我们在脚本中把关键的业务操作标记为事务。例如，把“登录”操作标记为一个名为lr_login的事务。LoadRunner会统计这个事务的响应时间、成功率等。响应时间是性能测试最核心的指标之一，它直接代表了用户的等待时间。

理解了这些，我们就可以进入下一步：录制第一个能“动”起来的脚本。

3. 脚本录制与开发：让你的虚拟用户“学会”操作

录制脚本是性能测试的第一步，也是最容易出“杂音”的一步。一个录制得不好的脚本，就像让一群没经过训练的演员上台，结果要么演不下去，要么演得完全不对。

3.1 首次录制：捕获飞机订票流程

打开VuGen，创建一个新的“Web - HTTP/HTML”协议脚本。给脚本起个名字，比如Flight_Booking。

  1. 录制配置：在录制开始前，弹出录制选项对话框。这里至关重要：

    • Application type：选择Internet Applications。
    • URL Address：填入我们的目标地址http://localhost:1080/WebTours。
    • Record into Action：选择Action。LoadRunner脚本默认由vuser_init、Action、vuser_end三部分组成。通常，我们把登录放在vuser_init（只执行一次），核心业务操作放在Action（可以循环执行），登出放在vuser_end（只执行一次）。首次录制，我们先全放在Action里简化操作。
    • 录制方式：确保选中“基于HTML的录制”，这对于现代Web应用更友好，能自动处理关联。

  2. 开始录制：点击OK，VuGen会启动一个内置浏览器。你在这个浏览器里的所有操作都会被记录下来。现在，请手动完整执行一遍订票流程：

    • 访问http://localhost:1080/WebTours
    • 在登录框输入之前注册的用户名（jojo）和密码（bean），点击Login。
    • 点击“Flights”进入航班查询页面。
    • 选择出发城市和到达城市（例如，Denver到London），点击“Continue”。
    • 选择航班班次（比如，第一班），点击“Continue”。
    • 填写乘客信息（姓名、地址等，可随意填），点击“Continue”。
    • 在支付页面，输入信用卡信息（样例程序不校验，可随意填），点击“Purchase”。
    • 看到订票成功的确认页面。
    • 最后，点击右上角的“Sign Off”退出登录。

  3. 停止录制：完成操作后，回到VuGen点击停止按钮。你会看到VuGen自动生成了一大段C语言的代码，里面充满了web_url，web_submit_data这样的函数，每一个都对应着你刚才操作的一个HTTP请求。

3.2 脚本优化与增强：从“录像”到“智能脚本”

刚录制的脚本是“死的”，只能原样回放。如果直接用于压力测试，所有虚拟用户都会用相同的账号（jojo）、订相同的航班，这不符合真实情况，也容易导致服务器缓存命中率异常高，测试结果失真。因此，必须对脚本进行参数化和关联。

参数化 (Parameterization)： 将脚本中的常量（如用户名、密码、城市、航班日期）替换为从数据文件中读取的变量。

  • 为什么这么做？模拟真实世界中不同用户的不同行为。例如，1000个用户应该使用1000个不同的用户名登录，查询不同的航线。
  • 如何操作？在VuGen中选中一个常量值（如用户名“jojo”），右键选择“Replace with a Parameter”。创建一个新参数（如username），选择参数类型为“File”。然后，你需要创建一个文本文件（如accounts.dat），里面每一行就是一个用户名和密码的组合（用逗号分隔）。在参数属性中，设置“Select next row”为“Unique”，“Update value on”为“Each iteration”。这样，每个虚拟用户每次迭代都会取一个唯一的用户名。

关联 (Correlation)： 处理服务器返回的动态值。这是LoadRunner脚本开发中最核心、也最容易出错的技术点。

  • 为什么需要关联？Web应用经常使用Session ID、Token、动态生成的订单号等。这些值每次请求都会变化。录制时，脚本里记录的是当时的一个具体值（如sessionid=12345）。回放时，服务器会生成一个新的值（如sessionid=67890），如果脚本还发送旧的12345，服务器就会拒绝请求，导致脚本失败。
  • 如何操作？LoadRunner有自动关联和手动关联两种。对于Web Tours，一个常见的关联点是登录后服务器返回的userSession值。你需要找到这个值在响应中的位置（通常通过“Scan Script for Correlations”功能或查看“Recording Log”），然后使用web_reg_save_param函数将它捕获到一个参数中（如lr_userSession），并在后续请求中用这个参数{lr_userSession}替换掉硬编码的session值。
  • 一个关键技巧： 关联函数（如web_reg_save_param）必须放在它要捕获的请求之前。因为它是注册一个“规则”，告诉LoadRunner“在下一个请求的响应中，按照这个规则去抓取数据”。

添加事务 (Transaction)： 在关键步骤前后插入lr_start_transaction和lr_end_transaction函数。例如，把从点击“Flights”到出现航班列表的整个过程标记为“查询航班”事务。这能让我们在最终报告里清晰地看到每个业务环节的耗时。

添加检查点 (Checkpoint)： 使用web_reg_find或web_image_check函数，验证页面是否包含关键文本（如“Payment Details”），以确保脚本执行到了正确的位置，而不仅仅是服务器返回了HTTP 200状态码。

经过这些步骤，你的脚本就从简单的操作录像，变成了一个可以模拟真实、多样用户行为的智能测试单元。接下来，我们就要指挥千军万马（虚拟用户）来执行这个脚本了。

4. 场景设计与执行：指挥一场可控的“压力风暴”

脚本准备好后，我们移步到LoadRunner的“大脑”——Controller。在这里，我们把单个用户的脚本，编排成一场模拟真实用户访问的压力测试。

4.1 构建基础负载场景

在Controller中新建一个场景，选择“Manual Scenario”（手动场景），它给我们最大的控制灵活性。将优化好的Flight_Booking脚本添加进来。

  1. 设计负载模型：这是场景设计的灵魂，决定了压力如何施加。

    • 虚拟用户数：初期可以设置一个较小的值，比如50个VUser，用于调试。
    • 负载生成器 (Load Generators)：默认使用本地机。如果压力较大，需要配置远程负载机。确保状态为“Ready”。
    • Schedule（计划）：这是核心配置区。
      • Ramp Up（逐步加压）：设置VUser如何启动。例如，设置50个用户，在5分钟内逐步启动完毕（每6秒启动一个）。这比瞬间启动50个用户更温和，也更能观察系统在压力逐渐增大时的表现。
      • Duration（持续时间）：压力保持时间。例如，所有用户启动后，持续运行10分钟。这个时间要足够长，以便观察系统在稳定压力下的性能表现（如内存是否有缓慢泄漏）。
      • Ramp Down（逐步退出）：设置用户在几分钟内逐步停止。给系统一个缓冲期来结束会话。

  2. 配置运行时设置 (Run-time Settings)：双击脚本，进入运行时设置。这里有几个关键项：

    • Run Logic：定义Action部分迭代执行的次数。
    • Pacing：设置迭代之间的间隔时间。可以固定间隔，也可以随机间隔，这能更真实地模拟用户思考时间。
    • Log：为了性能，在正式压测时通常选择“Enable logging only when an error occurs”（仅在出错时记录日志）。调试阶段可以选“Standard log”。
    • Think Time：录制时捕获的用户操作间隔时间。在压测时，我们通常忽略或按比例缩放思考时间，以产生更大的压力。但要注意：完全忽略思考时间会使压力远超真实情况，可能得出不合理的结论。

4.2 监控系统资源：找到瓶颈在哪

压力测试不只是看脚本能不能跑通，更重要的是看服务器在压力下的状态。Controller提供了强大的监控功能。

点击“Run”标签页，在右侧的“Available Graphs”中，将关键的监控指标拖到中央图表区。对于Web Tours这个本地应用，我们需要监控运行它的Windows机器的资源：

  • System Resources->Windows Resources：添加对localhost的监控。关键计数器包括：
    • % Processor Time：CPU使用率。持续高于80%可能成为瓶颈。
    • Available Mbytes：可用内存。如果持续下降，可能有内存泄漏。
    • Disk Time或Avg. Disk Queue Length：磁盘IO情况。
    • Network Interface\Bytes Total/sec：网络吞吐量。
  • Web Tours应用本身：由于它是简单的CGI应用，我们还可以通过Web Server Resource Monitor监控其连接数等（如果支持）。

一个重要的实操心得：在正式压测开始前，先记录下服务器在无压力状态下的这些指标基线值。这样，在压测中看到的增长才有对比意义。例如，CPU基线是5%，压测中涨到70%，那就是显著的增长；如果基线就是40%，涨到70%则压力相对没那么大。

4.3 执行测试与实时诊断

点击“Start Scenario”按钮，测试开始。Controller界面会动态显示：

  • 虚拟用户的状态（就绪、运行中、已完成、错误）。
  • 事务的响应时间曲线。
  • 每秒点击率（Hits per Second）。
  • 吞吐量（Throughput）。
  • 以及你添加的各种资源监控计数器。

这时，你要像一个急诊室医生一样，紧盯这些仪表盘：

  • 如果错误数（Errors）突然飙升，立即停止测试，查看错误日志。常见原因是脚本关联没做好，或者服务器应用崩溃了。
  • 如果事务响应时间随着用户数增加而线性增长，说明系统处理能力可能已达到瓶颈。
  • 如果吞吐量曲线先上升后持平，而用户数还在增加，响应时间急剧上升，这就是典型的系统饱和状态。

第一次执行，目标不是把系统压垮，而是验证整个测试链条（脚本->场景->监控）是否通畅，获取一个初步的性能数据。根据这次的结果，我们再调整脚本、调整场景设计，进行更深度的测试。

5. 结果分析与报告生成：从数据中讲述性能故事

测试执行完毕，数据都收集好了，接下来是最关键的一步——分析。LoadRunner Analysis工具的作用，就是把Controller收集到的海量原始数据，变成一份能说明问题的性能报告。

5.1 核心性能指标解读

打开Analysis，加载本次测试的结果文件。你会看到很多图表，重点关注以下几类：

  1. 事务响应时间分析：

    • 平均响应时间：这是最直观的指标，但要注意其局限性。如果90%的请求都很快，但10%的请求极慢，平均时间可能看起来“还行”，但实际上用户体验很差。
    • 百分比响应时间：这才是黄金指标。重点关注90th Percentile和95th Percentile响应时间。例如，“登录”事务的90%响应时间是2秒，意味着90%的用户在2秒内完成了登录。这比平均响应时间更能代表大多数用户的体验。如果业务要求是“95%的订单支付在3秒内完成”，那么就直接看95%分位的响应时间是否达标。

  2. 吞吐量与点击率：

    • 吞吐量 (Throughout)：单位时间内服务器成功处理的数据量（通常以字节/秒计）。它反映了系统的处理能力。吞吐量随着用户数增加而增加，直到达到系统瓶颈后趋于平缓或下降。
    • 每秒点击率 (Hits per Second)：单位时间内客户端向服务器发出的请求数。这个指标有助于判断负载是否真的施加上了。

  3. 虚拟用户与错误：

    • 运行中虚拟用户数：对照你设计的场景计划，看实际运行曲线是否符合预期（如是否平滑上升、平稳保持、平滑下降）。
    • 错误统计：有哪些错误？发生在什么阶段？错误率是多少？一个健康的系统，在目标压力下的错误率应该极低（例如<0.1%）。

5.2 关联性分析与瓶颈定位

单一指标很难定位问题，必须进行关联性分析（Merge Graphs）。这是Analysis的精髓。

  • 经典关联：将“运行中虚拟用户数”图与“事务平均响应时间”图合并。你会看到一条清晰的曲线：随着用户数增加，响应时间如何变化。如果响应时间在用户数达到某个点后急剧上升，那个点可能就是系统的最佳并发用户数。
  • 资源瓶颈关联：将“事务响应时间”图与“Windows Resources - % Processor Time”图合并。如果响应时间变差的同时，CPU使用率也飙升至90%以上，那么CPU就很可能是瓶颈。同理，可以关联内存、磁盘IO等。

以我们的飞机订票系统为例：分析发现，“查询航班”事务在用户数超过30后，响应时间显著变长。同时，监控到运行Web Tours服务的机器CPU使用率超过了85%。而磁盘和网络IO都很低。那么初步结论就是：这个单机部署的Web Tours应用，其处理能力（很可能是CGI进程处理能力或数据库查询）在30个并发用户左右达到了瓶颈，CPU是主要制约资源。

5.3 生成专业测试报告

Analysis提供了强大的报告生成功能。你可以使用内置模板，也可以完全自定义。

一份合格的性能测试报告应包含：

  1. 测试概述：测试目标、测试时间、测试环境（服务器/客户端配置）、测试工具及版本。
  2. 场景设计：虚拟用户数、加压策略、脚本业务逻辑简述。
  3. 性能摘要：核心事务的响应时间（平均、90%分位）、通过/失败事务数、总吞吐量。
  4. 关键图表：用户数-响应时间关联图、资源监控图（突出显示瓶颈点）。
  5. 错误分析：列出主要错误类型及数量。
  6. 结论与建议：这是报告的价值所在。基于数据，给出明确的结论（如“系统在30并发用户下满足3秒响应要求，超过40并发则响应时间超标”），并给出可操作的建议（如“建议优化航班查询的SQL语句，或对查询结果增加缓存，预计可将瓶颈提升至60并发”）。

最后一个小技巧：在生成报告前，使用Analysis的“Auto Correlate”功能，它有时能自动帮你找到与事务响应时间相关性最高的资源计数器，为你的瓶颈分析提供线索。

性能测试是一个“设计->执行->分析->优化->再测试”的循环过程。LoadRunner提供了完成这个循环所需的完整工具链。通过这个从零开始的实战，你不仅学会了工具操作，更重要的是理解了性能测试的核心思想：通过模拟真实负载，量化系统表现，定位瓶颈所在，为系统优化和容量规划提供数据支撑。下次当你再面对一个系统时，你就能有计划、有步骤地对它进行“体检”，确保它能在真正的业务洪流中屹立不倒。