提示:聚合报告组件的使用和察看结果树组件的使用方式相同。本篇文章主要是详细的介绍一下聚合报告组件内容,不做示例演示。

1、聚合报告介绍

在使用JMeter进行性能测试时,聚合报告(Aggregate Report)可以说是必用的监听器。

(1)聚合报告的生成方式

聚合报告有2中生成方式:

    在已有.jtl文件的情况下,直接选择加载文件即可生成聚合报告。     在运行JMeter的过程中,动态生成聚合报告。

    提示:我们一直使用GUI模式操作JMeter,所以看到的聚合报告组件中的内容,是第二种生成方式。等之后我们介绍非GUI模式操作JMeter时,会讲解第一种方式生成的聚合报告。

(2)聚合报告的数据来源

聚合报告中统计的数据来源,其实都是从统计的SampleResult中收集的数据。

需要特别注意的是:

    聚合报告中的每一行,代表一个请求。注意:同名的请求会只显示一个,把结果合并。    聚合报告中的每一列信息,是由SamplingStatCalculator类的不同方法实现统计的,相同名称的请求会共用同一个SamplingStatCalculator。    不管是JMeter实时生成聚合报告,还是根据已经存在.jtl结果文件生成的聚合报告,最终的底层都是调用StatGraphVisualizer类的add(sampleResult)方法来生成表格的一行数据,传递的参数为每个请求的请求结果(sampleResult)信息。

add方法的调用时机:

1)根据.jtl文件生成报告时,每解析一行数据就调用一次add方法。

2)实时运行生成聚合报告,每请求一次,就调用一次add方法。

提示:

    1、注意:使用聚合报告时,测试计划中不要用相同的的请求取样器名称。     2、观察聚合报告的结果发现,聚合报告是累加的,即每次运行的结果统计都是基于前一次运行的结果进行统计,包括发起的请求样本数等都是叠加的。

2、聚合报告界面详解

添加聚合报告组件方式:选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告。

界面内容如下图所示:

聚合报告界面说明:

名称:聚合报告组件的自定义名称,见名知意最好。注释:即添加一些备注信息,对该聚合报告组件的简短说明,以便后期回顾时查看。

(1)将所有数据写入一个文件

在JMeter中,我们可以将脚本测试中每个用户的访问内容,都存储到一个文件中。

需要操作聚合报告组件中的如下位置:

说明:

文件名:输入一个文件的完整路径,后缀可以为.csv,.html等。文件若不存在,则创建该文件;若已存在该文件,运行结果选择覆盖原有文件即可。显示日志内容:

1)仅日志错误:仅保存错误的日志信息到文件中。

2)仅成功日志:仅保存正常响应的日志信息到文件中。

配置(configure):配置测试结果文件中需要记录的内容,可以依据自己需求来选择。  

 如下图所示:

    提示:我们可以点击“浏览”按钮,选择已存储的聚合报告文件,来查看之前脚本的请求结果。

(2)聚合报告列表项介绍

1、Label:请求的名称,就是脚本中Sampler的名称。

2、#Samples(样本):总共发给服务器的请求数量,如果模拟10个用户,每个用户迭代10次,那么总的请求数为:10*10 =100次。

3、Average(平均值):默认情况下是单个Request的平均响应时间,当使用了Transaction Controller(事务控制器) 时,也可以用Transaction的时间,来显示平均响应时间 ,单位是毫秒。

4、Median(中位数):50%用户的响应时间小于该值。

5、90% Line(90% 百分位):90%用户的响应时间小于该值。

6、95% Line(95% 百分位):95%用户的响应时间小于该值。

7、99% Line(99% 百分位):99%用户的响应时间小于该值。

8、Min(最小值):最小的响应时间。

9、Maximum(最大值):最大的响应时间。

10、Error%(异常%):错误率=错误请求的数量/请求的总数。

11、Throughput(吞吐量):默认情况下表示每秒完成的请求数(Request per Second)。

12、Received KB/sec (接收数据):每秒从服务器端接收到的数据量。

13、Sent KB/sec(发送):每秒发送到服务器端的数据量。

(3)保存聚合报告报表

    在标签中包含组名称?:需要就勾选,不需要则取消勾选。     保存表格数据:就是保存聚合报告页面中显示的表格内容,而不是用户的请求日志信息。     保存表格标题:需要就勾选。

3、聚合报告中信息点说明

(1)百分位数的说明

    1、科普:90% Line参数正确的含义

在这里我觉得有必要说一下对 90%Line 的理解:

很多人都理解为:90%用户的平均响应时间。我之前也一直这样认为,但是后来才发现我错了。

那看看JMeter 官网是怎么说的?

90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.

意思是:有 90% 的样本不超过这个时间, 剩下的样品至少只要等于或超过这个时间。

换句话说,就表示有90%的请求耗时,都在这个时间之内。

    2、这里涉及到一个数学中的概念:百分位数

百分位数:统计学术语,如果将一组数据从大到小排序,并计算相应的累计百分位,则某一百分位所对应数据的值,就称为这一百分位的百分位数。可表示为:一组n个观测值按数值大小排列,处于p%位置的值称第p百分位数。

百分位通常用第几百分位来表示,如以身高为例,身高分布的第5百分位,表示有5%的人的身高小于此测量值,95%的身高大于此测量值。

    3、再举个例子:

有10个数:1、2、3、4、5、6、7、8、9、10,按由小到大将其排列。

求它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line就是9 。

    4、那么百分位数用在性能测试中有什么意义呢?

它可以使用我们的分析结果更准确!

因为在评估一次测试的结果时,仅仅有平均响应时间是不够的。假如在一次测试中,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒。你会不会想到最小和最大响应时间,这样如此大的偏差,是否会导致平均值本身并不可信?

如果我们把每个请求的响应时间用Excel统计出来,会发现那个最大值的出现几率,只不过是千分之一甚至万分之一,剩下99%的用户请求的响应时间,都是在性能需求所定义的范围之内的。所以为了更准确的衡量整体请求的耗时情况,除了平均响应时间之外,还要有90%Line、95%Line、99%Line来辅助统计。

总结一下,聚合报告中的百分位数的含意:

    Median:中位数,50%用户的响应时间在小于该值,注意它与Average平均响应时间的区别。    90% Line:90%用户的响应时间小于该值。    95% Line:95%用户的响应时间小于该值。    99% Line:99%用户的响应时间小于该值。

(2)吞吐量说明

吞吐量(QPS):默认情况下表示每秒完成的请求数。

误区:把吞吐量值当服务器每秒处理的事务数的值(TPS)。

经常有的同学直接把聚合报告中的吞吐量当作TPS来看,这种做法是相当不严谨的。

那么聚合报告中的吞吐量什么情况下可以看成TPS?

从严格意义来讲就是交易成功率为100%(一个完整的事务)。

还有一种情况是,交易失败率在你可以接受的范围内,也就是对当前测试整体结果影响不大,到了可以忽略的程度。

 

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式: 这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。

相关阅读

评论可见,请评论后查看内容,谢谢!!!评论后请刷新页面。