6种常见性能测试设计方法
-
普通性能场景设计
阶梯性能场景(负载测试场景)
压力测试场景
面向目标场景（loadrunner很容易，但是jmeter比较复杂）
混合场景设计（混合，if条件）不同数量的人，向不同的接口发起请求
有时间规律场景
一 普通性能场景
-
-
先了解性能测试需使用的组件
线程组
1 线程数： 模拟的并发用户数量
线程数，有没有限制呢？
jmeter本身是没有对线程数做限制
但是， jmeter启动这些并发用户数时，需要消耗资源，受电脑cpu的主频限制，一台电脑不可能创建无限量的线程数
实际的情况，http协议的脚本，线程数，大概能 1500左右 2000个可能产生，但是可能会出错，1000左右比较保守，可能能产生。
也就是说，1台电脑，http协议脚本，保守估计是可以参数1000个并发用户数
如果你想模拟超过1000并发用户数，你可能需要考虑 分布式
2 ramp-up时间
启动所有线程数启动的时间(线程数在合理的范围)
在ramp-up时间结束点，所有的人会产生
在ramp-up时间内，是否均匀产出并发用户数，是不确定
在启动时间内，产生的并发用户数，一产生，就去发起请求
启动了并发用户，就会去发起请求，不同时间产生的并发用户数，与前面产生的并发用户数，调用的接口可能不一样
jmeter做性能测试，更多时候，使用的是，广义并发
ramp-up时间要大于等于1
线程数 + ramp-up时间，一般的设置(不是死的)
500以内并发用户， ramp-up 2~4s
500-1000 ramp-up 5s
>1000 ramp-up 5-8s
一个原则： ramp-up时间在总执行时间中，占比要很低
一般的情况，一个性能测试的总执行时间 几十秒钟 ~ 几十分钟
3 循环次数
默认必须大于等于1
循环次数，就是每个并发用户数要去执行的请求数量
复习框 永远 一直循环，直到你点击停止，才会停止
永远要与 调度器 一起使用
必须把两个勾 都勾选
调度器：
持续时长
启动延迟
延迟启动,用于定时开始任务,一般不使用
- 在取样器错误后要执行的动作
场景：
30个并发用户，持续运行300s
-
聚合报告： avgRT： 2.945s 90%RT：3.748s avgTPS：10.1
响应时间图
-
结论：
90%RT：3.748s 可以看到，这个响应时间是比较长，已经超过了我们用户能容忍的范围了，用户满意度指数1.5s，说明我们的接口响应比较慢。
30个人， avgTPS： 10.1 tps<用户数 那么，每个人1秒钟发不了1个请求，所以，我们次数 30个并发用户数，已经超过了我们项目这个接口能承受最大并发用户数了。
可以简单得到一个结论： 服务器注册接口最大并发用户数小于30的
-
-
负载测试性能场景--脚本
负载测试： 逐步增加并发用户数
插件安装，
插件管理： jpgc 安装这个插件
用 5秒钟 增加10个并发用户数，持续运行30秒
阶梯线程组： 负载测试
负载测试： 逐步增加并发用户数
增加的量(步长)，可以相同，也可以不相同
-
相同只是一种特殊请求 stepping threads group
不相同的增量，不能用stepping threads group
-
在阶梯线程组，执行过程中，我们的并发用户数是时刻发生变化
阶梯线程组设计的规律：
缓起步，快结束
快结束： 并不是瞬间结束
聚合报告：
阶梯线程组可以看聚合报告吗？
聚合报告中的数据，都是 平均值
在负载场景(阶梯场景)，不看聚合报告
聚合报告是可以看到 失败率
负载测试性能测试
