jmeter使用初稿.docx
- 文档编号:18166857
- 上传时间:2023-08-13
- 格式:DOCX
- 页数:29
- 大小:1.14MB
jmeter使用初稿.docx
《jmeter使用初稿.docx》由会员分享,可在线阅读,更多相关《jmeter使用初稿.docx(29页珍藏版)》请在冰点文库上搜索。
jmeter使用初稿
目录
1.读懂性能方案1
2.相关的测试环境1
3.Jmeter操作栏描述1
4.场景的设置2
4.1线程组的添加2
4.2脚本的开发(即交易的请求)4
4.2.1用户定义的变量4
4.2.2HTTP信息头的添加4
4.2.3HTTPCookie的添加4
4.2.4添加sampler样本(即脚本交易)5
4.2.5参数化9
4.2.6关联(后置处理器正则表达式提取器)12
4.2.7断言(检查点)13
4.2.8脚本调试15
4.3添加思考时间19
4.4添加集合点SynchronizingTimer20
4.5监听器(响应数据、图表等)21
4.6逻辑控制22
4.7注意点23
5.服务器资源监控24
6.分析结果24
编写要点:
围绕怎么做,为什么要这么做,以及从方案中如何隐射到实际操作中。
1.读懂性能方案
待补充(一些废话,好处等,结合Jmeter工具后主要需要的关注点)
2.相关的测试环境
待补充(一些测试环境的记录,查看并记录服务器等的详细配置,为以后的调优作为准备,另有一些命令)
3.Jmeter操作栏描述
根据上图简单介绍部分按钮操作。
◆灰色方块:
保存按钮,保存格式为jmx,保存名称为【项目名称+版本号+测试场景名称+日期.jmx】,且每个场景保存一个单独的文件夹,以后关于该场景测试的信息都存放于此
◆黑色方块:
Toggle启用按钮,可以置灰测试Jmeter中的测试内容、元件等,调试脚本和变更场景时经常使用
◆红色方块:
执行按钮
◆绿色方块:
强制停止按钮
◆蓝色方块:
将所有远程的机器全部启动
◆紫色方块:
清除当前选定图表数据/清除全部数据,每次执行测试计划应清除上一次遗留的数据。
4.场景的设置
4.1线程组的添加
线程组即通俗的VU用户数,右击测试计划→添加Thread(Users)→线程组。
添加线程组后,就要对线程组进行设置,主要有线程组名称、取样器错误后要执行的动作、线程属性与调度器配置。
在设置之前,可以先准备从方案中获得数据。
1.测试策略场景下所需要测试的模块
2.用户的并发数量
3.用户启动的策略,即每多少秒启动一个线程等等
4.时间的设置(持续时间、启动时间等等)
●线程组名称:
一般取方案中所定义的测试场景的模块的名称
●对于取样器错误后执行的动作,一般选择【继续】选项,这样的选择无非就是保证设置的场景中的线程不变或者测试能够继续的执行下去,若选择其他选项如停止线程或者停止测试则最后可能造成一遇到错误,当前线程就停止,这样可能就与方案中的测试场景不一致了。
●对于线程属性,需要设置线程数、Ramp_upPeriod以及循环次数。
线程数:
VU用户数,即并发用户数
Ramp_upPeriod:
设置的线程数全部启动需要的时间,若方案中有如10用户并发,每2秒启动一个线程,则Ramp_upPeriod设置的时间为10*2=20秒
循环次数:
可设置为永远或者输入次数,一般除基准测试或者调试时可能会输入循环次数,大多数场景都勾选永远选项
●调度器其实是对于场景设置的可选操作,但是根据实际操作它时设置场景不可缺少的一部分,几乎每一个场景都需要设置,主要有启动时间、结束时间、持续时间、延迟时间
举例若方案中有一测试场景,按照并发数为10用户进行测试,迭代(循环)次数100,设置如下图。
举例若方案中有一测试场景,按照并发数为10用户进行测试,线程启动时间每2秒一个,延迟五分钟执行,持续时间30分钟(设置了持续时间和启动延迟后,启动时间与结束时间已经失效),设置如下图。
注意点:
1.若循环次数不为永远,同时又设置持续时间时,不管时两个中哪一个先执行到达,另一个立即判定失效。
因此除方案中所描述的需要进行循环的次数场景(持续时间不设置),其余场景都设置循环次数为永远。
2.启动时间与延迟时间若同时设置且不一致,则已延迟时间为准;持续时间与结束时间同时设置且不一致,则以持续时间为准。
3.若启动时间为“已经过去的时间”,启动后,立即执行
4.若结束时间为“已经过去的时间”,不管如何设置,启动后,执行循环次数一次。
因此当持续时间没有设置,启动时间和结束时间都设置时,确认结束时间的有效性。
4.2脚本的开发(即交易的请求)
本例中主要讲了HTTP请求,主要使用Google浏览器下的审查元素功能,方法很多,同样可以使用Httpwatch等工具来获得请求信息。
4.2.1用户定义的变量
点击添加配置元件→用户定义的变量,影响子节点内容,在用户定义的变量中添加自己定义的变量,可以先添加该配置元件,待有需要添加的变量时再添加,为了清晰的了解变量的含义,最好添加Description描述。
可能在sampler与断言等内容中使用到,具体使用方法在实际中描述。
4.2.2HTTP信息头的添加
点击添加配置元件→HTTP信息头管理器,影响子节点内容,在信息头管理器中添加需要的内容,主要有User-Agent、Accept、Accept-Language以及Content-Type。
可先添加此配置元件,需要时在添加内容信息,信息头获取在脚本开发的第三节有介绍,一般通用的信息头在下表中已经指出。
HttpHeaderManager通用信息头,具体遇到实际项目可适当修改。
名称:
值
User-Agent
Mozilla/4.0(compatible;MSIE7.0;WindowsNT6.1;Trident/4.0;SLCC2;.NETCLR2.0.50727;.NETCLR3.5.30729;.NETCLR3.0.30729;MediaCenterPC6.0;.NET4.0C;.NET4.0E)
Accept
application/json,text/plain,*/*
Accept-Language
zh-CN
Content-Type
application/json;charset=utf-8
4.2.3HTTPCookie的添加
点击添加配置元件→HTTPCookies管理器,cookie的功能是辨别用户身份而储存在用户电脑上的数据,在HTTP请求中需要使用该配置元件。
4.2.4添加sampler样本(即脚本交易)
Sampler样本即测试的系统的协议,实际添加的sampler根据方案及系统确认,有Http、Java、Ftp等等。
选择某一需要添加sampler的线程组,点击添加sampler→HTTP请求,主要设置有sampler名称、注释、web服务器名设置、Timesouts、Http请求、Proxyserver等。
●HTTP请求基本设置
1)名称:
方案中所定义的测试场景模块中的功能点名称
2)注释:
更好的理解该请求测试的内容(可不填写)
●Web服务器信息(从页面请求Network中获得)
1)服务器名称或IP:
被测试系统的根地址
2)端口:
被测系统的端口
●Timeouts:
超时时间,分为连接超时和响应超时,根据实际内容设置,一般不用填写
●Http请求内容(从页面请求Network中获得)
1)Implementation:
2)协议:
根据实际内容填写请求的协议
3)方法:
分为POST和GET两种方法,登陆操作,提交、删除等操作都是POST方法;查询类操作为GET方法,根据实际情况选择
4)Contentencoding:
5)跟随重定向:
勾选
6)UseKeepAlive:
为了保持登陆后的持续连接,一般勾选此项
7)路径:
详细的请求地址,因为web服务器中已经有根地址,所以只需要添加请求的路径
8)同请求一起发送的参数/文件:
进行POST操作(登陆,表格提交等)时需要填写,查询类不需要填写
●ProxyServer代理服务器(从页面请求Network中获得)
1)服务器名称或IP:
代理服务器的地址
2)端口:
代理服务器的端口
了解基本设置后,开始准备填写数据,除名称是从方案中模块的功能点名称获取,其他设置数据一般通过请求页面获得。
1.打开Google浏览器,右击选择审查元素项,再选择Network标签。
2.首先要确认你要执行的请求是什么,操作页面至请求之前,在请求操作之前,先清除Network下的信息,例如要获取登陆的请求,则打开页面直到登陆页面,清除Network下的数据。
3.登陆请求的操作(特别的操作)
注:
因为登陆操作成功后会有地址跳转,从而造成没有抓取到该登陆POST的请求,所以在此有特别的方式来获取,一些与登陆请求相同有跳转的请求也适用此方法。
1)输入错误的登陆信息,原用户/密码admin/admin,改输入为admin1/admin,特别注意的是一般不能用户名和密码都输错。
点击登陆后,Network下出现一POST请求
2)点击登陆打开请求的详细信息,获取Headers页签下的RequestURL,RemoteAddress,其中RemoteAddress的信息即为代理服务器(ProxyServer)需要填写的内容,IP:
10.36.232.17,端口:
8080
RequestURL的信息为web服务器需要填写的内容(注意:
取根地址),服务器名称或IP:
mhis-fwa-,此数据在之后的sampler中都能使用。
RequestURL中/mhis-fwa/login.action即为HTTP请求下路径中所需要填写的内容
3)RequestHeaders信息内容即为4.2.2HTTP信息头所需要添加的内容,不过就如上面已经给出的表格,HTTP信息头也就是那些通用的就行了,遇到实际情况再修改。
4)获取RequestPayload中的标红的数据,即为BodyData中需要填写的内容,拷贝并且复制,另外此数据因为是错误的登陆信息,需要一定的修改,或者再另外把用户名写正确,密码写错。
5)根据以上内容,最终sampler(HTTP请求)的参数设置内容为如图所示:
6)其他HTTP请求内容如协议、方法等,如不确认也可从Headers中取得。
4.常用查询类请求的操作
与登陆请求操作的方式大致相同,若有可参数化数据,则适当的进行参数的替换。
若有一下查询请求的操作,则可以进行条件的参数化。
1)点击针对医疗机构监控的GET请求
2)从Headers中获取web服务器、HTTP请求、ProxyServer代理服务器信息,以下图片中RequestURL中可以发现有可参数化的数据,如结算起始月份endDate、结算结束月份startDate等。
(参数化在下节描述)。
添加完如下图的变量就可以用变量直接赋值,或者进行参数化。
使用方法如$(变量名称),替换RequestURL中的endDate与startDate,替换完成后Http请求中的路径中为如下图所示。
5.待续
如有则待补充
4.2.5参数化
右击添加配置元件→CSVDataSetConfig,如下图所示,
●Filename:
文件名,默认选择在场景文件夹下保存,一般CSV、dat格式,用UltraEdit工具打开后修改,根据需要的参数填写数据,一列为一个参数
●Fileencoding:
编码方式,默认为空
●VariableNames:
需要参数化的变量
对应于Filename中的文件,以逗号分开,第一个参数对应于文件中的第一列数据
●Allowquoteddata:
未知
●RecycleonEOF?
:
是否循环使用参数,一般选择TRUE
●StopthreadonEOF?
:
参数读取到结尾时,是否停止线程,一般选择False
●Sharingmode:
参数文件的分享模式,一般选择currentthreadgroup整个线程组
举例:
上节添加Sampler中有HTTP请求的内容,针对开始、结束日期简单的做一下参数化的例子,如下图,
1)方法一:
用户自定的变量(实际不算是参数化,只是简单的变量的替换,放在这里是为了方便比较)
使用之前讲过的用户定义的变量这种方法,添加完如下图的org_endDate、org_startDate变量就可以用变量直接赋值。
2)方法二:
CSVDataSetConfig参数化
使用这节中配置的文件,如下图,
两种方法不同,但填入路径中的结果是一致的,使用方法如$(变量名称),替换RequestURL中的endDate与startDate,替换完成后Http请求中的路径中为如下图所示。
当然最终场景运行时发出的请求时有所差别的,方法一中纯粹的替换,只能有一个固定的请求,而方法二中则可以有多种部分差异的请求(参数化时需要充分的确认提供的值是否可用,会不会引出其他的问题,比如说检查点方面无法查找到数据了等等)
方法一:
请求地址固定,如下图,
方法二:
请求地址一,如下图,
方法二:
请求地址二,响应结果正常,脚本不通时因为参数化的文件中检查点orgCode设置错误的原因(检查点设置4.2.7),如下图,
方法三:
请求地址三,响应结果正常,但是数据为空,检查点还是没有找到响应的orgCode值,因此可以看到参数化的值需要慎重,它可能会影响结果(检查点设置4.2.7),如下图,
若用户定义的变量与CSVDataSetConfig参数化中有相同的变量,同作用域下,CSVDataSetConfig中的数据为有效数据。
4.2.6关联(后置处理器正则表达式提取器)
简单的理解就是从服务器的信息中匹配需要数据,点击添加后置处理器→正则表达式提取器,弹出如下界面。
●名称:
提取器名称
●Applyto:
应用范围
●要检查的响应字段:
一般选择主体
●引用名称:
关联字段名称
●正则表达式:
●模板:
$1$,当同时匹配多个组时,中间数字为提取的那个组。
●匹配数字:
负数匹配全部,0随机匹配,正数匹配的个数
●缺省值:
没有匹配到任何数据时的取值
从下图中的正则表达式可以发现需要匹配的数据为name="findId"id="abc(.+?
)",找到后真正需要提取的值为括号内的数据,取第一组全部的数据,如果匹配不到,默认为abc
匹配到的参数的使用方法:
${find_id_1}表示取第一个值;${find_id_matchNr}表示匹配到的参数的总数量。
下图中正则表达式同时匹配两个参数组,根据设置的内容,取第二组中的status中的匹配值。
表达式${find_id_g}表示匹配的参数组的个数。
4.2.7断言(检查点)
断言即检查点,判断一支交易是否运行成功的关键操作,实际的意思就是要在交易请求的时候,从服务器的响应信息中检查到一个值,而这个值就是能够判断这支交易的有效性。
例如:
一个登陆的请求,用户登陆成功后,服务器可能在响应信息中包含了success这个字段,而这个字段就可以作为检查点的值。
所以如果交易中没有相对的断言,则这支脚本是一支不完善的脚本,即使勉强运行,最终得出的结果也是无效的。
选中某一支需要添加断言的sampler,点击添加断言→响应断言后,有如下界面,
●名称:
检查点的名称
●Applyto:
检查点作用的范围
●要测试的响应字段:
检查点应用在服务器响应范围(包括响应头、响应Body等),如果不能确认检查点的确切范围,可以选择响应文本
●匹配模式:
正则表达式选择匹配,相等选择Equals,子字符串选择Substring,根据实际情况选择设置,不清楚的可以选择包括,也就是全选操作
●要测试的模式:
最直白的理解就是需要检查的值
了解的实际的设置内容后,需要根据HTTP请求中服务器响应的内容来正确的填写检查点的内容。
例如:
要为医疗机构查询这支交易做检查点。
操作的步骤同样是在页面端获得医疗机构查询这支交易的请求响应信息,与之前添加sampler样本不同的是,这一次关注点主要在ResponseBody这一块。
(这里将检查点这一操作独立出来,实际操作中要有一个超前的意识,在添加sampler样本内容(HTTP请求)时,考虑到检查点的添加,将检查点的值寻找出来,后面就不用再一次从页面中寻找了。
)
点击查询的请求,然后在Response中寻找检查点。
下图中,关注到ResponseBody中有一字段orgCode,值为0303,并且确认每次执行该交易都能够得到该0303值,由此可以选定该值为检查点的值,即需要测试的模式中填写的内容。
选定检查点的时候,最好再三确认该值,一劳永逸,以防后期代码修改等原因,该值改变或者无效,导致交易执行失败,浪费时间再次修改检查点。
根据选定的值,在要测试模式中添加红线标注的内容,上面写到的值是0303,而此处写的是${orgCode},原因可以追溯到4.2.1中用户已经定义的变量,填写0303固然也可以,但是相对于${orgCode},可读性相差很大,因此对于一些检查点的值最好定义成变量以便于理解,如果检查点的值是可知的不断变化的,那么还可以使用参数化的方法。
其他两种方式,如下图
4.2.8脚本调试
在将交易参数化、关联以及添加断言等之后,可以先进行交易的调试,以确认交易是否调通。
没有监控的工具,脚本的调试也是空谈,所以在进行交易请求的调试前,需要先添加几个常用的监听器,它们可以用来辅助我们调试脚本,发现错误之处。
1)察看结果树:
在需要调试脚本的平行节点上,右击添加监听器→察看结果树,如下图;
●名称:
察看结果树名称
●文件名:
保存的文件名称、类型,如果需要保存,尽量选择保存在脚本根目录下,保存格式为日期+场景名称+察看结果树名称
●Log/DisplayOnly:
选择日志中需要输出的信息,调试交易脚本时一般勾选仅日志错误
●Configure:
用来选择导出到文件时,所筛选后的内容,根据实际需要勾选内容
●取样器结果、请求、响应数据:
发出交易请求时,可以察看到实际信息,用来分析脚本
2)断言报告:
对断言的分析,用来查看交易检查点是否被成功找到,也就是交易是否成功的依据
在需要调试脚本的平行节点上,点击添加监视器→断言报告,如下图(具体内容大致同断言报告)
●名称:
断言名称
●文件名:
保存的文件名称、类型,如果需要保存,尽量选择保存在脚本根目录下,保存格式为日期+场景名称+断言
●Log/DisplayOnly:
选择日志中需要输出的信息,调试交易脚本时一般勾选仅日志错误
●Configure:
用来选择导出到文件时,所筛选后的内容,根据实际需要勾选内容
添加完成之后,针对单支交易进行调试,把没有选定的交易都进行禁用Toggle操作,设置循环次数单次或者多次后,点击Jmeter启动按钮后,点击察看结果树,主要察看如下结果,如图所示
从上图中可以发现所有交易请求都是打钩通过,但是为防万一还是需要检查下请求与响应数据中的信息,确认无误后,单支脚本调试通过。
●情况一:
医疗机构监控查询请求出错,查看请求内容发现GET请求中endDate的值有问题,因此需要进一步的查找错误的源头。
返回到sampler交易医疗机构监控查询中,可以发现endDate的值是通过变量赋值的,因此可以大致推断错误可能发生在用户自定义变量或者参数化中。
●情况二:
医疗机构监控查询请求出错,查看取样器结果内容中发现Responsecode为401,请求内容中没有cookies,进一步分析可能是因为缺少上下文关系。
●情况三:
医疗机构监控查询请求出错,查看发现取样器结果、请求、响应数据都正常,这时可以往断言设置错误方向考虑。
(关联暂时还没用到,稍等片刻)
脚本调试情况太多,实际操作还需要不断的分析、不断积累经验。
4.3添加思考时间
定时器时一种可以用来设置思考时间的元件,使用较多的有固定定时器和高斯定时器,根据测试方案中不同的实际要求,选择相应的定时器。
设置定时器的功能主要有:
第一,拉近与真实场景的差距,像用户操作系统一样有一定的时间去思考;第二,可以调整性能测试对其的压力。
⏹固定定时器(定时时间=线程延迟时间)
线程延迟(毫秒):
固定延迟时间
⏹高斯定时器(定时时间=0到偏差内的时间+固定延迟偏移时间)
偏差(毫秒):
范围时间内的偏差
固定延迟偏移(毫秒):
固定延迟时间
注意点:
定时器设定后影响同一平行节点以及子节点的sampler。
如下图,影响红线端的所有samplers,而不影响登陆(HTTP请求的)sampler。
4.4添加集合点SynchronizingTimer
点击添加定时器→SynchronizingTimer,集合点就是将线程集合起来,当线程数集合等待达到了设定的数量时,一同并发的操作。
测试方案中若是对某些sampler有集合点并发的要求,则需要在该sampler下添加SynchronizingTimer集合点。
如图所示,医疗机构监控_单击查询这个请求设置了集合点,当等待的线程数达到了10个之后,立即并发执行该请求操作,可以从图中看到医疗机构监控_单击查询并发的结果。
4.5监听器(响应数据、图表等)
监听器功能就是获得场景运行后得出的响应数据,用来判断部分性能指标是否通过的报告,经常使用的监听器有断言报告、聚合报告、察看结果树。
上面4.2.9已经描述了断言报告、察看结果树,当然这两个监听器不仅仅只是在脚本调试中使用,在具体的run场景中也时刻需要关注。
聚合报告:
在需要获取结果的父节点或者平行节点上,右击添加监听器→聚合报告(监听器的添加大致如前),如下图;
●名称:
断言名称
●文件名:
保存的文件名称、类型,如果需要保存,尽量选择保存在脚本根目录下,保存格式为日期+场景名称+聚合报告.jtl
●Log/DisplayOnly:
选择日志中需要输出的信息,调试交易脚本时一般勾选仅日志错误
●Configure:
用来选择导出到文件时,所筛选后的内容,根据实际需要勾选内容
●Label:
交易名称
●Samplers:
执行的交易请求总数
●Average:
事务平均响应时间(毫秒)
●90%Line:
90%事务响应时间(毫秒)
●Min/Max:
最小/最大响应时间(毫秒)
对于事务响应时间这一块,测试方案中肯定有一定的通过指标,性能方面主要关注的还是Average、90%Line这两个事务响应时间,如果时间过长,则需要进一步的分析,主要关注点在数据库语句、系统页面加载及展示、响应数据量、环境配置等几个方面去着手。
另外在Average以及90%Line事务响应时间都通过的情况下,也适时的查看分析Max响应时间。
●Error%:
请求错误率。
性能测试中主要的关注点,一般在方案中会有直接的描述,除稳定性测试中可以有适当的错误率,其他测试场景中一般正确率达到100%。
●Throughout:
TPS每秒执行的请求数
性能测试中主要关注点,直接体现出测试系统的处理能力。
聚合报告中如出现Error,可以进一步的观察察看结果数以及断言报告分析错误的原因等,部分图示如下:
通过聚合报告中的内容,可以比对测试方
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- jmeter 使用 初稿