LoadRunner学习总结.docx
《LoadRunner学习总结.docx》由会员分享，可在线阅读，更多相关《LoadRunner学习总结.docx（20页珍藏版）》请在冰点文库上搜索。
LoadRunner学习总结
一、LoadRunner参数分析
1、Duration（持续时间）：
了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
StatisticsSummary（统计摘要）：
只是大概了解一下测试数据,对我们具体分析没有太大的作用.
TransactionSummary（事务摘要）：
了解平均响应时间Average单位为秒.
查看运行Vuser可以看到用户的加载正如我们设置的一样，每隔30s加载10个用户。
在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上.右键选择“合并图”，然后在“选择要合并的图”中选择即将用来进行比较的图，如下：
下图是各个操作的平均事务参数：
这张图包括“平均事务响应时间”和“运行用户”两个数据图：
从图中可以看到Vuser_init_Transaction（用户访问xmgd）对系统的影响非常大,平均响应时间非常高，那是因为把用户连接该站点作为初始化，这样就相当于有200个用户并发访问该站点，所以这个数据可以理解。
大概在06:
00的时候Vuser达到90个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许90个用户同时处理事务,Vuser达到160时,系统响应时间最大,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在20S内.Vuser数量最多不能超过100个.
如果我们要想要知道在给定时间的范围内完成事务的百分比就要靠下面这个图（TransactionResponseTime（Percentile）
图中画圈的地方表示80%的事务的响应时间是在25S以下.25S对于用户来说还是稍大的数字,不过有80%的事务.由于测试的站点在我的PC机上，可以理解。
实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?
以确定这个系统我们还要付出多少的代价来提高它.
TransactionResponseTime（Distribution）-事务响应时间（分布）
显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
很明显大多数事务的响应时间在14-30S.通常项目中多数客户所能接受的最大响应时间要在20S左右.
2、吞吐量
还可以查看吞吐量与运行用户两图的数据比较：
从图中可以看出当用户逐渐增加的时候吞吐量也跟着增加，是正常表现，由此也可以重复运行场景，可以将最大用户数量增多，也就是增加最大压力，然后再来分析吞吐量随着用户数增加到多少时，吞吐量趋于平稳，这就可以测出服务器的最大承受能力是多少了。
3、网页分析图：
该图底下显示了网页中每个元素包括图片，css,js等下载时间情况的分析。
一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web页.webpagebreakdown中显示的是每个页面的下载时间.点选左下角webpagebreakdown展开,可以看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性.
添加“页面下载时间细分图”如下：
从该图可以查看从DNS解析到接收完成的各个环节中所用的时间情况，由此可以分析是在那个环节出问题。
具体各含义如下：
除了上述所述，还有其它从不同角度观察的图表，并且还可以在运行场景时，添加对服务器资源使用情况进行监控，主要监视CPU,内存，硬盘的资源情况，这也是分析系统瓶颈重要证据，后续说明。
用户事务分析是站在用户角度进行的基础性能分析。
1、TransationSunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、AverageTransacitonResponseTime（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：
随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、TransactionsperSecond（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：
当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、TotalTransactionsperSecond（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、TransactionPerformanceSunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是符合用否户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、TransactionResponseTimeUnderLoad（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、TransactionResponseTime（Percentile）（事务响应时间（百分比））
“事务响应时间（百分比）”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。
通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、TransactionResponseTime（Distribution）（事务响应时间（分布））））
“事务响应时间（分布）”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。
如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
Web资源分析是从服务器入手对Web服务器的性能分析。
1、HitsperSecond（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTPStatusCodeSummary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。
HTTP状态代码表示HTTP请求的状态。
4、HTTPResponsesperSecond（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、PagesDownloaderperSecond（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。
使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。
但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。
而每秒下载页面数只考虑页面数。
注：
要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数（仅HTML模式）”。
6、RetriesperSecond（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接XX
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址
7、RetriesSummary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。
将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：
当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、ConnectionsPerSecond（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。
通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLsPerSecond（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。
当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
WebPageBreakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。
1、WebPageBreakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1）、DownloadTimeBreaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2）、ComponentBreakdown（OverTime）（组件细分（随时间变化））
“组件细分”图显示选定网页的页面组件随时间变化的细分图。
通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。
该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3）、DownloadTimeBreakdown（OverTime）（下载时间细分（随时间变化））
“下载时间细分（随时间变化）”图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分（随时间变化）”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4）、TimetoFirstBufferBreakdown（OverTime）（第一次缓冲时间细分（随时间变化））
“第一次缓冲时间细分（随时间变化）”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。
可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
FirstBufferTime：
是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。
2、PageComponentBreakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。
可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。
3、PageComponentBreakdown（OverTime）（页面组件分解（随时间变化））
“页面组件分解（随时间变化）”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间（以秒为单位）。
4、PageDownloadTimeBreakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。
5、PageDownloadTimeBreakdown（OverTime）（页面下载时间细分（随时间变化））
“页面下载时间细分（随时间变化）”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。
使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分（随时间变化）”图和“页面下载时间细分（随时间变化）”图通常结合起来进行分析：
首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。
6、TimetoFirstBufferBreakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。
如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：
定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：
定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。
7、TimetoFirstBufferBreakdown（OverTime）（第一次缓冲时间细分（随时间变化））
“第一次缓冲时间细分（随时间变化）”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。
可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
8、DownloaderComponentSize（KB）（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。
通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。
2、案例分析
1．Error:
Failedtoconnecttoserver“172.17.7.230″:
[10060]Connection
Error:
timedoutError:
Server“172.17.7.230″hasshutdowntheconnectionprematurely
分析：
A、应用服务死掉。
（小用户时：
程序上的问题。
程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）
B、应用服务没有死
（应用服务参数设置问题）
对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connectionrefused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！
C、数据库的连接
（数据库启动的最大连接数（跟硬件的内存有关））
D、我们的应用程序spring控制的最大链接数太低
2.Error:
Pagedownloadtimeout（120seconds）hasexpired
分析：
A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太大多
D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境
3.Error“http:
//172.17.7.230/Home.do....”
分析：
A、脚本设计错误，造成页面异常。
服务器有响应！
B、并发数过大，造成服务器响应延迟。
4.Errorpage“text=xxxxx”
分析：
A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。
B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。
只能反复修改脚本！
3、LoadRunner连接数据库
首先要安装ORACLE的客户端，这样才能连接ORACLE数据库服务器，如果是SQLServer的话，就不用这么麻烦了。
需要进行的参数设置。
具体的参数设置如下：
Action（）
{
#include"lrun.h"
#include"vdf.h"
#include"print.inl"
#include"lrd.h"
//codebyshiwanli----------参数定义
unsignedlongrownum;
charTemp[200];
charPrem_value[200];
//codebyshiwanli----------以下两行为结构声明，在绑定时使用，如果不声明则会报错
//codebyshiwanli----------LRD_VAR_DESC数据结构声明是很重要的，他是用来存储sql结果数据集的结构体
//codebyshiwanli----------第二个参数，设置结果集中最大行数，在lrd_ora8_fetch中的第二个参数如果大于该值，则会报错。
//codebyshiwanli----------第三个参数，设置结果集中每一行的最大长度，如果获得的查询结果比定义的长，运行时就会报错，提示列被截断
//codebyshiwanli----------最后一个参数是查询结果的类型，可以再帮助中的索引输入datatypes,database，列出的表格中是各种变量类型的名称
//codebyshiwanli----------常用的数据类型有DT_VARCHAR,DT_DECIMAL,DT_DATETIME,DT_SF,DT_SZ,DT_NUMERIC
staticLRD_VAR_DESCNUM={LRD_VAR_DESC_EYECAT,10,32,LRD_DBTYPE_ORACLE,{1,1,0},DT_LONG_VARCHAR};
staticLRD_VAR_DESCNUM1={LRD_VAR_DESC_EYECAT,10,32,LRD_DBTYPE_ORACLE,{1,1,0},DT_LONG_VARCHAR};
staticLRD_VAR_DESCOBJECT_NAME_D1;
staticLRD_INIT_INFOInitInfo={LRD_INIT_INFO_EYECAT};
staticLRD_DEFAULT_DB_VERSIONDBTypeVersion[]={{LRD_DBTYPE_NONE,LRD_DBVERSION_NONE}};
staticvoidFAR*OraEnv1;
staticvoidFAR*OraSvc1;
staticvoidFAR*OraSrv1;
staticvoidFAR*OraSes1;
staticvoidFAR*OraStm1;
staticvoidFAR*OraDef1;
staticunsignedlonguliFetchedRows;
//codebyshiwanli----------初始化数据库
lrd_init（&InitInfo,DBTypeVersion）;
lrd_initialize_db（LRD_DBTYPE_ORACLE,3,0）;
lrd_env_init（LRD_DBTYPE_ORACLE,&OraEnv1,0,0）;
lrd_ora8_handle_alloc（OraEnv1,SVCCTX,&OraSvc1,0）;
lrd_ora8_handle_alloc（OraEnv1,SERVER,&OraSrv1,0）;
lrd_ora8_handle_alloc（OraEnv1,SESSION,&OraSes1,0）;
//codebyshiwanli----------连接数据库,这里数据库服务名为lisx
lrd_server_attach（OraSrv1,"lisx",-1,0,0）;
lrd_ora8_attr_set_from_handle（OraSvc1,SERVER,OraSrv1,0,0）;
//codebyshiwanli----------设定数据库用户名密码checker
lrd_ora8_attr_set（OraSes1,USERNAME,"checker",-1,0）;
lrd_ora8_attr_set（OraSes1,PASSWORD,"checker",-1,0）;
//codebyshiwanli----------初始化连接session
lrd_ora8_attr_set_from_handle（OraSvc1,SESSION,OraSes1,0,0）;
//codebyshiwanli----------开始连接数据库
lrd_session_begin（OraSvc1,OraSes1,1,0,0）;
lrd_ora8_handle_alloc（OraEnv1,STMT,&OraStm1,0）;
//codebyshiwanli----------设定查询语句
lrd_ora8_stmt（OraS
升级会员 