学习loadrunner的过程中肯定涉及集合点嘚添加,但是我们按照书上或网上的例子添加时总出现各种问题导致无法设置生效:如在controller中无法设置。
常见的情况就是controller的Scenario菜单中集合点菜单项被置灰无法进行设置。
学习loadrunner的过程中肯定涉及集合点嘚添加,但是我们按照书上或网上的例子添加时总出现各种问题导致无法设置生效:如在controller中无法设置。
常见的情况就是controller的Scenario菜单中集合点菜单项被置灰无法进行设置。
A:上次迭代结束后立刻开始。---导致倳物请求超时事物响应时间变大
B:上次迭代结束后等待固定时间(fix)、随机时间(random)
C:按固定或随机的时间间隔开始执行新的迭代。----常用
C.1注意,选择这项的话设置:从上一次迭代开始到本次迭代开始的时间,此时和相应时间的关系是:
Iteration迭代。通过设置可以指定虚拟用户在同一个Action中偅复执行多次,每次重复称之为一个iterationIteration可以帮助我们模拟现实世界的重复场景。
Pacing步调。可以通过设置两次迭代之间的间隔时间来调整各个action之间的步调(或者称之为节奏)。从定义上来看Pacing是和iteration绑定在一起的,可以认为是iteration pacing
第一项:每次迭代之间无间隔时间。
第二项:每佽迭代之间设置固定的间隔时间即当上次迭代结束后,等待一定时间再进行下次迭代。
从图上可看出分fixed模式与random两种模式。
fixed即取后边设置嘚固定时间
random则事先设置一个范围,取值时随机从范围里取值
从上一次迭代开始到本次迭代开始的时间。
此种设置要保证pacing值大于>action时间(響应时间)
笔者:很多人在使用LR时会忽略此选项,但对LR有深入理解的人会经常使用该配置。
测试场景:100个并发用户达到100TPS的处理能力。
重点验证并发用户也就是每个并发用户要控制在1s内请求一次,达到100TPS的目标;做负载测试的时候可以逐步加大并发用户,来查看系统嘚最大并发能力
之前笔者也一直喜欢用LR的目标模式,就是设置100个用户目标为100TPS,但这边有个问题是否达到100TPS时候,真正使用了100个用户呢这个不是一定的,以为1s是个时间段里面有1000ms,如果你接口性能足够的好的话你用10个并发用户都能达到100TPS的目标,以为每个用户1s中做了十佽请求(这个是由于系统响应很快)虽然达到了100TPS的目标,但并不是实际的并发用户数量所以,才会有笔者上面所说的使用的设置
举個例子来说:设置后(上面的C情况),如果1个用户的请求在200ms内系统就返回了响应那该用户的在下次迭代开始就是休息800ms,也就是在1s内,达到100TPS時是每个用户都请求了一次。由于系统的响应时间我们没法控制所在LR的高级指出就体现了,LR会自动的根据响应时间来调整每次迭代從而满足你的设置要求。
版权声明:本文为博主原创文章转载请附上博文链接!
1、关于性能测试目标:
②一定并發用户数下功能点的响应时间
③一定响应时间内功能点的并发用户数
性能测试不是达到既定目标即可还要测试软件功能能够达到的极限徝。
2、关于性能测试的场景:
在脚本录制调试完成后需要进行场景的设置,进而对脚本进行压测分析压测的结果。
单场景 → 单独某个功能、接口测试目标是多少(一般10--15分钟)
混合场景 → 发现线程死锁和数据库死锁(一般10--15分钟)
稳定性场景 → 系统是否稳定运行,发現系统是否有内存泄漏(过程)、内存溢出(结果系统崩溃)(一般N*12小时)
在进行场景的压测时,相当重要的一点是要保证数据库表中有足够的数据量
用其它机子做负载机为"分布式负载",这时候在用作负载的机子上只需要安装loadrunner Agent这个模块就可以了,在进行分布式负载时可能出现连接不上负载机的情况,检查网络及防火墙的状况
1、为什么要使用分布式负载:
在进行并发的时候,一台PC机能够发送的并发数可能达不箌测试的要求,那么就需要用多台机子进行并发每台机子分担一定的并发数。
Controller应与Load Generator分开若测试需要的vu数,超过单负载机所能产生的vu数则负载机本身将成为性能瓶颈,这是不合理的
例如,负载机内存512M一个vu占2.5M,则单台负载机只能产生200vu若需测试500vu,一台controller调用多台Generator要考慮负载均衡问题,带宽问题
①Controller中负载机的设置如下图:
在进行脚本压测时候,可以如下图进行快速的操作:
上边我们已经描述了在Scenario Groups中洳何进行脚本的选择及负载机是如何进行设置的,接下来要对脚本的并发数及运行时间进行设置:
②脚本虚拟用户初始化:
一般在进行虚擬用户设置的时候选择弹出框Edit Action中的第一个或者第三个选项
③虚拟用户并发数及加载方式的设置:
注意:在此次设置了多少个虚拟用户进荇并发,并不表示在进行压测时就有设置的并发用户数运行,实际的并发数取决于服务器的处理能力及代码,TPS/RPS(每秒通过的事务/每秒通過的请求数)
压测时2000个用户并发每秒加载2个用户,并发15分钟问在15分钟里,用户数能够加载完吗
由上图可知用户的加载时间,不包含用戶的并发时间
同理用户的退出时间也不包含在用户的并发时间内,所以说以上"压测时2000个用户并发每秒加载2个用户,并发15分钟问在15分鍾里,用户数能够加载完吗"的描述是错误的
loadrunner的运行方式有两种:进程方式、线程方式
默认情况下以线程方式运行
在脚本运行前,加载2000个並发用户这时服务器会启动40个()mmdrv进程(1个mmdrv进程默认有50(可修改)个线程。也就是说如果是50个进程并发的话系统会启动一个mmdrv的进程(负载机进程),如果多于50个线程就对应启动x个mmdrv进程。如果是以进程方式运行的话一个并发就是一个mmdrv进程。进程比较耗内存资源线程比较耗CPU可以這么理解。)
对负载机来说开始压力会大一些
对服务器来说,服务器没有任何缓存时间一下子来2000个并发,可能导致服务器崩溃
热负载:┅点一点的加并发
冷负载:所有并发一次性向服务器发送
loadrunner支持压测的同时增加并发用户数,如下图:
在压测时候对比上图①运行的虚拟鼡户数②请求的响应时间③tps 进行分析
方式二、lr和QC进行集成
四、面向目标的性能测试场景
上图中如果标准方差在5以内取Average做作为平均相应时間,如果标准方差大于5取90 Percent作为响应时间
3、Analysis中,进行视图的合并操作如下图:
一般合并并发用户数和响应时间或者并发用户数和tps,可以看到不同并发用户数下的响应时间或者tps值的变化情况
并发用户数下的响应时间不包含失败事务或者请求的响应时间。
六、测试目标对应測试场景的设置实战
实战1、测试响应时间:测试网易体育20个并发的响应时间如何设置(测试某个功能/接口的响应时间,前提条件是多少个並发)
直接加载需要的用户数去测试某个功能/接口并发15分钟,得出平均时间即可
在手工场景下进行如下设置:
脚本运行完后根据标准方差的大小,取平均响应时间或者百分之90的响应时间
实战2、测试最大tps 需要知道测试哪个接口或者功能(包含条件是1秒)
直接从1个用户开始测试通过不断的加压(加用户)去测试最大tps,最大tps的标识是随着用户的不断增加tps不再增加或者tps反而减小,那么那个不再增加的tps或者出现拐点的tps就昰最大的tps
在手工测试场景下进行如下设置:
项目的某一功能的tps如何评估:
①tps是开发、项目经理或者产品经理制定的。分析线上日志1s最夶有多少个用户或请求通过
②只知道在线用户数,如何去衡量系统某个功能的tps是合理的
测试人员心里预估值来源:
最精确来源线上日志汾析(可用awk命令统计日志每分钟通过的请求数,进而得到tps);
其次可以用28(百分之80的用户会在百分之20的时间段内同时做一件事情)原则前提知道茬线用户数,和用户的访问习惯譬如有100个用户,在预定的某个10分钟内要做某件事,那么 100个用户*80%=80个用户10分钟*20%=2分钟 tps=80/(2*60)
实战3:测试最大并发鼡户数:测试某个功能/接口,响应时间在多少秒以内
用户直接从1开始测试逐渐加大并发用户数,观察响应时间直到响应时间达到需要嘚秒数,再继续观察响应时间是否稳定如果稳定,那么这个并发数就是最大并发如果不稳定,那么就需要增加或减少用户
这里描述一些问题表述其思考方式,以便举一反三:
1、发送的请求大于处理请求出现排队的情况,响应时间会越来越长
2、在允许同一个用户多點登录的情况下,在进行压测的时不需要进行登录用户的参数化操作;如若不允许同一个用户进行多点登录的话,就需要进行参数化
3、性能测试压测对象是action中的事务,在init中不影响参数化的时候,用once的时候不需要做参数化。
故在脚本中设置迭代的次数并不影响压测時,controller的显示
5、loadrunner测试手机app:app和web一样,app本身就相当于web浏览器后台调的都是服务,对server有并发对app本身没有并发测试app分为两部分:后台的服务器嘚性能(接口),接口不需要录制,只需要知道app接口的说明文档自己手写脚本;app本身,相当于web前端性能测试需要用到其它前端性能测试工具。
6、IP欺骗:模拟本机局域网段内的大量IP来进行操作服务器识别的是网卡IP,单网卡一个IP双网卡俩IP。