JMeter接口&性能測試

JMeter接口測試

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

一、建立測試任務

添加線程組，右擊測試計劃，在快捷菜單單擊添加-》線程(用戶)-》線程組。設置線程組主要包含三個參數：線程數、Ramp-Up、循環次數。

線程數：設置虛擬用戶數。一個虛擬用戶佔用一個進程或線程。線程數就至關於虛擬用戶數。

Ramp-Up：設置的線程數啓動時長，單位爲秒。若是線程數爲100，準備時長爲20秒，那麼須要20秒啓動100個線程，平均每秒啓動5個線程。

循環次數：每一個線程發送請求的個數。若是線程數爲100，循環次數爲2，那麼每一個線程發送2次請求，總請求數爲100*2=200次。若是勾選了「永遠」複選框，那麼全部線程會循環發送請求，直到手動單工具欄中止按鈕，或者設置的線程運行時間結束纔會中止運行。

此次針對接口測試，默認都爲1就行。

二、添加get的HTTP請求

右擊線路組，在快捷菜單單擊添加-》取樣器-》HTTP請求。

協議：向目標服務器發送HTTP請求時的協議，能夠是HTTP或HTTPS，默認不填爲HTTP。

服務器IP和端口：輸入目標服務器地址和端口號。

內容編碼：默認值爲iso8859

方法：針對請求方法選擇

路徑：輸入請求目標地址

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

三、添加post的HTTP請求

方法同上，只是請求方法不一樣，此次改用POST傳遞參數向服務器及POST請求的URL地址。

根據開發提供的接口文檔，參考傳入參數選項，錄入進去。

四、添加斷言

分別右擊發佈會查詢信息和添加發佈會信息，添加-》斷言-》響應斷言

此次選擇響應文，而後錄入須要匹配的數據。

五、添加察看結果樹

右擊發布系統項目，單擊添加-》監聽器-》察看結果樹，運行後：

成功顯示綠色標誌，失敗顯示紅色標示，能夠查看到每一個用例返回的數據。

六、添加用表格察看結果

能夠更詳細查看到耗時及字節大小，結果狀態，用例信息。

JMeter性能測試

因爲JMeter支持錄製不夠好，如今經常使用的方法是使用Badboy錄製,生成JMeter腳本,而後用JMeter打開,添加監聽器來查看結果。

雙擊軟件圖標開啓badboy便可看到如下界面：

一、開始錄製

在地址欄(圖中用紅色框住部分)中輸入你須要錄製的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個併發用戶數量運行一次登陸測試。

二、添加監控

這個主要是用來查看測試結果用的，能夠以不一樣形式展示，這裏舉例說明添加監聽器：用表格查看結果、聚合報告和圖形報告thread Group->添加->監聽器->聚合報告（圖形報告、用表格查看結果）以下圖所示：

程序運行完成之後，就能夠查看相應的測試結果這裏以1000個線程組瞬時併發爲例獲得以下報告：

上圖表參數含義以下：

    一、樣本數目是總共發送到服務器的請求數。
　　二、最新樣本是表明時間的數字,是服務器響應最後一個請求的時間。
    三、吞吐量是服務器每分鐘處理的請求數。
    四、平均值是總運行時間除以發送到服務器的請求數。
    五、中間值是表明時間的數字，有一半的服務器響應時間低於該值，而另外一半高於該值。
    六、偏離表示服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分佈。

能夠看出當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不會出現錯誤，所獲得性能測試數據準確。

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