LoadRunner基本使用流程及结果分析(图文)

1/42一、录制脚本1.打开2.点击编辑脚本3.点击按钮新建脚本2/424.弹出对话框，选着web（http/html）3/425.输入网址，点击ok6.录制脚本，录制结束后，点击一下按钮停止录制4/427.录制成功后，生成脚本8.点击如下按钮回放脚本9.点此按钮，可新增action5/4210.点此按钮可以进行录制和回放设置11.弹出的参数话界面一般回放设置下这里就好6/4212.点击图中图表设置参数化13.弹出的设置界面，主要设置红色区域的几个地方7/4214.下图按钮为脚本调试8/4215.下图按钮为设置时间的其实点和结束点的按钮16.下图两个按钮分别为与hp质量管理工具ALM连接按钮和创建场景按钮9/4217．插入事件，分别表示时间的开始和结束事件插入成功：18.设置集合点10/4211/42二、创建场景1.在vugen中点击图中按钮创建场景2.弹出编辑框，设置场景，设置完成后点击ok第一个是目标场景第二个是手动场景其中手动场景可以设置加载虚拟用户数12/423.双击这里选着加压主机13/424.选择主机ip，和系统5.点击ok关闭对话框图中红色区域是选着场景执行方式：模拟真是环境还是基于时间表模拟14/426.下图中：1）Scheduleby选项表示加载方式，基于脚本还是基于组2）Runmode表示加载模式：分别表示模拟真实情况和还是基于场景15/427.双击下图红色区域，可选着加压力度16/428.双击红色区域，可设置压力下完运行时间17/429.双击下面红色的内容，可以选着虚拟用户停止的模式18/4210.弹出设置选项框，可以选着停止的方式全部一下停止每多少时间停止多少个的方式停止11.点击run，来到执行界面19/4212.在执行界面点击startScenario,开始跑场景13.下图为执行过程中14.场景跑完后显示如图界面：其中右边红色区域是运行过程中监控服务器的资源占用率等等的一些信息，在左边还可以添加或查看其他的一些图标20/4215.点击下面按钮也能添加加压主机21/4216.经15后，弹出选项框，点击add可以输入主机信息22/4217.设置ip欺骗23/42三、结果分析1.点击下面按钮，进入分析结果界面2.分析界面如下：3.点击这里的图表可以查看各结果的，然后对结果进行分析24/424.按照如下操作可以增加新的图表5.右键图表选着合并图表，可以合并分析25/426.合并后的图表26/42具体实例教你如何做LoadRunner结果分析LoadRunner最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对ResultsAnalysis我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1个人接管的时间在5S内.2.系统资源:2.1硬件环境：CPU：奔四2.8E27/42硬盘：100G网络环境：100Mbps2.2软件环境：操作系统：英文windowsXP服务器：tomcat服务浏览器：IE6.0系统结构：B/S结构3.添加监视资源下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。MercuryLoadrunnerAnalysis中最常用的5种资源.1.Vuser2.Transactions3.WebResources4.WebPageBreakdown5.SystemResources在Analysis中选择“Addgraph”或“Newgraph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.28/42如果想查看更多的资源,可以将左下角的displayonlygraphscontainingdata置为不选.然后选中相应的点“opengraph”即可.打开Analysis首先可以看的是SummaryReport.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。StatisticsSummary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.TransactionSummary(事务摘要)：了解平均响应时间Average单位为秒.其余的看不看都可以.都不是很重要.【注】51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。内容导航4.分析集合点在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous(集合点)图.29/42图1可以看到大概在3分50的地方30个用户才全部集中到start集合点,持续了3分多,在7分30的位置开始释放用户,9分30还有18个用户,11分10还有5个用户,整个过程持续了12分.30/42图2上面图2是集合点与平均事务响应时间的比较图.注:在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:点击图上.右键选择mergegraphs.然后在selectgraphtomergewith中选择即将用来进行比较的graph.如图3:31/42图3图2中较深颜色的是平均响应时间,浅色的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.32/42图4这张图包括AverageTransactionResponseTime和RunningVuser两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达到15个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14个用户同时处理事务,Vuser达到30后1分,系统响应时间最大,那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.看来是很难满足用户的需求了.做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(TransactionResponseTime(Percentile)33/42图中画圈的地方表示10%的事务的响应时间是在80S左右.80S对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.TransactionResponseTime(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.34/42很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右.140S的时间!很少有人会去花这么多的时间去等待页面的出现吧!通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.35/42一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web页.webpagebreakdown中显示的是每个页面的下载时间.点选左下角webpagebreakdown展开,可以看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性.在selectpagetobreakdown中选择页面.见图.36/42在SelectPageToBreakdown中选择:8888/usertasks后,在下方看到属于它的两个组件,第一行中Connection和FirstBuffer占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.37/42也有可能你的程序中client的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.%processortime(processor_total):器消耗的处理器时间数量.如果服务器专用于sqlserver可接受的最大上限是80%-85%.也就是常见的CPU使用率.%Usertime(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。%DPCtime(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:%ProcessorTime非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。%Disktime(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%DiskTime比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows2000的命令行窗口中运行diskperf-yD。若数值持续超过80%，则可能是内存泄漏。Availiablebytes(memory):用物理内存数.如果AvailableMbytes的值很小(4MB或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。Contextswitch/sec(system):(实例化inetinfo和dllhost进程)如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。%Diskreads/sec(physicaldisk_total):每秒读硬盘字节数.%Diskwrite/sec(physicaldisk_total):每秒写硬盘字节数.Pagefaults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。Pagespersecond:每秒钟检索的页数。该数字应少于每秒一页Workingset:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。38/42Avg.diskqueuelength:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个RaidDisk实际有多个磁盘。Averagedi