loadrunner 详细解释.docx
《loadrunner 详细解释.docx》由会员分享，可在线阅读，更多相关《loadrunner 详细解释.docx（17页珍藏版）》请在冰豆网上搜索。
loadrunner详细解释
LoadRunner
2010-10-2910:
24
事务TRANSACTION
所谓事务（TRANSACTION）,就是在脚本定义中定义的某段操作（ACTION）,更确切的说,就是一段脚本语句.定义事务时,首先在脚本中找到事务的开始和结束位置,然后分别插入一个事务起始标记,这样,当脚本运行的时候,LOADRUNER会自动在事务的起始点计时,脚本在运行到事务结束点时计时结束,系统会自动记录这段操作的运行时间等性能数据；在脚本运行完毕后,系统会在结果信息中单独反映每个事务运行结果.
LR_START_TRANSACTION（“事务名称”）
LR_END_TRANSACTION（“事务名称“）
集合点RENDEZVOUS
多用户同时加载并发,并发过程仅仅体现在开始执行的那一刹那,随着服务器对请求的响应时间的不一致或系统环境条件的限制,在运行过程中能集合到一点的可能性微乎其微,所以将一定数量的用户同时加载并不是真正意义上的并发.
系统压力最大的情况是:
所有用户都集中到系统瓶颈的某个点上进行操作,从脚本的角度来讲,这个点就是执行脚本的某一条或一段语句,为了真实模拟这个最坏的情况,查看系统在最坏情况下的反映,LOADRUNNER提供了集合点的功能,帮助测试人员实现真正意义上的并发.
LR_RENDEZVOUS（“集合点名称”）
参数化PARAMETERS
让所有用户都使用相同的数据来运行,对系统造成的压力与实际情况会有所不同.而对于那些禁止一个用户多次登陆的系统,也就严重到无法测试的地步了.为了解决这个问题,让系统更加真实的模拟多用户使用的实际环境,LOADRUNNER提供了对脚本进行参数化输入的功能.
所谓的脚本参数化,就是针对脚本中的某些常量,定义一个或多个包含数据源的参数来取代,让场景中不同的虚拟用户在执行相同的脚本时,分别使用参数数据源中的不同数据代替这些常量,从而达到模拟多用户真实使用系统的目的.
注:
参数化输入只能用于函数中的参数,不能用参数代替非函数中的常量参数.
检查点CHECKPOINT
LOADRUNNER检查点的功能主要用来验证某个界面上是否存在指定的TEXT或IMAGE等对象，在使用LOADRUNNER测试WEB应用时，可以检查压力较大时WEB服务器能否返回正常的页面。
系统在执行时是否起用检查点，是由一个系统参数控制的，该参数的设定方法为：
VUSER|RUN-TIMESETTINGS|PREFERENCES，如果想让检查点起作用，需要选中ENABLEIMAGEANDTEXTCHECK复选框。
ØRUN-TIMESETTINGS
ITERATIONCOUNT（重复次数）
入口:
GENERAL|RUNLOGIC;
参数说明:
设定每个ACTION的重复执行次数;
注意:
DURATION参数是优先于ITERATION的,举例说明,假定将DURATION设为5分钟,即使在RUN-TIME中将INRATIONS参数设为1,虚拟用户也会在5分钟之内进行尽可能多的反复执行脚本,在限定了DURATION的场景中,DURATION时间是从所有用户状态变为INIT开始计算的,这样就存在一个问题,有些初始化过程很长的用户,可能还没有到达RUN状态就因DURATION时间限制而中止了,要解决这个问题,测试人员可选择INITIALIZEALLVUSERSBEFORERUN选项,这样DURATION时间会在所有用户都到达RUN状态后开始计时.
THINKTIME
参数设定入口:
GENERAL|THINKTIME
参数说明:
设定脚本回放时对思考时间的处理方式.
IGNORETHINKTIME:
选择该选项,脚本回放时将不在执行LR_THINK_TIME（）函数,这样会给服务器造成更大的压力.
REPLAYTHINKTIME:
选择该选项,脚本回放时执行LR_THINK_TIME（）函数,
ERRORHANDLING
入口:
GENERAL|MISCELLANEOUS
参数说明:
设定遇到错误时的处理方式
1,CONTINUEONERROR,遇到错误继续运行;
2,FAILOPENTRANSACTIONSONLR_ERROR_MESSAGE,
执行到事务中调用的LR_ERROR_MESSAGE（）函数时将事务的结果置为FAILED
3,GENERATESNAJPSHOTONERROR对错误进行快照.
MULTITHREADING
设定脚本运行方式;
入口:
GENERATOR|MISCELLANEOUS
1,RUNVUSERASAPROCESS,以多进程方式运行;
2,RUNVUSERASATHREAD,以多线程方式运行;
关联Correlation
Ø自动关联----RulesCorrelation
1.启用auto-correlation
点选VuGen的【Tools】>【RecordingOptions】，开启【RecordingOptions】对话窗口，选取【InternetProtocol】>【Correlation】，勾选【Enablecorrelationduringrecording】，以启用自动关联。
设定当VuGen侦测到符合关联规则的数据时，要如何处理：
【Issueapop-upmessageandletmedecideonline】：
跳出一个讯息对话窗口，询问您是否要建立关联。
【Perform.correlationinsceipt】：
直接自动建立关联
Ø自动关联----CorrelationStudio
使用CorrelationStudio的步骤如下：
1.录制脚本并执行；
2.执行完毕后，VuGen会跳出下面的【ScanActionforCorrelation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。
3.扫描完后，可以在脚本下方的【CorrelationResults】中看到扫描的结果。
4.检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【CorrelateAll】让VuGen一次就对所有的数据建立关联。
注意：
由于CorrelationStudio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【CorrelateAll】。
Ø手动关联
有可能有些需要做关联的动态数据，连CorrelationStudio都无法侦测出来，这时您就需要自行做手动关联了。
CONTROLLER场景
ØMANUALSCENARIO这种方式是完全手动设置，测试人员需要手工设定虚拟用户数，SCHEDULE和LOADGENERATOR等
ØMANUALSCENARIWITHPERCENTAGEMODE这种方式与MAMUALSCENARIO方式比较相似，只是在分配用户数的方式有所不同
1，后者需要设定TOTALNUMBEROFVUSERS，即所有虚拟用户数；
2，后者需要为每个脚本分配用户数比例，由系统按照比例自动分配用户数；
3，后者脚本选择LOADGENERATOR时，除了可以选择单个的LOADGENERATOR外，还可以设置为ALLLOADGENERATOR，即使用所有的LOADGENERATOR。
由于这种方式没有用户组的概念，因此在设置SCHEDULE时，不能按组设置，只能按整个场景设置
ØGOAL-ORIENTEDSCENARIO
这种方式是基于目标自动创建场景的方式，测试人员只要输入性能测试所要达到的目标，LOADRUNNER就会自动根据目标安排场景的运行；
采用GOAL-ORIENTEDSCENARIO方式创建场景时，需要单击EDITSCENARIOGOAL按钮定义场景目标，CONTROLLER在执行的时候会根据场景目标的要求，自动加载用户，控制场景的运行；
VIRTUALUSERS
以虚拟用户数作为目标，当一个应用对用户数要求比较高时，可以使用这种方式来测试一个应用程序能够允许多少个用户同时运行。
基于用户数目标的原理和设定方法比较简单，他和MANUALSCENARIOWITHPERCENTAGEMODE方式基本相似，只需要定义要求达到的用户数就可以了。
从某种意义上讲，它还不能体现面向目标类型的优势。
HITSPERSECOND，以每秒点击数作为目标
TRANSACTIONSPERSECOND，以每秒事务数作为目标
PAGESPERMINUTE，以每分钟页数作为目标
以上三种类型都需要用户指定虚拟用户数的范围，CONTROLLER在运行场景的时候，首先加载最小的用户数，如果使用最小的用户数不能达到目标，系统会自动逐渐增加用户直到能够达到设定的目标为止。
当加载的用户数达到最大值仍然不能满足要求时，就需要重新设置场景，增加最大用户数。
可以通过LOADBEHAVIOR选项设定三种不同的用户加载策略，如果没有达到目标，LOADRUNNER会重新运行场景，一次加载最大的用户数，尝试是否能够达到目标，如果出现如下情况之一，场景的运行结果都会置于FAILED状态，
CONTROLLER两次加载了最大的用户数都没有达到目标；
在运行过程中所有的用户都失败了；
LOADGENERATOR数目不能满足要求；
CONTROLLER在增加用户的过程中，性能指标没有增加；
CONTROLLER在加载第一批用户后，没有捕获到指标的值；
TRANSATIONSRESPONSETIME，以事务响应作为目标，
主要用于衡量要达到预期的事务响应时间，系统所容纳的最多用户数，如果系统已经加载了最大的用户数，响应时间仍然低于设定的值，说明系统还有能力容纳更多的用户，如果使用一部分用户就达到了设定的响应时间，说明系统是无法容纳设定的最大数量的用户的，必须通过完善应用程序来达到目的；
多机联合产生负载
LOADRUNNER对应用程序施压时，采用的方法就是让一台机器模拟很多用户，同时向被测用户发送请求或进行操作。
这样，如果一台测试机器模拟的虚拟用户数过多，他本身性能的下降会直接影响测试效果。
为了避免这种情况，LOADRUNNER允许使用多台机器运行场景来均衡测试机器的负荷。
只要一台机器安装了LOADGENERATOR并启动了LOADRUNNERAGENTPROCESS进程，就可以被CONTROLLER统一调度来运行场景，CONTROLLER负载收集统一的测试信息和执行结果。
Ø安装LOADGENERATOR，如果一台测试机仅用来被CONTROLLER调用执行场景，只需安装LOADGENERATOR就可以了。
Ø在CONTROLLER中创建LOADGENERATOR
Ø在场景中用不同的LOADGENERATOR联合产生负载
设定集合点策略
LOADRUNNER在运行场景的时候，允许测试人员根据项目需要自己设定集合点的并发策略，要设定一个集合点以何种方法运行，在创建或打开脚本中包含集合点的场景时，选择SCENARIOI|RENDEZVOUS命令，可以查看场景中所有脚本中的集合点名称，所属脚本，当前状态和相关的虚拟用户列表信息等，根据系统需求，还可以针对集合点的执行进行设定。
Ø单击DISABLE/ENABLERENDEZVOUS按钮可以选定集合点是否启用；
Ø单击DISABLE/ENABLEVUSERS按钮可以设定一个用户是否参与到集合点中；
Ø单击POLICY按钮可以设定集合点执行策略。
n在POLICY对话框中的TIMEOUTBETWEENVUSERS文本框中设定了一个超时时间，当第一个用户到达集合点时，系统开始计时。
如果在这个设定的时间内没有达到要求的集合点用户数，系统就不在等待，释放用户让场景继续执行；
启用IP欺骗
LOADRUNNER进行压力负载测试的时候，是让一台机器模拟成百上千的用户对服务器施压，这样就产生了一个问题，那就是所有用户向服务器发起请求的时候，使用的都是同一个IP地址，即LOADGENERATOR所在机器的固定IP地址，这是和实际运行环境不符的，而且有些应用系统在设计的时候会根据IP来分配资源，有些还限制同一个IP的多次登陆过程。
LOADRUNNER为了解决这个问题，使用了一种称为“IP欺骗（IPSPOOFER）”的技术。
也就是让一个LOADGENERATOR上的虚拟用户模拟从不同的IP来向服务器发起请求，以达到以假乱真的目的。
配置IPSPOOFER
LOADRNNER配置动态IP的工具是程序组中的一个小工具-IPWIZARD，它能够指导用户按步骤完成配置过程，这里有三个单选按钮；
第一个单选按钮CREATENEWSETTING，用于创建一个新的设置，首次运行时选用；
第二个单选按钮LOADPREVIOUSSETTINGFROM可以调用以前保存的设置；
第三个单选按钮RESTOREORIGINALSET不是用来创建动态IP，而是将设置恢复为原始状态，这个选项主要用于使用后释放IP，如果使用完毕后不释放IP的话，那么这些IP会被一直占用，别人就无法使用了。
Ø启用IP欺骗
在CONTROLLER窗口中，选择SCENARIO|ENABLEIPSPOOFER命令，就可以起用IP欺骗了，在IP欺骗启用后，在CONTROLLER状态栏中会显示相应的状态标识；
Ø在OPTIONS中设置IP地址的分配方式；
创建虚拟IP地址之后，还要选择TOOLS|OPTIONS命令，在弹出的对话框中单击GENERAL标签以设定IP地址的分配方式；
nIPADDRESSALLOCATIONPERPROCESS：
给每个进程分配不同的IP地址；
nIPADDRESSALLOCATIONPERTHREAD：
给每个线程分配不同的IP地址；
一般来说，如果在RUN-TIMESETTING中设置的是以多线程的方式运行，则这里就给每个线程分配不同的IP地址。
如果在RUN-TIMESETTING中设置的是以多进程的方式运行，则这里给每个进程分配不同的IP地址；
注意：
只有在CONTROLLER中选择TOOL|EXPERTMODE命令，才能在OPTIONS对话框中包含设定IP分配的选项；
控制场景的运行
按钮开始执行场景以后，LOADRUNNER首先检查场景的配置信息，并激活被测应用，然后将虚拟用户分配到相应的LOADGENERATOR上。
当虚拟用户准备好以后就开始对被测应用施压，在施压的同时LOADRUNNER会完成如下的操作；
1）记录在脚本中定义的每个事务的执行时间；
2）执行脚本中定义的集合点的功能；
3）收集每个虚拟用户发出的告警，错误和提示信息；
Ø初始化用户组
单击STARTSCENARIO按钮执行场景时，虚拟用户并没有立刻执行脚本，而是首先执行一个初始化过程，初始化完毕的用户状态会变为READY，只有状态为READY的用户才能真正开始执行脚本。
由于各种条件的限制，场景中用户的初始化过程是无法达到完全同步的，这就造就了用户无法同时运行测试脚本。
为了让用户能够同时对被测应用施压，LOADRUNNER提供了初始化用户组的策略，让所有用户在执行脚本之前全部变为READY状态。
初始化用户组的方法是在开始运行场景之前，先在RUN选项卡中选中要初始化的用户组，然后单击工具栏的INITIALIZETHESELECTEDVUSERS按钮，或者单击鼠标右键，在弹出的菜单中选择INITIALIZEGROUPS命令，如果初始化成功，用户状态变为READY，如果失败，用户的状态就会变为ERROR。
Ø停止场景的运行
一个场景会在以下三种情况停止运行：
1）所有用户都执行完脚本；
2）测试人员手动停止了场景的运行；
3）执行超时；
在线监视场景
注意：
必须以被监视机器的管理员身份登陆到CONTROLLER所在机器，才能添加被监视机器的性能计数器；
Ø常见的计数器
1）MEMORY相关，内存问题主要检查应用程序是否存在内存泄露，如果发生了泄露，PROCESS\PRIVATEBYTES计数器和PROCESS\WORKINGSET计数器的值往往会升高,同时AVALIABLEBYTES的值会降低.内存泄露应该通过一个长时间的测试来检查,主要测试当所有内存都耗尽时应用程序的反应情况;
2）PROCESSOR相关,判断应用程序是否存在处理器的瓶颈
如果PROCESSORQUEUELENGTH显示的队列长度保持不变（>=2）,且处理器的利用率%PROCESSORTIME超过90%,那么很可能存在处理器瓶颈;
如果发现PROCESSORQUEUELENGTH显示的队列长度超过2,而处理器利用率却一直很低,那么或许更应该去解决处理器的阻塞问题,处理器一般不是瓶颈;
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（CONTEXTSWITCHES/SEC,显示的上下文切换次数）比较大,那么就会造成大量的系统资源;
如果系统吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在1500以上,那么意味着上下文切换的次数过高;
还可以比较CONTEXTSWITCHES/SEC和%PRIVILEGEDTIME来判断上下文切换是否过量;如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这么高的上下文切换;
3）网络吞吐量及带宽
BYTESTOTAL/SEC:
判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较,相除结果应该小于50%;
4）磁盘相关
判断磁盘瓶颈的方法是通过以下的公式来计算:
每磁盘的I/O数=[读次数+（4*写次数）]/磁盘个数
如果计算的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈;
5）WEBSERVER相关
6）数据库服务器相关
设定监视器选项
选择TOOLS|OPTION命令,在MONITORS选项卡中可以统一设定监视器的一些参数选项,
1）TRANSACTIONDATA
用于监视事务图表的数据行为,这些参数不能在场景运行过程中更改,参数修改后需要重新连接虚拟用户的LOADGENERATOR才能生效;
ENABLETRASACTIONMONITOR:
如果选择该选项,场景启动后就自动开始监视事务,默认情况下,该选项是选中的;
FREQUENCY:
设定MONITOR抽样数据产生事务,获取数据点和生成网络资源在线图表的频率.默认为5秒,如果是小的场景建议使用1秒;如果大一些的场景,建议3-5秒;这个参数越低,采样间隔越小,监视图表越精确,网络工作量也就越大;
2）SERVERRESOURCEMONITORS
定义了服务器资源监视器的行为,修改该选项对已经被激活的图表不起作用,只对随后被激活的图表起作用;
DATASAMPLINGRATE:
定义了服务器两次采样数据的时间间隔,默认为3秒,这个参数对所有图表都起作用,如果要对单个图表起作用,需要在单个图表的配置属性中定义,
每个图表都有一个最小的采样频率,如果这里设定的值低于图表的最小采样频率,图表仍然使用最小的采样频率;
3）ERRORHANDLING
定义了监视过程中的错误处理方式；
SENDERRORTOTHEOUTPUTWINDOW：
遇到错误时将出错信息输出到OUTPUT窗口；
POP-UPANERRORMASSAGEBOX：
遇到错误时弹出错误信息窗口；
4）DEBUG
设定DEBUG场景的方式；
DISPLAYDEBUGMESSAGE：
选中该复选框，系统会向输出日志中发送DEBUG相关信息，定义DEBUG的等级
合并图表
LOADRUNNER为了便于测试人员比较两个图表数据之间的关系，提供了图表合并的功能，也就是可以将同一个场景中的两个图表中的计数器合并到一个图表中，合并以后的图表共用一个X轴。
要合并两个图象，只需右键单击一个图表，在弹出的快捷菜单中选择OVERLAYGRAPHS命令，然后在系统提示的对话框中选择另一个图表，并为新图表命名，需要注意的是只有X轴相同的图表才能合并
其他与监视图表相关的功能
Ø穿越防火墙监视图表；
为了安全起见，运行MONITOR和VUSER的机器安装了防火墙，这样处于防火墙之外的CONTROLLER在控制虚拟用户执行和监视场景的时候就会碰到一些麻烦；
LOADRUNER通过在防火墙上使用基于HTTPS或者使用标准SSL端口（443）的安全的TCP/IP的协议来解决这个问题。
使用LOADGENERATOR机器或MONITOR机器上的代理充当通信过程的媒介，与MILISTENER通信。
MILISTENER是一个需要单独安装的LOADRUNNER组件，它服务于CONTROLLER和LOADRUNNER代理之间，
如果未安装MILISTENER组件，LOADRUNNER也可以穿越防火墙实现监控MONITOR和执行VUSERS，这时需要在LOADGENERATOR端和CONTROLLER端的防火墙上均打开54345端口；
Ø远程监视场景；
LOADRUNNER提供了一个组件，用于同时通过多个机器上的WEB页面远程监视场景，每个监视还可以根据需要定制不同监视图表
要完成远程监控，需要一个远程性能监视服务器，（REMOTEPERFORMANCEMONITORSERVER），它是一个包括很多ASP页面和性能图表过滤器的网站，和CONTROLLER交互数据，并且决定能够在线查看场景的用户数。
远程性能监视服务器上必须安装LOADRUNNER的REMOTEPERFORMANCEMONITORSERVER组件，该组件有如下系统需求：
∙WEBSERVER:
IIS5.0
∙操作系统:
WINDOWS2000SERVER或WINDOWS2000ADVANCEDSERVER
∙客户端浏览器:
IE5.0或NETSCAPE6.2以上;
使用ANALYSIS分析结果图表
LOADRUNNER除了将获取的原始数据形成直观的图表外,还对数据进行了一些统计,,例如在多数分析图表下方的图例列表中,给出了最大值,最小值,平均值,中间值和STD等一些统计字段,便于用户分析;
STD是一个统计学概念,称为标准偏差值,是用来衡量数据的偏离程度的.当平均值不多时,可以从STD指标看出统计图表列数据到底是分散还是集中的.STD越小表示图表的列数据越集中,拿AVERAGERESPONSETIME来说,也就表示每个虚拟用户单一的响应时间值大致是差不多的,即被测系统的反应很稳定,没有大起大落;
1）TRANSACTIONPERFORMANCESUMMARY
可以基本确认哪个事务的响应时间比较长,一般来说,响应时间长的事务是分析的重点;
2）AVERAGETRANSACTIONRESPONSETIME
可以详细查看每个事务在场景运行中的响应时间,
3）WEBPAGEBREAKDOWN
用于分解页面,查看页面中哪些组件导致事务的响应时间比较长,
∙DNSRESOLUTION时间DNS服务器解析IP地址的时间,这个度量时间可以确定DNS服务器或者DNS服务器的配置是否有问题,如果DNS运行正常,这个值一般比较小;
∙CONNECTION时间浏览器和WEBSERVER建立初始化连接的时间,这个度量可以判断网络情况,也可以判断
升级会员 