具体实例教你如何做LoadRunner结果分析
作者 | 修改日期 | 简单描述 |
姜全尧 | 07。07。10 | 增加对监视参数的解释，修改部分描述语言 |
| switch语句具体例子 | ||
1．前言:
LoadRunner最重要也是最难理解的地方-—测试结果的分析。其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.
针对 Results Analysis我用图片加文字做了一个例子，希望通过例子能给大家更多的帮助。
这个例子主要讲述的是多个用户同时接管任务，测试系统的响应能力，确定系统瓶颈所在。客户要求响应时间是1个人接管的时间在5S内。
2．系统资源：
2.1 硬件环境：
CPU：奔四2。8E
硬盘：100G
网络环境：100Mbps
2。2 软件环境：
操作系统：英文windowsXP
服务器:tomcat服务
浏览器：IE6。0
系统结构：B/S结构
3．添加监视资源
下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数。另外有些特殊的资源暂时在这里不做讲解了。我会在以后相继补充进来.
Mercury Loadrunner Analysis中最常用的5种资源.
1.Vuser
2.Transactions
3.Web Resources
4.Web Page Breakdown
5.System Resources
在Analysis中选择“Add graph”或“New graph"就可以看到这几个资源了。还有其他没有数据的资源，我们没有让它显示。
如果想查看更多的资源，可以将左下角的display only graphs containing data置为不选。然后选中相应的点“open graph”即可.
打开Analysis首先可以看的是Summary Report。这里显示了测试的分析摘要。应有尽有。但是我们并不需要每个都要仔细去看。下面介绍一下部分的含义：
Duration（持续时间）：了解该测试过程持续时间。测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
Statistics Summary（统计摘要）：只是大概了解一下测试数据，对我们具体分析没有太大的作用。
Transaction Summary（事务摘要):了解平均响应时间Average单位为秒。
其余的看不看都可以。都不是很重要。
4．分析集合点
在录制脚本中通常我们会使用到集合点，那么既然我们用到了集合点，我们就需要知道Vuser是在什么时候集合在这个点上，又是怎样的一个被释放的过程。这个时候就需要观察Vuser-Rendezvous图。
图1
可以看到大概在3分50的地方30个用户才全部集中到start集合点,持续了3分多,在7分30的位置开始释放用户,9分30还有18个用户,11分10还有5个用户，整个过程持续了12分.
图2
上面图2是集合点与平均事务响应时间的比较图.
注：在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上。右键选择merge graphs。然后在select graph to merge with 中选择即将用来进行比较的graph。如图3：
图3
图2中较深颜的是平均响应时间，浅的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值，可见用户的并发对系统的性能是一个很大的考验.
接下来看一下与事务有关的参数分析.下看一张图.
图4
这张图包括Average Transaction Response Time和Running Vuser两个数据图.从图中可以看到Vuser_init_Transaction（系统登录）对系统无任何的影响,Vuser达到15个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14个用户同时处理事务,Vuser达到30后1分，系统响应时间最大，那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.看来是很难满足用户的需求了。
做一件事有时候上级会问你这件事办得怎么样了。你会说做完一半了。那么这个一半的事情你花了多少时间呢？所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time（Percentile)
图中画圈的地方表示10％的事务的响应时间是在80S左右.80S对于用户来说不是一个很小的数字,而且只有10%的事务,汗。你觉得这个系统性能会好么!
实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事
情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些，但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少？以确定这个系统我们还要付出多少的代价来提高它.
Transaction Response Time（Distribution）—事务响应时间(分布）
显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
很明显大多数事务的响应时间在60—140S。在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右。140S的时间！很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表。我们不难看到此系统在这种环境下并不理想。世间事有果就有因，那么是什么原因导致得系统性能这样差呢？让我们一步一步的分析.
系统性能不好的原因多方面，我们先从应用程序看。有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图。
一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片
中显示了整个测试过程中涉及到的所有web页.web page breakdown中显示的是每个页面的下载时间。点选左下角web page breakdown展开,可以看到每个页中包括的css样式表,js脚本，jsp页面等所有的属性。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论