我们在性能测试过程中，首先应该去设计测试场景，模拟真实业务发生的情境，然后针对这些场景去设计测试脚本。为了暴露出性能问题，要尽可能的去模拟被测对象可能存在瓶颈的测试场景。

　　我在本地部署了一个项目，可以用来模拟考勤打卡

性能测试之前我们要设计一下场景：

业务流程：

打卡首页--点击登录--跳转项目--打开考勤页--考勤打卡

业务预期的日常考勤量为400/min,也就是6.6/s

性能需求指标：

计算出需要加载的线程数：

Thread = BC/(60/t) = BC*(t/60)
t：单用户单次业务消耗时间，尽可能模拟用户的真实行为
单次消耗时间=打开主页(0.5s)+思考时间(3s)+输入用户名密码(1.5s)+主页响应时间(0.5s)+考勤打卡时间(3s)=8.5s（90%线）
BC： 业务量，本例 BC=400
单次消耗8.5s 
需要的线程数=400*（8.5/60）=56(取整数)

利用jmeter的浏览器驱动，获取用户访问的响应整体时间：

设计测试脚本模型：

运行脚本，查看聚合报告结果：

最终结果显示，吞吐量大约在32/s，符合预期值

并发用户数C=(400*8.5s)/60=56
并发用户峰值C1=56+(3* 根号56)=78 在预期范围之内

上面的性能测试案例我们是利用了业务单次消耗时间和预期吞吐量计算出需要并发的线程数，接下来我们换一种线程组来做另一次实验。

利用Arrivals Thread Group(预期事物通过线程组)来自动释放线程数

业务场景的测试脚本保持不变，启动线程组，观察释放的线程数

结果显示，系统根据需要自动释放的线程数是55，吞吐量是31/s，和之前我们自己计算得出的结论几乎一样。