一次性打包呈现,Jmeter的场景设置及常见问题

发表于:2020-11-05 09:34

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:程序员一凡    来源:博客园

  Jmeter线程组实际上是建立一个线程池,Jmeter根据用户的设置进行线程池的初始化,再运行时做各种异常的处理,如下图:
  参数说明如下
  名称:可以随意设置,最好有业务意义。
  注释:可以随意设置,可以为空。
  在取样器错误后要执行的动作:也就是其中的某一个请求出错后的异常处理方式。
  ◆继续
  请求(Sampler元件模拟的用户请求)出错后继续运行,那么为什么要继续运行呢?
  因为我们在大量用户并发时,服务器偶尔响应错误是正常现象,比如服务器由于性能问题不能正常响应或者响应慢,此时出错我们正好要记录下来,作为有性能问题的依据。
  勾选此项后,后面的请求将继续执行,比如我们的发文章示例脚本,登录出错了,后面的发帖请求照常发送,只是由于没有登录,发帖也会失败(我们在论坛中设置了只有登录用户才可以发帖)。
  ◆StartNextThreadLoop
  如果出错,则同一脚本中的余下请求将不再执行,直接重新开始执行。比如,我们登录失败了,那么发帖的操作将不再执行,重新开始新一轮迭代,从重登录开始执行。如果我们进入论坛板块失败了,后面的发帖也将在此轮迭代中不再执行,新开始新一轮的迭代。
  ◆停止线程
  如果遇到请求(Sampler元件模拟的请求)失败,则停止当前线程,不再执行。比如我们配置运行50个线程,如果其中某一线程中的某一个请求失败了,则停止当前线程,那么就只剩下49个线程在运行,如果失败的事务增多,那么停下来的线程也会增多,运行状态的线程会越来越少,最后负载不够(对服务器的压力不够,测试结果不具参考性),所以我们一般不会这样设置。
  ◆停止测试
  如果某一线程的某一请求失败了,则停止所有线程,也就是停下整个测试。但是每个线程还是会执行完当前迭代后再停止,比如线程1正好执行到登录操作,有其他线程出错了,现在要全部停下来,线程1也会执行完发帖操作后才会停止。
  ◆StopTestNow
  如果有线程的请求失败了马上停止整个测试场景。
  线程属性如下
  线程数运行的线程数设置,一个线程对应一个模拟用户。
  Ramp-UpPeriod(insecond)
  线程启动开始运行的时间间隔,单位是秒。即所有线程在多长时间内开始运行。比如我们设置线程数为50,此处设置10秒,那么每秒就会启动50/10,5个线程。如果设置为0秒,则开启场景后50个线程立刻启动。
  循环次数
  请求的重复次数,选择后面的forever,那么请求将一直继续除非停止或崩溃;如果不选择forever,而在输入框中输入数字,那么请求将重复指定的次数,如果输入1,那么请求将执行一次,执行0次无意义,所以不支持。
  DelayThreadcreationutilneeded
  勾选,线程在Ramp-upPeriod的间隔时间启动并运行。比如50个线程10秒的Ramp-upPeriod时间,那么每隔1秒启动5个线程并运行(RUNNING状态)后面的Sampler(即取样器模拟的请求,比如我们示例中的登录操作)。
  不勾选,测试计划开始后启动所有线程(NEW状态),但不立即运行Sampler,是按照Ramp-upPeriod时间来运行的。
  比如50个线程10秒的Ramp-upPeriod时间,那么计划开始后线程全部就序,但第1秒只会有5个线程开始运行Sampler。
  实际运用过程中选择哪一个都可以,不影响测试结果。
  线程一般有以下5个状态。
  **●NEW:**创建未启动,已经实例化,只是没有开始运行线程的Run方法。
  **●RUNNABLE:**就绪状态,线程对象创建后,其他线程调用了该对象的start()方法,该状态的线程位于可运行线程池中,已经准备好了只等获取CPU的使用权,然后开始运行。
  **●RUNNING:**运行状态,就绪状态的线程获取了CPU使用权执行程序代码。
  **●BLOCKED:**阻塞状态,线程因为某种原因放弃CPU使用权,暂时停止运行(典型的如IO等待导致的线程处于BLOCKED状态);直到线程进入就绪状态,才有机会转到运行状态。
  阻塞的情况分为以下3种。
  **●等待阻塞:**运行的线程执行wait()方法,线程进入等待池中。
  **●同步阻塞:**运行的线程在获取对象的同步锁时,若该同步锁被别的线程占用(意思就是资源争用落败),该线程放入锁池中。
  **●其他阻塞:**运行的线程执行sleep)或join()方法,或者发出了I/O请求时,该线程置为阻塞状态。当sleep()状态超时、join)等待线程终止或者超时、或者I/O处理完毕时,线程重新转入就绪状态。
  ●DEAD:死亡状态,执行完毕或者异常退出,线程生命周期结束。
  调度器配置:设置何时开始运行。
  启动时间:测试计划什么时候启动,时间格式“2015/03/1309:54:09”
  结束时间:测试计划什么时候结束,时间格式“2015/03/1310:54:09”。
  持续时间:测试计划持续多长时间,如果启动时间+持续时间大于结束时间,那么此设置覆盖结束时间。
  启动延迟:点击执行按钮后(此时间为T),仅初始化场景,不运行线程,等待延迟到时后开始运行线程。如果T+延迟时间大于启动时间则覆盖“启动时间”设置,以延迟时间为准。
  JMeter的场景运行方式分为两种:
  ◆GUI(视窗运行,即我们可以看到运行界面)方式;
  ◆非GUI方式运行(命令窗口),在Windows中我们可以在命令窗口运行。
  JMeter的场景运行基于运行架构分为两种:
  ◆本地化运行,即单机运行;
  ◆远程运行。
  不管是GUI方式还是非GUI方式都支持本地运行与远程运行。下面我们以Windows系统下的JMeter为例讲解场景运行。
  本地运行
  本地运行即只运行本地一台JMeter机器,所有的请求从一台机器发出,下图是GUI方式本地运行,我们启动了5个线程。
  在运行前快捷菜单栏是这样的
  本地运行点击
  开始运行后菜单栏是
  同时我们可以看到
  0代表没有线程异常,一个0代表当前运行(线程活动状态)的线程数是0个,后一
  后面绿色框代表线程运行正常,需要停止时点击。
  远程运行
  远程运行是用一台JMeter控制机(Master)控制远程的多台机器(Slave)来产生负载。
  JMeter控制机与远程负载机的通信是通过RMI方式来完成的,在负载机上运行Agent程序(启动命令是%JAVAHOME%\binjmeter-serverbat),在JMeter控制机(Master)上单击运行远程负载机。
  大家可以在%JMETERHOME%\bin目录下找到ApacheJMeter.jar与jmeter-server.bat两个文件。我们通过运行jmeter-server.bat来启动Agent,Agent程序是由ApacheJMeter.jar中的程序来实现的。
  旧版本的JMeter在进行远程通信时要指定端口,当前我们用的2.11版本已经不需要指定端口了,JMeter控制机会自动探测,只要先启动远程负载机上的Agent,JMeter控制机开始运行测试计划时就会自己连接。
  不过在连接之前先得告诉JMeter控制机,让它尝试去连接哪些机器。这个告诉动作是通过配置文件来完成的。打开jmeter.properties文件,搜索“remotehosts”关键字,可以找到如下内容:
  #Remote Hosts-comma delimited多个IP用逗号隔开remote_hosts=127.0.0.1, 192.168.1. 100#remote hosts=localhost:1099, localhost :2010#RMI port to be used by the server(must start rmiregistry with same port)#server_port= 1099                                                                       
  我们在“remotehosts=”后加上远程JMeter负载机的IP即可(推荐用IP而非机器名),多个机器之间的IP以逗号分隔(修改了jmeter.properties文件需要重启JMeter才可以生效)。
  上面表格中我们把127.0.0.1与192.168.168.100两台机器都作为了远程负载机,虽然127.0.0.1就是本地JMeter机器(也是控制机),但是我们在运行远程场景时还是会把本机机器当作远程机(除非本地机仅做控制器,不运行脚本)。
  在本地也需要启动Agent(双击%JMETERHOME%\bin\jmeter-server.bat运行)。此Agent被用来连接的端口是7649,192.168.45.1是本机IP,在配置时填写的是127.0.0.1,这并不矛盾。
  远程运行点击
  开始执行测试计划,正常运行时快捷菜单显示器
  如果要停止当前计划,点击或%都可以,前者是执行完当前迭代停止(比如当前脚本有5个请求,在第2个请求时收到停止命令,那么将继续执行完第5个请求后再停止),后者是立刻终止(立刻中断线程,请求是否运行完成不考虑)。
  远程运行与结束时我们在命令窗口可以看到图上所示内容,Startingthetestonhost…表示开始执行,Finishedthetestonhost…表示执行完成。
  一、参数化的意义
  我们经常会出现开发环境验证完成之后,在测试环境验证,在线上环境验证,其实只是URL发生了变化。
  所以在实际的测试过程中,我们经常会碰到脚本开发时与测试执行时的服务地址不一样的情况。为了方便,我们会把访问地址参数化,这样当访问地址变化了,我们只需要把参数对应的值改动一下就可以了。
  在我们录制的脚本中,每个元件默认的名称就是访问的链接地址,这个是可以随意取名的,所以我们暂且不管它,我们要参数化的是“服务器名称或IP”及“端口号”,下面可以看到我们改变IP地址为192.168.19.123,端口号变为了8080,这样还是不方便。
  我们可以使用参数来代替,在用户自定义变量中我们定义URL、PORT变量。
  然后引用:

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号