线程组:使用复杂场景的性能测试
有时候我们做性能测试时,只依靠自带的线程组,显示满足不了性能测试中比较复杂的场景,下面这两种线程组可以帮助你很好的完成复杂的场景
第一种:Stepping Thread Group
在取样器错误后要执行的动作
继续:即取样器执行错误后(失败的接口),会继续向下执行后面的接口,直到整个线程完成
Start Next Thread Loop:即取样器执行错误后,终止当前循环,进入下一个循环;
停止线程:即取样器执行错误后,停止当前线程;
停止测试:即取样器执行错误后,等待当前执行的采样器结束后停止执行测试;
Stop Test Now:即取样器执行错误后,出现错误立刻终止测试;
1、This group will start 50 threads:单台负载机,线程组启动的线程总数为50个。
2、First,wait for 8 seconds:等待8秒后开始起线程(实际7秒就开始了)。
3、Then start 5 threads:最开始时启动5个线程。
4、Next,add 10 threads every 10 seconds using ramp-up 5 seconds:在5秒内启动10个线程,运行10秒,以此类推。
5、Then hold load for 50 seconds:单台负载机启动的线程数达到50后,再持续运行60秒。
6、Finally,stop 25 threads every 2 seconds:25个线程停1次,等2秒后再停25个线程
![](https://i-blog.csdnimg.cn/blog_migrate/34607b3551c6277b8b0ad34b201f2513.png)
第二种:Ultimate Thread Group(终极线程组、阶梯线程组)
比如有这样的一个场景:
50个用户(线程数),5秒后开始逐步请求,且每秒启动5个(10秒内全部启动全部线程数),全部线程启动后运行1分钟,且不要求全部停止,而是逐步停止(每秒停止2个用户即线程)
我们该如何做呢???
如果用普通的线程组其实也可以,但是没有用户启动或者停止的走势我们看到,不够直观,另外不能做更复杂的需求,这时我们可以用Ultimate Thread Group。
Ultimate Thread Group 提供了一个"Threads Schedule" 线程计划表。
添加之后有这样一个页面,我们先了解一下这些页面的功能或作用。
1、Start Threads Count:线程数量
2、Initial Delay,sec:每组开始添加到测试执行之前的延迟(xx秒开始启动线程)
3、Startup Time ,sec:线程组的加速期(xx秒全部启动)
4、Hold Load For,sec:在所有线程启动后运行的时间(只针对该行,每个线程组都有自己的Intial Delay“初始延迟”值)
5、Shutdown Time:所有线程组关闭的速度(xx秒后全部停止)
按照场景设置的值如下图所示:
我们如果有更复杂的场景:
场景二:比如第一批用户是上图的场景,但是还会有第二批用户又是一种场景,第三批、第四批等等、而这些场景中有部分重合,那么可以继续添加线程组(比如又添加一个),但是这两行不是每一列的值累加后再除以2的,而是每种场景根据自己的规则进行,然后计算后的值再进行累计展示。
例如双十一买物品,0点后开始疯狂 抢购(第一批用户),可能有一部分人5分钟后才进入,那这个就是第二批用户,那此时第一批和第二 批会存在同时请求的情况。
附赠:并发线程:bzm - Concurrency Thread Group(阶梯式请求)![](https://i-blog.csdnimg.cn/blog_migrate/b8290c66668cff9d2bca7f6590841a78.png)
1、Target Concurrency:线程数(用户数)
2、Ramp Up Time:加速时间(xx分后全部启动所有线程)
3、Ramp-Up Steps Count: 阶段数(在加速时间内分为几个阶段),每一阶段直接递增(并发)xx用户数(线程数)
4、Hold Target Rate Time:所有线程启动后,运行持续时间
5、Time Unit:时间单位(分钟或者秒),针对"加速时间"和"运行持续时间",一般我们选择默认就可以(分钟)
6、Thread Iterations Limit:线程迭代次数(循环次数)
7、Log Threads Status into File:将线程状态记录到文件中(将线程启动和线程停止事件保存为日志文件,txt格式文件即可)
也适用于分批请求的场景,但是没有 Ultimate Thread Group线程组的阶梯灵活