jmeter性能测试场景记录

一.普通性能场景设计

线程数：jmeter本身对线程数没有限制,但是jmeter钱这些并发用户数的时候，需要消耗资源，收到 电脑spu的主频限制，一条电脑不可能无限制的启动线程数，实际情况下，http协议大概可以产生1500左右，保守一点是1000左右，如果要模拟超过1000的并发线程数，可能需要考虑分布式。
ramp-up：启动所有线程数的时间，500以内的并发用户，ramp-up 大概是2-3秒；500-1000 ramp-up大概是5秒；大于1000 ramp-up大概是5-8秒；一个原则：ramp-up时间在总的执行时间中占比要很低。
循环次数：默认必须大于1。
一个简单的例子：并发用户数是40，运行1分钟，看到吞吐率没有网络瓶颈，所以聚合报告中的吞吐量等于tps

tps是9.7左右，并发用户数是30，吞吐量小于用户数，说明每秒不能处理一个请求，这个接口的tps较低；
90%的响应时间是3.035秒已经超过用户满意度指数1.5s所i响应时间有点慢；
由此得出此用户的并发用户数小于30

二.阶梯性能场景设计（负载场景设计）

应用场景：如果接口从来没有做过性能测试，不知道一些指标信息，可以使用负载场景测试逐渐增加并发用户数来找出性能瓶颈。逐步增加并发用户数，是缓起步快结束，并不是瞬间结束
测试前的准备：使用jmeter中的插件安装jp@gc插件的安装并重启jmeter
负载测试的执行：添加线程组–jp@gc Stepping Thread Group

这个配置的测试场景是从0线程组进行增加，每次增加1个线程组，达到一个线程组就持续运行30秒时间，然后知道达到最大的线程数10，持续运行60s时间，最后在5s内将线程停掉看测试结果
添加监听器有三个,三个图要结合一起看：
jp@gc -Active Threads Over Time:查看并发用户线程的变化
jp@gc -Transactions per Second:查看tps的变化趋势图
jp@gc -Response Times Over Time:查看响应时间的变化


三个图结合一起看下，可以看到并发数是10，tps发改是在18左右，响应时间0.5s左右，所以通过上面三张图可以看到并发数10是完全可以达到的，tps也大于18。
注意：
（1）jp@gc -Transactions per Second这个图表可以看到tps的变化趋势，也可以看到失败的数据
（2）jp@gc -Response Times Over Time这个图可以看到响应时间的变化，如果响应时间是一条直线的时候此时大部分是因为接口超时了。
（3）负载测试是不可以看聚合报告的，因为聚合报告中的线程数要一样，所以阶梯性能长江不能看聚合报告

三.压力测试场景设计

应用场景：通过负载测试找到对应的性能的最大并发用户数，然后设置最大用户数的20%和80%进行长时间的测试。
执行测试：普通线程组设置持续时间即可，持续时间设置久一点。

四.面向目标场景设计

应用场景：期望项目的接口达到多少tps，或者期望项目的接口达到多少并发用户数，这种即是面向目标场景的性能测试场景。
场景一：面向多少tps：期望我项目的接口都要满足50tps，中小企业如果日均访问量是千万，基本50tps就可以满足了。
执行测试：添加线程组–bzm-Arrivals Tjread Group

Target Rate(arrivals/sec)：目标的tps值
Ramp Up Timde(sec)：达到这个目标tps的总时间
Ramp-Up steps Count：分几次达到这个目标值
Hold Target Rate Time：达到目标值以后持续运行多久



分析：从上面三张图可以看出来，tps达到50tps以后，并发用户数再160左右，但是响应时间是一条直线并且时间都大于3s，所以这个接口的性能达不到50tps。
举个例子：要做一个秒杀，能支持1000个人同时秒杀，我们的系统不能崩溃怎么设计性能场景？？1000个人访问我们系统持续运行，系统不能崩溃，用户对秒杀的理解，我要在1秒钟内收到处理结果1000tps转换为面向目标的场景。
场景二：面向多少并发用户数/线程数
执行测试：添加线程组-bzm-Concurrency Thread Group

Target Concurrency：目标的并发用户数
Ramp Up Timde(sec)：达到这个目标的总时间
Ramp-Up steps Count：分几次达到这个目标值
Hold Target Rate Time：达到目标值以后持续运行多久



测试结论：并发用户数设置80以后，tps大概是60左右，小于并发用户数，并且响应时间在3s左右近似一条直线，可以判断接口超时了，所以这个接口的并发用户数达不到80。

五.有时间规律场景（波浪型场景）

应用场景：比如点餐系统饭点会比较频繁调用，打卡的时候指定时间点会频繁使用

执行测试：添加线程组–Ultimate Thread Group
start_threads count：达到的总的线程数

Initial Delay：起始的时间（如果是第二行新增的起始时间应该是上一行所有时间之和）

Startup Time：达到线程数的总时间

Hold Load For：持续运行的时间

六.混合场景测试

应用场景：接口1线程数是10，接口2线程数是20，接口3线程数是30，并且接口之间有关联，分别设置三个线程组，每个线程组的线程数不一样，三个线程组之间传参可以跨线程组传参
执行测试：有两个接口一个是登录接口并发用户数是80，另外一个是商品查询6合一接口并发用户数是18怎么设计性能测试场景？？
分析：商品6合一接口要使用到登录接口的token，所以要将token设置成jmeter的属性进行跨线程组进行调用。
（1）编写登录的接口，并且根据响应结果使用json提取器将对应的token进行提取出来

（2）使用函数助手将提取的token应用setProperty函数给设置成jmeter的属性

（3）将这个属性通过P函数将对应的值取出来用于下一个线程组的接口中

（4）将登录接口的线程数设置成80，将商品6合一接口的线程数设置成18，并且添加监听器进行查看

（5）执行对应的性能测试

登录接口的测试结果图如下

性能测试结论：响应时间在1s左右，对应的tps大概在85左右，所以这个接口的并发数可以达到80，tps可以达到85，还可以继续进行往上施压进行测试。

商品6合一接口对应的性能测试结果如下图：



测试结论：并发数是18，对应的响应时间是1.2s左右。tps在20 左右，所以这个接口的性能是可以达到18并发数，tps可以达到20，性能还可以继续往上进行施压得到更好的数据。

七.拓展知识

   在性能测试过程中，能不启动监听器则不启动，但是没有监听器我们怎么知道性能测试结果？？

（1）生成jmeter的html报告，与是否启用添加监听器无关

（2）添加结果数将测试结果存储在文件中

（3）运行完成以后，可以使用jmeter中的工具–Generate html report功能将刚刚生成的结果文件保存成html文件格式进行打开

————————————————

                        版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.youkuaiyun.com/weixin_44249280/article/details/133133122