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

发表于:2020-11-20 10:00

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:星空6    来源:博客园

  业务需求
  假设公司领导现在给你分配了一个性能测试需求如下:
  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;
   
      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号