全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)

目录:导读

    • 前言
    • 一、Python编程入门到精通
    • 二、接口自动化项目实战
    • 三、Web自动化项目实战
    • 四、App自动化项目实战
    • 五、一线大厂简历
    • 六、测试开发DevOps体系
    • 七、常用自动化测试工具
    • 八、JMeter性能测试
    • 九、总结(尾部小惊喜)


前言

负载测试性能场景–阶梯式

回顾一下负载测试的概念: 负载测试是逐步增加并发用户数,找到性能拐点。 关键词是“逐步增加并发用户”。

那么要做到逐步增加,肯定不能使用普通的线程组,不然每次增加用户数都得手动改一次线程数,那得改到什么时候。

所以这里就需要用到插件:jpgc
使用插件管理器,找到jpgc - Standard Set 插件并安装

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第1张图片

然后添加新的线程组,但这里不是再添加普通的线程组了,而是添加jp@gc - Stepping Thread Group (deprecated)

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第2张图片

This group will start:线程组最大启动的用户数;
First,wait for:首次启动用户时,将等待多少秒后才开始启动;
Then start:首次启动多少个用户数;
Next,add; every:这是一个组合,意思是接下来每次启动N个用户后持续运行N秒。Next,add是指每次启动的用户数,every是指持续运行时间
using ramp-up:每次启动用户的时长,其实就是在多少秒内启动多少个用户数;
Then hold load for: 所有用户启动后持续运行N秒;
Finally, stop; every: 这也是一个组合,意思是每个N秒停止N个用户;

场景实战

接下来就是实战了,利用负载测试找到性能的拐点。

举例,现在不知道当前系统或接口的性能拐点在哪,那么可以设置:一开始运行10个用户,然后每运行1分钟后增加10个用户,直到增加到50个用户后持续运行120秒,最后每秒停止10个用户。

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第3张图片

另外由于现在使用的是阶梯性能场景,这个场景下是无法用聚合报告的,因为聚合报告是要计算持续时间内的平均值,一旦并发用户数改变了,这个平均值就不准确了。

所以这里使用到另外的监听器

jp@gc - Active Threads Over Time: 随着时间变化的并发用户数

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第4张图片

jp@gc - Response Times Over Time: 随着时间变化的响应时间图

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第5张图片

jp@gc - Transactions per Second: 随着时间变化的TPS图

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第6张图片

上面的三张图由于不像聚合报告有具体的平均值,所以在看的时候可能对平均值的把握不会太准确。

但这个其实影响并不大,首先从上面三张图片可以看出: 随着并发用户数的增加,响应时间也在增加,有很明显的上升趋势;

而TPS的图由于波动比较大,不好判断中心线在哪,但其实也可以发现随着并发用户数的增加,TPS的波动幅度会越来越大。

经上述结果,可以简单得到一个结论是,当前系统的性能拐点大约在20~40个并发用户之间。

这还没完,在实际工作中,如果得到一个范围值且范围值符合业务期望值时,最好是根据当前范围值继续压,尽可能找到粒度尽可能小的数值,范围值一旦过大,对未来的性能测试并不能做到一个参考标准,那这次的性能测试基本就是白费了。

如当前系统的拐点大约在20~40个并发用户之间,那么可以设置为:一开始运行20个并发用户,每隔60秒后启动5个并发用户,直到启动到40个并发用户后,持续运行120秒。

以此类推,尽可能找到粒度尽可能小的值,而这个值就是最大的并发用户数。

备注
负载测试场景使用的阶梯线程组有一个弊端,它每次增加的并发用户数总是相同的,然而实际情况中,我们的并发用户数是时刻发生变化的,也正因如此,上述的这个线程组后面是标识了“deprecated”,意思就是这个线程组已经不推荐使用了,因为它只能解决这种单一的性能测试。其它在后面会讲到解决这个问题。

另外,阶梯线程组设计的规律:
缓起步,快结束;因为突然间一瞬间大量请求发给服务器,服务器可能会崩,在做负载测试阶段并不推荐做这种测试,后面再讲这种瞬间大量请求的场景该怎么设计。

压力测试性能场景

压力测试的关键词是:长时间、稳定的。

压力测试的并发用户数有两种选择:
最大并发用户数的20%;
最大并发用户数的80%;

根据情况来选择即可。

接下来是关于场景的设置,压力测试的场景设置不限制使用线程组,因为通常情况下压力测试的并发用户数是不变的,因此用普通线程组还是阶梯线程组都可以完成。

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第7张图片

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

一、Python编程入门到精通

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第8张图片

二、接口自动化项目实战

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第9张图片

三、Web自动化项目实战

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第10张图片

四、App自动化项目实战

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第11张图片

五、一线大厂简历

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第12张图片

六、测试开发DevOps体系

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第13张图片

七、常用自动化测试工具

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第14张图片

八、JMeter性能测试

全网火爆,Jmeter性能场景设计 - 压力负载测试性能场景+分析性能指标(二)_第15张图片

九、总结(尾部小惊喜)

懒惰是意志薄弱者的隐藏所。人的活动如果没有理想的鼓舞,就会变得空虚而渺小。告诉你一个宝藏的地点,它就在你的生命里。

要想改变命运,首先改变自己。今天的成功是因为昨天的积累,明天的成功则依赖于今天的努力。成功需要一个过程。命运掌握在自己手里,命运的好坏由自己去创造。

用鞭子抽着,陀螺才会旋转。成功需要付出代价,不成功需要付出更高的代价。宁可失败在你喜欢的事情上,也不要成功在你所憎恶的事情上。

你可能感兴趣的:(jmeter,软件测试,性能测试,jmeter,性能测试,软件测试,jmeter性能测试,压力测试)