全网最全,Jmeter性能测试-90%响应时间/事务/并发(详解)


前言

1、90%响应时间

90%Line :
一组数由小到大进行排列,找到他的第90%个数(假如是12),那么这个数组中有90%的数将小于等于12 。

用在性能测试的响应时间,也就是90%请求响应时间不会超过12 秒。

例如:
某一次测试结果,每个sample的响应时间分别是:1、3、4、9、2、8、5、7、6、10,将其按由小到大将其排列为:1、2、3、4、5、6、7、8、9、10

那么它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line 就是9 。即90%响应时间是9ms,理解为:90%的用户请求时间不冲9ms。

另一测试结果,20个sample,响应时间分别为:
2、2.1、2.5、3、3.4、3.4、4、4、4、4、5、5、5、5.9、5.91、6.8、8、12、24、24.1 按由小到大将其排列。

求它的第90%百分位,第18个数是12 么,他的90%Line 就是12。

2、事务

事务的组织:
计算机术语中,事务应该具有4个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

扫描二维码关注公众号,回复: 15679055 查看本文章

在性能测试脚本设计中,事务的设置至少应该遵守原子性,即不可分割性。
如购物事务一般包括登录、查找商品、查看商品详情、加入购物车、结算几个步骤,每个步骤都缺一不可;

又比如转账业务(A账户向B账户转出50元),包括A账户-50元、B账户+50元两个步骤,每个步骤缺一不可。
再比如百度搜索,包括两步:打开百度首页,输入关键字搜索,两个步骤组成一个搜索事务。

A1

常用的场景:
事务=单个请求;
事务=思考时间+单个请求;
事务=多个相关联的请求;

如果事务中增加思考时间,运行结果统计的事务响应时间是包括思考时间的,所有场景的设计,脚本的设置,对测试结果是有影响的,具体需要根据需求进行设计。

项目举例

项目1:
需求:测试一个系统的TPS
分析:该系统包含多个功能点,选择主要的功能点进行压测
设计:每个功能点设计为一个事务,每个事务包含N个请求,通过脚本描述。

项目2:
需求:有一个接口,用于跟踪用户行为,一旦用户登录就上传用户的登录时间。要求:测试一下性能看能撑多少用户同时在线。
分析:单个接口(请求)无需事务概念

项目3::
需求:测试一下某个电商系统能同时支持多少用户下单并购买成功
分析:业务是下单并购买,包含多个请求,需要组织成事务

3、TPS

TPS、TPM、QPS、PV
pv:是指页面被浏览的次数,比如你打开一网页,那么这个网站的pv就算加了一次;
tps:是每秒内的事务数,比如执行了dml操作,那么相应的tps会增加;
tpm:是每分钟的事务数。
qps:是指每秒内查询次数,比如执行了select操作,相应的qps会增加。

不同的应用系统tps,qps是没有可对比性的。
例如:
应用A,每个select查询需要1ms, 一个connection的话,一直不停的执行,1S内 可执行1000次,也就是1000qps;
应用B,每个select查询需要100ms, 一个connection的话,一直不停的执行,1S内 可执行10次,也就是10qps;

上面不同系统的两个qps是无法对比的,不能说哪个好哪个坏。

TPS的作用
例1:
某单个接口,tps=10,希望这个接口每天能处理100万个请求,问能否满足?
每分钟处理6010=600个请求;
每小时处理600
60=36000个请求;
每天处理24*36000=864000个请求;
不能满足需求

例2:
希望某个接口每天能处理200万个请求,问TPS至少应该达到多少?
2000000/243600=28

例3:
钉钉打开系统,9:00上班,8:30-9:00期间打开,一般集中在30分钟。
公司500人,平均每个员工打卡1.6次(有人怕没打上会再打),算一下TPS多少能支撑目前的应用不挂?
tps=5001.6/3060=0.44

如果是10分钟以内打完卡
tps=5001.6/1060=1.3

如果是集中在最后一分钟
tps=5001.6/160=13

假设现在一台服务器的tps是7,那么至少需要2台服务器
这两台服务器平时都很闲,只有上下班时才忙,该如何设计?(类似的还有新浪微博,流量激增时可能需要1000台,平时500台即可)
使用动态扩容,热点警告

常用的应用场景:
tps常常是有限制的,如cpu<80%,内存<60%时的tps
cpu使用率和内存占用率往往是默认的或取经验值

容量测试:一般可设置运行1小时

压力测试:一般可设置10分钟

稳定测试:724小时、524小时

很不明确的需求:一般测试最大TPS

4、常见问题
如果某一次测出的TPS非常小,怎么办?

可能的原因

1)服务器处理能力本如此

2)负载机的用户数没发出去,如给10个用户,只发了3个用户。如果是这种情况,可以用siege试一下

3)如果这时的CPU和内存占用也很小,可能是网卡满了

5、性能调优的本质
拿时间换空间
拿空间换时间
时间:响应时间

空间:缓存

4、并发

并发量怎么理解?
测试计划包三个线程组,分别如下:
线程组1:线程数200,Ramp-Up Perios200秒——每秒并发1
线程组2:线程数200,Ramp-Up Perios100秒——每秒并发2
线程组3:线程数200,Ramp-Up Perios10秒——每秒并发200

测试计划运行时是同时运行的,无delay。

并发分析:
前10秒:200+1+2=203
10秒到100秒:1+2=3
最后100秒:1
第0秒:user1被创建,执行所有的samples用了10s,并发1
第1秒:user2被创建,执行所有的samples用了10s,并发2(user1+user2)

0秒——10秒,并发量递增1.2.3…10
第10秒:user1执行完退出,user11被创建,并发量10
第11秒:user2执行完退出,user12被创建,并发量10

10秒——200秒,并发量稳定保持在10
所以,一个用户的存活时间可以影响并发。jmeter报告中一般会有一个平均并发数

实际案例

某场景要求:100个用户,希望每秒并发数是100。该怎么做?
100用户,20s释放,逐渐加压;
用户创建后不让其退出,循环次数设置为永远;
这样第20秒时,肯定能达到100并发,更加精确;

所以如果要精确控制并发量的话,建议thread不退出(永远循环),通过调度器设置运行时间。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

请添加图片描述

二、接口自动化项目实战

请添加图片描述

三、Web自动化项目实战

请添加图片描述

四、App自动化项目实战

请添加图片描述

五、一线大厂简历

请添加图片描述

六、测试开发DevOps体系

请添加图片描述

七、常用自动化测试工具

请添加图片描述

八、JMeter性能测试

请添加图片描述

九、总结(尾部小惊喜)

只有不断超越自己的勇气和毅力,才能在人生的征途中闪耀出属于你的光芒。无论前路如何艰辛,努力奋斗,坚持追求,你将成为梦想的主宰者,书写属于自己的辉煌篇章。

只有不断超越自己的勇气,才能成就辉煌的人生航程。无论前路多么曲折,心怀梦想的你,请坚定地迈向每一步,永不放弃,终将成就非凡的未来。

只有拼尽全力,才能让梦想破茧成蝶;只有不断进取,才能让希望绽放光彩;只有坚持不懈,才能让努力变得更加美丽。奋斗吧,因为你值得拥有更好的未来!

猜你喜欢

转载自blog.csdn.net/shuang_waiwai/article/details/131724598