业务需求
（转载自）https://www.cnblogs.com/canglongdao/p/12620948.html
假设公司领导现在给你分配了一个性能测试需求如下：
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个线程；
实际请求中，还需要考虑登录时输入账户密码的时间，可加定时器；
参考：https://testerhome.com/articles/21163，最终汇总如下：
测试模型构建 & 用例设计
这种需求是典型的根据负载量计算并发数的场景。首先我们需要设计一下业务场景；
一、场景构建：登录业务操作流程、考勤打卡操作流程；
二、场景用例设计
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；
尴尬了，跑了2次，均未到达5000业务数，无解ing