LoadRunner 学习笔记.docx
- 文档编号:10713250
- 上传时间:2023-02-22
- 格式:DOCX
- 页数:23
- 大小:1.29MB
LoadRunner 学习笔记.docx
《LoadRunner 学习笔记.docx》由会员分享,可在线阅读,更多相关《LoadRunner 学习笔记.docx(23页珍藏版)》请在冰豆网上搜索。
LoadRunner学习笔记
LoadRunner学习笔记
1简介
作为初学者和使用者,我们只需要关心如下几个功能点:
下面将详细介绍这三部分功能的用途和使用。
2VirtualUserGenerator
从字面意思可以理解为虚拟用户生成器。
我们知道压力测试就是分析多用户并发下所测试系统运行状况的一种行为。
那么怎么实现多用户并发操作呢?
这就需要用到VirtualUserGenerator功能。
该功能用来模拟实体用户的业务操作,感觉有点像按键精灵,不过更加智能,也可以参数化配置。
脚本的录制很简单,工具会自动记录你的页面操作轨迹,并生成相应的脚本文件,其实和录制视频教程很类似。
功能主界面如下:
1.
2.
2.1.网页类脚本
网页类脚本,也就是指在浏览器中操作的业务,基本上B/S架构都是这个类的,当然如果前端使用flash展示的话,效果未知。
新建Web(HTTP/HTML)类型的脚本
脚本创建后我们可以看到如下界面,从界面中我们可以看到一个web脚本分为三个部分:
vuser_init、Action、vuser_end。
2.1.1.vuser_init部分
这部分的代码是虚拟用户初始化的代码,这部分代码只会调用一次,用在B/S结构上可以理解为用户登录系统这部分逻辑。
2.1.2.Action部分
这部分的代码为活动代码,即用户所操作的具体业务行为,在压力测试的时候可以重复调用。
2.1.3.vuser_end部分
这部分的代码是虚拟用户结束时的代码,这部分代码也只会调用一次,用在B/S结构上可以理解为用户退出系统这部分逻辑。
这部分脚本也可以不创建,对测试影像不大。
具体操作,点击菜单栏中的红色按钮(StartRecord)就可以开始脚本的录制。
录制开始的时候会弹出如下窗口,稍微说明一下,至于后续的业务操作就自己动手吧,呵呵
●URLAddress:
压力测试的环境地址
●RecordintoAction:
脚本的位置(vuser_init、Action、vuser_end),默认开始录制时使用vuser_init部分。
注意事项
●Programtorecord:
必须使用iexplore,不要使用其他的浏览器,恩,这个和偶要测试的系统有关;
●关闭防火墙和杀毒软件,否则会在录制脚本的时候录制到这类软件的操作。
2.1.4.脚本录制要点
一个脚本中,可以设置多个交易段,也就是用来细分业务操作的,方便问题定位啥的,怎么细分需根据具体业务具体分析。
不过简单的划分,可以按照一个按钮一个交易定位。
一切就绪可以点击事件按钮前设置为交易开始,点击按钮等待所有事件触发完毕设置为交易结束。
呵呵,听不懂吗,那你就一边儿凉快去吧。
脚本的具体录制就不详述了,完毕后如下所示,你可以看到录制好后自动生成的脚本文件。
2.2.脚本参数化
脚本录制完毕后,并不是说这个虚拟用户的操作脚本就完成了,还需要进行参数化配置。
2.2.1.简易参数
什么是简易参数呢,就是这类参数是已知的,人工在界面上录入的,例如:
姓名、性别、订单号之类的。
一个脚本是否复杂要看其参数的多少了。
简易参数化举例:
如下图所示,变量00000000001是我们在录制脚本的时候填入的动态值,这就需要对该变量进行参数设置。
操作的方法为,选中00000000001,点击鼠标右键,在弹出的菜单中找到ReplacewithParameter选项。
在弹出的窗口中,设置Parametername,默认的type类型为File,点击Properties…按钮可设置详细信息。
详细设置界面如下:
点击CreateTable创建变量列表文件,
创建完毕后,界面如下:
可以点解EditwithNotepad…按钮设置变量数据,如下
注意事项
●文本文件的最后一行要有一个回车,即第一行是变量名称,最后一行是一个空行。
●为了保证变量在运行的过程中被唯一使用,需要设置如下的变量使用规则。
变量设置完毕后,在脚本页面就可以将所有的00000000001替换为{OtherNo},如下:
2.2.2.复杂参数
什么是复杂参数呢?
和简易参数对比可知,这类参数也是一串重复的变量,不过这个字符串不是人工输入的,而是由系统生成再返回给前台使用的变量。
复杂参数化举例:
第一步你需要找到这个变量第一次从后台返回的地方,这需要你对系统比较熟悉,否则找起来蛮头痛的,呵呵。
个人建议,直接将视图转换成下面的样式,然后查阅所有的response返回信息,如果对系统熟悉的话,那么基本上很容易就可以定位到返回值的url地址段。
具体步骤如下:
●第一步:
打开tree视图
●第二部:
打开httpview视图
●第三部:
一次浏览http请求,图左;
●第四步:
查看Response信息。
当找到变量从后台返回的语句后,再次将视图还原到script模式下,鼠标会定位到该http请求的位置,这个时候我们就需要用到web_reg_save_param这个函数。
web_reg_save_param函数说明
●变量名称,根据需要随便起,呵呵
●LB(LeftBoundary):
返回信息的左边界字串。
该属性必须有,并且区分大小写。
●RB(RightBoundary):
返回信息的右边界字串。
该属性必须有,并且区分大小写。
●Search:
返回信息的查找范围。
可以是Headers,Body,Noresource,All(缺省)。
●LAST,默认参数,不可或缺。
举例
要解析的字符串为fm.EdorAcceptNo.value=”00000000009”;
函数则web_reg_save_param("EdorAppNo","LB=EdorAcceptNo.value=\"","RB=\"","Search=All",LAST);
当完成了复杂变量的关联后,就可以将其视为简易变量来使用了,把所有的00000000009替换为{EdorAppNo}即可。
2.3.脚本的验证
参数化后的脚本的有没有问题,可以通过点击运行按钮来运行脚本,并查看后台日志和数据的情况来判断。
2.4.参数列表
虚拟用户脚本的录制和参数就差不多了,剩下的就是对变量的File文件进行扩充了,如果你打算让Action部分被运行10000次,如果变量是唯一的,那么你就需要准备一个有10000不同变量的配置File文件。
切记,变量的配置都是在各个脚本中进行的,后续无法变更。
可以点击下面的按钮,弹出该脚本的变量列表清单。
3Controller
从字面意思可以理解为控制器、管理员。
实际上这个功能的我理解为场景布置,即设定满足某种状况的一种运行实体。
这里面可以设定虚拟用户的数量,运行的业务操作(VirtualUserGenerator),运行的时间,用户的递增规则,用户的递减规则等等。
Controller功能主要分为两大部分,一部分是Design,另一部分是Run。
前者是用来配置场景运行参数的,后者是场景运行时监控的。
1.
2.
3.
3.1.Design视图
进入Design试图前,会让你选择要添加的脚本,左边列表是已注册的脚本清单,右边列表是该场景需要添加的脚本清单。
如下图所示:
选择好脚本后,进入的主界面如下:
每一个脚本我们都需要设置下面的5个属性,麻烦的是只能单独设置,不够人性化啊:
●基本上1、2的属性不用调整,字面意思很好理解自己看着来吧,呵呵。
●StartVusers和StopVusers的功能相同,一个是设置虚拟用户递增的规则,一个是设置虚拟用户递减的规则。
虚拟用设置举例
虚拟用户总数为3名,从场景运行开始,每10秒增加一个虚拟用户。
右边的曲线图可以看到一个虚拟用户递增的效果。
●Duration用来设置,全部虚拟用户加载完毕之后,脚本运行的总时间,一般来说你也不是想把测试环境压垮,所以压个20-30分钟就差不多了。
当然也可以采用Rununtilcompletion设置,就是当所有准备的变量都被使用后自行停止,听起来就是很没谱的事情,呵呵。
脚本的运行参数可以批量设置,比较人性,不过也有一些属性只能单独设置,认命吧,呵呵
运行参数设置举例
同一类脚本,脚本的运行参数设置就可以一次性设置,如下
选择sharedRTS即可让这些脚本共享运行设置。
运行参数主要设置两个部分:
第一个设置脚本的执行次数,也就是action的重复次数,记得要确保变量足够。
第二个设置是否启用思考时间,是否启用测试结果差异会很大的哦,至于怎么设置去翻资料吧,哈哈
注意事项
由于是B/S模式测试,还有可以设置的就是请求超时的内容,默认值好像是120,改成999吧,记得有3个可以改,嘿嘿
3.2.Run视图
Design界面的东西都设置好了的话,就可以将主界面切换到Run视图下了,接下来就是运行并监控了。
剩下的就看人品了,呵呵,点击StartScenario开始运行场景,如果没有什么异常的话,你就会很顺利的完成。
如果有异常的话,呵呵,那么你就只能自己分析了,loadrunner还是提供了很丰富的错误信息供你查看的。
场景运行的时候是可以监控一些指标的,不过我觉得没啥意义,所以不用关注。
因为这些数据最终都可以在Analysis功能中查看到,而且数据更丰富。
运行完毕后,点击下面的按钮会自动生成Analysis报告,用来分析压力测试状况。
4Analysis
从字面意思可以理解为分析、解析。
实际上也的确就是这么个意思,主要是用来分析场景(Controller)运行完毕后的一些收集数据,通常我们拿出的压力测试报告的依据就来源于此。
默认的情况LoadRunner提供的分析报告有6份:
SummaryReport(汇总),RunningVusers(虚拟用户),HitsperSecond(点击率),Throughput(吞吐量),TransactionSummary(交易量),AverageTransactionResponseTime(平均交易响应时间)。
下面将介绍几个比较有用的报表。
1.
2.
3.
4.
4.1.SummaryReport(汇总)
页面上部显示的内容如下:
●记录了虚拟用户的总数
●总的吞吐量,据说loadrunner的吞吐量指的是纯接收的字节数,单位是大B(Byte)。
●平均每秒的吞吐量
●总的点击次数
●平均每秒的点击次数
●总的错误数,当然这个错误数有的是交易错误,也有的是运行时的其他错误,总之不太多的话不重要,呵呵
页面下部显示的内容如下:
罗列该场景运行的所有脚本信息,比较关注的列有Average(平均时间),Maximum(最大时间),90Percent(90%的事务响应时间,此百分比可调整,默认90%,所以不看也罢),Pass(成功件数),Fail(失败件数)
4.2.TransactionSummary(交易量)
此报告也没啥大的用途,主要是用来做汇报的时候,比较有数据效果,呵呵
4.3.AverageTransactionResponseTime(平均交易响应时间)
这个报告呢,就比较有分析价值了,如果曲线是比较平缓分布的话,那说明系统在并发压力下承受能力很不错,如果曲线的落差很大,那么说明系统可能存在瓶颈,这就需要技术人员对功能进行分析了。
4.4.其他报表
当然如果loadrunner只能提供这么几个报表的话,那么也太弱了吧,真对不起好几千块的大洋啊。
之前说过loadrunner的数据是存储在mdb文件中的,实际上就是个小型数据库,那么肯定还有更多的分析功能等着我们挖掘。
在大纲结构图的地方,点击鼠标右键然后依次选择addnewitem->addnewgraph…,就可以弹出所有可提供的分析报表。
可以看出主要的分析是从五个方面给出,即用户、错误、交易、web资源、web分析,每个大类下有明细划分了诸多小项。
这个具体的使用就不描述了,需要什么就添加什么,英文不好所以也就不详述了,哈哈
4.5.报表过滤器
LoadRunner的分析报告很多数据都是存储在mdb文件中的,因此数据过滤整合很方便,当然可配置信息很多,只是显示的主要是下面的,可以看到过滤掉了思考时间,以及90Percent的比例是90等,
更详细的过滤器设置界面如下:
比较常用的是脚本过滤了(GroupName)和交易过滤(TransactionName),谁让我们只想看关心的数据呢,呵呵
5压力测试的问题总结
此次测试的问题
●带宽不够是不能强求的
●不要用xp做压力机,真的不经折腾
●并发要求高的话多准备几个压力机
●B/S的系统尽量用Web(HTTP/HTML)类型的脚本
●Java脚本的用户数和web脚本的用户数概念不同,这个被玩死了n次
●硬盘要足够大,loadrunner的日志不是吹的,真的很大
●一个场景要多测试几次,总会有不小的偏差
其实压力测试还有很多东西要掌握和学习,推荐spotlight工具用来监控操作系统、数据库的运行情况。
如果用的是Oracle数据库,可以设置好awr报告的抓取时间,这个报告还是蛮有用处的,对于我这样的使用者。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- LoadRunner 学习笔记 学习 笔记
![提示](https://static.bdocx.com/images/bang_tan.gif)