JMeter根据负载量计算并发用户数实例

目录

       前言：

　　业务需求

　　分析需求

　　测试模型构建 & 用例设计

　　一、场景构建：登录业务操作流程、考勤打卡操作流程；

　　二、场景用例设计

　　三、测试脚本用例设计：

　　模型构建

　　登录打卡-操作流程：

　　场景设计

　　常用测试场景的类型:

---

       前言：

JMeter是一款常用的性能测试工具，通过模拟真实用户场景来测试系统性能。在进行测试前，需要确定所需的并发用户数，以保证测试的可靠性和准确性。

　　业务需求

　　假设公司领导现在给你分配了一个性能测试需求如下：

　　1：公司有1000人在上班时间段会登录平台进行打卡操作，可能会登录打卡多次

　　2：业务高峰时间段在8:00-8:30，半小时

　　3：需要保证90%用户的响应时间在1s以内

　　4：保证在半小时内支撑5000笔打卡业务完成，同时90%业务时间不超过1s，半小时内最大系统并发数能达到多少？每秒最大用户并发能达到多少？

　　分析需求

　　a.1000人在30分钟内完成登录，那么每分钟有1000/30=33的人登录，每秒有0.56人登录，也就是2s中有1个人登录；

　　b.5000笔打卡业务在30分钟内完成，那么每秒中需要完成5000/(30*60)=2.78个打卡事务；

　　综合就是半小时内，每2s有一人登录，每秒需有3个打卡事务；也就是线程持续时间30分钟，打卡tps=3；

　　循环一次，登录317ms+打卡976ms=1293ms，1s中可迭代0.77次；30分钟可迭代1392次；登录请求1个线程即可满足要求；

　　30分钟想完成5000笔打卡，需并发线程5000/1392=3.6 即4个线程；　

　　实际请求中，还需要考虑登录时输入账户密码的时间，可加定时器；

　　测试模型构建 & 用例设计

　　这种需求是典型的根据负载量计算并发数的场景。首先我们需要设计一下业务场景；

　　一、场景构建：登录业务操作流程、考勤打卡操作流程；

　　二、场景用例设计

　　1.测试场景类型：

　　单业务基准测试、单业务压力测试、单业务负载测试；

　　综合业务基准测试、综合业务压力测试、综合业务负载测试；

　　2.业务量线程数的确定：

　　登录业务-线程数确定、考勤打卡-线程数确定；

　　3.测试场景用例设计：

　　登录并发-场景用例、登录业务量-场景用例、并发考勤-场景用例、考勤打卡业务量-场景用例；

　　三、测试脚本用例设计：

　　登录-脚本用例、考勤打卡-脚本用例；

　　模型构建

　　登录业务-操作流程

　　a）访问登录页面；

　　b）输入账号、密码，点击【登录】，跳转到主页；

　　c）点击【退出】，跳转到登录页面；

　　登录打卡-操作流程：

　　a）访问登录页面；；

　　b）输入账号、密码，点击【登录】，跳转到主页；

　　c）点击【考勤管理】，进入考勤主页；

　　d）点击【打卡】；

　　e）进入考勤打卡页面，查看打卡记录；

　　e ）点击【退出】，跳转到登录页；

　　场景设计

　　性能测试过程中，首先应该设计测试场景，然后针对场景设计脚本。为了真实反映被测对象的性能问题，需要尽可能模拟出被测对象可能发生瓶颈的业务场景。然后设计针对业务的测试场景；

　　常用测试场景的类型:

　　性能测试通常有几种常用测试场景：单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试；

　　1）基准测试

　　测试某个具体业务是否满足系统设计 或 用户期望的性能指标；基准测试可以为并发基准、业务量基准；

　　如，期望登录接口支持500个用户并发登录，同时响应时间不超过需求值。满足则认为基准测试完成，否则失败；

　　2）压力测试

　　测试某个具体业务在最大负载下，持续服务的时长，以此验证被测业务的稳定性；

　　压力测试过程中所设计的负载，是以系统基准测试为标准，如登录接口最大并发为500个并发，则压力测试的负载设计为500个；通过运行时长的变化，验证服务器在系统最大负载下持续服务的能力；

　　3）负载测试

　　测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数；

　　如系统基准测试最大并发为500个，则通过多次测试，逐步加大负载，最终获得被测业务的最佳负载。在最佳负载下，系统需要满足各项性能指标；

　　登录打卡345ms*5=1725ms

　　加了事务控制器后，登录打卡1397ms

　　实际情况，还需要考虑以下情形的思考时间，如：

　　用户输入用户名、密码：5s；

　　打开考勤后等待时间：2s；

　　用定时器模拟思考时间；

　　那么一次登录打卡需要时间（t）为1.397+5+2=8.397s；

　　那么30分钟(T)可以迭代登录打卡的次数=30*60/8.397=214.36；实际需要5000笔业务数；

　　需要设置的线程数=5000/214.36=23.32，为了保证>=5000笔业务数，所以线程取24；线程数=5000/(60*T/t)=5000*[t/(60*T)]

　　由此可以得出：Thread = BC*[t/(60*T)]，

　　BC：业务数/业务量，本例中 BC=5000 ；

　　t：单用户单次业务消耗时间，尽可能模拟真实用户的真实行为，本例中 t=8.397s；

　　T：考察时长，本例中 T=30分钟；

　　关于Thread，这里计算的是需要的线程数，事实上这个公式计算的是单位时间平均并发数。就是单位时间内有多少用户或者线程并发向服务端发起请求；

　　假如登录打卡业务场景，计算的是24.

　　在jmeter中表示需要系统平均需要24个线程同时发起请求才能在对应的时间段内支撑对应的业务量；

　　在真实的用户场景中，则表示平均每秒最大支撑24个用户同时发起请求才能在对应的时间段内支撑对应的业务量；

　　这个计算的是评价并发

　　对应的峰值并发：Thread_Max = Thread + 3*根号Thread

　　如果平均并发是24的花，那么Thread_Max = 24 + 3*根号24 = 38.7，每秒的并发用户峰值大约是39。

作为一位过来人也是希望大家少走一些弯路，在这里我给大家分享一些自动化测试前进之路的必须品，希望能对你带来帮助。（WEB自动化测试、app自动化测试、接口自动化测试、持续集成、自动化测试开发、大厂面试真题、简历模板等等），相信能使你更好的进步！

留【自动化测试】即可