测试驿栈-由浅入深学性能 性能测试连载 (19)-负载场景模型构建
性能答疑 QQ 群:697244251
业务需求
假设公司领导现在给你分配了一个性能测试需求如下:
1:公司有 1000 人在上班时间段会登录平台进行打卡操作,可能会登录打卡多次
2:业务高峰时间段在 8:00-8:30,半小时
3:需要保证 90% 用户的响应时间在 1s 以内
4:保证在半小时内支撑 5000 笔打卡业务完成,同时 90% 业务时间不超过 1s,半小时内最大系统并发数能达到多少?每秒最大用户并发能达到多少?
需求分解
1:注册用户是 1000 人
2:业务时间段是半小时,也就是 30 分钟,1800s
3:需要保证 90% 业务响应时间在 1s 以内
4:需要测试半小时内的最大系统并发和每秒的最大用户并发数
测试模型构建 & 用例设计
这种需求是典型的根据负载量计算并发数的场景。首先我们需要设计一下业务场景
模型构建
选取的测试业务为:登录业务、考勤打卡业务。此两项业务对应的操作流程,如下:
1.登录业务 - 操作流程:
1)访问打开首页
2)点击【请登录】,跳转到登录页面
3)输入:用户名 + 密码,点击【立即登录】,跳转到首页
4)点击【退出】,跳转到首页
2.考勤打卡 - 操作流程:
1)访问打开首页
2)点击【请登录】,跳转到登录页面
3)输入:用户名 + 密码,点击【立即登录】,跳转到首页
4)点击考勤打卡,跳转到考勤页面
5)点击考勤
6)点击【退出】,跳转到登录首页
场景设计
性能测试过程中,首先应该设计测试场景,然后针对场景设计脚本。为了真实反映被测对象的性能问题,需要尽可能模拟出被测对象可能发生瓶颈的业务场景。然后设计针对业务的测试场景。
常用测试场景的类型
性能测试通常有几种常用测试场景:单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试。
归属为 4 种测试类型:基准测试、压力测试、负载测试
1)基准测试
测试某个具体业务是否满足系统设计 or 用户期望的性能指标。
如期望登录接口支持 500 个用户并发登录,同时响应时间不超过需求值。满足则认为基准测试完成,否则失败。基准测试过程中,性能指标的任何一项均需成功,才认为基准测试完成。基准测试可分为并发基准、业务量基准,其目的都在于验证是否满足预期目标设定。
2)压力测试
测试某个具体业务在最大负载下,持续服务的时长,以此验证被测业务的稳定性
压力测试过程中所设计的负载,是以系统基准测试为标准,如登录接口最大并发为 500 个并发,则压力测试的负载设为 500 个。通过运行时长的变化,验证服务器在系统最大负载下持续服务的能力。
3)负载测试
测试某个具体业务能够承受的最大负载,验证被测业务能够承受的最大负载数
如系统基准测试最大并发为 500 个,则通过多次测试,逐步加大负载,最终获得被测业务的最佳负载。在最佳负载下,系统需要满足各项性能指标。
确定本次性能测试的场景主要有下面 4 个场景:
①登录并发基准测试
②登录业务量基准测试
③考勤并发基准测试
④考勤业务量基准测试
业务线程数确定
场景设计中需设置线程数,以本次测试为例,要求在 30 分钟内支持 5000 次用户登录。线程数计算方式如下:
Thread = BC*[t/(60*T)]
T: 考察的时间段,本例 T=30min
t: 单用户单次业务消耗时间,尽可能模拟用户的真实行为
BC: 业务量,本例 BC=5000
利用 JMeter 测试单次业务消耗时间
1)登录业务 - 线程数确定
利用抓包工具, 编写"登录,退出"的脚本。 收集聚合报告的数据,加了事物控制器,归总了一下整体事物,响应时间如下图
由上图数据结果可知,若采用 90% 采样,登录系统单次业务时间为:329ms。
实际情况下,还需要考虑模拟用户输入用户名及密码、登录成功后等待返回主页、退出后等待返回主页等操作的思考时间。作如下假设:
用户输入用户名及密码:5s用定时器模拟思考时间
则单用户登录退出所消耗时间为:0.329+5=5.329s
计算模拟 30min 时间、5000 次用户登录最大所需的线程数为:.
Thread = 5000×[5.329/(30×60)] = 14.80,取整为 15
2)考勤打卡 - 线程数确定
利用抓包工具, 编写"登录 - 考勤打卡"的脚本。 收集聚合报告的数据,加了事物控制器,归总了一下整体事物,响应时间如下图:
采用 90% 采样,用户登录后考勤打卡单次消耗时间为 1055ms
实际情况,还需要考虑以下情形的思考时间,作如下假定:
用户输入用户名、密码:5s
登录后在首页等待时间:5s
打开考勤后等待时间:3s
用定时器模拟思考时间
所以单用户登录后考勤的时间为:
5+5+3+1.055=14.055s
计算模拟 30min 时间、5000 次用户登录考勤打卡所需的线程数为:
Thread = 5000×[14.055/(30×60)] = 39.04,取整 39
关于公式的解释
上面抛出了一个公式:Thread = BC*[t/(60*T)]
关于 Thread,这里计算的是需要的线程数,事实上这个公式计算的是单位时间平均并发数。就是单位时间内有多少用户或者线程并发向服务端发起请求
比如上面的登录业务场景,计算的是 15,。
在 jmeter 中表示需要系统平均需要 15 个线程同时发起请求才能在对应的时间段内支撑对应的业务量
在真实的用户场景中,则表示平均每秒最大支持 15 个用户同时发起请求才能在对应的时间段内支撑对应的业务量
这个计算的是平均并发
对应的还有峰值并发:Thread_Max=Thread +3* 根号 Thread
如果平均并发是 15 的话,那么 Thread_Max =15+3* 根号 15 =21,每秒的并发用户峰值大约是 21