全网火爆，Jmeter性能场景设计 - 面向目标性能场景+分析性能指标（三）

---

前言

面向目标性能场景（1）

比如现在有一个需求，要求TPS要达到：50，如果是有用过loadrunner的，这个需求很容易就能解决，因为它本身就内置这种场景。但如果在jmeter中，就需要用到插件的内容了，不过因为同样也是jpgc的插件，所以只要有用过上面讲得阶梯式线程组，那肯定就会有bzm - Arrivals Thread Group线程组。

面向目标的场景有个特点，它不需要设置并发用户数，它会按照你设定的目标值，自动的增加并发用户数，直到TPS达到了目标值之后才会停止。

线程组的参数：
Target Rate (arrivals/min)：TPS的目标值；
Ramp Up Time (min)：在设置的时间内启动所有的用户，启动时间可以灵活调整。
Ramp-Up Steps Count：分多少次启动所有的用户，次数可以灵活调整，但是不能太少了，要给程序有容错的机会。
Hold Target Rate Time (min)：达到目标之后持续运行多长的时间
Time Unit：两个选项，可以改变上述时间的单位，minutes=分， seconds=秒。

场景实战（秒杀性能场景）

需求：要做一个秒杀，要求能支持1000个人同时秒杀，系统不会崩溃

首先，这个需求有两个含义：
从产品角度，1000个用户的访问系统且系统不崩溃，这里的不崩溃指这1000个用户上来之后持续运行一段时间也不会崩溃，并非就那一秒不崩溃而已，因此是允许系统响应时间慢点，只要不出现异常就可以。

但从用户角度，我既然参与了秒杀活动，我希望我点了秒杀之后你系统就得给我做出响应，所以从用户角度看，这里是要指系统得有1000tps的处理能力，这就用到了面向目标的线程组了。

面向目标场景（2）

面向目标还有另一种线程组bzm - Concurrency Thread Group，它与上面的不同的地方在于，上面是的目标是TPS，而这个的目标是并发用户数。

回到上面的秒杀，如果我们要看系统能否支持1000个用户，那就可以用这个场景：

有时间规律的性能场景（波浪型）

jpgc插件里面有一个叫jp@gc - Ultimate Thread Group的线程组，如果直译过来，名称就是“终极线程组”。

它能做到有时间规律的场景，也能做到类似于阶梯式的场景，因此叫终极其实也没错。

线程组参数：
start Threads Count：总共启动的用户数
Initial Delay：起始时间点
startup time：要用N秒启动全部用户数
hold load for：持续运行时间
shutdown Time： 要用N秒结束全部用户数

这个线程组比较有意思，添加一行线程数据之后，显示是一个梯形，那再添加一条相同的呢？

关键点就是Initial Delay（起始时间点），如果把起始时间改为上一行线程数据的所有时间总和，就会变成下面这样：

因此在用这个线程组的时候，要注意这个时间的调整。

混合场景

真正的混合场景应是不同数量的并发用户数向不同接口发起请求，只有这样才是符合企业产品实际情况。

现在常见有一种“假”混合场景：在一个线程组中，添加逻辑控制器，控制脚本的运行；这种，脚本是混合了，但这种场景很难控制并发用户数，与生成的情况还是有差异。

那么在jmeter如何要混合？

其实很简单，首先jmeter的所有线程都是并行的，基于这点，我们只需要创建多个线程组即可。每个线程组里面填写对应的业务逻辑，给每个线程组按照真实场景设定并发用户数即可。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

奋斗，就要放弃那份自由，选择宁静孤独相伴。奋斗，就要割舍那段缘分，选择勇气自信相伴。奋斗，就要摆脱那种繁华，选择苦楚辛酸相伴。

穿过黑夜，就迎来朝阳。奋进，首先要靠自己。桨，或许可以请人帮助摇：而舵，只能自己掌握。总之，要在奋进中掌握命运，让命运操在自己手里。

有时候，追梦的路上，除了要坚持、肯努力外，还得吃得了苦。咽得下多痛苦的经历，才扛得起多沉重的梦想。