-
6种常见性能测试设计方法
-
-
普通性能场景设计
-
阶梯性能场景(负载测试场景)
-
压力测试场景
-
面向目标场景(loadrunner很容易,但是jmeter比较复杂)
-
混合场景设计(混合,if条件)不同数量的人,向不同的接口发起请求
-
有时间规律场景
-
-
一 普通性能场景
-
-
先了解性能测试需使用的组件
-
线程组
-
1 线程数: 模拟的并发用户数量
-
线程数,有没有限制呢?
-
jmeter本身是没有对线程数做限制
-
但是, jmeter启动这些并发用户数时,需要消耗资源,受电脑cpu的主频限制,一台电脑不可能创建无限量的线程数
-
实际的情况,http协议的脚本,线程数,大概能 1500左右 2000个可能产生,但是可能会出错,1000左右比较保守,可能能产生。
-
也就是说,1台电脑,http协议脚本,保守估计是可以参数1000个并发用户数
-
如果你想模拟超过1000并发用户数,你可能需要考虑 分布式
-
-
-
-
2 ramp-up时间
-
启动所有线程数启动的时间(线程数在合理的范围)
-
在ramp-up时间结束点,所有的人会产生
-
在ramp-up时间内,是否均匀产出并发用户数,是不确定
-
在启动时间内,产生的并发用户数,一产生,就去发起请求
-
启动了并发用户,就会去发起请求,不同时间产生的并发用户数,与前面产生的并发用户数,调用的接口可能不一样
-
jmeter做性能测试,更多时候,使用的是,广义并发
-
ramp-up时间要大于等于1
-
-
线程数 + ramp-up时间,一般的设置(不是死的)
一个原则: ramp-up时间在总执行时间中,占比要很低
一般的情况,一个性能测试的总执行时间 几十秒钟 ~ 几十分钟
-
500以内并发用户, ramp-up 2~4s
-
500-1000 ramp-up 5s
-
>1000 ramp-up 5-8s
-
-
-
3 循环次数
-
默认必须大于等于1
-
循环次数,就是每个并发用户数要去执行的请求数量
-
复习框 永远 一直循环,直到你点击停止,才会停止
-
永远要与 调度器 一起使用
-
必须把两个勾 都勾选
-
调度器:
-
持续时长
-
启动延迟
延迟启动,用于定时开始任务,一般不使用
-
-
- 在取样器错误后要执行的动作
-
场景:
-
30个并发用户,持续运行300s
-
-
-
聚合报告: avgRT: 2.945s 90%RT:3.748s avgTPS:10.1
-
响应时间图
-
-
-
结论:
-
90%RT:3.748s 可以看到,这个响应时间是比较长,已经超过了我们用户能容忍的范围了,用户满意度指数1.5s,说明我们的接口响应比较慢。
-
30个人, avgTPS: 10.1 tps<用户数 那么,每个人1秒钟发不了1个请求,所以,我们次数 30个并发用户数,已经超过了我们项目这个接口能承受最大并发用户数了。
-
可以简单得到一个结论: 服务器注册接口最大并发用户数小于30的
-
-
-
-
负载测试性能场景--脚本
-
负载测试: 逐步增加并发用户数
-
插件安装,
-
插件管理: jpgc 安装这个插件
-
用 5秒钟 增加10个并发用户数,持续运行30秒
-
阶梯线程组: 负载测试
-
负载测试: 逐步增加并发用户数
-
增加的量(步长),可以相同,也可以不相同
-
-
相同只是一种特殊请求 stepping threads group
-
不相同的增量,不能用stepping threads group
-
-
-
-
在阶梯线程组,执行过程中,我们的并发用户数是时刻发生变化
-
阶梯线程组设计的规律:
-
缓起步,快结束
-
快结束: 并不是瞬间结束
-
-
-
聚合报告:
-
阶梯线程组可以看聚合报告吗?
-
聚合报告中的数据,都是 平均值
-
在负载场景(阶梯场景),不看聚合报告
-
聚合报告是可以看到 失败率
-
-
-
-
负载测试性能测试
-
-
-