Loadrunner使用手册(整理版).doc

《Loadrunner使用手册(整理版).doc》由会员分享，可在线阅读，更多相关《Loadrunner使用手册(整理版).doc（125页珍藏版）》请在三一办公上搜索。

1、一、Loadrunner简介LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间， 优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢， 系统崩溃等问题。这些都不可避免地导致公司收益的损失。 Mercury Interactive 的 L

2、oadRunner 能让企业保护自己的收入来源， 无需购置额外硬件而最大限度地利用现有的IT 资源， 并确保终端用户在应用系统的各个环节中对其测试应用的质量， 可靠性和可扩展性都有良好的评价。LoadRunner 是一种适用于各种体系架构的自动负载测试工具， 它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测， 来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。 负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果分析。 . (1) 计

3、划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。 .(2) 创建 Vuser 脚本：将最终用户活动捕获到自动脚本中。选择协议 录制脚本 编辑脚本 检查修改脚本是否有误(3) 定义场景：使用LoadRunner Controller 设置负载测试环境。创建场景（Scenario）选择脚本 设置机器虚拟用户数 设置Schedule （场景计划表）如果模拟多机测试，设置Ip Spoofer （ip 欺骗）(4) 运行场景：通过LoadRunner Controller 驱动、管理和监控负载测试。(5) 分析结果：使用LoadRunner Analysis 创建图和报告并

4、评估性能。 LoadRunner 分为Windows 版本和Unix 版本。如果我们的所有测试环境基于Windows 平台， 那么我们只要安装Windows 版本即可。本章讲解的安装过程就是LoadRunner11英文的Windows xp 版本的安装。 系统要求：测试机和工作机可以满足LoadRunner11 的最低要求。不过要比较好的运行LoadRunner， 内存最好在512M 以上， 安装LoadRunner 的磁盘空间至少剩余500M。Loadrunner有7.5、8.0、8.2、8.3、9.2、9.5和11等版本其中从9.2版本开始支持IE7及以上的浏览器，9.2以下的只支持IE6

5、的。二 . Loadrunner11安装和运行环境Loadrunner11是最新的版本主要是支持IE7以及以上内核的浏览器,且菜单划分更明晰更易于操作，如图所示为安装界面要想流程的运行Loadrunner11需要有以下条件.1. AMD或Intel双核或核心处理器2. 1GB以上内存推荐2GB3. 20G左右硬盘空间4. 2M以上带宽的网络5. 操作系统:WinXPSP3，WinVista,Win7或linuxLoadrunner的安装(WindowsXP)双击Setup.exe文件点击Load Runner完整安装程序系统会检测安装环境，如果系统中没有安装.NETfameworks3.5会自

6、动下载此插件。下载后进入下面的界面,点击下一步如果之前已经安装过会有如下提示 三、Loadrunner破解1、 安装完成后，系统会自动打开“Loadrunner License Information”窗口：并提示你的“license”只有十天的使用期。破解篇1、 安装好loadrunner11后2、 退出程序，把下载文件中的lm70.dll和mlr5lprg.dll覆盖掉.HPLoadRunnerbin下的这两个文件 3、 注意，win7的话一定要以管理员身份运行启动程序，启动后，点击 configuration-loadrunner license，此时可能会有两个许可证信息存在，退出程序

7、，点击deletelicense.exe文件，来删除刚才得许可证信息（即时原来没有lisense最好也运行一下）4、 再次打开程序， configuration-loadrunner license-new license，在弹出的输入框中输入license序列号AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB，点击确定，验证通过后，则破解成功！5、 具体操作如下：启动loadrunner，如下图选择“CONFUGURATIONloadrunner license”。6、 选择“New License”,输入“AEABEXFR-YTIEKEKJJMFKEKEKW

8、BRAUNQJU-KBYGB”这里可能会弹出：这是因为这里已经有试用的“license”了，下面我们将试用的“license”删除。点击deletelicense.exe文件，来删除刚才得许可证信息。7、 OK。我们可以安照刚才的步骤重新启动Loadrunner了。再次选择“CONFUGURATIONloadrunner license” 这时会发现，License中已经空了。8、 点击“New License”，输入web-10000的注册码：AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB。OK再次成功。四、Loadrunner的运行双击打开Loadrunn

9、er程序(Win7和Vista中需要在图标上右击鼠标选择以管理员身份运行)。左侧依次为录制编辑脚本文件,运行脚本文件和分析负载结果。我们点击第一项创建和录制脚本进入后点击新建脚本由于是WEB测试所以选择HTTP模式.点击Create按钮在这个窗口中主要有录制的类型这里选择网络程序，如果是本地的选择WIN32程序；第二个选择默认值“浏览器”；第三个是输入要录制的URL连接；第四个输入保存脚本的路径；第五个是默认名称，可以点击NEW修改。设置好路径和要录制的URL后点击OK 后开始录制脚本注：如果录制脚本中中文显示乱码，则需要对LR进行设置1、Tools Recording Options在回放脚

10、本之前：Vuser-运行时设置-浏览器-浏览器仿真-更改-使用浏览器-语言下来选择 “中文（中国）”；2、设置录制脚本的执行的次数点击ToolsRun-time SettingGeneralRun Logic打开设置窗口（注：如果脚本中用户名参数化，如果写入的人员都需要执行，有几个用户写执行几次；编码中如果存在多个参数化字段，将第一个跟其他的参数化字段合并）注：如果录制脚本中增加了参数化或设置了关联，需要在录制脚本VuserRun time Setting 下设置“miscellaneous中选择difine each action as a transaction”（定义任意一个活动为一个事

11、务）；如不设置则运行脚本时通过事务数、失败事务数、错误数均显示0注意：参数化脚本（如流水号、文号）中如果选择Unique Number（唯一值），使用该类型必须注意数据表中有足够的数据。比如在Controller中设定20个虚拟用户进行5次循环，那么编号为1的虚拟用户取前5个数，编号为2的虚拟用户取6-10的数，依次类推，数据表中至少有100个数据，否则Controller 运行中会返回一个错误。例如：Error: Parameter num2: All values in unique block already used. Block size is 10. The parameter c

12、ontinues with last value of the range according to When Out Of Values policy. 3、运行脚本Manual Scenario为手工场景（其中“使用百分比模式运行”可以勾选也可以不勾选）Goal-Oriented Scenario面向目标的场景（注意不要选择该项，该项是验证系统能否达到预期目标，适用场合等有明确的目标，如验收测试）然后选择一个录制好的脚本如send071802.1点击Add添加进来添加后可以进行运行的时间设定可以设置初始用户数量,可以设定增加用户的间隔比如每隔10S增加一个用户。达到最大用户数量后持续运行多

13、长时间比如达到10个人同时访问后持续运行10分钟.可以选择单个用户还是以组的形式运行；同时可以设置“服务水平协议”（SLA，设定性能测试的目标，便于确定是否达标）点击左下角的RUN按钮可以看见正在运行脚本曲线状态图：运行用户数事物的响应时间点击率4、运行结果点击左下角的Design按钮可以看见整个脚本运行过程的系统负载图可以直观了解到当前系统的负载情况.上图左侧的边栏显示的是每一个图表的包含信息如平均响应时间图表中就含有多长时间刷新一次图表,右边是同时显示4个图,通过选项可以显示1,2,4,8个图表；如下图所示.还可以自定义显示“Custom Number”，如显示3个或6个图表.注：如果需要

14、生成web资源图，则需要下图中的配置Running Vusers:运行的虚拟用户数Elapsed Time:运行时间Hits/Second:平均点击数Passed Transaction:通过事务数Failed Transaction:失败事务数Errors:错误数左边图片是运行控制栏可以控制脚本的运行,暂停,继续和重置查看每一个事物等操作.右边的图显示的是正在运行脚本的结果可以看到有运行的时间平均的响应时间,有多少运行成功,多少失败还有有多少是有错误。5、分析结果测试完毕后系统会给出每一个事物的详细结果。如平均的响应时间,CUP和内存的占有率,系统的负载情况点击上方的不同标签可以查看不同的结

15、果如图看到的是统计运行的成功和失败图表.在运行结果界面可以通过点击工具栏的“筛选”按钮来查找想要的内容,比如只想查看运行PASS的实例这时就可以通过筛选来实现.还可以点击工具栏的打印按钮,HTML按钮存成MID和HTML文件以及打印结果.通过点击工具栏像时钟一样的图表可以得到整个运行周期的负载情况.点击保存按钮可以把结果保存在电脑上以便以后导入查看.保存时可能会比较卡请耐心等待.在左侧目录中单击这几个标签可以查看详细的结果和文件的路径和脚本运行的总时间，以及创建脚本时间等.通过这几个标签可以大致分析出系统当前存在的瓶颈,如内存太小或网络环境不佳以及网站的负载能力太差等问题都可以通过这几个标签查

16、看.注：设置用户的并发集合点，在进行性能测试时在集合点策略中设置同时有多少用户同时对服务器发出请求。集合点的意思时等到特定的用户数后再一起执行某个操作，比如一起保存，一起提交（我们通常意义上的并发数并不是指一起提交或者一起保存），一般情况下使用不到集合点，不过，订票系统或者促销类需要用到，比如说某个促销品的促销时间在8点到8点30，这样的话，就可能出现在8点时很多人一起提交的场景（在线并不等于并发）五、LR性能分析图解释 Transactions（用户事务分析）：用户事务分析是站在用户角度进行的基础性能分析。1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第

17、一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重

18、要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是

19、否符合用户的要求。重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。6、Transaction Response Time Under Load（事务响应时间与负载）“ 事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、Transaction Response Time(Percentile)（事务响应时间(百分比)）“事

20、务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。Web Resources（Web资源分析）：Web资源分析是从服务器入手对Web服务器的性能分

21、析。1、Hits per Second（每秒点击次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流

22、量方面的处理能力以及是否存在瓶颈。“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（HTTP状态代码概要）“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。4、HTTP Responses per Second（每秒HTTP响应数）“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态

23、码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。5、Pages Downloader per Second（每秒下载页面数）“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。6、Retries

24、 per Second（每秒重试次数）“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。在下列情况将重试服务器连接：A、初始连接未经授权B、要求代理服务器身份验证C、服务器关闭了初始连接D、初始连接无法连接到服务器E、服务器最初无法解析负载生成器的IP地址7、Retries Summary（重试次数概要）“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。8、Connections（连接数）“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP

25、/IP连接数。借助此图，可以知道何时需要添加其他连接。例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。9、Connections Per Second（每秒连接数）“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。10、SSLs Per Second（每秒SSL连接数）“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开

26、TCP/IP连接后，浏览器将打开SSL连接。Web Page Breakdown（网页元素细分）“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Page Breakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。“页面分解”图可以按下面四种方式进行进一步细分：1)、Download Time Breaddown（下载时间细分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、

27、建立连接时间、第一次缓冲时间等各自所占比例。2)、Component Breakdown(Over Time)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程

28、中的下载情况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。First B

29、uffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。2、Page Component Breakdown（页面组件细分）“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。4、Page Downlo

30、ad Time Breakdown（页面下载时间细分）“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间

31、哪一时间点发生了问题。“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件分析结果中无WINDOWS监控信息一：在Scenario中鼠标右键点击Windows Resource图(在Run栏中)，选择Add Measurement，然后添加你要监控的服务器的IP或名称，最后运行Scenario二：Scenario运行完成后，在Analysis的菜单栏中点击Graph，然后点击add new graph，选择windows resource就可以了参数化： 由于系统文号必须是唯一值，于是尝试loadrunner自动的参数化功能， 例如：

32、如果start=1，Block size per Vuser=10000时，就相当于给每个用户分配了10000个惟一数字，第一个用户从1开始，第二个用户从10001开始，第三个用户从20001开始，依次加10000；但是如何设置好start 和Block size per Vuser这也是一门学问，设置不好就会出现数字不够用的情况，刚开始我就在这块走了很多弯路，经过百度发现如果一下个公式供大家参考：设：块大小设置为:B(block)，起始值为：S（start)，当前用户为：(number)，当前取值为(value)则：V = B*(N-1)+SLoadRunner参数类型的含义：Date/Ti

33、me：运行时，参数用脚本执行时的日期和时间来代替Group Name：运行时，参数用执行脚本的VU所属组的名称来代替Iteration Number：运行时，参数用脚本执行的当前迭代次数来代替Load Generator Name：运行时，参数用产生执行脚本VU的负载产生器(Load Generator)的名称来代替Random Number：运行时，参数用一个随机的整数来代替Unique Number：运行时，参数用一个唯一的整数来代替Vuser ID：运行时，参数用Controller应用为每个VU分配唯一的ID来代替Data File/Table：最常用的参数类型，二者基本相同，均可以利

34、用数据文件为参数提供数据池，并设置参数依据某种规则从数据池中取出数据代替脚本中的参数User-Defined Functions：LoadRunner保留的一个扩展接口Each Iteration，表示在每次迭代时更新参数的值；Each Occurrence，表示在参数每次出现时更新参数的值；Once，表示VU在执行的时候，只在第一次迭代时为参数取一次值，以后每次迭代使用相同的值。其中，对Each Iteration而言，一个VU执行时，每次迭代时更新参数的值，如果在一个迭代过程中某参数出现了多次，参数取相同的值；而对Each Occurrence而言，如果在一个迭代过程中某参数出现了多次，每

35、次都取不同的之。When out of values选项只在Select next row设置为Unique时才有效，当数据池中的数据量不能支持迭代和Unique要求的数据量时，可以通过设置该选项的值指示LoadRunner的处理方法：设置为Abort VUser，则遇到这种情况，VU停止运行；设置为Continue in a cyclic manner，则遇到这种情况，重新从数据池的第一个取值开始循环；设置为Continue with last value，则遇到这种情况，所有不足的取值都用最后一个取值来代替。只要将Select next row设置为Sequential，Update va

36、lue on设置为Each Occurrence即可。Sequential：虚拟用户 Vuser 按照行顺序的进行读取参数文件中的数据，如果参数文件中没有足够的数据，则返回到第一个值，并一直循环到结束。例：如上图我们这里有 测试1、测试2、测试3 三个数据，假设我们有 5 个Vuser，那么第 1 个 Vuser 读到的参数为 测试1，于此类推，到第 4 个 Vuser 的时候， 这里表中已经没有数据了， 于是又从第一个数据开始读取， 故第4 个 Vuser读到的数据是 测试1，第 5 个 Vuser读到的数据是 测试2。注：运行脚本时建议关闭360安全卫士，否则可能提示超时。六、结果分析1、

37、结果集中默认显示2、Summary Report详解1） 概要整体信息上图所示为待分析的性能场景的基本信息。例如场景持续的时间是13分钟16秒，相应文件的名称和存放位置。2） 统计信息概要从上图可知：最大运行用户：40总吞吐量：10382617809B平均吞吐量：13027124B/s总点击次数：730208平均点击次数：916.196单击相应的超链接查看详细信息。3） N个执行情况最差的事务针对“事务超出SLA阈值的比率及超出比率的幅度”而言执行最差的事务。相对于SLA阈值，send_transaction 事务的持续时间超出了38.71%，整个运行期间超出的平均百分比为53.859%单击+

38、可查询在特定的时间间隔内，事务超出SLA的平均百分比和最大百分比。单击按钮，可查看更详细的事务分析注：SLA 即服务水平协议，通过定义场景测试目标，Controller将在场景运行期间进行目标评测并在Analysis概要报告中进行分析。4） 随时间变化的场景行为场景运行期间不同的时间间隔内各个事务的执行情况。（1） Application Under Test Errors :表示在各时间间隔内，所测试程序每秒收到的平均错误数（0表示每秒收到的错误数为0,0+表示每秒收到的错误数略大于0）（2） 事务后面的色块：绿色代表事务未超过SLA；红色代表事务失败；灰色代表尚未定义相关的SLA5） 事务

39、概要单击“SLA Status”状态标志（），可查看具体的SLA信息，如下图所示注： 标准方差，是描述数据采样离散状态的一个重要指标。可以将标准方差跟平均值（）进行比较，前者越大于后者，则表明数据离散度越高，曲线越不平稳即波动较大通过选择“ToolsOptionsGeneral”菜单命令，可设置百分比数值（默认为90）6） HTTP响应概要显示运行测试期间WEB返回的HTTP状态码。例如HTTP 200代表页面返回正常；HTTP 404代表浏览的网页在服务器中不存在，网页可能已经转移； HTTP 500代表服务器遇到内部错误，不能够完成请求。HTTP 302代表重定向（一条对网站浏览器的指令来

40、显示浏览器被要求显示的不同的URL，当一个网页经历过短期的URL的变化时使用。一个暂时重定向是一种服务器端的重定向，能够被搜索引擎蜘蛛正确地处理。302重定向是暂时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。）3、Analysis图GraphAdd New GraphOpen a New Graph通过双击各项可以新建图表。1) Running Vusers正在运行的虚拟用户图显示在场景运行的整个过程内，执行虚拟用户脚本的Vuser数量及其状态。场景设计为Vuser从0开始增加，从上图查看，Vusers数量并不是从0开始，而是直接从

41、某一数值开始递增。原因是由于存在一些网络延迟，该情况属于正常。常常跟其他的图表进行关联，比如跟事务响应时间图，吞吐量图等等进行关联，可以看出在多大用户量的情况下响应时间最大，吞吐量最高等等2) Hit per Second 每秒点击次数是指在场景运行过程中虚拟用户每秒向Web服务器提交的HTTP请求数。在虚拟用户数变化趋势前提下，每秒点击次数逐渐增大，在场景结束前呈减小趋势，属正常情况。每秒点击次数越高，说明产生的压力越大。3) Throughput 吞吐率，显示场景执行期间每秒接收的服务器返回的数据总量。吐量的度量单位是字节。表示在任何给定的某一秒钟虚拟用户从服务器获得的数据量。依据服务器的

42、吞吐量可以评估虚拟用户产生的负载量。该图用用衡量服务器的处理能力。通常将该图与“Hits per Second”图进行合并，若系统性能良好，则二者曲线类似；同一时段内，若Hits per Second图曲线处于上升趋势，而Throughput图趋于平缓或下降趋势，则表明服务器性能存在问题。吞吐率图与点击率图的形状基本类似，区别是点击率图指每秒服务器处理的HTTP请求数，吞吐率图指客户端每秒从服务器获得的总数据量。4) Transaction Summary事务概要图，衡量事务或业务成功率。通过的事务数越高，表明系统处理能力越强，反之，系统可靠性越低。5) Average Transation

43、Response Time平均事务响应时间：显示场景执行期间每秒执行事务所使用的平均时间。该指标越小证明系统处理速度越快。事务随时间变化曲线比较平缓，而且相比于预期的期望值较小，如果平均事务响应时间在虚拟用户数平稳的时候出现突然上升或突然下降的情况，说明可能当前事务中某个页面元素造成了事务响应时间过长，需要查看事务或网页细分图。 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？ 如果服务器耗时过长，请使用相应

44、的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题。平均事务响应时间图显示在场景或者会话步骤运行期间每一秒内执行事务所用的平均时间。 X轴表示从场景或者会话步骤开始运行以来已用的时间；Y轴表示执行每个事务所用的平均时间(单位秒)。 对于每个粒度（间隔尺度），此图以不同的方式显示。粒度越小，结果就越详细，但是要研究虚拟用户在整个场景或者会话步骤的总体行为，使用较高粒度查看结果将会更加有用。 例如，使用低粒度可以看到不执行事务的时间间隔，然后，如果使用较高粒度查看同一个图，将看到事务总体响应时间图。 (默认情况下，只显示已

45、经通过的事务)例如,如果平均事务响应时间图显示性能逐渐改善,则可以将其与正在运行的虚拟用户图进行对比,看性能时间是否因为虚拟用户的负载减少而得到改善.如果定义了可以接受得最小和最大事务性能时间,则可以使用此图确定服务器性能是否再可以接受得范围,很多朋友再没有定义事务性能期望得情况下,进行测试,结果将是很难判断得,测试之前一定要一定得期望6) Transaction per Second每秒事务数，场景执行期间每秒各事务通过、停止、失败的次数；通常将该指标与用户期望进行比较。该指标越大说明系统处理能力越强。同时负载的大小对该指标有一定的影响。若负载稳定，则该指标的曲线应相对平缓；若随着负载的增加

46、，该指标曲线仍平缓显示，则可能服务器或程序出现瓶颈。如上图所示：在虚拟用户数变化的趋势前提下，tem1_TransactionPass 事务数逐渐增大，在场景结束前呈现减小趋势，该情况属于正常现象。7) Transaction Response Time(Percentile) 事务响应时间以百分比的形式展现各事务的响应时间范围。横轴显示为事务总数的百分比，纵轴显示为最大事务响应时间。较高的最大事务响应时间未超出预期的期望值（服务水平协议的设置），则表示满足用户需求。如上图所示：%95左右的最大事务响应时间不超过1.3秒。8) Transaction Performance Summary 事

47、务性能概要，以柱状图对比方式显示场景执行期间各事务的最小、平均以及最大响应时间。从该表可以清晰辨别系统响应时间是否满足用户需求；该图支持事务细分树、事务细分图及事务网页细分图的查看。9) Page Component Breakdown(Over Time)显示场景执行期间每秒内各网页及页面组件的平均下载时间。如下图显示，场景执行期间，127.0ow/addRcvInfo.do页面的下载时间波动最大，最高达1.130s页面及页面组件的下载时间由DNS解析时间、连接时间、第一次缓冲时间、接收时间、SSL握手时间、客户端时间及错误时间等共同组成。如下图所示，127.0.ow/addRcvInfo.do组件的下载时间消耗主要是第一次缓冲时间（First Buffer）就实际情况分析，该时间可接受。10) Time to First Buffer Breakdown 以条形图显示第一次缓冲时间的细分情况，可衡量性能问题时候由服务器或网络导致。如下图所示，127.0.