目录
- 一、回顾
- 二、性能测试场景设计
- 六种常见设计方法
- 三、普通性能场景
- 1.jmeter的线程数，有没有限制呢？
- 2.ramp-up时间
- 3.线程数 ramp-up时间，怎么设置才比较合理？
- 4.循环次数
一、回顾
- ngrinder：
- maven groovy进行脚本开发，必须ngrinder的版本要小于等于3.5.2。
- ngrinder的版本：3.5.5有兼容性问题，管理台界面会打不开。
- 建议使用ngrinder3.5.2。
二、性能测试场景设计
如果公司要求你去做性能测试，会有一个“需求”，活动页面，要你做性能测试，看是否能满足1000个人同时访问。
需求2：商定，对接的接口，要满足50tps。---这样的场景怎么设计。
需求3: 秒杀活动，我要看秒杀时，服务器能否支持500个人同时秒杀。
六种常见设计方法
- 普通性能场景设计。
- 阶梯性能场景(负载测试场景)。
- 压力测试场景。
- 面向目标场景（lr很容易实现这个场景。但是jmeter，如果没有系统得讲解，是不知道怎么来实现这个场景）。
- 混合场景设计：不同数量的人，向不同的接口发起请求。
- 有时间规律的场景。
三、普通性能场景
- 线程组：
- 线程数：模拟的并发用户数量。
1.jmeter的线程数，有没有限制呢？
jmeter本身是没有对线程数做限制的。但是jmeter启动这些并发用户数时，需要消耗资源，受电脑cpu的主频限制，一台电脑不可能创建无限量的线程数。
实际的情况，「http协议」的脚本，一台电脑的线程数大概能产生1500左右并发用户数，可能产生2000个并发用户数，但是可能会出错，肯定能产生1000个并发用户数左右。
也就是说，1台电脑，「http协议」脚本，保守估计是可以产生1000个并发用户数。
如果你想模拟超过1000并发用户数，你可能需要考虑「分布式（用多台电脑）」。
其它的协议和受一些别的因素的影响，产生的并发用户数量也不同。
2.ramp-up时间
「ramp-up时间：」 启动所有线程数的时间(线程数在合理的范围)。
1）在ramp-up时间结束点，所有的人会产生。
2）在ramp-up时间内，是否均匀产生并发用户数，是不确定。
3）在启动时间内，产生的并发用户，一产生，就去发起请求。
4）启动了并发用户，就会去发起请求，不同时间产生的并发用户，与前面产生的并发用户，调用的接口可能不一样。---广义并发。
「广义并发：」 同一时间点向服务器发起请求，并不是同一时间点发起相同的请求。
「狭义并发：」 同一时间点发起相同的请求。
jmeter做性能测试，更多时候，使用的是广义并发。
ramp-up时间默认必须「大于等于1」。
3.线程数 ramp-up时间，怎么设置才比较合理？
代码语言：javascript复制500以内并发用户数，ramp-up:2~4s。
500-1000并发用户数，ramp-up:5s。
>1000并发用户数，ramp-up:5-8s。
「一个原则：」 ramp-up时间在总执行时间中，占比要很低。
一般的情况，一个性能测试的总执行时间：几十秒钟~几十分钟。
4.循环次数
循环次数默认必须「大于等于1」。
「循环次数：」 就是每个并发用户要去执行的请求数量。
「复选框：」 永远。一直循环，直到你点击停止，才会停止。
这个停止会有问题吗？
会有问题，会导致请求报错，或卡死。
永远应该怎么用呢？
要与调度器一起使用。「必须把永远的勾和调度器的勾都勾选。」
文章中的图片，皆为小编本人所画所截图，计算机知识都一样，如有雷同，纯属巧合。「文章是清菡编写的，如有转载，请标明出处！」
