JMeter介面測試

目前最新版本發展到5.0版本，需要Java7以上版本環境，下載解壓目錄後，進入\apache-jmeter-5.0\bin\，雙擊ApacheJMeter.jar檔案啟動JMemter。

1、建立測試任務

新增執行緒組，右擊測試計劃，在快捷選單單擊新增-》執行緒(使用者)-》執行緒組。設定執行緒組主要包含三個引數：執行緒數、Ramp-Up、迴圈次數。

執行緒數：設定虛擬使用者數。一個虛擬使用者佔用一個程序或執行緒。執行緒數就相當於虛擬使用者數。

Ramp-Up：設定的執行緒數啟動時長，單位為秒。如果執行緒數為100，準備時長為20秒，那麼需要20秒啟動100個執行緒，平均每秒啟動5個執行緒。

迴圈次數：每個執行緒傳送請求的個數。如果執行緒數為100，迴圈次數為2，那麼每個執行緒傳送2次請求，總請求數為100*2=200次。如果勾選了“永遠”複選框，那麼所有執行緒會迴圈傳送請求，直到手動單工具欄停止按鈕，或者設定的執行緒執行時間結束才會停止執行。

這次針對介面測試，預設都為1就行。

2、新增get的HTTP請求

右擊線路組，在快捷選單單擊新增-》取樣器-》HTTP請求。

協議：向目標伺服器傳送HTTP請求時的協議，可以是HTTP或HTTPS，預設不填為HTTP。

伺服器IP和埠：輸入目標伺服器地址和埠號。

內容編碼：預設值為iso8859

方法：針對請求方法選擇

路徑：輸入請求目標地址

引數：錄入查詢的引數數值

3、新增post的HTTP請求

方法同上，只是請求方法不同，這次改用POST傳遞引數向伺服器及POST請求的URL地址。

根據開發提供的介面文件，參考傳入引數選項，錄入進去。

4、新增斷言

分別右擊發佈會查詢資訊和添加發佈會資訊，新增-》斷言-》響應斷言

這次選擇響應文，然後錄入需要匹配的資料。

5、新增察看結果樹

右擊發布系統專案，單擊新增-》監聽器-》察看結果樹，執行後：

成功顯示綠色標誌，失敗顯示紅色標示。

6、新增用表格察看結果

可以更詳細檢視到耗時及位元組大小，結果狀態，用例資訊。

JMeter效能測試

由於JMeter支援錄製不夠好，現在常用的方法是使用Badboy錄製,生成JMeter指令碼,然後用JMeter開啟,新增監聽器來檢視結果。

雙擊軟體圖示開啟badboy即可看到以下介面：

1、開始錄製

在位址列(圖中用紅色框住部分)中輸入你需要錄製的Web應用的URL,並點選紅圓點按鈕開始錄製。開始錄製後,你可以直接在Badboy內嵌的瀏覽器(主介面的右側)中對被測Web應用進行操作,所有的操作都會被記錄在主介面左側的編輯視窗中：如下圖所示

將指令碼匯出為jmeter

執行緒數代表傳送請求的使用者數目，Ramp-up period（inseconds）代表每個請求發生的總時間間隔，單位是秒。假如我的請求數目是5，而Ramp-up period（inseconds）引數是10，那麼每個請求之間的間隔就是 10／5，也就是2秒。如果Ramp-up period（inseconds）設定為0就代表併發請求。

最後，清除迴圈次數的複選項“永遠”，然後輸入１。這個值是告訴JMeter你的測試重複多少次。如果你輸入1，那麼JMeter只會執行一次測試。要不停的執行你的測試計劃，選中“永遠”複選框。

如下圖摸擬1000個併發使用者數量執行一次登入測試。

2、新增監控

這個主要是用來檢視測試結果用的，可以以不同形式展現，這裡舉例說明新增監聽器：用表格檢視結果、聚合報告和圖形報告thread Group->新增->監聽器->聚合報告（圖形報告、用表格檢視結果）如下圖所示：

程式執行完成以後，就可以檢視相應的測試結果這裡以1000個執行緒組瞬時併發為例得到如下報告：

上圖表引數含義如下：

    1、樣本數目是總共傳送到伺服器的請求數。
　　2、最新樣本是代表時間的數字,是伺服器響應最後一個請求的時間。
    3、吞吐量是伺服器每分鐘處理的請求數。
    4、平均值是總執行時間除以傳送到伺服器的請求數。
    5、中間值是代表時間的數字，有一半的伺服器響應時間低於該值，而另一半高於該值。
    6、偏離表示伺服器響應時間變化、離散程度測量值的大小，或者，換句話說，就是資料的分佈。

可以看出當1000人瞬時併發時平均響應時間為1630ms，吞吐量為3,940.887/分鐘，平均響應中值為230ms。

圖表含義說明如下：

Label：說明是請求型別，如Http，FTP等請求。

#Samples：也就是圖形報表中的樣本數目，總共傳送到伺服器的樣本數目。

Average：也就是圖形報表中的平均響應時間，是總執行時間除以傳送到伺服器的請求數。

Median：也就是圖形報表中的中間值50%使用者響應時間，有一半的伺服器響應時間低於該值而另一半高於該值。

90%line：是指90%請求的響應時間比所得數值還要小，也就是90%使用者的響應時間。

Min：是代表時間的數字,是伺服器響應的最小時間。

Max: 是代表時間的數字,是伺服器響應的最大時間。

Error%:請求的錯誤百分比。本次測試中出現錯誤的請求的數量/請求的總數。

Throughput:也就是圖形報表中的吞吐量，這裡是伺服器每單位時間處理的請求數，注意檢視是秒或是分鐘。預設情況下表示每秒完成的請求數。

KB/sec:每秒從伺服器端接收到的資料量。

要所得的資料為正確，聚合報告error%必須為0.00%,否則說明使用者沒有全部通過測試，這裡得到平均響應時間1630ms，平均響應中中值為230ms

上圖Error出現錯誤，所得的資料不是準確，從日誌和表格來看中間過程發生連線請求超時，在響應時間內，接收請求數響應時間為０。如下圖所示：

在測試過程中，平均響應時間、吞吐量、併發連線數是我們效能測試的一個重要衡量指標，但是在測試中，特別是在聚合報告中，得出的90%Line等同於該使用者提出的90%響應時間,這個數值對我們效能測試分析也很有參考價值。90%響應時間是說在傳送的請求中，90%的使用者響應時間都比得到的數值上要短，同時說明，一個系統在應用時，90%的使用者響應時間都能達到這個數值，那麼就為系統性能分析提供了很好的參考價值。

如果把執行緒數改為500併發連線請求，結果Error不會出現錯誤，所得到效能測試資料準確。

總之，需要不斷的調優對比資料，接近最佳狀態，確定負載達到多少併發數量。