loadrunner
概述
LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner能支持广泛的协议和技术，为您的特殊环境提供特殊的解决方案。[2]
主要功能轻松创建虚拟用户
使用LoadRunner的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定)，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。
用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。
为了进一步确定您的Virtual user 能够模拟真实用户，您可利用LoadRunner控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。
创建真实的负载
Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner的Controller，您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。
而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能---- 包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。
定位性能问题
LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据（如响应时间）和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。
利用LoadRunner的ContentCheck TM ，您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。
分析结果以精确定位问题所在
一旦测试完毕后，LoadRunner收集汇总所有的测试数据，并提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner的Web 交易细节监测器，您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能
够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网络延时进行分解，以判断DNS 解析时间，连接服务器或SSL 认证所花费的时间。通过使用LoadRunner的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。
重复测试保证系统发布的高性能
负载测试是一个重复过程。每次处理完一个出错情况，您都需要对您的应用程序在相同的方案下，再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。
LoadRunner完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上，提供广泛的应用服务。通过测试这些组件，您可以在应用程序开发的早期就确认并解决可能产生的问题。
利用LoadRunner, 您可以很方便地了解系统的性能。 它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基准，以此衡量在一段时间内，有多大程度的改进并确保应用成功。由于这些报告是基于HTML 的文本，您可以将其公布于您公司的内部网上，便于随时查阅。
接下来的文章编者就将辑录一篇网上的使用LoadRunner®来测试BEA中间件产品文章来与大家分享如何使用LoadRunner进行实际的性能测试。
性能测试1． LoadRunner的虚拟用户
LoadRunner使用虚拟用户（Virtual users）来模拟实际用户对业务系统施加压力。虚拟用户在一个中央控制器（controller station）的监视下工作。
在做一个测试方案时，要做的第一件事就是创建虚拟用户执行脚本。LoadRunner提供了Virtual User Generator来录制或编辑虚拟用户脚本。
2． 使用Vugen创建虚拟用户执行脚本
A．从菜单中选择运行Virtual User Generator：
B．创建一个单协议脚本，选择协议类型为"Tuxedo 7"
C．选择工具条中的" "来录制一个脚本，在弹出的窗口中输入Tuxedo客户机程序的可执行文件名（SimpApp.exe），并选择"Record into Action"为Action。
点击"OK"开始录制脚本，这时Vugen就会启动Simpapp.exe，如下图所示，输入WSNADDR，输入字符串（Tuxedo is powerful!）之后，点击TOUPPER，TUXEDO服务器完成请求后把输出字符串（TUXEDO IS POWERFUL！）写到"Output string"中，点击停止录制按钮。
D．编辑Vuser脚本。在C中做的所有操作都被录了下来，记录到一个脚本文件中，其内容如下，把它存为simpapp。
脚本内容如下：
/* This file is generated by LoadRunner. You may edit it carefully! */
#include "lrt.h"
#include "replay.vdf"
Actions()
{
lrt_tuxputenv("WSNADDR=//172.22.32.25:7110");
lr_think_time(3);
tpresult_int = lrt_tpinitialize(LRT_END_OF_PARMS);
lrt_abort_on_error();
data_0 = lrt_tpalloc("STRING", "", 1);
/* Request STRING buffer 1 */
lrt_strcpy(data_0, sbuf_1);
data_1 = lrt_tpalloc("STRING", "", 1);
tpresult_int = lrt_tpcall("TOUPPER",
data_0,
0,
&data_1,
&olen,
0);
/* Reply STRING buffer 1 */
lrt_abort_on_error();
lrt_tpfree(data_0);
lrt_tpfree(data_1);
lrt_tpterm();
return 0;
}
代码中加粗的函数是LoadRunner对TUXEDO函的二次包装。
E．点击工具栏中的" "按钮来执行我们刚才录制的脚本，确保执行无误。
3． 使用控制器（Controller）来调度虚拟用户
A．从菜单中选择运行Controller：
B．创建一个新的Scenario，选择刚才录制的脚本（simpapp）：
点击"OK"，弹出Scenario调度界面。在"Quantity"中输入100，表示使用100个虚拟用户。（虚拟用户与购买的LICENSE有关联）
C．点击"Edit Schedule"来编辑压力调度。
D．选择"Runtime settings"来作运行时设置。
在Pacing的设置中，"Number of Iterations"用于设置Vusers的Actions被执行的次数；"Start new iteration"用于设置调度器在什么时机迭代执行Vusers的Actions。
"Think Time"用于设置Vusers的反应和思考时间，以尽量做到和正常人一样来施压。"Ignore think time"表示忽略思考时间，这是理想状态，一般不使用。"As recorded"表示按照录制时的实际操作时间。"Multiply recorded think time by"表示Vusers的思考时间是实际录制时间的若干倍。
在"Miscellaneous"中设置一些杂项，如使用进程还是使用线程等。对于TUXEDO，好象只能选进程模式。
E．选择"Start scenario"来开始本次压力测试调度。
执行结果分析如下：
施压时间为5分41秒，Vusers数量为100，一共完成的Actions交易数量为5625笔，平均响应时间为5.561秒，TPS为17.8。[2]
实例应用在软件测试工具中如何巧用LoadRunner的随机函数
LoadRunner有自带的随机函数，如果巧妙的加以采用，能解决一些看似很困难的实际问题。
一个项目的性能测试。与数据库直连，根据外部传入的SQL ID和SQL参数，从指定数据库中读取SQL模版，拼装成真实的SQL语句、执行，并将得到的结果放入缓存中。目的是减少数据库的压力。
该系统将支撑大量的SQL操作，性能自然成为备受关注的焦点之一。
由于它跟SQL语句相关，在真实环境下，同一时间可能执行着不同类型的SQL，即便是同一类型，其参数也各式各样。那么，怎样才能模拟出最符合实际情况的性能测试场景呢？
首先设计场景，即，在LoadRunner中按照比例随机取到某一类型的SQL，再随机传入参数给它，让最终的每条SQL都是随机生成，各不相同。
从场景中，可以看到，此处涉及双重随机。只采用loadruner的参数设置是无法实现的。此时需要想办法先按设定好的比例随机取到SQL，然后在每条SQL上随机取参数列表中的参数。
于是想到了loadrunner的随机函数。先实现随机取SQL ID，之后再在特定的SQL中随机取参数列表中的参数。
LoadRunner中，随机函数是rand()，它用来产生0到rand_max之间的随机整数。函数原型是
int rand ( void );
然而调用rand之前，必须给随机数产生一个随机种子。这个种子由srand()函数产生。其原型是
int srand ( seedTime );
采用上述两个函数，就能实现第一重随机了。具体脚本代码如下：
//generate rand number
int rNum = 0;
srand(time(NULL));
rNum = rand() % 10;
lr_output_message(”the number is :%d”,rNum); //print the current random number
生成随机数后，再按比例用if … else … 来取到各种类型的SQL，并给它们传参。具体脚本代码如下：
//get certain SQL and random value
if (rNum>=0 && rNum<2) {
web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “,
”Resource=0″,
”RecContentType=text/html”,
”Referer=”,
”Snapshot=tn.inf”,
“Mode=HTTP”,
LAST);
}
…
else if(rNum>=8 && rNum<10){
web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “,
”Resource=0″,
”RecContentType=text/html”,
”Referer=”,
”Snapshot=tn.inf”,
“Mode=HTTP”,
LAST);
}
else {
rNum = 0;
lr_output_message(”the number is :%d”,rNum);
}
注：sqlid_name是SQL ID名称；random_para是通过file方式实现的随机参数；tn是web_url函数的快照名称。
通过上面的脚本，实现了性能测试设计的场景。调试通过后，放入Controller中执行。实际执行过程中，Vuser将会按比例随机取到不同类型的SQL，并随机取到SQL中的参数，执行特定的SQL语句。
巧用LoadRunner的随机函数，能解决不少实际问题。[1]
用LoadRunner分析资源占用率
1. 平均事务响应时间
Average Transation Response Time 优秀：<2s
良好：2-5s
及格：6-10s
不及格：>10s
2. 每秒点击率
Hits per Second
当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈大体一致，则系统基本稳定若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.
3. 请求响应时间
Time to Last Byte
4. 每秒系统处理事务数
Transaction per second
5. 吞吐量
Throughout
6. CPU利用率
Processor / %Processor Time 好：70%
坏：85%
很差：90%+
7.数据库操作消耗的CPU时间
Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
8. 核心态CPU平均利用率
Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统
9. 处理列队中的线程数
Processor / Processor Queue Length 如果该值保持不变(>=2)个并且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
10. 文件系统缓存
Memory / Cache Bytes 50%的可用物理内存
11. 剩余的可用内存
Memory / Avaiable Mbytes 至少要有10% 的物理内存值
12. 每秒下载页数
Memory / pages/sec 好：无页交换
坏：CPU每秒10个页交换
很差：更多的页交换
13. 页面读取操作速率
Memory / page read/sec 如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
14. 物理磁盘利用率
Physical Disk / %Disk Time 好：<30%
坏：<40%
很差：<50%+
15. 物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘
16. 网络吞吐量
Network Interface / Bytes Total/sec 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽，结果应该小于50%
17. 数据高速缓存区命中率 命中率应大于0.90最好
18. 共享区库缓存区命中率 命中率应大于0.99
19. 监控 SGA 中字典缓冲区的命中率 命中率应大于0.85
20. 检测回滚段的争用 小于1%
21. 监控 SGA 中重做日志缓存区的命中率
应该小于1%
22. 监控内存和硬盘的排序比率 最好使它小于 10%[4]
安装LoadRunner 分为Windows 版本和Unix 版本。如果所有测试环境基于Windows平台，那么只要安装Windows 版本即可。
系统要求
运行LoadRunner，内存最好在128M 以上，LoadRunner7.8 的最低要求。 内存最好在512M 以上，安装LoadRunner 的磁盘空间至少剩余500M。操作系统最好为Windows 2000。
最新版本届时2009-9月，最新版本为9.5.1。其中9.5以上版本支持Windows Vista Win7。但不支持IE8.
背景Mecury已于2006年被HP收购。