jmeter可以做性能测试,这个很多人都知道,哪你知道,jmeter可以在启动运行时,指定线程数和运行时间,自定义性能场景吗?
平时,我们使用jmeter进行性能测试时,使用普通线程组,并发用户数和运行时间等场景参数都是固定写死的。运行脚本时,就按照写死在脚本中的场景来运行。
相信,绝大多使用jmeter进行性能测试,性能场景设计,都类似上图,写死线程数、ramp-up时间、持续运行时间。
这样,固然很好,直接就可以用,但是,当我们用CLI模式,做负载测试时,我们期望能随时更改线程数、ramp-up时间和持续运行时间,你怎么做?
用jmeter的gui界面,修改场景中的这些参数值,然后,保存,再运行;或者,直接编辑脚本jmx文件,保存,再运行。
两种方法都可以,但是,有没有感觉,比较麻烦?有没有更简洁的方法呢?
在我的教学中,给大家讲过,jmeter除了变量之外,还有‘属性’,属性是jmeter工具的标签,可以在jmeter这个工具的任何地方被使用。
jmeter不仅支持属性文件配置静态属性,也支持,在脚本运行过程中,动态生成属性,而且,还支持,外部传入动态属性。
通过获取属性pthreads,来指定线程数, 获取属性pramp来指定ramp-up时间,获取属性pruntime来指定持续运行时间。
这些属性,真实存在吗? 后面的数字,又是什么意思呢?
首先,P函数,在jmeter中,是获取属性函数,它有两个参数,第1个参数,是属性名,这些属性,可以事先定义的静态属性,也可以是动态生成的动态属性,图中用到的所有属性,就是事先没有定义,在运行时动态定义的属性;第2个参数,是属性默认值,当这个属性没有获取到值时,使用这个默认值。
什么意思?
意思是,如上图这样设计,你不传任何属性值,直接运行,就会按1秒钟内启动30个并发用户数,持续运行60秒的场景来运行。
现在,你可以放心了吧,即便你没有传入这些属性值,这个场景,也是可以正常运行的。
那,我们在CLI模式下,进行性能测试时,到底应该怎么传入这些属性值呢?
首先,我们要知道,使用CLI模式,进行性能测试,通常有两种方式,一种,就是直接启动本地脚本运行;另外一种,就是采用分布式,指定助攻机器来运行。
用CLI命令,直接指定本地脚本运行
CLI命令中,使用 -J[property_name]=value 的方式,传入属性值
# 本地运行, 指定pthreads线程数属性参数值为50,pruntime持续运行时间属性参数值为70秒
jmeter.bat -n -t .\jkscript\demo_script.jmx -Jpthreads=50 -Jpruntime=70 \
-l test001.jtl -e -o .\jkscript\test001
看,实际运行时,50个线程数,运行70秒钟。
用CLI命令,指定助攻机运行
CLI命令中,使用 -G[property_name]=value 的方式,传入属性值
# 采用助攻机运行 指定pthreads线程数属性参数值为80,指定pruntime持续运行时长属性参数值为120秒
jmeter.bat -n -R 192.168.x.x:port -t .\jkscript\demo_script.jmx -Gpthreads=80 -Gpruntime=120 \
-l test002.jtl -e -o result002
看,实际运行,根据命令参数设置,运行了80个线程数,持续运行了120秒钟。
有了这样一种技术之后,我们再也不用去打开脚本修改性能场景了,只需要在执行命令的时候,改下脚本参数就可以了。只是,我们要记清楚,本地直接运行,属性参数名称前用‘J’,分布式运行,属性参数名称前用‘G’。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
梦自己想梦的,做自己想做的,生命只有一次……一旦错过了就不可能再有这个机会了,不要让自己后悔。
平静的湖面只有呆板的倒映,奔腾的激流才有美丽的浪花!幸福不是靠别人来施舍,而是要自己去赢取!生命的意义在不断挑战自己,战胜自己!
机会,需要我们去寻找。让我们鼓起勇气,运用智慧,把握我们生命的每一分钟,创造出一个更加精彩的人生。