根据需求,设计jmeter元件

需求1:有一个项目,500用户同时登录,响应时间能达到多少;

需求2:考勤打卡,最大吞吐量能达到多少(每秒最大能完成多少笔打卡业务);

需求3:银行业务,如果需要支持1分钟内完成3000笔取款操作,平均每秒能支持多少用户同时取款完成;

答1:线程组设置线程数500,循环1次,并设置集合点为500;查看聚合报告响应时间即可;

答2:通过rps定时器,设置60s,rps从1均匀的增加到1000/s,查看hps,响应时间,tps,找出tps拐点;

也可以使用自由形式到达线程组;

答3:1个线程,一次取款的时间tms,那么一个线程取3000笔,需要3000*tms,并发用户(线程)=3000*t/(1*60*1000)=t/20;

平均并发=单笔业务时间*业务总量/总业务时间

原文地址:https://www.cnblogs.com/canglongdao/p/12639904.html

时间: 2024-10-13 11:25:10

根据需求,设计jmeter元件的相关文章

爱心银行需求设计

https://www.zybuluo.com/Feather/note/354940 易助爱心银行需求设计 产品设计 易助 易助爱心银行需求设计 1.引言 1.背景 2参考资料 3.假定和约束 4.用户的特点 2.功能需求 1系统范围 2.功能需求 获取爱心币的方式 爱心币的用处 爱心银行爱心币来源 3.爱心银行系统体系结构 爱心银行模块构架: 具体板块说明等细则 4.需求分析 3.非功能需求 1.性能需求 2.安全保密性要求 3.灵活性要求 1.引言 1.背景 说明: a.待开发的模块名称:

JMeter元件运行顺序

执行脚本案例:如图 通过多次运行测试,案例中JMeter元件之间的执行顺序(优先级)如下: 1)执行配置元件“HTTP Cookie”管理器: 2)执行前置处理器“用户参数”: 3)执行定时器元件“固定定时器”: 4)执行每个取样器,如http:127.0.0.1/XXX: 5)执行后置处理器“正则表达式提取器”: 6)执行断言元件“响应断言”: 7)执行监听器元件“断言结果”: 8)执行监听器元件“聚合报告”. 值得注意的是:上面的执行脚本案例中,添加固定定时器(设置为3000ms)的位置,会

慢阻肺疾病管理app——需求设计心得

需求确定已经两个星期过去了,现在回过头来写需求设计心得,能够总结出很多问题 过程: 拿到老师给的需求文档,对老师的需求进行提炼,选择自己将要实现的功能 对选择的需求进行了细分,完成需求原型.在此过程中,我们对需求的内容进行了讨论,对我们要实现的app进行了一个大致的想象,勾勒出每一个需求的呈现形式以及每一个功能的实现方式:当需求确定完,开始制作需求原型的时候,又发现了很多可以修改的地方,并且因为技术的原因,制作出来的需求原型似乎并没有完美的展现我们所期待的哪些功能,不过原型制作完需求也差不多确定

jmeter元件作用域和执行顺序

一.前言 本文主要简单jmeter元件作用域和执行顺序. 二.jmeter元件作用域 8类可被执行的元件(测试计划与线程组不属于可执行元件) ,这些元件中,取样器( Sampler )是典型的不与其它元件发生交互作用的元件,逻辑控制器只对其子节点的取样器有效,而其它元件(配置元件.定时器.断言.监听器.) 需要与取样器( Sampler )等元件交互. 在jmeter中,元件的作用域是靠测试计划的的树型结构中元件的父子关系来确定的,作用域的原则是: 取样器( sampler )元件不和其它元件相

jmeter元件的作用域与执行顺序

Jmeter测试步骤如下:1.测试计划2.线程组3.http请求4.监听器5.运行脚本6.查看报告 怎么看元件的作用域:从各个元件的层次结构判断没给元件的作用域

探索需求——设计前的质量之一

有人说开发软件比建一幢大楼复杂多了,因为软件行业缺乏准确而又统一的语言来描述相应的工作. 在这里我阅读了第一篇的内容,我了解到团队以及消除含混性的重要,而需求分析人员与设计人员应达成一种理解上的共识,以便减少不必要的麻烦的解释过程. 首先,书中有介绍,画映射图来直观易读的呈现业务需求,映射图有利于其他人迅速在头脑里形成业务流程的脉络,在根据业务概念,就能分析出并理解准确业务的具体功能需求以及实现方法. 对于我们获得的需求,试着逐字回忆需求或问题陈述,这将能够揭示那些必须在一个成功的需求被开发之前

《探索需求-设计前的质量》阅读笔记三

获取信息的第一步就是定义功能,在这个阶段描述产品是为了做什么的动作.假设是决策树的根源,那么客户说想要什么东西存在就是问题声明的提出.而客户说产品能够实现什么功能就是指他的测试功能.在描述功能方面,需要记录所有用户想要的功能,然后进行理解,不能记录记录用户不想要的功能.做到这些也需要一些技巧,首先要记录所有潜在功能,:理解明显的隐藏的以及装饰性的功能,识别未注意到的功能.实用功能启发的方式来进行识别功能,创造归功能的一直处理方法. 属性是客户希望的特征,要将属性和功能加以区分,属性不同的产品有可

【CityHunter】游戏进度总控,及需求设计

需求列表 序号 标题 描述 进度 1 游戏主界面 游戏进入的主操作界面,   2 基础定位功能 实现自身定位功能,   3 特殊地点的Marker 搜索周边银行(资产保护).医院(状态回复).商店(道具购买). 学校(技能学习)的基础设施,并在地图中标记出Marker   4 实现Marker的点击事件 点击相应的Marker,展开操作菜单   5 绘制Marker操作菜单 绘制银行.医院.商店的操作菜单   6 绘制玩家状态界面 玩家基本信息及角色状态界面   7 绘制道具界面     8 绘

《探索需求-设计前的质量》阅读笔记二

软件是以人为中心的,所以说需求也是以人为中心的,而在使用一些工具的时候往往会忽略人的因素从而导致含混性.由于需求阶段所发问题越多,以后付出的成本就会越少,所以说含混性是非常重要的.整个需求与系统范围边界是有相似之处的,只要划定了什么是我们的需求,什么不是我们的需求,那就会很容易地,感觉这个也相当于是把复杂的问题简单化地过程,而基本上所有的问题都会是这样一个解决的模式,这也说明了事物之间的共性.而且,要在探索中发现乐趣会别有一番风味. 含混性是由于对事物的不同理解而产生了不同的解释,在对于含混性难