LoadRunner 12 在http-server上的实践

目录：

- 引言：关于LoadRunner

- 准备：搭建待测试的服务器

- Load Runner三朵云：

• Vuser Generator：录制和配置测试脚本

• Controller：设置情景参数、服务器和客户端连接，并运行场景模拟，得到模拟结果

• Analysis：对场景模拟的结果进行分析

- 总结

_

关于LoadRunner

LoadRunner是一款压力测试软件，用于对系统进行模拟测试。它通过产生模拟用户，按照录制好的脚本和一定的配置访问服务器，并在此过程中对表征服务器各项指标的参数进行记录和统计，通过一系列分析手段，得出当前系统存在的性能瓶颈和可能有效提升性能的手段，以供开发人员参考。
LoadRunner由三部分（“三朵云”）构成：

1. Vuser Generator：录制脚本，在测试人员对服务器进行一段访问动作时，抓取各个动作并将其“翻译”成源码（支持C、Java、HTML，类似于编译过程）；修改脚本，可按照测试需求对源码进行修改（设置一些额外事件如“用户等待”，对事件做标记以用于检测）；回放脚本，检测录制的脚本代码是否符合测试需求。
2. Controller ：场景模拟，导入调试好的脚本，设置好虚拟用户参数并连接服务器，即可进行场景模拟，该过程中controller会对服务器响应、资源占用的各种参数进行记录并生成统计图表；
3. Analysis：模拟结果分析，通过虚拟用户数、响应时间、每秒点击量、吞吐量等各项指标分析，得出系统可能存在的性能瓶颈；

在实习过程中，我使用的是Web HTTP/HTML策略来进行脚本配置，并对Web服务器进行压力测试。HP LoadRunner 12 适用于 Win10 平台，但大多教程均采用lr11进行教学，而且这两个版本之间不同之处还蛮多（许多选项卡的位置不一样，要找好久），而且事实证明，lr12-Win10运行过程中会有不少莫名其妙的问题。下面我将以本机搭建的http-server服务器为例，来说明这套压力测试流程，希望能够对学习者特别是lr12的使用者提供帮助，更希望技术大牛们能够多多指教。

_

搭建http-server服务器

其实在lr12安装包的Webtours目录下，包含一个订票网站的服务器，开启服务后访问http://localhost:1080/Webtours/即可访问。
不过如果像我一样觉得不过瘾的话，那就自己搭建一个服务器来测试吧
（对此不感兴趣请直接跳过该条目）

• 首先我们需要安装node.js并配置npm环境

在https://nodejs.org/en/中下载并安装Node.js(推荐选择左边的Recommended For Most Users)，成功安装后在DOS界面下运行npm install http-server -g命令，全局安装http-server。
值得一提的是，有一定概率出现“npm既不是内部或外部命令……”的情况，这是由于node.js没有安装在命令行运行的环境变量目录下，我们需要在环境变量路径中添加它的安装位置。
在控制面板\系统和安全\系统中以管理员身份进入高级系统设置，选择环境变量，在Path中添加刚刚安装node.js的目录。
然后重启命令行，运行上面的命令，即可成功安装。

• 接下来在npm目录下打开http-server批处理文件，即可开启服务器。

• 访问 http://localhost:8080/ 或 http://127.0.0.1:8080/ 即可访问本机服务器。在后台能够看到访问记录。

• 服务器提供的链接可用于编写好的js网页脚本。避繁就简，在这里就不做其它链接了。

至此，我们已经搭建好http-server服务器，下面就可以对它进行压测了。

_

Vuser Generator

录制、回放、调试脚本是压测的基础。Vuser Generator通过监测用户行为自动生成对应的脚本。

• 新建Web-HTTP/HTML Script

在File菜单中选择New Script and Solution（或使用Ctrl+N快捷键），选择Web-HTTP/HTML方式，设置好路径后即可生成新脚本。

脚本配置界面如下：

左边显示的是整个脚本文件的信息，其中Actions条目下即为我们所关心的脚本代码，global.h中包含各种头文件，Runtime Settings中可以对脚本运行的参数进行设置（如是否使用参数替换、Action模块循环次数、是否加入思考时间等等），Parameters是参数化的变量列表，Replay Runs是回放的相关信息。这些项目同样可以在上方的按钮嗯还选项卡中找到。
上述涉及的各类参数将在下文中详述。

• 录制脚本

点击录制按钮，首先做一些设置：

脚本代码共分为三部分：vuser_init ,Action ,vuser_end三个部分，init部分通常包含一些初始化动作（如连接服务器、登入），Action部分包含脚本运行动作，end部分通常包含脚本的收尾动作（如登出）。其中Action部分可以设置多次循环。故大多数的模拟动作均放置在Action模块下。
我们选择录制在Action模块下，应用可选择IE浏览器（默认），URL设置为服务器地址后，即可以开始录制：

开启录制后，Vugen会打开相应浏览器并访问url。右侧的状态栏里显示了已经记录的事件个数。

Attention:这里时常会出现浏览器卡住、未响应的情况，服务器也没有访问记录，更换浏览器同样会出现这样的情况。初步判断是内存占用过多，关闭其它高功耗应用或重启后有所改善。

录制完毕后，Vugen生成了脚本代码，服务器后台也记录了相应的动作：

代码下方记录了服务器与客户端的数据通信。在Snapshot视图下还能看到每次响应后对应的网页截图，以便于之后与回放进行比对。
代码中的每一块都记录了一定的事件。在这一脚本中只包含了对链接的访问（web_url），其它脚本中可能还包含提交信息(web_summit)、思考时间即等待时间(thinktime)等其它事件。

• 脚本修改

在录制好脚本后，有一些配置技巧能够为之后的模拟和检测提供便利。
Transaction：事务。利用lr_start_transaction(“name”)和lr_end_transaction(“name”,LR_AUTO)来标记一个事务的起始和结束。当一个事务生成后，每一次脚本运行时都会记录它的状态（是否passed）和响应时间，便于统计处理。需要注意的是，事务必须包含完整的代码块，不能插在代码块之间。一般最好也不要包含思考时间。
Rendezvous：集合点。使用lr_rendezvous(“name”)来设置集合点，即脚本运行至此时会挂起，当积累到设定量值后统一释放。这一策略可对在突发高并发用户数下的系统表现做出检测。
关联设置：某些服务器在用户访问时，会分配标识字符，也就意味着即使同一用户，两次访问时的参数也不尽相同。因此我们需要检测到生成的脚本中的哪些参数是在每次登陆时发生变化的。在Design -> Design Studio->Correlation中可以看到Vugen探测到的关联项目。将动态变化的参数设置关联后，每次访问遇到这个参数时，都会用当次服务器分配的值来替换original值，从而顺利访问。
变量参数化：当设置模拟用户循环访问时，如果每次的操作完全相同，显然是不符合实际情况的。将变量参数化后，可以设置每次循环时使该变量按某种顺序或随机地遍历列表中的值，从而更真实地模拟实际情况。
错误处理函数：lr_continue_on_error()函数，用于判断当前错误发生时是否继续执行接下来的动作。在实际测试过程中，发生一些小的错误（如图片无法加载）不至于为此让整个测试过程终止。当函数参数为1时，继续执行后面的脚本；当参数为0时，结束脚本。

• 回放脚本

回放脚本主要是检测配置好的脚本是否能够执行预期的动作。
在回放前可以通过Run Settings设置回放循环次数（Action部分）、间隔时间、是否忽略思考时间、返回日志信息、网速限制等等。
回放时可以选择Step by step，不过它更常用于debug时。
回放后，可以看到运行结果：

结果显示回放成功运行。同样可以在Snapshot视图下看到每次响应的网页截图，并与录制时的进行比较，查看是否相符。
值得一提的是，在日志中标明事务成功pass且记录了时长。设置多个事务的统计数据记录，有助于后期分析系统的性能障碍。

_

Controller

Controller为我们提供了多用户场景模拟和数据监测的平台，实际测试过程即是在这个平台上运行的。

• 创建测试场景

在创建场景时，有手工场景、目标场景可供选择。

• 手工场景：需要自己设定虚拟用户数、用户访问间隔、持续访问时间等各项参数，测试时严格按照该设定执行。在分析性能瓶颈时多采用该方式。
• 目标场景：只需要设置用户数范围、触发方式和测试目标，结果会返回是否达到目标。常用于较完备系统的性能达标测试。

下面我们以手工场景为例进行测试：

Controller中包含设计和运行两个面板。

– 设计

在设计界面下，我们需要对场景模拟策略进行设置。

– Scenario Groups

在上方的Scenario Group里，我们可以添加多个脚本共同进行测试（在实际情境下，一个服务器需要同时处理各种各样的请求）。Quantity显示每个脚本测试的虚拟用户数。

Load Generators标识负载生成器（运行脚本的负载引擎）。它用来表明该脚本测试时的负载来源，通常默认为localhost(本机)。但是每生成一个虚拟用户，会使负载生成器多占用2M-3M空间，这会对主机的测试性能造成一定影响。因此，实际测试时负载生成器的工作常由多个远程客户端担任（一个负载生成器的内存使用过多时会成为系统的性能瓶颈，因此常需要多个PC来生成若干负载生成器）。

需要注意的是，PC在启用代理（LR Agent）后才可以连接主机进行测试。
在HP LoadRunner -> Advanced Settings目录下打开Agent Configuration，选择Enable Terminal Sevices即可启用代理。

添加远程客户端：

正确添加后，即可与服务器进行连接。
如果Status显示Failed，请检查IP地址、操作平台是否正确，LR Agent是否启用。

– Scenario Schedule：选择测试方式

• Schedule by：选择场景模拟设置是应用于全局进行or分组设置。在多个脚本共同时测试时，当选择“Scenario”时，下方的选项卡题目为“Global Schedule”（如上图），其中的设置会应用于所有脚本；当选择“Group”时，下方的选项卡题目变为“Group Schedule for : xxxx”（如下图），这样可以对不同的脚本设置不同的测试策略（如实际情况下A动作的发生频率/并发用户数远低于B动作）。

• Run Mode：选择运行时的计划种类。“Basic schedule”只包含初始化、启动用户和持续运行时间三个部分（如下图）。“Real-worlld schedule”中则还可以设置停止用户、重新新建用户等自定义设置，以达到更加逼真地模拟实际情况的测试效果（如上上图）。
  

– Schedule：设计测试计划

• Initialize: 选择同时初始化所有用户or间隔一定时间进行一定数量初始化or在用户被创建前进行初始化 （多用最后者）。
• Start Vusers: 选择当次新建用户总数；选择同时新建所有用户or间隔一定时间新建一定数量用户 （多用后者）。
• Duration: 设置持续运行时间。
• Stop Vusers: ：选择当此停止用户总数；选择同时停止所有用户or间隔一定时间停止一定数量用户。

– IP Wizard：使用IP欺骗来增强场景真实性

• 在实际访问过程中，每个客户端都使用自己的独有IP。为了实现这种效果，可以使用HP LoadRunner -> Tools 目录下的IP Wizard工具来为一台PC申请多个虚拟IP，从而达到更真实的模拟效果。
  注意：IP Wizard需要将本机IP设为静态IP才可以启动
  我在启动了IP Wizard时，在Generate的时候，DOS窗口闪现了若干次，但查看本机IP依然只有一个静态IP，在Manual中也没有找到有效的解决方案。

– Interactive Schedule Graph：显示对应的用户数量变化图。

– Service Level Agreement(SLA)：用于手工场景下，判断各项测试数据是否达标（Pass or Fail）。

需要注意的是，这项分析必须在Analysis中才能看到。
(目标场景测试下的设置与此大同小异，不过前者会直接在场景运行结束后告知测试人员是否达标)

我们对事务的平均响应时间设定目标（当运行用户数处在不同区间时标准不同）。在稍后的Analysis中可以看到详细的返回信息。

– 运行

进入运行界面：

界面中包括了实时用户状态、各项参数的统计图表。可见的图表有：

通常我们关心的有：运行用户数、事务响应时间、每秒点击量、吞吐量、系统资源使用等。

需要注意的是，系统资源使用图要添加服务器才能显示：

接下来就可以真正开始场景测试了。（不要忘记打开服务器！）

等待场景运行结束。

运行结束。

注意：如果自行设置了集合点，运行过程中可以在Scenario -> Rendezvous中监控和手动释放。

有时场景运行结束后会出现几个Errors(我的一般是4个)，log中显示“Can't find the server” ，目前也没有找到解决方案，不过似乎不影响后续的结果分析。

_

Analysis

将场景运行结果导入Analysis后，可以获得更为详尽的测试数据，借助强大的图表、统计工具进行更加细致的分析，得到可能存在的性能瓶颈并生成测试报告。

导入结果后，Analysis会生成一份简述和若干图表。与Controller不同的是，Analysis中的图表可以进行筛选、放缩、合并等操作。

– Analysis Summary

Summary中包括场景测试的各项基本信息、SLA考核结果、事务统计信息和HTTP响应数等。

在事务汇报中，可以看到各个事务响应的指标。
在HTTP响应汇报中，状态返回码均为200，表明服务器已成功处理所有请求。
在SLA考核指标中，三项待考核的事务响应均未达标。打开Analyze Transaction可以查看每个事务的详细考核报告：

– 图表分析

在每个图表中可以对运行过程的各个细节进行查看。而图标合并策略更有利于我们的分析。

Ctrl+M进入Merge界面。共有三种模式进行图像合并。个人觉得常用的有两种：

• Correlate： 将两个变量分别为x,y轴建立关系图，可以直观地看出因变量随自变量的变化情况。但只能用于两个直接相关的变量。
  

• Overlay： 在需要合并多个变量图时，选用这一方法。例如：通常情况下每秒点击量即访问请求增加时，如果吞吐量达到饱和了，那么响应时间就会增大。可以通过Overlay策略来反映这一关系。
  

– 性能指标分析

前端指标：

• 响应时间，最直观的感受。
• 吞吐量，每秒钟服务器与客户端成功传输的总数据量 。
• TPS、TPM、TPH每s/min/h处理事务数。用户角度的事务处理速度。
• HPS每秒点击数，反映服务器运行是否稳定，同时也可以评估客户端的请求频率，必要时可以调整、合并操作。

后端指标：

• CPU
  CPU使用率 %Processor Time。与windows的调度策略有关（优先运行程序or后台程序）。
  处理器队列长度 %Processor Queue Length。CPU内核数的两倍以内属于正常范围。

线程池

①多线程：分布式应用服务器：每个线程负责一个用户请求；数据库：每个线程负责一个SQL请求。

②线程池：用于管理多线程的一种机制。线程主要消耗CPU资源。

③动态影响：三层架构C—S—D，瓶颈可能出现在任何一层。例如增大S端线程数量，CPU需要修改为支持更多线程，还要保证在数据库的支持范围内。

• 内存
  内存使用率 %Memory Time 。
  可用内存 Available Mbytes。
  内存的页交换频率 %page/sec。内存跟虚拟内存交换的频率，数值处于低水平，说明内存性能良好，足够使用。

虚拟内存：利用一块硬盘区域去模拟内存操作。最初内存很小很快，而硬盘便宜容量又很大。内存比硬盘贵100倍左右，而速度又快100倍。内存不够的时候，先用虚拟内存临时保存，之后要用的时候再用内存读回来，即页交换。内存的管理单位称为页。

缓存：某程序使用的内存。内存速度快于硬盘，硬盘速度又快于网络。 进行系统级性能优化的时候，重点利用好内存缓存机制。代码级性能优化，SQL语句，算法。少用内存，但要用好读到的内存，减少运算次数。

• 硬盘I/O
  硬盘使用率 %Disk Time。

– 生成分析报告
生成HTML Report，使得开发人员不必安装lr测试环境即可查看测试的各项详细数据。

至此，整个压测流程结束，可以撰写性能测试报告了。

_

总结

整体而言，LoadRunner的操作还算是比较友好。但本文仅仅阐述了最基础的压测过程，在实际测试过程中，面对的操作动作代码和分析要复杂得多，而且还会出现各种各样意想不到的问题。这需要我们掌握更多的技巧，能够优化脚本代码、更真实地模拟场景，以提供更可靠的分析结果。