Jmeter（四十）性能测试实战

 

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

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

性能测试以前咱们要设计一下场景：

业务流程：

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

业务预期的平常考勤量为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，和以前咱们本身计算得出的结论几乎同样。