您的位置:首页 > 其它

JMeter-03-主要功能介绍(依据官方标准脚本)

2019-08-15 16:38 316 查看
版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/weixin_40326608/article/details/98069625

JMeter-03-主要功能介绍(依据官方标准脚本)

  • 4.3线程(Thread)
  • 4.4取样器(Sampler)
  • 4.5断言(Assertion)
  • 4.6定时器(Timer)
  • 4.7后置处理器(Post-Processors)
  • 4.8监听器(Listener)
  • 1.怎么打开JMeter

    上一篇博文讲了,JMeter不需要安装,所以开启的时候,有10种方法:

    1. 去“\apache-jmeter-5.1.1\bin\”的目录下,找到ApacheJMeter.jar即可开启。
    2. bin下,找到ApacheJMeter.jar,然后建立桌面快捷方式(老哥我怀疑你在强行凑数,但我没有证据。。。)
    3. bin下,找到jmeter.bat即可开启(GUI模式)。
    4. bin下,找到jmeterw.cmd即可开启,此方式不会打开Windows Shell(GUI模式)。
    5. bin下,找到jmeter-n.cmd即可开启,但是会删除jmx脚本(非GUI模式)。
    6. bin下,找到jmeter-n-r.cmd即可开启,但是会删除jmx脚本(非GUI的远程模式)。
    7. bin下,找到jmeter-t.cmd即可开启,但是会删除jmx脚本(GUI模式)。
    8. bin下,找到jmeter-server.bat,可开启服务器模式。
    9. bin下,找到jmeter.sh即可开启(GUI模式)。
    10. 使用cmd控制台开启,先cd到ApacheJMeter.jar所在的路径,然后通过“java -jar arg”命令开启,如下图:

      注意看,启动时,JMeter会提示“Don‘t use GUI mode for load testing.”,意思其实是说,JMeter是支持无界面运行的,因为有界面的模式会影响压力或负载测试的准确度。但是为了做下文的演示,我还是开启GUI模式,非GUI模式会在之后的博文中进行介绍。

    2.开始之前的设置

    JMeter对于中文支持得已经很棒了,所以,我们把语言设置成中文,可以方便大家理解,如下图:

    就可以设置成简体中文了。

    3.官方标准脚本模板

    上来就巴拉巴拉说一大堆功能组件什么的,大家肯定会晕,所以我觉得官方的脚本模板就是一个很好的切入点,这样即可以看看一个标准的、结构清晰、功能完备的脚本长啥样,也可以初步认识下主要的功能组件。JMeter自带脚本在哪呢?如下图:

    以Web test plan为例,JMeter会生成一个标准的测试脚本模板,如下图:

    4.脚本里用到的主要功能组件

    4.1测试计划(Test Plan)

    测试计划是一项测试的根节点,用于描述整个的性能/功能测试,包含本次测试的所有相关功能。

    4.2配置元件(Configuration Elements)

    简单来说配置元件就是对于请求做各种配置的一系列组件,它是与取样器(发请求的东东)联系最紧密的组件,虽然它不能发送请求,但是它可以添加或修改请求。

    4.2.1HTTP请求默认值(HTTP Request Defaults)

    这么理解这个元件会简单些:该元件,用于设置其他HTTP请求取样器能用到的默认的值。例如,如果你的测试计划下面有很多请求都是指向相同的服务器地址/URL路径/端口号/请求参数等,那么你可以将这些数据保存在“HTTP请求默认值”元件中,然后再在其下方创建的任何HTTP请求取样器,如果不单独指定这些数据,那么它们都可以直接继承“HTTP请求默认值”元件中的服务器地址/URL路径/端口号/请求参数。如下图:

    4.2.2用户定义的变量(User Defined Variables)

    这个元件,真香,因为它是实现脚本参数化的最重要的元件。当你的测试步骤非常多,又用到了很多重复的数据时,一定要把这些数据作为参数提取出来,配置到“用户自定义的变量”元件中,这样在后期维护脚本的时候,会节省很多的时间。如下图:

    上图中这个参数host,在本文上一节的“HTTP请求默认值”元件中被设置为默认值,当然也可以在其他任何地方通过${host}这种格式进行调用,很方便。

    4.2.3HTTP Cookie管理器(HTTP Cookie Manager)

    当你的请求头Request Header需要包含Cookie,或者需要捕获响应Response返回的Cookie时,就需要用到此元件。它主要分为两种功能:

    1. 自动存储并发送Cookie,就像一个真正的浏览器一样。
    2. 可手动设置Cookie值,然后JMeter发送请求时就会带上所填写的Cookie值。

    作为自动存储器时,如果捕获并存储了Cookies,则HTTP Cookie管理器会将Cookies自动添加到该元件作用域内(也可以理解为“之后的”)所有对该站点所发起的请求上面,也就是说,在这之后创建的“HTTP请求取样器”都会默认添加Cookie管理器所保存的Cookie。在JMeter内部,每个线程Thread都有其自己的Cookie存储区域(Cookie Storage Area),假如Cookie中包含session信息,那么每个Thread都会有自己的session。注意,自动保存的Cookie信息在界面上是不显示的,但是可以在监听器(例如“查看结果树”元件)中看到结果。
    JMeter默认不保存跨域的Cookie,如果想要保存的话,找到bin下的jmeter.properties文件,修改其中的属性为“CookieManager.check.cookies=false”。
    你也可以将存储的Cookie信息保存为参数,首先找到bin下的jmeter.properties文件,修改其中的属性为“CookieManager.save.cookies=true”,然后JMeter会自动将Cookie中的信息保存成名字以“COOKIE_”为开头的格式的参数,例如“COOKIE_SESSIONID”。
    作为Cookie设置器时,你就可以手动设置Cookie值,例如sessionid、uid或token之类的。注意,如果有多个Thread,那么所有的线程都会使用当前设置的Cookie信息。

    图中还有一项功能:Cookie策略。默认的是Standard,这个在大多数情况下是适用的。至于其他策略,本人没有细研究过,所以不在这班门弄斧,上一张官网的解释吧,如下图:

    4.2.4HTTP信息头管理器(HTTP Header Manager)

    HTTP信息头管理器其实就是用于为发送的请求配置其Request Header信息的,就像下图中的这些信息:

    可以为整个线程组中所有的HTTP请求配置公共的请求头,如官方脚本中这样:

    或者也可以为每一条请求设置单独的Header,如我自己的脚本:

    4.2.5CSV数据文件设置(CSV Data Set Config)

    在做压力测试时,例如检查登录操作的压力,为了尽量拟真,一般都会为每个线程都设置不同的用户名密码,此时“CSV数据文件设置”元件就成了最好的选择。JMeter把CSV文件作为一个数据池,当测试需要大量的相同用途的数据,或者获取“随机抽取的数据”,就可以通过该元件设置的读取规则,来读取CSV中的数据。由于官方脚本中该元件是空的,不便于说明,因此我用自己的脚本来演示,如下:

    默认情况下,即使有多个线程,此CSV都只会被读取一次(一个线程读取一次还得了?),然后各个线程都会读取不同的行的数据(后台逻辑是,挨行读取,哪个线程先到了就先给哪个线程)。如果线程数多于行数,则意味着部分线程需要共享相同的数据,也意味着JMeter要循环读取CSV,因此千万要记得将“遇到文件结束符再次循环?”的选项置为True,如上图。

    4.3线程(Thread)

    如果把一套测试的各个步骤想象成一条工厂流水线的话,那么JMeter中的一个线程,就相当于这条测试流水线从开始到结束的传送带。在JMeter中,一个线程是测试的最小粒度,跟LoadRunner中的虚拟用户是一个概念,可以想象为,执行测试的一个小人儿,或者执行脚本的一条生产线。

    4.3.1线程组(Thread Group)

    线程组是一组虚拟用户的集合(或者说一组流水线的集合)。线程组是任何测试计划的起点,也就是说,一项测试在执行之前,我必须定义流水线是什么样的,例如流水线的数量(线程数),流水线的准备时间、循环次数,流水线遇到异常了是跳过,还是停止,还是重来?等等,如下图。

    每个线程将完全独立地执行测试计划。多个线程用于模拟与服务器应用程序的并发连接。
    Ramp-Up准备时间是告诉JMeter要花多长时间才能“加速”到选择的全部线程数。如果使用10个线程,并且准备时间是100秒,那么每个线程会间隔10(100 / 10)秒开始执行。如果有30个线程并且准备时间是120秒,则每个线程的启动间隔时间是4秒。注意,这个“准备时间”的目的是避免系统在测试开始时工作负载过大,所以一定要拿捏好这个时间,不能太短(否则系统负载很大),也不能太长(否则第一个线程都结束了,靠后的线程还没开始,你说尴不尴尬)。
    线程组还提供了一个调度器,用来配置整个线程组的持续时间(到了规定时长就停止运行)和启动延迟(等待多长时间开始线程组)。

    4.4取样器(Sampler)

    取样器是向服务器发送并接收请求的单元。JMeter的取样器包括:

    1. FTP请求
    2. HTTP请求(也可以用于SOAP或REST Webservice)
    3. JDBC请求
    4. Java对象请求
    5. JMS请求
    6. JUnit测试请求
    7. LDAP请求
    8. 邮件请求
    9. 操作系统进程请求
    10. TCP请求

    由于取样器只是一个向服务器发送并接收请求的单元,所以它需要与其他元件进行配合才能更好的完成测试:例如,如果为请求添加Cookie,则需要在测试计划中添加HTTP Cookie管理器;如果请求的header需要一些特殊的参数,则需要为取样器配置单独的HTTP信息头管理器;如果要查看并保存请求结果,则需要在测试计划中添加一个监听器,用于监听所有的发出和收到的请求的详细结果;还需要为每个取样器单独配置一个断言,用于判断返回的请求结果是否符合预期(比如,某个接口返回的请求的状态码虽然是200 success,但是实际报文中的结果与预期不符,甚至还有报错,如果不添加针对性的断言的话,JMeter会默认只检查状态码而判断此次请求是成功的)。

    4.4.1HTTP请求(HTTP Request)

    最常用的是HTTP请求取样器,如下图:

    下面我举个例子,例如登录操作,一般情况下,在接口层面会包含两步操作:
    1.GET登录页面,包括各种页面资源,如下图:

    2.POST用户名密码,服务器验证通过后返回登录成功的响应,如下图:

    因此可以使用两个HTTP取样器,一个GET一个POST,来实现这两个步骤,如下图:


    关于HTTP请求取样器的详细用法我会再开一篇博文进行描述,这里就不占用过多的篇幅了。

    4.4.2测试活动(Flow Control Action/Test Action)

    官方翻译为“测试活动”其实容易让人产生歧义,个人觉得翻译为线程执行逻辑控制器更为恰当。而测试活动虽然被划分到取样器分类里,但它完全没有取样器的功能,它最常见的用法是置于其他取样器后面,当作一个暂停线程执行等待的工具,如下图所示:

    4.5断言(Assertion)

    断言是用于更高精度地判断测试结果的方式,用于判断响应数据是否符合指定的预期。类似于Load Runner中的检查点,可以为取样器添加多个断言,提高测试的精确度。
    注意,断言的作用域是与其同级的所有取样器,所以如果想要为某一取样器添加断言,则必须把断言作为子节点,放置于采样器下面。
    一般我用的最多的是响应断言

    4.5.1响应断言(Response Assertion)

    响应断言主要用于判断请求/响应报文中是否包含/等于指定的字符串,如下图:

    注意,这里的Apply to有四个选项:

    1. Main sample and sub-samples
    2. Main sample only
    3. Sub-samples only
    4. JMeter Variable Name to use

    我看了很多博客,大部分,全都把这里翻译成“主取样器和子取样器”。。。错得简直离谱(就像小时候和同学一起抄作业,一个人抄错,后面的人越抄越错。。。)。所以我要在这里明确说明下:
    Sample(取样)和Sampler(取样器)完全不是一码事。取样器没有父子的关系。而取样的main和sub,指的是某一取样器,在发送和接收请求时,如果跟随了重定向的请求,然后取样到了一连串的请求,那么,取样器会将最后一个请求作为最终结果,也就是主取样结果,而所有跳转过程中产生的请求,作为子取样结果。 如下图:

    所以前条的意思就很明确了:

    1. Main sample and sub-samples(断言范围为当前取样器收到的所有请求)
    2. Main sample only(判断范围仅为当前取样器收到的主请求)
    3. Sub-samples only(判断范围仅为当前取样器收到的子请求)

    至于第四条“JMeter Variable Name to use”,其意思是“取指定name的JMeter参数的值,进行断言”。其可能用于如下场景,例如:取样器A的response中含有需要提取的值a,取样器B的response中含有需要提取的值b,那么在AB执行完后,使用正则表达式提取器,将a、b的值提取出来,然后使用BeanShell后置处理程序,定义一个新变量var x = a + b,这时候如果需要判断x的值是不是等于y,那么就需要在断言的“JMeter Variable Name to use”这里,填入x,然后“测试字段”选择“文档(文本)”,“匹配规则”选择“相等”,最后“测试模式”填写y即可。

    4.6定时器(Timer)

    定时器主要用于在操作之间设置等待时间。不过定时器需要额外注意的是:

    • 定时器是在每个sampler(取样器)之前执行的,而不是之后。是的,你没有看错,不管这个定时器的位置放在sampler之后,还是之下,它都在sampler之前执行;
    • 定时器是有作用域的,当执行一个sampler之前时,所有当前作用域内的定时器都会被执行。如果希望定时器仅应用于其中一个sampler,则把该定时器作为子节点加入;
    • 如果希望在sampler执行完之后再等待,则可使用Test Action

    4.6.1统一随机定时器(Uniform Random Timer)

    名字吓唬人的定时器,哈哈。功能其实很简单,就是让线程随机等待一段时间,时间范围是:Constant Delay Offset <= 等待时间 <= Constant Delay Offset + Random Delay Maximum。如下图:

    统一(Uniform)的意思就是,延时时间在指定范围内且每个时间点的取值概率相同,每个时间间隔都有相同的概率发生,总的延迟时间就是随机值和偏移值之和。

    4.6.2高斯随机定时器(Gaussian Random Timer)

    又是个名字吓唬人的定时器,功能也很简单,即让线程随机等待一段时间,总延迟 = 高斯分布值(平均0.0和标准偏差1.0)* 指定的偏差值 + 固定延迟偏移(计算参考:Math.abs((this.random.nextGaussian() * 偏差值) + 固定延迟偏移))。如下图:

    高斯随机定时器和统一随机定时器的区别在于,高斯的延迟时间的分布概率,是属于正态分布(高斯分布)的。

    4.7后置处理器(Post-Processors)

    后置处理器一般置于取样器之后,用于处理取样器所接收到的response信息,比如提取响应文本中的特定信息(例如我在CSDN写了文章,接口返回了我的文章列表及文章实体的属性,我需要通过文章名称提取某篇文章的id)。而如何提取,则根据报文的格式来选择,如果是JSON,则选用“JSON提取器”;如果是HTML,则选用“XPath提取器”;或者都使用“正则表达式提取器”,因为其适用范围最广。
    注意,后置处理器的作用域是与其同级的所有取样器,所以如果想要为某一取样器添加后置处理器,则必须把后置处理器作为子节点,放置于采样器下面。

    4.7.1正则表达式提取器(Regular Expression Extractor)

    正则表达式提取器如下图:

    正则表达式提取器的“Apply to”跟“响应断言”一样:

    1. Main sample and sub-samples(提取范围为当前取样器收到的所有请求)
    2. Main sample only(提取范围仅为当前取样器收到的主请求)
    3. Sub-samples only(提取范围仅为当前取样器收到的子请求)
    4. JMeter Variable Name to use(取指定name的JMeter参数的值,再进行提取)

    “要检查的响应字段”:

    • 主体(Response Body):响应报文的主体,最常用;
    • Body(unescaped):Body是替换了所有的html转义符的响应主体内容,注意html转义符处理时不考虑上下文,因此可能有不正确的转换,不太建议使用;
    • Body as a Document:从不同类型的文件中提取文本,注意这个选项比较影响性能;
    • 信息头(Response Headers):响应信息头;
    • Request Headers:请求信息头;
    • URL:请求URL;
    • 响应代码(Response Code):响应状态码,如200、500等;
    • 响应信息(Response Message):响应信息,如OK;

    “引用名称”:提取出的数据的名称,其他功能可以使用${名称}的格式进行调用。
    “正则表达式”:使用正则表达式解析响应结果。
    “模板”:正则表达式的提取模式。如果正则表达式有多个提取结果,则结果是数组形式,模板$1 $ ,$2 $等等,表示把解析到的第几个值赋给变量。若只有一个结果,则只能是$1 $。
    “匹配数字”:正则表达式匹配数据的结果可以看做一个数组,表示如何取值:0代表随机取值,正数n则表示取第n个值(比如1代表取第一个值),负数则表示提取所有符合条件的值。
    “缺省值”:匹配失败时候的默认值,我一般都设置为null。

    4.8监听器(Listener)

    监听器也是压力/接口测试过程中一个非常重要的组件,它主要用于存储和可视化展示测试的结果。
    一般来说,为整个线程组添加一个于其同级的监听器即可,它便可以记录整个线程组的测试结果以及详情。
    注意,JMeter有GUI模式和无GUI的CLI(Command Line Interface)模式,在这两种模式下,监听器的保存数据的逻辑略有差别:

    • GUI模式:监听器只能临时保存测试详情及结果,即,重启JMeter后所有的测试结果都会丢失。所以如果想查看以往的数据,必须在监听器中选择“将所有数据写入文件”(文件格式为xml、jtl或csv),将数据保存到本地文件中。
    • CLI模式:监听器不保存测试详情及结果,因为没有GUI,看不了可视化的结果,并且保存数据会影响压测性能,所以JMeter也不会处理并保存测试结果。所以如果想保存数据,需要在监听器中选择“将所有数据写入文件”(文件格式为xml、jtl或csv),将数据保存到本地文件中。

    4.8.1查看结果树(View Results Tree)

    “查看结果树“是最常用的监听器之一,因为其可以按照执行顺序,将各个取样器及断言的结果呈树状展示出来。如下图(由于官方的脚本无法运行出结果,所以树是空的):

    运行我自己的脚本,可以看到结果树的样子,如下图:

    注意,JMeter为了性能优先,默认情况下即使保存结果到本地文件,也只会保存”取样器结果“这一栏的数据(数据量小,对效率影响小),所以在我们调试的时候,如果想把取样器结果、request headers、request body、response headers和response body这些数据全部保存下来,则需要在”配置“选项中,进行修改,如下图:

    内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: