（49）其他的性能测试场景

其他的性能测试场景

普通线程组设计性能测试场景

压力测试

关键点：运行的时间比较长 -----看服务器的稳定性

把性能测试场景的运行时间设置的比较长。时间单位一般是以小时或天为单位

方法1：普通线程组，持续运行时间设置比较长

方法2： stepping thread group 最大线程和起始线程设置相等 holdload 时间设置比较长

波浪型场景

Ultimate Thread Group ————》终极线程组

波浪型的场景，是用于模拟有明显的时间规律请求的场景

配置：
- 并发用户数 -------设置，根据你的业务背景要求
- 时间设置：
  - 下一行的起始时间，大于等于上一行所有时间之和 --------这样，波浪就不会重叠
  - sum(初始化的起始时间 +启动用时 + 持续运行时长 + 结束时间 )
实际场景：
- 10:00 —— 12:30 时间进入系统人比较多，并发是比较大
- 12:30 —— 15:00 时间没有什么请求
- 15:00 —— 16:00 有少量并发
- 17:00 —— 19:00 有比较高的并发
- 要你模拟，你怎么模拟。
  这个场景中，有没有并发请求的时间，我们不需要等待对于时间长度。

面向目标场景

有个问题：并发用户数应该用多少呢？

做负载测试、性能测试、压力测试，我们都说并发用户数是我们性能测试的源动力。都是使用并发用户数去请求，然后，看请求的结果各项性能指标（tps的数值）

这个需求，就可以理解为，只要你能达到要求的tps值，并发用户数随意多少。

Arrivals Thread Group 线程组，达到多少每秒 ------每秒多少事物=tps
- targets rate就是目标tps值
- ramp-uptime 达到到目标用时长
- ramp-up step 达到目标你有多少次调整计划
- hold 达到目标后，持续运行多长时间
Concurrency Thread Group 线程组，是达到多少人
- targe：目标人数
- ramp-uptime 达到到目标用时长
- ramp-up step 达到目标你有多少次调整计划
- hold 达到目标后，持续运行多长时间
注意点：
- 切换time unit 时间单位为秒，如果不选择秒，而选择分钟，那么就相隔60倍。

业务背景：有一个秒杀的需求，要求能支持 1500人秒杀，系统依然正常。

分析：
- 绝对不能容忍，秒杀把系统搞宕机（崩溃）
- 可以容忍：一段时间内处于处理状态，不报错 -------可以接受一个请求的响应时间远远超过1秒钟
  - 需求就变成了，我们的系统要能支持 1500人并发，并且能持续运行一段时间，系统不出错
场景：
- 并发用户数比较高，ramp-up时间比较短，然后，要持续运行一段时间
- 我们关注： tps中，不要出现错误
  - 不关系：平均响应时间多少

混合场景

很多接口放在一个场景中，测试，=============算混合，但是，是有业务背景的混合吗？

关机键点：就在于接口比例（接口的并发用户数比例）

并发用户数的比例，能把多个接口放1个线程组吗？

线程组是用于性能场景设计的，可以设计不同的并发用户数。放到一个线程组下面，线程组下的所有的接口的并发用户数都相同。所以，真正的混合场景，是要用多个线程组。

多个线程组： jmeter多个线程组之间，不能直接跨线程组传参。多个线程组挂接口，接口之间有关联，默认，是不能直接传递参数，关联是关联不到参数值的。

所以，我们得先讲 jmeter属性

跨线程组的使用：