17-混合场景设计

面向目标的场景

• Target Rate：TPS
• Ramp Up Time：启动时间
• Ramp-Up Steps Count：启动步长 总共可以调整的次数，如果少于总次数可以达到目标，那么后面剩余的次数就不会再调整。如果所有的调整次数都用完了，也无法达到目标，就是无法实现目标

调整次数，调整的是「并发用户数」

在这个场景中，完全没有设置「并发用户数」的地方，是通过自动调整并发用户数来实现的

bzm - Arrivals Thread Group

混合场景

错误的混合场景

1. 一个线程组中，挂载多个接口，向服务器发起请求。但是这种严格意义上来说，属于伪混合场景
2. 加吞吐量控制器当作混合场景：完全不知道如何做性能测试的思路
3. if条件控制器来做混合场景，也是伪混合场景

真正的混合场景

不同数量的并发用户，向服务器发起不同的接口请求

因为并发用户数量设置，是要使用线程组的。所以「不同数量的并发用户」需要使用多个线程组

多个线程组

难点

jmeter中，写脚本，最难的技术点，是跨线程组传参

用户定义变量：全局变量，可以跨线程组。在启动时获取一次，在运行过程中不会动态获取值 用户参数：局部变量，不能直接跨线程组

1. 属性

jmeter属性

• 静态属性：properties
• 动态属性：setPorperty

系统属性：

• 前面线程组中的接口参数值，设置为jmeter的属性
• 后面的线程组，获取jmeter属性值
• 线程组设置不同的并发用户数

1. 文件嫁接：使用「数据库」方式比使用「csv」方式性能要好 消耗本机的资源要小

属性跨线程组

线程1：注册

为了让数据读取的比较整齐，将注册与属性设置放在一个「事务控制器」中

事务控制器

HTTP请求

用户参数

使用JSON取样器将返回内容进行提取

JSON取样器

编写两个「调试取样器」进行属性的设置

${__setProperty(pro_mobile,${gmobile},)}
${__setProperty(pro_gqid,${gqid},)}

设置手机号

设置gqid

运行一次查看「属性显示」

image-20210509104547525

线程2：登录

在HTTP请求中电话号码和gqid设置为

${__property(pro_mobile,,)}
${__property(pro_gqid,,)}

HTTP请求

问题

由于Jmeter中线程数同时运行的，所以会出现获取到的值为上一次的值

当并发数量增加后，会出现多个请求使用了同一个属性

解决方法

属性名称设置时携带「线程号」

${__setProperty(pro_mobile_${__threadNum},${gmobile},)}
${__setProperty(pro_gqid_${__threadNum},${gqid},)}

登录接口
{
    "mobile": "${__property(pro_mobile_${__threadNum},,)}",
    "gqid":"${__property(pro_gqid_${__threadNum},,)}",
    "password": "123456"
}

波浪场景

波浪：有一定的时间规律

x轴：时间

y轴：并发用户数

jp@gc - Ultimate Thread Group

终极线程组

添加三条：

• 线程数100，开始时间0秒，起线程时间30秒，持续60秒，停止线程时间10秒
• 线程数100，开始时间110秒，起线程时间30秒，持续60秒，停止线程时间10秒
• 线程数100，开始时间220秒，起线程时间30秒，持续60秒，停止线程时间10秒

110秒=第一条的30秒+60秒+10秒+ 10秒等待时间

波浪