前言:
本文主要介紹了如何利用jmter進行接口的性能測試
1.在測試計劃中添加線程組
1.1.線程組界面中元素含義
如果點擊循環次數為永遠:
2.添加HTTP取樣器
2.1.填寫登錄接口的各個參數
2.2.在線程組下面增加查看結果樹
請求成功的情況:
請求失敗的情況:
我們注意到在同一個系統中,協議+IP+端口號是不會發生改變的,所以我們需要添加HTTP請求默認值
3.添加HTTP請求默認值
當取樣器中存在未配置的選項,會直接去HTTP請求默認值配置中去取;取樣器中配置了的選線不會去http請求默認值配置中取
當我們在測試列表頁接口的時候,發生了錯誤,因為我們沒有能獲取到用戶的登錄信息,直接跳過登錄進入列表頁,這肯定是不行的,因此我們還需要給HTTP請求添加請求頭數據
4.給HTTP請求添加請求頭數據
注意左側目錄跟二叉樹結構類似:
5.Json提取器
接口響應成功,通過提取返回值對應字段,可用于其他接口的參數配置
5.1.添加Json提取器
Json操作符參考:
5.2.添加Json配置
5.3.配置Json提取的參數
注意變量名要用 ${變量名} 的格式!
當然我們也可以輸入表達式,點擊右側的test按鈕檢查json提取表達式寫的是否正確?
注意要先調整成JSON Path Tester格式?
如何提取登錄接口返回值里的data數據,作為列表頁接口的請求信息呢?
如果多個接口中都有符合條件的json提取字段,則會發生覆蓋,那我們如何只提取登錄界面的token呢?根據目錄的主從關系!
想象場景:有兩百個詳情頁接口,每個接口都要用到寫死的id值,而這個id值后續可能需要修改---最好的方式用批量修改的方式
6.用戶定義變量
一次修改,終身受益!
解決bug
?當出現問題時,先放在postman上面進行運行看看正確情況,在jemter上不好發現錯誤
添加博客時,出現了內部的錯誤
將請求的content-type類型的數據修改之后,成功了!
7.JSON斷言
接口發送請求成功,響應碼為200并不能完全代表接口請求成功,我們更多需要關注接口響應數據是否符合預期。
7.1.添加斷言
7.2.添加JSON配置
注意:
- 若不選Additionally assert value,表示添加斷言值,則可用來判斷字段是否存在
- 選擇Additionallyassert value,則必須添加Expected Value期望的斷言值
- 若不選Match as regular expression正則匹配,則Expected Value必須填寫完整,少一個字符都會導致斷言失敗
- 若選擇Match as regular expression正則匹配,則Expected Value可以僅寫上部分關鍵詞即可斷言成功
正則表達式的使用方法:
8.同步定時器(集合點)
我們如果不手動添加同步定時器,那么多線程是達不到同步的效果的,那么我們創建多線程就失去了意義。
如下圖:配置了五個線程,這五個線程是陸陸續續的完成了測試計劃,誰先準備好誰先執行
所以我們要添加同步計時器:
這下我們測試多線程就完美實現了同步的效果!
TIP:
模擬用戶組的數量不能超過線程組里配置的線程數
當準備好的線程數>=配置數量,就直接發送請求當配置的數量小干線程數時,最好把循環打開,避免最后一次為準備好的線程數量達不到并發數
8.CSV數據文件設置
以登陸接口為例,當我們執行登陸接口的性能測試時,手動配置了用戶名和密碼為固定的username和password,然而實際使用中不可能只有一個用戶登陸,為了模擬更真實的登錄環境,我們需要提供更多的用戶username和password來實現登錄操作、
添加方式:線程組--配置元件--CSV數據文件設置
操作步驟:
8.1.CSV數據文件設置
- 文件名:填寫csv文件的路徑。建議使用絕對路徑。
- 文件編碼:UTF-8
- 變量名稱:從csv數據文件中讀起的數據需要保存到的變量名。有多個變量時用逗號分隔
- 是否忽略首行:是否從csv數據文件第一行開始讀取。
- 分隔符:要求與csv數據文件中多列的分隔符一致
- 遇到文件結束符再次循環:若選擇為True當數據不夠的時候會從頭取。若選擇False,則需要勾選下面的配置,遇到文件結束符停止線程,這里如果不勾選,請求將會報錯。
此時就需要根據我們自己寫的變量名稱進行賦值,如下圖:
測試效果:
兩者登錄的賬號密碼各不相同
8.2.編寫test.csv文件
注意一定要這樣轉為csv文件,不能直接改后綴,不然會出現未定義的錯誤!
?
8.3.修改登陸接口及其他涉及到username和password獲取的參數
8.4.修改線程組中線程數,使得每次取到的username和password都不?樣
9.HTTP Cookie管理器
添加了HTTP Cookie管理器后,會自動存儲并發送Cookie
10.添加梯度壓測線程組
10.1.解析梯度壓測線程組
注意要先將項目里面的內容拷貝一份!
- This group will start:啟動多少個線程,同線程組中的線程數
- First,wait for:等待多少秒才開始壓測,一般默認為0
- Then start:一開始有多少個線程數,一般默認為0
- Next,add:下一次增加多少個線程數
- threads every:當前運行多長時間后再次啟動線程,即每一次線程啟動完成之后的的持續時間:
- using ramp-up:啟動線程的時間;若設置為5秒,表示每次啟動線程都持續5秒、
- thenhold loadfor:線程全部啟動完之后持續運行多長時間
- finally,stop/threadsevery:多長時間釋放多少個線程;若設置為5個和1秒,表示持續負載結束之后每1秒鐘釋放5個線程
進一步解讀:
解讀:每隔3秒啟動5個線程,這5個線程必須在1秒之內完成準備
結束方式:
還需要吞吐量和響應時間 都需要添加進來
還有活躍線程的狀態
11.常見監聽器
11.1.聚合報告
從聚合報告可以看到性能測試過程中整體的數據變化,
11.2.?Response Times Over Time
Response Times Over Time主要用于監聽整個事務運行期間的響應時間。在測試過程中,它可以幫助測試人員觀察并分析響應時間的實時平均值以及整體響應時間的走向。通過這一監聽器,測試人員能夠更直觀地了解系統在不同時間點的響應性能,從而發現可能存在的性能問題或瓶頸。
Response Times Over Time的圖形展示中,橫坐標通常代表運行時間,而縱坐標則代表響應時間(單位是毫秒)。測試人員可以根據圖形中的趨勢線來判斷響應時間的穩定性以及是否存在大的波動。例如,如果響應時間在某個時間點突然增加,這可能意味著系統在該時間點遇到了性能問題。
11.3.Transactions per Second(TPS)
JMeter中的Transactions per Second(TPS)監聽器是一個用于分析系統吞吐量的重要工具。TPS即每秒事務數,表示一個客戶機向服務器發送請求后服務器做出反應的過程。這個指標反映了系統在同一時間內處理業務的最大能力。TPS值越高,說明系統的處理能力越強。
在使用TPS監聽器時,橫坐標通常代表運行時間,而縱坐標則代表TPS值。通過監聽器展示的圖表,可以清晰地看到TPS值隨時間的變化情況。在圖表中,紅色通常表示通過的TPS,而綠色可能表示失敗的TPS。這有助于我們快速識別系統性能的變化和瓶頸。
12.測試報告
JMeter測試報告是一個全面而詳細的文檔,它提供了關于測試執行結果的詳細信息,幫助用戶全面評估系統的性能并進行性能優化。
生成性能測試報告的命令:
jmeter -n -t 腳本文件?-l ?志文件?-e -o 目錄
-n : 無圖形化運行
-t : 被運行的腳本
-l : 將運行信息寫入日志文件,后綴為jtl的日志文件6-e : 生成測試報告
-o : 指定報告輸出目錄
?最后生成測試報告的時候,先要進入到測試報告的那個目錄
打開報告 發現全部通過!
雙擊index.html文件,界面展示如下:
13.性能分析
通過三大指標來分析性能問題
13.1 響應時間
如果響應時間超過了要求,代表系統到了瓶頸注意事項:分析在多少線程的情況下發生了超標
響應時間變化的原因:
系統不穩定,有時快有時慢
隨著并發壓力變大而慢慢變慢,響應時間變高
13.2 錯誤率(可靠性)
高并發場景下,系統是否能夠正常處理業務要求:99.99%可靠,99.9999%
錯誤率高的原因,
接口請求錯誤
服務器無法繼續處理,達到了瓶頸(代碼寫的不好,內存泄漏、硬件資源等)后端系統限流(系統里配置了不能超過多少并發)、熔斷、降級什么是熔斷、降級?
熔斷:防止系統因某個服務的故障而整體崩潰。當電商平臺上用戶支付時,收銀臺發現某個支付渠道,如微信支付失敗率突增,超時嚴重,那么就可以臨時把這個支付方式熔斷掉降級:主動關閉一些非核心功能,以確保核心功能的正常運行。某次騰訊視頻掛了的時候,用戶名稱默認顯示騰訊用戶,這也是一種降級方式,用兜底名稱做展示
13.3 吞吐量
吞吐量越大,性能越好,吞吐量相對穩定或者變低,可能系統達到了性能瓶頸吞吐量變化規律:
波動很大:代表系統性能不穩定
慢慢變高,再趨于穩定:和并發量強相關。如果并發量小于吞吐量,慢慢增大并發量,吞吐量也會隨之增加
慢慢變低,并發量也減少了:要么說明性能測試要結束了,并發減少;也可能是系統變的卡頓,從而導致響應時間變慢,導致單個線程發起的并發量變少
TIP:解決jmeter亂碼問題:
通過后置處理器BeanShell PostProcessor
? ? ? ? 1)在線程組中添加后置處理器:BeanShell PostProcessor
? ? ? ? 2)輸入prev.setDataEncoding("utf-8"),目的是修改響應數據編碼格式為utf-8
? ? ? ? 3)保存腳本再次執行jmeter即可。
用后置處理器修改響應編碼的方式更方便一些,不用改文件,也不用重啟jmeter。
所以性能測試的拐點如何測試?
14.HTTP請求中post和get有什么區別?
1. 語義和使用場景
- GET:
- 語義: 用于請求從指定的資源獲取數據。
- 用途: 常用于請求服務器發送某個資源,例如請求一個網頁、圖片或其他文件。
- 冪等性: GET請求被認為是冪等的,即多次執行同一請求對資源狀態沒有副作用。
- 緩存: GET請求的結果可以被緩存。
- 參數傳遞: 請求參數附加在URL之后,以查詢字符串的形式傳遞,例如?
http://example.com/resource?param1=value1¶m2=value2
。
- POST:
- 語義: 用于向指定的資源提交數據,請求服務器進行處理(例如創建/更新資源)。
- 用途: 常用于提交表單數據、上傳文件等操作。
- 冪等性: POST請求通常不是冪等的,即多次執行同一請求可能會對資源狀態產生副作用。
- 緩存: POST請求的結果一般不被緩存。
- 參數傳遞: 請求參數包含在請求體中,而不是URL中。
2. 數據傳輸
- GET:
- 數據傳輸量有限制(由于URL長度限制,不同瀏覽器和服務器有不同限制)。
- 數據暴露在URL中,不適合傳輸敏感信息。
- POST:
- 沒有數據大小的嚴格限制(雖然服務器可能設置了自己的限制)。
- 數據在請求體中傳輸,相對更安全,適合傳輸敏感信息(但仍需注意使用HTTPS來保證安全性)。
3. 瀏覽器行為
- GET:
- 瀏覽器會將GET請求的結果緩存起來,并在用戶嘗試重新加載頁面時可能直接從緩存中讀取數據。
- 用戶可以將GET請求的URL收藏為書簽。
- POST:
- 瀏覽器通常不會緩存POST請求的結果。
- 用戶無法直接將POST請求的URL收藏為書簽。
4. IDEMPOTENCY(冪等性)
- GET?是冪等的,即多次執行同一GET請求對服務器狀態沒有副作用。
- POST?通常不是冪等的,多次執行同一POST請求可能會改變服務器狀態。