关于性能测试的总结报告Loadrunner.docx

关于性能测试的总结报告Loadrunner.docx

《关于性能测试的总结报告Loadrunner.docx》由会员分享，可在线阅读，更多相关《关于性能测试的总结报告Loadrunner.docx（41页珍藏版）》请在冰点文库上搜索。

关于性能测试的总结报告Loadrunner

关于性能测试的总结报告

一、目的

于系统完成的初始阶段模拟真实的使用环境，运用性能测试工具对系统进行压力负载，重现缺陷发生的状态，并监控的客服端和服务端性能指标，检验该系统是否能够满足用户的需求，以次来避免系统在使用过程中出现不必要的问题，最终进一步完善系统。

二、背景

很多系统开发完成后在性能方面还存在着很多的缺陷，简单的手动测试是发现不了这些隐藏的缺陷的，需要通过工具来找出并解决这些问题。

三、工具

HPLoadRunner11.00.

LoadRunner，是一种预测系统行为和性能的负载测试工具。

通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。

通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。

四、Loadrunner使用介绍

4.1主界面

图4-1-1

打开loadrunner后出现此界面，有三个功能键：

第一步：

创建/录制脚本

第二步：

运行脚本，进行负载测试

第三步：

报告分析

4.2Create/EditScripts（创建/录制脚本）

录制脚本非常重要，是进行负载测试的基础，因此要保证脚本不能出现问题。

图4-2-1

此图为创建/录制脚本界面，可以通过以下几种方法录制或打开一个脚本：

1.点击“File”→“New”,出现图4-2-2，选择“（网页测试）Web（HTTP/HTML）”

2.点击“File”→“Open”,可以打开一个已录制好的脚本。

3.

点击此图标，也会出现图4-2-2，步骤同1。

4.

点击此图标，直接打开一个已录制好的脚本。

图4-2-2

4.2.1脚本创建的过程

图4-2-3

点击“StartRecord”按钮开始录制，出现以下一个提示框：

图4-2-4

在“Programtorecord”选项里填入网页浏览器的地址名称；

在“URLAddress”选项里填写要测试网站的地址；

在“Workingdirectory”里填写Loadrunner的工作目录；

在“RecordintoAction”里有三个选项：

vuser_init（开头的脚本）、Action（操作间的脚本）、vuser_end（结束时的脚本）。

即vuser_init录制的一般是用户登录的时候，action录制的一般是操作的事件，而vuser_end录制的一般是退出的时候。

但vuser_init、Action和vuser_end三者之间的区别是vuser_init和vuser_end不能迭代多次，只能运行一次，而action可以迭代多次运行。

配置完成后，点击“Ok”后，录制正式开始，自动登陆到配置时填写的网站地址，并且可以看见正在录制的图标。

暂停录制

结束录制

图4-2-5

图4-2-6

可以看出：

随着操作步骤的增多，录制的事件数目也加增加。

4.2.2编辑脚本

结束录制后，回到脚本创建的界面，在“Script”中我们会发现比之前多了代码，这就是刚刚录制的内容。

图4-2-7

4.2.2.1参数化

在对网页进行负载测试的时候，会要求我们同时登陆多个账号来检验用户的最大承载量，此时我们需要使用参数化。

首先我们要在代码中找到账号和密码信息，然后再进行替换。

图4-2-8

如图4-2-8所示，选择"Value=sm1中的sm1，然后右击，点击列表中“ReplacewithaParameter”,就会出现图4-2-9的提示框。

在“Parametername”框中输入一个易于记忆的账户参数名（如:

Name）,然后可以点击“Properties..”按钮对“Name”参数进图4-2-9

图4-2-10

添加用户个数比较少的话，可以通过点击

来添加，如果需要添加几十个甚至一两百个用户的话，建议使用

来通过在文档里进行编辑，比较方便。

图4-2-11

密码的参数化方式和账户相同。

注：

在进行参数化的过程中，账号和密码是一一对应的关系，即，密码的排序要根据账号的排序来确定，否则会影响之后的测试结果。

4.2.2.2集合点

集合点的用处对于LoadRunner来说意义非常大，它可以设置多个虚拟用户等待到一个点，同时触发一个事务，以达到模拟真实环境下同时多个用户操作，同时模拟负载,实现性能测试的最终目的。

举例如下：

要检测1000个用户同时登陆，在LoadRunner中可以通过在提交数据操作前面加入集合点，当虚拟用户运行到提交数据的集合点时，Loadrunner就会检查同时有多少用户运行到集合点，等到这1000个虚拟用户都运行到集合点后，就会触发同时进行提交数据的操作，从而能够测试系统对于这1000个用户提交数据的响应情况，依次来看系统是否满足客户的该点需求。

通常添加集合点的方式有两种：

1.

录制时添加

在需要并发操作的事务前直接点击插入集合的按钮图4-2-12

2.录制后在代码处添加：

图4-2-13

接着，出现如图4-2-14所示的对话框。

输入该集合点的名称，注意，名称最好能够清楚地说明该集合点所完成的动作。

图4-2-14

4.2.2.3事物

事务（Transaction）在loadrunner中的定义如下：

事务（Transaction）是这样一个点，我们为了衡量某个action的性能，需要在action的开始和结束位置插入这样一个范围，这就定义了一个transaction。

事务的作用：

LoadRunner运行到该事务的开始点时，LoadRunner就会开始计时，直到运行到该事务的结束点，计时结束。

这个事务的运行时间在LoadRunner的运行结果中会有反映。

通俗的讲LoadRunner中的事务就是一个计时标识，LoadRunner在运行过程中一旦发现事务的开始标识，就开始计时，一旦发现事务的结束表示，则计时结束，这个过程中得到的时间即为一个事务时间。

通常事务时间所反映的是一个操作过程的响应时间。

通常事务的添加方法也有两种：

前者是开始事务，后者是结束事务。

1．录制过程中添加

首先进入录制页

点击开始事务，输入你给事务取的名字

结束该项操作，点击结束事务，直接点击OK即可。

2．录制结束后在代码中添加

确定被测流程的第一步，在被测流程的第一步前，点击开始事务按钮。

确定被测流程的最后一步，在被测流程的最后一步后，点击结束事务按钮。

下面是录制好的脚本

图4-2-15

此时又有两种方式选择插入和结束事务，一种是通过工具栏上的insert，还有是直接由快捷方式，如图所画：

图4-2-16

选择插入事务，给事务取名

图4-2-17

点击OK后的脚本中多了一行

图4-2-18

结束操作后选择结束事务

图4-2-19

点击OK后的脚本中多了一行

LR_AUTO–（默认值）–使用该值，LoadRunner会自动探测事务状态

添加事务的注意点

延迟时间

•将延迟时间包含在事务范围内，会降低事务测量的精确度。

•在虚拟脚本中添加多个Actions

•基于负载测试目标配置Actions

•设置正确的初始化和结束条件

•通过LoadRunner事务测量：

•一个业务流程中某些步骤的端到端的响应时间

•整个业务流程

•在录制过程中和录制结束后，添加LoadRunner事务

4.2.2.4Running-timeSettings

（在这里只是选择两个重要的说一下）图4-2-20

在脚本录制好后，此时我们需要运行一下脚本来检验脚本是否有错误，此时我们需要在Running-timeSetting里进行简单的配置：

此图为Running-timeSetting的主界面：

图4-2-21

1.Iteration（迭代）

“General”→“RunLogic”→“IterationCount”,可以根据情况选择迭代的次数。

迭代次数其实就是循环次数，但一个用户迭代十次，还是一个用户的压力，如跑登录脚本，给用户和密码设置了20个参数，那么迭代10次就表示20个用户循环登录10次。

除非我们是特别要求，一般不用迭代次数，而是用运行时间。

另外，迭代的设置是否有效还由Controller中的设置决定，如果在Controller中将持续时间设置为特定的时间如30分钟，这时设置的迭代次数不会生效，而是20个用户依次登录，30分钟后停止，如果Controller中将持续时间设置为“Rununtilcompletion”，这时设置的迭代次数才生效。

注：

在vuser_init和vuser_end中都不能进添加迭代，只能在action中设置迭代。

2.Log（日志）

图4-2-22

（1）log的设置方式 ：

Always send messages（这种方式会一直打印输出日志，不仅在错误时）；

standard log——记录所有的请求反馈的日志，包括successful和fail的日志。

Extended log——可提供扩展的日志信息，包括：

Parameter subsititution——日志中打印所有中使用的参数值

Data returned by server——日志中打印每个客户端请求服务器返回的数据值

Advanced trace——日志中打印所有的消息信息和函数执行信息

通常我们选择“Parameter subsititution”。

（2）log的存储方式

log的存储路径在res文件夹下。

如果是从脚本中直接关联create scenario则在脚本的目录下的res下。

如果是直接create scenario然后再选择脚本的话，则存储在c盘，如：

“C:

\Documents and Settings\USERNAME\Local Settings\Temp\res\log”

具体该场景的日志结果存哪，可以查看controll的result界面的result 

setting定义的目录。

根据不同的log记录级别，在log文件中记录日志。

（3）log信息的分析

a.从log中得到虚拟用户失败的原因。

通常如果场景在运行时出现用户失败，则先要查看错误原因，可直接查看

日志，从日志中查看ERROR的信息；

从outputdb中可以查看到错误代码ERROR CODE

b.从日志中确认每次分配给虚拟用户的参数值

想判断是否在场景中每个用户使用不同的或预定义规则的参数，可以

在log生成规则处设定为parameter subsititution，然后查看每个日志文

件中的对应行参数值是否为预计的参数值。

可从此判断出是否同用户的实际

使用类似，是否达到对服务器的压力策略。

c.从日志中确认服务器端返回的值是什么。

在脚本中通常设定了检查点，检查点策略是否生效，如果对此产生怀疑则

可以考虑从日志中查看一下。

查看服务器返回的值来验证是不是所期待得到的值。

4.2.2.5Showrun-timeviewerduringreplay（在重放脚本时显示网页画面）

图4-2-23

如图所示，点击“Tools”中的“GeneralOptions”，会出现下图4-2-24：

图4-2-24

点击“Display”，在“Showrun-timeviewerduringreplay”和“Autoarrangewindows”的前面打钩，操作完成后点击OK,这样在脚本回放过程中就能看见录制的网页过程。

4.3运行脚本，进行负载测试

这一步是整个测试的关键部分，通过运行上一步的脚本来对系统进行负载测试。

进入负载测试界面，我们会看见下图4-3-1的情况，从左边的小方框的选择要测试的脚本，然后添加到右边的方框内，点击“OK”。

（“Remove.”按钮：

用来把右方框内的脚本移除

“Browse..”按钮：

用来添加新的脚本到左方框里

“Record..”按钮：

用来重新录制一个脚本）

图4-3-1

当点击“OK”按钮后，我们会进入图4-3-2所显示的界面。

图4-3-2

此为负载测试的“Design”界面，在正式测试之前我们需要进行如下一些配置：

4.3.1ScenarioScript

图4-3-3

点击的下拉列表，确认添加后，跳出图4-3-4的窗口，在“Name”一栏里输入localhost，点OK按钮退出。

图4-3-4

4.3.2ScenarioSchedule

图4-3-5

此图显示的内容为负载测试的方案计划，即运行时间段、测试的用户数量、何时结束等相关内容。

4.3.2.1StartVusers

用来设定测试的用户数量，这里选择的是200个用户，分2次进入测试，10s进入一次。

图4-3-6

4.3.2.2Duration

用来设置测试运行的时间，即何时结束此时测试，一般我们选择第一种方案------“Rununtilcompletion（测试完成后结束）”

图4-3-7

图4-3-8

设置完成后，“Design”的显示界面的内容会有相应的变化，如图4-3-8所示。

4.3.3负载测试的“Run”界面

图4-3-9

进入这个界面后，负载测试的配置基本已完成，此时我们要做的就是根据情况从“AvailableGraphs“中选择需要的选项拉入右边的矩形方框内，以便测试运行时监测状况。

图4-3-10

当一切都设置好后，按下“StartScenario“开始运行。

图4-3-11

下图为测试过程中的界面变化情况：

图4-3-12

图4-3-12

从上图我们可以看出200个用户Passed有多少个，Failed有多少个，其间出现的Errors有多少个。

点击“Vusers..”按钮，跳出图4-3-14，从图中我们可以看出登陆失败的是哪一个用户。

图4-3-13

图4-3-14

点击图4-3-13中的Errors一栏的放大镜图标，可以查看error的具体信息。

图4-3-15

4.4AnalysisSummary报告分析

在第二步负载测试结束之后，会自动生成一个分析报告，里面记录了此次测试的相关数据。

图4-4-1

报告的内容主要分为两部分：

Reports和Graphs,图4-4-1显示的为Reports的内容，里面包含了StatisticsSummary和HTTPResponsesSummary等的具体内容。

“Graphs”选项中的内容为一系列反应数据的图表，我们在做测试结果分析的时候会用到，可以再菜单栏里的“Graph”→“AddNewGraph”添加。

图4-4-2

图4-4-3

图4-4-4

五、LoadRunner在运行时常见的提示错误和解决方法

1、Error-27727:

Stepdownloadtimeout（120seconds）hasexpiredwhendownloading

resource（s）.Setthe“ResourcePageTimeoutisaWarning”Run-TimeSettingtoYes/Notohavethismessageasawarning/error,respectively。

问题原因：

A、应用服务参数设置太大导致服务器的瓶颈

　　B、页面中图片太多

　　C、在程序处理表的时候检查字段太大或多

处理方法：

Run-TimeSetting-----InternetProtocol-----Preferences-----Option----Stepdownloadtimeout（sec）改为32000

2、Error-27979:

Requestedformnotfound[MsgId:

MERR-27979]

Action.c（41）:

web_submit_formhighestseveritylevelwas"ERROR",0bodybytes,0headerbytes [MsgId:

MMSG-27178]"

这时在treeview中看不到此组件的相关URL。

错误分析：

所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用"HTML-basedscript"模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的JavaApplet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用"URL-basedscript"模式进行录制。

解决办法：

打开录制选项配置对话框进行设置，在"RecordingOptions"的"InternetProtocol"选项里的"Recording"中选择"RecordingLevel"为"HTML-basedscript"，单击"HTMLAdvanced"，选择"ScriptType"为"Ascriptcontainingexplicit"。

然后再选择使用"URL-basedscript"模式来录制脚本。

3、Error-27728:

Stepdownloadtimeout（120seconds）hasexpiredwhendownloadingnon-resource（s）.

错误分析：

对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

解决办法：

首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"RuntimeSetting">"InternetProtocol：

Preferences">"Advanced"区域中设置一个"winlnetreplayinsteadofsockets"选项，再回放是否成功。

4、Error-27791:

Server“192.168.1.77″hasshutdowntheconnectionprematurely

　解决方案如下：

　　1、应用服务器死掉。

小用户时程序上的问题，程序上处理数据库的问题

　　2、应用服务没有死。

应用服务参数设置问题。

例如：

在许多客户端weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是weblogic中的server元素的acceptbacklog属性值设得过低。

如果连接时收到connectionrefused消息，说明应提高该值，每次增加25%。

　　3、数据库的连接，在应用服务的性能参数可能太小了，数据库启动的最大连接数（跟硬件的内存有关）

　　4、有时关闭卡巴斯基也会解决如上问题

　　1）观察responsetime是否超出默认的120秒

　　2）检查服务器日志是否有异常以及负载是否过高

　　3）web_set_timeout设置更长的超时超时上限

　　如：

web.set_timeout（”CONNECT”,“360″）;

　　web.set_timeout（”RECEIVE”,“360″）;

　　web.set_timeout（”STEP”,“360″）;

观察responsetime是否超出默认的120秒这个问题，要详细分析了。

　　应该不会是LR自身造成的问题,把时间调长，就是为了定位问题在什么地方，而不是为了绕过这个错误的出现。

5、Error-27492:

"HttpSendRequest"failed,Windowserrorcode=12002andretrylimit（0）exceededforURL

解决方法：

在runtimesetting中的preferences-->options-->http-requestconnect

timeout（sec）的值设为999。

6、Error-27498:

TimedoutwhileprocessingURL=http:

//172.18.20.70:

7001/workflow/bjtel/leasedline/querystat/subOrderQuery.do

错误分析：

这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。

如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

解决办法：

例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。

如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。

分析一下服务器，最好对其性能进行优化。

如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

最后，增加一下运行时的超时设置，在"Run-TimeSettings">"InternetProtocol:

Preferences"中，单击"options"，增加"HTTP-requestconnecttimeout"或者"HTTP-requestreceive"的值。

7、Error-26612:

HTTPStatus-Code=500（InternalServerError）forhttp:

//192.168.0.8:

10001/logonConsole.do;jsessionid={JSESSIONID2}

造成HTTP－500错误，如下几个可能：

1、运行的用户数过多，对服务器造成的压力过大，服务器无法响应，则报HTTP500错误。

减小用户数或者场景持续时间，问题得到解决。

2、该做关联的地方没有去做关联，则报HTTP500错误。

进行手工或者自动关联，问题得到解决。

3、录制时请求的页面、图片等，在回放的时候服务器找不到，则报HTTP500错误，若该页面无关紧要，则可以在脚本中注释掉，问题将会得到解决。

例如：

有验证码的情况下，尽管测试时已经屏蔽了，但是录制的时候提交了请求，但回放的时候不存在响应。

4、参数化时的取值有问题，则报HTTP500错误。

可将参数化列表中的数值，拿到实际应用系统中进行测试，可排除问题。

5、更换了应用服务器（中间件的更换，如tomcat、websphere、