LoadRunner基本使用流程及结果分析图文.docx
- 文档编号:1933865
- 上传时间:2022-10-25
- 格式:DOCX
- 页数:36
- 大小:2.06MB
LoadRunner基本使用流程及结果分析图文.docx
《LoadRunner基本使用流程及结果分析图文.docx》由会员分享,可在线阅读,更多相关《LoadRunner基本使用流程及结果分析图文.docx(36页珍藏版)》请在冰豆网上搜索。
LoadRunner基本使用流程及结果分析图文
一、LoadRunner基本使用流程及结果分析(图文)
1.打开
2.点击编辑脚本
3.点击按钮新建脚本
4.弹出对话框,选着web〔/html〕
5.输入网址,点击ok
6.录制脚本,录制终止后,点击一下按钮停止录制
7.录制成功后,生成脚本
8.点击如下按钮回放脚本
9.点此按钮,可新增action
10.点此按钮能够进行录制和回放设置
11.弹出的参数话界面
一样回放设置下那个地点就好
12.点击图中图表设置参数化
13.弹出的设置界面,要紧设置红色区域的几个地点
14.以下图按钮为脚本调试
15.以下图按钮为设置时刻的事实上点和终止点的按钮
16.以下图两个按钮分别为与hp质量治理工具ALM连接按钮和创建场景按钮
17.插入事件,分别表示时刻的开始和终止
事件插入成功:
18.设置集合点
二、创建场景
1.在vugen中点击图中按钮创建场景
2.弹出编辑框,设置场景,设置完成后点击ok
第一个是目标场景
第二个是手动场景
其中手动场景能够设置加载虚拟用户数
3.双击那个地点选着加压主机
4.选择主机ip,和系统
5.点击ok关闭对话框
图中红色区域是选着场景执行方式:
模拟真是环境依旧基于时刻表模拟
6.以下图中:
1)Scheduleby选项表示加载方式,基于脚本依旧基于组
2)Runmode表示加载模式:
分别表示模拟真实情形和依旧基于场景
7.双击以下图红色区域,可选着加压力度
8.双击红色区域,可设置压力下完运行时刻
9.双击下面红色的内容,能够选着虚拟用户停止的模式
10.弹出设置选项框,能够选着停止的方式
全部一下停止
每多少时刻停止多少个的方式停止
11.点击run,来到执行界面
12.在执行界面点击startScenario,开始跑场景
13.以下图为执行过程中
14.场景跑完后显示如图界面:
其中右边红色区域是运行过程中监控服务器的资源占用率等等的一些信息,在左边还能够添加或查看其他的一些图标
15.点击下面按钮也能添加加压主机
16.经15后,弹出选项框,点击add能够输入主机信息
17.设置ip欺诈
三、结果分析
1.点击下面按钮,进入分析结果界面
2.分析界面如下:
3.点击那个地点的图表能够查看各结果的,然后对结果进行分析
4.按照如下操作能够增加新的图表
5.右键图表选着合并图表,能够合并分析
6.合并后的图表
具体实例教你如何做LoadRunner结果分析
LoadRunner最重要也是最难明白得的地点--测试结果的分析.其余的录制和加压测试等设置关于我们来讲通过几次操作就能够轻松把握了.针对ResultsAnalysis我用图片加文字做了一个例子,期望通过例子能给大伙儿更多的关心.那个例子要紧讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时刻是1个人接管的时刻在5S内.
2.系统资源:
2.1硬件环境:
CPU:
奔四2.8E
硬盘:
100G
网络环境:
100Mbps
2.2软件环境:
操作系统:
英文windowsXP
服务器:
tomcat服务
扫瞄器:
IE6.0
系统结构:
B/S结构
3.添加监视资源
下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些专门的资源临时在那个地点不做讲解了.我会在以后相继补充进来。
MercuryLoadrunnerAnalysis中最常用的5种资源.
1.Vuser
2.Transactions
3.WebResources
4.WebPageBreakdown
5.SystemResources
在Analysis中选择〝Addgraph〞或〝Newgraph〞就能够看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.
假如想查看更多的资源,能够将左下角的displayonlygraphscontainingdata置为不选.然后选中相应的点〝opengraph〞即可.
打开Analysis第一能够看的是SummaryReport.那个地点显示了测试的分析摘要.无奇不有.然而我们并不需要每个都要认真去看.下面介绍一下部分的含义:
Duration(连续时刻):
了解该测试过程连续时刻.测试人员本身要对那个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的连续时刻。
StatisticsSummary(统计摘要):
只是大致了解一下测试数据,对我们具体分析没有太大的作用.
TransactionSummary(事务摘要):
了解平均响应时刻Average单位为秒.
其余的看不看都能够.都不是专门重要.
【注】51Testing授权IT168独家转载,未经明确的书面许可,任何人或单位不得对本文内容复制、转载或进行镜像,否那么将追究法律责任。
内容导航
4.分析集合点
在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要明白Vuser是在什么时候集合在那个点上,又是如何样的一个被开释的过程.那个时候就需要观看Vuser-Rendezvous(集合点)图.
图1
能够看到大致在3分50的地点30个用户才全部集中到start集合点,连续了3分多,在7分30的位置开始开释用户,9分30还有18个用户,11分10还有5个用户,整个过程连续了12分.
图2
上面图2是集合点与平均事务响应时刻的比较图.
注:
在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上.右键选择mergegraphs.然后在selectgraphtomergewith中选择立即用来进行比较的graph.如图3:
图3
图2中较深颜色的是平均响应时刻,浅色的为集合点,当Vuser在集合点连续了1分后平均响应时刻出现最大值,可见用户的并发对系统的性能是一个专门大的考查.接下来看一下与事务有关的参数分析.下看一张图.
图4
这张图包括AverageTransactionResponseTime和RunningVuser两个数据图.从图中能够看到Vuser_init_Transaction(系统登录)对系统无任何的阻碍,Vuser达到15个的时候平均事务响应时刻才有明显的升高,也确实是说系统达到最优性能的时候承诺14个用户同时处理事务,Vuser达到30后1分,系统响应时刻最大,那么那个最大响应时刻是要推迟1分钟才显现的,在系统稳固之后事务响应时刻开始下降说明那个时候有些用户差不多执行完了操作.同时也能够看出要想将事务响应时刻操纵在10S内.Vuser数量最多不能超过2个.看来是专门难满足用户的需求了.
做一件事有时候上级会问你这件事办得如何样了.你会说做完一半了.那么那个一半的情况你花了多少时刻呢?
因此我们要想明白在给定时刻的范畴内完成事务的百分比就要靠下面那个图(TransactionResponseTime(Percentile)
图中画圈的地点表示10%的事务的响应时刻是在80S左右.80S关于用户来说不是一个专门小的数字,而且只有10%的事务,汗.你觉得那个系统性能会好么!
实际工作中遇到的情况不是每一件事都能够在专门短的时刻内完成的,关于那些需要时刻的情况我们就要分配适当的时刻处理,时刻分配的不平均就会显现有些情况消耗的时刻长一些,有些情况消耗的短一些,但我们自己清晰.LR同样也为我们提供了如此的功能,使我们能够了解大部分的事务响应时刻是多少?
以确定那个系统我们还要付出多少的代价来提高它.
TransactionResponseTime(Distribution)-事务响应时刻(分布)
显示在方案中执行事务所用时刻的分布.假如定义了能够同意的最小和最大事务性能时刻,能够通过此图确定服务器性能是否在可同意范畴内.
专门明显大多数事务的响应时刻在60-140S.在我测试过的项目中多数客户所能同意的最大响应时刻也要在20S左右.140S的时刻!
专门少有人会去花这么多的时刻去等待页面的显现吧!
通过观看以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么缘故导致得系统性能如此差呢?
让我们一步一步的分析.
系统性能不行的缘故多方面,我们先从应用程序看.有的时候我不得不承认LR的功能确实专门强大,这也是我喜爱它的缘故.先看一张页面细分图.
一个应用程序是由专门多个组件组成的,整个系统性能不行那我们就把它完全的剖析一下.图片中显示了整个测试过程中涉及到的所有web页.webpagebreakdown中显示的是每个页面的下载时刻.点选左下角webpagebreakdown展开,能够看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性.
在selectpagetobreakdown中选择页面.
见图.
在SelectPageToBreakdown中选择:
//192.168.0.135:
8888/usertasks后,在下方看到属于它的两个组件,第一行中Connection和FirstBuffer占据了整个的时刻,那么它的消耗时刻点就在那个地点,我们解决问题就要从那个地点下手.
也有可能你的程序中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):
用物理内存数.假如Available
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- LoadRunner 基本 使用 流程 结果 分析 图文
![提示](https://static.bdocx.com/images/bang_tan.gif)