JMeter性能测试中控制业务比例

性能测试混合场景中,我们需要组合多个业务操作到场景中来。
比如有一个论坛的业务分布如下:
发布新帖与回复帖子的比例为2:3,
那么我们在JMeter测试计划中如何控制其比例呢?

可以通过以下两种方式解决:
多线程组方式

逻辑控制器控制

多线程组方式:

JMeter是用线程组来模拟虚拟用户的,JMeter支持一个计划中多个线程组。
利用这个特性我们可以把发布新帖业务放在一个线程组中,回帖业务放在另外一个线程组中。
通过控制线程数来达到需求的业务量的比例关系。

回帖线程组,添加90个线程;
发布新帖线程组,添加60个线程,刚好是3:2。

但,,,这只能是近似的,如果这两个事务的响应时间不一样,最终完成的业务数比例也会不一样。
当前线程数是在假定两个业务的响应时间一样的情况下,所以这完全是理想状况。
所以,这种方式控制并不完美。

控制器控制:

如果(If)控制器可以使用表达式来做为条件,这样我们可以获取迭代次数来决定
是回帖还是发新帖,比如一共3次迭代,第1次与第3次迭代时发新帖,1,2,3次迭代都会进行回帖

JMeter函数助手提供了一个“__counter”函数,可以用来获取当前的迭代次数。

如何保持3:2的比例呢?

${__counter(true,)}%2==1||${__counter(true,)}%3==0


上面__counter(true,)是获取当前迭代次数,%是取余,也就是除2余1与3整除时执行发新帖。
以9次迭代为例,回帖9次,1,3,5,6,7,9 次迭代时都会发新帖,回帖刚好是6次
9:6=3:2
3:2的比例达到。

时间: 2024-10-29 20:02:47

JMeter性能测试中控制业务比例的相关文章

在JMeter测试计划中如何控制业务比例

性能测试混合场景中,我们需要组合多个业务操作到场景中来.比如有一个论坛的业务分布如下:开新帖与回复帖子的比例为2:3,那么我们在JMeter测试计划中如何控制其比例呢? 下面我们介绍两种方式: 1.多线程组方式 2.逻辑控制器控制 多线程组方式: 我们知道JMeter是用线程组来模拟虚拟用户的,JMeter还可以支持一个计划中多个线程组. 利用这个特性我们可以把开新帖业务放在一个线程组中,回帖业务放在另外一个线程组中. 为了制造出业务量的比例关系,我们通过控制线程数来达到效果.如下图: Repl

jmeter通过if控制器控制业务比例

以发帖,看帖,回帖三个事物为例,这里就10个用户跑10次,进行测试下: 可以看到看帖,回帖,发帖比例是5:3:2,先来说说怎么做到的,就是通过if控制器,分别来看下几个控制器的内容, 看帖(if控制器):勾选“interpret condition as variable expression”,这时expression中不能直接填写条件表达式,需要借助函数将条件表达式计算为true/false,可以借助的函数有_jexl3和_groovy,比如${__groovy(${__counter(tr

如何性能测试中进行业务验证

在性能测试过程中,验证HTTP code和响应业务code码是比较基础的,但是在一些业务中,这些参数并不能保证接口正常响应了,很可能返回了错误信息,所以这个时候对接口进行业务验证就尤其重要.下面分享一个对某个资源进行业务验证的Demo. 改接口请求资源详情,其中有一个字段是表示该用户对于该资源的操作状态,踩赞类型:1-赞,2-踩,3-取消赞,4-取消踩. 改压测一个接口,但是需要两个接口的数据提供数据,一个是登录,一个是操作改资源的接口. 具体的项目结构之前讲过,主要解决了请求方式,身份验证的问

Jmeter性能测试中Tps图与响应时间图

[email protected] - Response Times Over Time显示图: [email protected] - Transactions per Second 原文地址:http://blog.51cto.com/357712148/2060214

JMeter在Web Services性能测试中的应用

性能测试是任何分布式或Web应用程序测试计划的重要组成部分.在计划和开发周期中进行性能评价,可以保证交付给客户的应用程序满足客户对于高负 载.可用性和可伸缩性的要求.提前确定软件的负载限制可以为适当地进行系统配置提供帮助,从而避免出现意料之外的故障.系统性能分析中要处理的几个问题 是:系统或服务器能否处理数百个或数千个客户端的同时请求,以及系统可以处理请求的频率.这种类型的测试不但提供了系统响应时间的绝对度量值,而且针对服 务器的回归测试和应用程序代码,检查服务器的响应是否和预期结果相匹配,并为

我的新课--快速上手Jmeter性能测试工具正在筹划中

大家好,感谢大家一直以来对我的支持,新课快速上手Jmeter性能测试工具正在筹划中,大纲如下: 随着软件性能测试行业的崛起,各种性能测试工具也随之层出不穷,各具特色.同时,开源的趋势不可阻挡,如何使用开源免费的性能测试工具完成相关测试工作是很多企业正在考虑的问题.本套课程正是基于以上需求和现状,选择目前市面上最流行的开源性能测试工具Jmeter作为阐述对象,带领大家从零开始.步步为营,以掌握Jmeter的基本概念并熟练使用Jmeter进行测试为目标,快速而高效的学习和使用Jmeter.俗话说,授

关于性能测试中“并发”的解释

当我们在谈论"并发"时 动辄要求系统支持成百上千并发的性能需求太多了,也许系统在实际中确实存在这样的需求,但能够较全面理解此需求的情况并不多. 对于并发,我过去接触了几种理解,在接触的第一种理解中,"并发"是由loadrunner中获取,即脚本中所有或部分vuser执行至集合点函数时进行停留,等待触发条件发生以后,同时执行集合点函数后的请求操作的这一个过程,为"并发"(这一个请求操作一般存在多个http请求),可惜这种"并发"

数据建模在性能测试中的理解

百度搜索:小强测试品牌 如果觉得本文不错,请多多转发一下哈 引子 概念是一个让人又爱又恨的东西,有些东西需要概念来解释,但有些东西又被概念所迷惑.很多所谓高大上的概念其实你剥开来看并没有那么高级. 因为在小强测试品牌培训班中看到了有的学员聊了这个话题,所以今天就顺便写写关于数据建模这个概念在性能测试中到底是个啥? 我所理解的数据建模 按照我个人的理解在性能测试中的数据建模可以分成两个方面来理解,一个是基础数据有的人也叫铺底数据(概念也是越玩越花),另一个是业务场景(其实就是场景用例). 1 基础

性能测试中关键指标的监控与分析

一.软件性能测试需要监控哪些关键指标? 软件性能测试的目的主要有以下三点: Ø  评价系统当前性能,判断系统是否满足预期的性能需求. Ø  寻找软件系统可能存在的性能问题,定位性能瓶颈并解决问题. Ø  判定软件系统的性能表现,预见系统负载压力承受力,在应用部署之前,评估系统性能. 而对于用户来说,则最关注的是当前系统: Ø  是否满足上线性能要求? Ø  系统极限承载如何? Ø  系统稳定性如何? 因此,针对以上性能测试的目的以及用户的关注点,要达到以上目的并回答用户的关注点,就必须首先执行性