文章目錄
- 添加線程組
- 添加定時器
- 添加HTTP請求默認值
- 添加HTTP頭管理
- 添加HTTP請求
- 添加結果斷言
- 響應斷言 Response Assertion
- JSON斷言 JSON Assertion
- 持續時間斷言 Duration Assertion
- 添加察看結果樹
- 添加聚合報告
- 添加表格察看結果
- 參考
以壓測百度搜索為例
- https://www.baidu.com/s?wd=lakernote
下面的步驟在大部分情況下可以套用。
添加線程組
右鍵單擊“Test Plan” -> “Add” -> “Threads (Users)” -> “Thread Group”。
-
Name:取一個描述性的名稱
-
Action to be taken after a Sampler error: 在請求發生錯誤時的處理方式,可以選擇中止線程、中止測試等。
-
Number of Threads (users): 設置模擬用戶數,即同時并發執行請求的用戶數。這決定了在每個線程組中啟動的線程數量。
-
Ramp-Up Period (in seconds): 設置啟動所有用戶的時間間隔。如果將用戶數設置為100,Ramp-Up Period設置為10秒,則系統將在10秒內逐漸啟動100個用戶。
- Ramp-Up Period定義了啟動所有虛擬用戶所需的時間。如果設置為10秒,而同時有100個虛擬用戶(線程),那么在10秒內,系統將逐漸啟動這100個用戶,而不是立即啟動所有。
- 這個選項的目的是模擬真實場景中用戶逐漸增加的情況,而不是突然出現大量用戶。這有助于更真實地模擬系統在負載逐漸增加時的性能表現。
-
Loop Count: 設置每個線程運行的次數。如果設置為1,每個線程將僅運行一次。如果設置為-1(無限循環),則線程將一直運行直到測試停止。
如果要達到剛好運行10次測試,則可以配置線程數:2,循環次數:5
如果要達到運行10s測試,而不管多少次,則可以設置循環次數:永遠,選中調度器設置持續時間:10
-
Same user on each iteration: 如果選中此選項,每個迭代中的同一個線程將使用相同的用戶。
- 如果選擇了這個選項,那么在每次迭代(循環)中,同一個線程(虛擬用戶)將使用相同的用戶標識。這意味著在每次循環中,該線程將以相同的身份(用戶標識)執行請求。
- 對于模擬單個用戶在多次迭代中使用相同的身份進行一系列操作很有用,例如登錄并執行多個操作,而不是在每次迭代中使用不同的用戶。
-
Delay Thread Creation until needed: 如果選中此選項,JMeter將推遲線程的創建,直到需要運行它們為止。這可以幫助減小資源消耗。
- 如果選擇了這個選項,JMeter將不會在測試計劃啟動時立即創建所有線程(虛擬用戶)。相反,它將等到線程實際需要運行時才創建它們。
- 這可以幫助減小資源消耗,特別是在你有大量線程但不是所有線程都在同一時間運行的情況下。例如,如果你有100個線程,但是測試計劃啟動后的第一秒只需要運行10個線程,那么只有這10個線程會在初始時創建,而其余90個線程將在后續需要時逐漸創建。
-
Scheduler Configuration: 可選的調度配置,允許你按照特定的時間計劃執行測試。如果你想在特定的時間段內執行測試,可以選擇此選項。
- Duration (持續時間): 設置測試計劃的持續時間。可以選擇執行測試的總時長,例如設置為3600秒(1小時)。
- Startup Delay (啟動延遲): 設置測試計劃開始執行前的延遲時間。這可以用來在啟動測試之前等待一段時間,以便進行預熱或等待其他資源的準備。
添加定時器
定時器(Random Timer)可以幫助模擬用戶在執行操作時的不規律性。你可以設置一個基礎定時器和一個隨機范圍,以便每個請求之間有一些隨機的等待時間,通常添加在需要模擬用戶請求之間的時間間隔的位置,常見的情況是將定時器添加在HTTP請求之前,以模擬用戶在執行不同操作之間的停頓。
以統一實際定時器舉例
- Random Delay Maximum (in milliseconds): 設置隨機等待時間的最大值(毫秒)。這個值表示在每個請求之間的最大等待時間。
- Constant Delay Offset (in milliseconds): 設置隨機等待時間的偏移值(毫秒)。這個值表示在每個請求之間的基本等待時間。
- 計算公式:
- 實際等待時間 = Constant Delay Offset + (0 到 Random Delay Maximum 之間的隨機值)
- 例如,如果你設置最大等待時間為500毫秒,偏移值為200毫秒,那么實際等待時間將在200毫秒到700毫秒之間變化。
- 設置示例:
- Random Delay Maximum: 500
- Constant Delay Offset: 200
添加HTTP請求默認值
HTTP Request Defaults
可以在多個HTTP請求中設置默認的服務器和協議信息,減少冗余配置。
HTTP Request Defaults
的設置會應用于同一級別下所有的 HTTP 請求。如果在具體的 HTTP 請求中有設置,它會覆蓋這里的默認設置。這樣,你就可以更方便地共享和管理一些通用的請求參數。
選擇 Add
-> Config Element
-> HTTP Request Defaults
進行添加。
- Server Name or IP: 輸入服務器的主機名或 IP 地址。這是服務器的基本地址,實際請求中的具體路徑可以在具體的 HTTP 請求中指定。
- Port Number: 輸入服務器的端口號。默認是80,如果是HTTPS則通常是443。
- Protocol: 選擇使用的協議,可以是
http
或https
。 - Path: 如果有一些請求共享相同的路徑,你可以在這里設置。在具體的請求中,你仍然可以覆蓋這個路徑。
- Content Encoding: 可選項,可以選擇請求的內容編碼方式,例如 gzip。
- Parameters: 如果有一些參數在多個請求中都是相同的,可以在這里設置。
添加HTTP頭管理
HTTP Header Manager
允許你添加自定義的HTTP頭部信息,如User-Agent,用于更真實地模擬瀏覽器行為。
選擇 Add
-> Config Element
-> HTTP Header Manager
。
- User-Agent :
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
- Authorization:
Bearer your_access_token
- Content-Type:
application/json
- Accept:
application/json
添加HTTP請求
在Thread Group下右鍵單擊 -> Add
-> Sampler
-> HTTP Request
。
- Name: 用于標識請求的名稱,顯示在測試計劃中,便于識別。
- Protocol: 指定使用的協議,可以是
http
或https
。 - Server Name or IP: 服務器的主機名或 IP 地址。
- Port Number: 服務器的端口號,默認是80。如果使用 HTTPS,通常是443。
- Method: HTTP 請求的方法,常見的有 GET、POST、PUT、DELETE 等。
- Path: 請求的路徑,即請求的具體終點。
- Content Encoding: 請求的內容編碼方式,例如 gzip。
- Parameters: 請求的參數,可以手動輸入鍵值對,也可以使用 “Add” 按鈕添加鍵值對。這是請求的查詢參數。
- Body Data: 如果是 POST 請求,你可以在這里輸入請求體的內容,通常用于傳遞 POST 請求的數據。
- Files Upload: 用于上傳文件的配置,可以指定要上傳的文件。
- Redirect Automatically: 如果勾選,JMeter 將自動處理重定向。
- Follow Redirects: 如果勾選,JMeter 將跟隨重定向。如果取消勾選,將不會跟隨重定向。
- Use KeepAlive: 如果勾選,將使用 HTTP Keep-Alive 以在單個連接上執行多個請求。
- Use multipart/form-data for POST: 如果勾選,請求將使用
multipart/form-data
編碼方式。常用于文件上傳等場景。 - Implementation: HTTP 請求的實現方式。默認為 “HttpClient4”,可以選擇其他實現。
- Retrieve All Embedded Resources from HTML Files: 如果勾選,JMeter 將嘗試檢索 HTML 頁面中引用的所有嵌入資源(例如圖像、樣式表等)。
添加結果斷言
結果斷言
(Response Assertion)是一種用于驗證請求響應是否符合預期的斷言。
常用的斷言類型,它們分別用于驗證不同方面的請求響應。以下是這幾種常用斷言的簡要說明:
- 響應斷言(Response Assertion):
- 用途: 用于驗證響應的內容是否符合預期,包括響應文本、響應代碼、響應消息等。
- 配置選項: 可以設置響應文本的包含、不包含、匹配等條件,以及驗證響應代碼、消息等。
- JSON斷言(JSON Assertion):
- 用途: 用于驗證 JSON 格式的響應是否符合預期。適用于處理 API 接口返回的 JSON 數據。
- 配置選項: 可以設置 JSON 路徑表達式和期望的值,以確保響應中包含或不包含特定的 JSON 數據。
- 持續時間斷言(Duration Assertion):
- 用途: 用于驗證請求的響應時間是否在指定的時間范圍內。
- 配置選項: 可以設置期望的響應時間范圍,如果實際響應時間在這個范圍內則斷言通過,否則失敗。
響應斷言 Response Assertion
響應斷言是最常用的一種斷言方法,主要是對響應結果中的文本內容進行斷言,比如響應結果是否包含指定的值,或者是否等于指定的值。響應斷言可以適用各種返回類型的響應結果,如Test、html、application/json、application/xml等。
JSON斷言 JSON Assertion
JSON斷言也是測試工作中經常用到的一種斷言方法,它一般用于斷言某個字段值是否等于我們指定的值。所以JSON斷言只能針對響應結果為applicaton/json格式的進行斷言操作。如果是其他類型(如:Test、html),則無法使用這種方式。
持續時間斷言 Duration Assertion
斷言持續時間通常用于做性能測試,一般用于檢查HTTP請求的響應時間是否超過預期值。而這個響應時間是性能測試中常關注的一個性能指標。
添加察看結果樹
選擇Add
-> Listener
-> 察看結果樹
。
將看到所有請求的詳細信息,包括請求頭、響應頭、響應數據等。
察看結果樹
是一個非常有用的監聽器,用于調試和分析測試中的問題。通過查看這個監聽器,你可以深入了解每個請求的執行情況,包括請求和響應的各個方面。
請注意,在進行實際的性能測試時,由于 察看結果樹
會占用大量資源,建議在測試結束后禁用或刪除該監聽器,以避免影響測試性能。
添加聚合報告
選擇 Add
-> Listener
-> 聚合報告
。
看到有關測試結果的聚合信息,包括平均響應時間、最小響應時間、最大響應時間、錯誤百分比等。
聚合報告
監聽器是用于查看整體性能指標的一種方便工具。它將匯總所有線程組中的結果,并顯示關鍵的性能統計信息。
請注意,在進行實際的性能測試時,由于 聚合報告
也會占用一些資源,建議在測試結束后禁用或刪除該監聽器,以避免影響測試性能。
添加表格察看結果
選擇 Add
-> Listener
-> 察看結果表格
。
將看到表格形式的結果,包括請求的詳細信息、響應時間、響應代碼等。
察看結果表格
是一種以表格形式查看結果的監聽器,提供了簡潔的視圖,便于查看關鍵信息。你可以在這個表格中查看每個請求的詳細信息,包括響應時間、響應代碼、錯誤等。
請注意,在進行實際的性能測試時,由于監聽器會占用一些資源,建議在測試結束后禁用或刪除不需要的監聽器,以避免影響測試性能。
參考
- http://testingpai.com/article/1655452307498