jmeter-結果分析



一、Listener的使用

1.聚合報告

通過這份報告我們就可以得到通常意義上性能測試我們所最關心的幾個結果了。

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

Average -- 平均響應時間

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

90% Line -- 所有transaction中90%的transaction的響應時間都小于xx

Min -- 最小響應時間

Max -- 最大響應時間

PS: 以上時間的機關均為ms

Error -- 出錯率

Troughput -- 吞吐量，機關：transaction/sec

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

2.檢視結果樹

通過這個Listener，我們可以看到上圖很詳細的每個transaction它所傳回的結果，其中紅色是指出錯的transaction，綠色則為通過

如果你測試的場景會有很多的transaction完成，建議在這個Listener中僅記錄出錯的transaction就可以了。要做到這樣，你隻需要将Log/Display:中的Errors勾中就可以了,如圖：

二、.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秒以内得到響應時，會感覺系統的響應很快；當使用者在2-5秒之間得到響應時，會感覺系統的響應速度還可以；當使用者在5-10秒以内得到響應時，會感覺系統的響應速度很慢，但是還可以接受；而當使用者在超過10秒後仍然無法得到響應時，會感覺系統糟透了，或者認為系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。故該系統的使用者資訊查詢資訊頁面的在10到25人并發通路時，系統響應速度很快，25人到50人并發通路時速度還可以，50人到100人并發通路就比較慢了。