🍅?點擊文末小卡片?，免費獲取軟件測試全套資料，資料在手，漲薪更快

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

JMeter接口測試

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

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

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于做【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。