jmeter測試報告分析

https://blog.csdn.net/qq_24373725/article/details/78952447

 

Jmeter報告解析
　　一、Aggregate Report 解析
　　Aggregate Report 是 JMeter 經常使用的一個 Listener，中文被翻譯爲「聚合報告」。今天再次有同行問到這個報告中的各項數據表示什麼意思，順便在這裏公佈一下，以備你們查閱。
　　若是你們都是作Web應用的性能測試，例如只有一個登陸的請求，那麼在Aggregate Report中，會顯示一行數據，共有10個字段，含義分別以下。
　　Label：每一個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值
　　#Samples：表示你此次測試中一共發出了多少個請求，若是模擬10個用戶，每一個用戶迭代10次，那麼這裏顯示100
　　Average：平均響應時間——默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以Transaction 爲單位顯示平均響應時間
　　Median：中位數，也就是 50％ 用戶的響應時間
　　90% Line：90％ 用戶的響應時間
　　Note：關於 50％ 和 90％ 併發用戶數的含義，請參考下文
　　http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html
　　Min：最小響應時間
　　Max：最大響應時間
　　Error%：本次測試中出現錯誤的請求的數量/請求的總數
　　Throughput：吞吐量——默認狀況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的 Transaction per Second 數
　　KB/Sec：每秒從服務器端接收到的數據量，至關於LoadRunner中的Throughput/Sec
　　基本知識：
　　一、吞吐量：是指在沒有幀丟失的狀況下，設備可以接受的最大速率。
　　二、存儲的最小單位是字節Byte，對於存儲單位，有如下幾個單位，GB、MB和KB，那麼這三者之間的換算關係是：1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。
　　Bit ：「位」，稱爲bit，也就是比特，有的時候也稱爲位。一個字節爲8位二進制表示。
　　Byte：「字節」，一個字節就是8比特。
　　三、Mbps (million bits per second 兆位/秒) 表明每秒傳輸1，000，000比特。該縮寫用來描述數據傳輸速度。例如：4Mbps=每秒鐘傳輸4M比特。
　　數據傳輸速率的單位，字母b（bit）是比特和字母 B （Byte）是字節。
　　四、吞吐量與帶寬的區分：吞吐量和帶寬是很容易搞混的一個詞，二者的單位都是Mbps.先讓咱們來看二者對應的英語，吞吐量:throughput ; 帶寬: Max net bitrate 。當咱們討論通訊鏈路的帶寬時，通常是指鏈路上每秒所能傳送的比特數。咱們能夠說以太網的帶寬是10Mbps。可是，咱們須要區分鏈路上的可用帶寬（帶寬）與實際鏈路中每秒所能傳送的比特數（吞吐量）。咱們傾向於用「吞吐量」一次來表示一個系統的測試性能。這樣，由於實現受各類低效率因素的影響，因此由一段帶寬爲10Mbps的鏈路鏈接的一對節點可能只達到2Mbps的吞吐量。這樣就意味着，一個主機上的應用可以以2Mbps的速度向另外的一個主機發送數據。
　　五、方差和標準差都是用來描述一組數據的波動性的（集中仍是分散），標準差的平方就是方差。方差越大，數據的波動越大。
詳細結果分析：用過LoadRunner的人應該都知道，LoadRunner會爲咱們提供一大堆圖標和曲線。可是在Jmeter裏，咱們只能找到幾個可憐的Listener來方便咱們查看測試結果。可是，對於初學者來講，一些簡單的結果分析工具可使咱們更容易理解性能測試結果的分析原理。因此，千萬別小看這幾個簡單的Listener啊。

A.Aggregate Report 聚合報告

 

咱們能夠看到，經過這份報告咱們就能夠獲得一般意義上性能測試所最關心的幾個結果了。

Samples -- 本次場景中一共完成了多少個Transaction

Average -- 平均響應時間

Median -- 統計意義上面的響應時間的中值

90% Line -- 全部transaction中90%的transaction的響應時間都小於xx

Min -- 最小響應時間

Max -- 最大響應時間

PS: 以上時間的單位均爲ms

Error -- 出錯率

Troughput -- 吞吐量，單位：transaction/sec

KB/sec -- 以流量作衡量的吞吐量

B.View Results Tree 以樹狀列表查看結果

 

經過這個Listener，咱們能夠看到很詳細的每一個transaction它所返回的結果，其中紅色是指出錯的transaction，綠色則爲經過的。

若是你測試的場景會有不少的transaction完成，建議在這個Listener中僅記錄出錯的transaction就能夠了。要作到這樣，你只須要將Log/Display:中的Errors勾中就能夠了。

2、.jtl文件的分析

在性能測試過程當中，咱們每每須要將測試結果保存在一個文件當中，這樣既能夠保存測試結果，也能夠爲往後的性能測試報告提供更多的素材。

Jmeter中，結果都存放在.jtl文件。這個.jtl文件能夠提供多種格式的編寫，而通常咱們都是將其以csv文件格式記錄，這樣作是由於csv文件格式看起來比較方便，更重要的是這樣作能夠爲二次分析提供不少便利。

我這裏所說的二次分析是指除了使用Listener以外，咱們還能夠對.jtl文件進行再次分析。

a.設置jtl文件格式

咱們從jmeter官方網站中下載下來的Jmeter解壓後是能夠直接使用的。可是，使用默認配置生成的jtl文件內容並不能知足咱們的須要。因而咱們必須進行必要的設置。在2.2版本中，若是要修改jtl設置必需要到jmeter.properties文件中設置；可是在2.3版本中，咱們只須要在界面上設置就能夠了。你只須要選擇某個Listener，點擊頁面中的configure按鈕。此時，一個設置界面就會彈出來，建議多勾選以下項：Save Field Name，Save Assertion Failure Message。

b.jtl文件中的各項

通過了以上設置，此時保存下來的jtl文件會有以下項：

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,Latency

請求發出的絕對時間，響應時間，請求的標籤，返回碼，返回消息，請求所屬的線程，數據類型，是否成功，失敗信息，字節，響應時間

其中聚合報告中的，吞吐量=完成的transaction數/完成這些transaction數所須要的時間；平均響應時間=全部響應時間的總和/完成的transaction數；失敗率=失敗的個數/transaction數

舒適提示：在jmeter2.2和2.3版本中，都存在的一個問題是當咱們從新打開jmeter，使用某個Listener來查看jtl文件時，jmeter是會報錯的。所以當你使用命令行方式完成了一個場景的測試後，你獲得的只是一堆保存在jtl文件中的原始數據。因此知道聚合報告中的各項的來源是能夠方便你們擺脫測試工具來進行結果的分析。

總的來講，對於jmeter的結果分析，主要就是對jtl文件中原始數據的整理，我是使用一些小腳本進行相關的分析的，不知道你打算怎麼作呢？

反正實踐後，你總能找到一條屬於本身的數據分析之路。

測試結果的分析說明

說明：

Label：每一個 JMeter 的 element （例如 HTTP Request ）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值

#Samples：表示你此次測試中一共發出了多少個請求，個人測試計劃模擬 10 個用戶，每一個用戶迭代 10 次，所以這裏顯示 100

Average：平均響應時間 —— 默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以 Transaction 爲單位顯示平均響應時間

Median：中位數，也就是 50 ％用戶的響應時間

90% Line： 90 ％用戶的響應時間

Min： 最小響應時間

Max： 最大響應時間

Error%：本次測試中出現錯誤的請求的數量 / 請求的總數

[NextPage]

Throughput：吞吐量 —— 默認狀況下表示每秒完成的請求數（ Request per Second ），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的 Transaction per Second 數

KB/Sec：每秒從服務器端接收到的數據量，至關於 LoadRunner 中的 Throughput/Sec

我分別模擬十、2五、50、75和100個用戶併發訪問該頁面，根據報告所得測試結果做出以下統計。注：時間單位是ms

 

用戶數 #Samples Average Median 90%Line Min Max Error% Throughput KB/Sec

10 642 672 688 125 125 719 00.0 14.8/sec 221.15

25 250 1620 1687 1750 250 1781 00.0 14.5/sec 217.14

50 500 3319 3438 3578 281 3657 00.0 14.2/sec 212.02

75 750 4887 5109 5584 328 7094 00.0 14.5/sec 216.67

100 1000 6244 6485 6672 250 6844 00.0 15.1/sec 225.43

通常狀況下，當用戶可以在2秒之內獲得響應時，會感受系統的響應很快；當用戶在2-5秒之間獲得響應時，會感受系統的響應速度還能夠；當用戶在5-10秒之內獲得響應時，會感受系統的響應速度很慢，可是還能夠接受；而當用戶在超過10秒後仍然沒法獲得響應時，會感受系統糟透了，或者認爲系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。故該系統的用戶信息查詢信息頁面的在10到25人併發訪問時，系統響應速度很快，25人到50人併發訪問時速度還能夠，50人到100人併發訪問就比較慢了。--------------------- 做者：slq520 來源：CSDN 原文：https://blog.csdn.net/qq_24373725/article/details/78952447 版權聲明：本文爲博主原創文章，轉載請附上博文連接！