1、事物
1)概念
loadrunner里响应时间指的是事物的响应时间、TPS指的是每秒通过的事物数,因此事物是loadrunner跑脚本的基础。事物是用来计时用的,把一个或多个请求圈起来放在一起,统计这一个或多个请求的时间。
2)定义事物时保证事物的准确性(干净)
● 一个事物里就放一个被测请求,这样事物响应时间就是请求响应时间;
● 除了被测试请求外,事物中不放任何其他东西,检查点、集合点全放在事物外面;
● 录制时用纯的URL,这样一个URL就是一个请求;
● 修改录制脚本中Mode=“HTTP”;
3)单场景压测与混合场景压测
● 单场景测试:先测单个接口是否满足要求,不用考虑其他依赖
● 多场景测试:对多个接口共同进行压测
问题1:对于用户来说,用户要注册必须得先进入首页,要压测注册请求是不是要模拟用户的实际操作来压接口?
要压注册不用脚本中不用加首页,单场景压测脚本的干净性会影响响应时间和TPS,如同样是压注册,小A的脚本里有首页和注册两个请求,小B的脚本里只有注册。同样运行5分钟小A的注册TPS肯定会小于小B的注册TPS。
问题2:单个场景压测,用户操作注册动作,除了注册单个API,还有js、css等请求也会对服务器有压力,怎么处理?
Js、图片、css样式都不用管,一方面有专门的前端性能测试会去测试,另一方面现在都是采用缓存技术,访问一次这些图片等静态资源资源全部缓存下来了,后面发的都是纯的接口请求。
4)添加事物
● 可录制时加事物也可录制完成后再添加事物,录制时添加事物,容易有冗余,不干净;
● 录制完后加事物,可ctrl+T,也可点击下图图标
● 录制时加事物,点击如下图标
2、检查点
1)概念
检查点的实质是从请求的response里判断有没有返回某个字符串,从而判断请求有没有成功。
压测要保证请求的成功率,检查点会影响请求成功率,通常与金钱相关的要求成功率为100%,其他的为99%、99.9%、99.99%,视具体项目而定。
2)什么情况下加检查点
问题1:脚本中一定要加检查点吗?
检查点影响性能,不必要的检查点不加。
问题2:如何确定是否要加检查点?
● 数据库的add、update、delete操作不用检查点(跑完数据库查);
● 数据库的查询操作一定要有检查点;
3)添加检查点
3、集合点
1)概念
当通过controller虚拟多个用户执行该脚本时,用户的启动或运行步骤不一定都是同步的。集合点是在脚本的某处设置一个标记,当有虚拟用户运行到这个标记处时,停下等待,直到所有的用户都达到这个标记处时,再一同进行下面的步骤。这样能够用最大的用户并发去做下面的操作,就像集合再前进一样。集合点是为加大瞬时并发的概率,通常抢购、秒杀会用到。
2)插入集合点
4、思考时间
1)概念
控制单位时间段内向服务器发起请求的数量,以达到控制服务器压力的目的,从而影响测试的响应时间以及tps。
2)Run-time setting中开启think time
3)思考时间如何影响响应时间
例1:已知注册TPS=1,RT=1s,分别以1个vu和两个vu跑,RT分别为多少?
1个并发时,RT=1
2个并发:
vu1_1 RT=1s----vu2_1 RT=2s(1s等待+1s处理)
vu1_2 RT=2s(1s等待+1s处理)----vu2_2 RT=2s(1s等待+1s处理)
vu1_3 RT=2s(1s等待+1s处理)----vu2_3 RT=2s(1s等待+1s处理)
......
可以看出当时间足够长时,2个并发RT=2
例2:已知注册TPS=1,RT=1s,脚本中注册前加思考时间1s,分别以1个vu和两个vu跑,RT分别为多少?
1个并发时,RT=1
2个并发:
vu1_1 RT=1s----vu2_1 RT=1(思考时间1s,刚好把等待时间耗完)
vu1_2 RT=1s(思考时间1s)----vu2_2 RT=1s(思考时间1s)
vu1_3 RT=1s(思考时间1s)----vu2_3 RT=1s(思考时间1s)
......
可以看出当时间足够长时,2个并发RT=1s
4)思考时间如何影响TPS
假如TPS很大,单位时间内发的请求越多,TPS就越大。那么加思考时间会让单位时间内发送的请求数变少,从而使TPS减少。
例:服务器tps=100,每次处理时间为0.1s
1个vu,1s能发10个请求,则tps=10
1个vu,思考时间1s,处理1s,则tps=1
TPS 简单说明
* 1s是按过去的上一秒算的,过去1s内处理的事物数,
* tps忽略思考时间,只算处理时间
5)添加思考时间
更多内容欢迎关注微信公众号查看