负载测试性能场景–阶梯式
回顾一下负载测试的概念: 负载测试是逐步增加并发用户数,找到性能拐点。 关键词是“逐步增加并发用户”。
那么要做到逐步增加,肯定不能使用普通的线程组,不然每次增加用户数都得手动改一次线程数,那得改到什么时候。
所以这里就需要用到插件:jpgc
使用插件管理器,找到jpgc - Standard Set 插件并安装
然后添加新的线程组,但这里不是再添加普通的线程组了,而是添加jp@gc - Stepping Thread Group (deprecated)
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个用户。
另外由于现在使用的是阶梯性能场景,这个场景下是无法用聚合报告的,因为聚合报告是要计算持续时间内的平均值,一旦并发用户数改变了,这个平均值就不准确了。
所以这里使用到另外的监听器
jp@gc - Active Threads Over Time: 随着时间变化的并发用户数
jp@gc - Response Times Over Time: 随着时间变化的响应时间图
jp@gc - Transactions per Second: 随着时间变化的TPS图
上面的三张图由于不像聚合报告有具体的平均值,所以在看的时候可能对平均值的把握不会太准确。
但这个其实影响并不大,首先从上面三张图片可以看出: 随着并发用户数的增加,响应时间也在增加,有很明显的上升趋势;
而TPS的图由于波动比较大,不好判断中心线在哪,但其实也可以发现随着并发用户数的增加,TPS的波动幅度会越来越大。
经上述结果,可以简单得到一个结论是,当前系统的性能拐点大约在20~40个并发用户之间。
这还没完,在实际工作中,如果得到一个范围值且范围值符合业务期望值时,最好是根据当前范围值继续压,尽可能找到粒度尽可能小的数值,范围值一旦过大,对未来的性能测试并不能做到一个参考标准,那这次的性能测试基本就是白费了。
如当前系统的拐点大约在20~40个并发用户之间,那么可以设置为:一开始运行20个并发用户,每隔60秒后启动5个并发用户,直到启动到40个并发用户后,持续运行120秒。
以此类推,尽可能找到粒度尽可能小的值,而这个值就是最大的并发用户数。
备注
负载测试场景使用的阶梯线程组有一个弊端,它每次增加的并发用户数总是相同的,然而实际情况中,我们的并发用户数是时刻发生变化的,也正因如此,上述的这个线程组后面是标识了“deprecated”,意思就是这个线程组已经不推荐使用了,因为它只能解决这种单一的性能测试。其它在后面会讲到解决这个问题。
另外,阶梯线程组设计的规律:
缓起步,快结束;因为突然间一瞬间大量请求发给服务器,服务器可能会崩,在做负载测试阶段并不推荐做这种测试,后面再讲这种瞬间大量请求的场景该怎么设计。
压力测试性能场景
压力测试的关键词是:长时间、稳定的。
压力测试的并发用户数有两种选择:
最大并发用户数的20%;
最大并发用户数的80%;
根据情况来选择即可。
接下来是关于场景的设置,压力测试的场景设置不限制使用线程组,因为通常情况下压力测试的并发用户数是不变的,因此用普通线程组还是阶梯线程组都可以完成。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
懒惰是意志薄弱者的隐藏所。人的活动如果没有理想的鼓舞,就会变得空虚而渺小。告诉你一个宝藏的地点,它就在你的生命里。
要想改变命运,首先改变自己。今天的成功是因为昨天的积累,明天的成功则依赖于今天的努力。成功需要一个过程。命运掌握在自己手里,命运的好坏由自己去创造。
用鞭子抽着,陀螺才会旋转。成功需要付出代价,不成功需要付出更高的代价。宁可失败在你喜欢的事情上,也不要成功在你所憎恶的事情上。