17-混合场景设计

面向目标的场景

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

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

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

bzm - Arrivals Thread Group

混合场景

错误的混合场景

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

真正的混合场景

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

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

多个线程组

难点

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

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

用户参数：局部变量，不能直接跨线程组

属性

jmeter属性

静态属性：properties

动态属性：setPorperty

系统属性：

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

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

属性跨线程组

线程1：注册

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

事务控制器

HTTP请求

用户参数

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

JSON取样器

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

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

设置手机号

设置gqid

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

线程2：登录

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

1 2	${__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"
}