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,和之前我们自己计算得出的结论几乎一样
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值