Apache JMeter 中的會話/Cookie 管理

1. 簡介

在本教程中，我們將了解 JMeter 如何管理會話和 cookie、設定登入應用程式的測試計劃、存取受保護的資源以及登出。在此過程中，我們將使用 HTTP Cookie 管理器、CSV 資料集配置和回應斷言來確保我們的測試模擬真實的使用者行為。

2. Web 應用程式中的會話管理

在 Web 應用程式中，會話和 cookie 管理有多種形式，對於身份驗證和使用者體驗至關重要。

讓我們考慮一個使用表單登入的應用程式。這種類型的身份驗證允許我們發送單一身份驗證請求，成功時返回帶有 JSESSIONID 的 cookie，我們可以在未來的請求中包含該 cookie 。這樣就無需在每個請求中包含憑證。

2.1. JMeter 如何處理會話和 Cookie

與瀏覽器不同，JMeter 需要明確的配置來維護請求的狀態。我們需要的特定元件是HTTP Cookie 管理器和HTTP 標頭管理器。

3.配置JMeter測試計劃

我們將使用這些元件來建立測試計劃，以登入應用程式、存取受保護的資源並登出。

最後，我們將得到以下結構：

3.1.建立線程組

首先，我們需要一個Thread Group ，它控制我們在測試中使用多少個使用者和迭代次數。

讓我們右鍵單擊Test Plan ，然後Add > Threads (Users) > Thread Group並修改一些屬性：

• Stop Thread ：由於我們需要登入才能訪問應用程序，因此我們還希望測試在第一次錯誤時停止。如果登入因任何原因失敗，此選項有助於產生更少的請求。
• 執行**緒**Number of Threads ：3。由於我們需要每個使用者的有效憑證，因此我們不能超過資料庫中的使用者數量，我們稍後會進行配置。
• Loop Count ：2。
• Same user on each iteration ：此選項控制每個使用者是否在測試計劃的多次迭代中保持其身分。如果不選中，則下次迭代開始時不會保留 cookie。由於我們的計劃以登入開始並以登出結束，因此此選項的值並不相關。

我們可以將其他選項保留為預設值，因為它們與會話管理無關。

3.2.使用 CSV 檔案載入用戶

由於我們正在與多個使用者一起執行測試，因此最有效且最安全的載入方法是將它們包含在 CSV 檔案中。

讓我們建立一個名為users.csv的檔案並包含三個用戶，使用第一行作為標題：

username,password

 alex_foo,password123

 jane_bar,password213

 john_baz,password321

然後，我們右鍵單擊Thread Group ，選擇Add > Config Element > CSV Data Set Config ：

在此元件中，我們不會保留預設值的唯一屬性是Filename ，我們將使用它來選擇我們的 CSV 檔案。其他值得注意的選擇包括：

• Variable Names ：這將覆寫使用檔案第一行中的列名作為變數名的預設行為。與「 Ignore first line 」結合，如果我們想要不同的變數名，這很有用。
• Recycle on EOF ：每個新線程選擇文件中的下一行。如果此選項為false ，則當行用盡時，值將為下一個使用者傳回「 EOF 」。否則，它會循環回到文件的開頭。

這裡定義的變數幾乎可以在任何地方使用，我們可以在任何地方為稍後將使用的請求和斷言元素輸入值。

3.3.新增 HTTP Cookie 管理器

最後，我們將新增另一個Config Element ，然後選擇HTTP Cookie Manager 。此元件啟用 JMeter 中的會話管理：

• Clear cookies each iteration ：這與「 Same user on each iteration 」選項具有相同的效果，因此當我們檢查下一個選項時不可用。
• Use Thread Group configuration to control cookie clearing ：顧名思義，這考慮了我們之前定義的「 Same user on each iteration 」。

4. 建立登入請求

我們的第一個請求是登入表單。讓我們右鍵單擊Thread Group ，然後選擇Add > Sampler > HTTP Request ：

讓我們檢查一下與我們的場景最相關的配置位元：

• Protocol ：如果我們的應用程式使用 HTTPS，我們只需要更改它
• Server Name or IP ：應指向我們的伺服器位址
• Method ：我們的應用程式對登入頁面使用 HTTP POST 方法
• Path ： /login 。此路徑是我們的登入端點
• Follow Redirects ：只有當登入重新導向到我們想要進行測試斷言的頁面時，我們才應該檢查這一點。否則，我們應該不去控制它，以提高效能

最後， Body Data是一個查詢字串，我們在其中定義使用者憑證。由於我們使用 CSV 檔案元件，因此我們可以在此處引用當前遊標的變數。此外，我們使用 Spring Security 登入表單的預設參數名稱：

username=${username}&password=${password}

4.1.包含 HTTP 標頭管理器

我們需要將登入請求的Content-Type標頭定義為application/x-www-form-urlencoded 。為此，我們右鍵單擊登入請求，然後選擇Add > Config Element > HTTP Header Manager並將其包含為名稱/值對：

如果我們不包括它，我們的登入將失敗，因為伺服器不知道如何處理請求。

4.2.斷言登入後重定向請求

當登入請求成功時，它會返回 302 代碼，重定向到應用程式中的登入頁面。為了斷言這一點，我們可以右鍵單擊我們的登入請求，然後選擇Add > Assertions > Response Assertion ：

在這裡，我們結合使用「 Response Code 」和「 Equals 」選項，在「 Patterns to Test 」欄位中輸入302碼。我們將保留其他選項的預設值。

4.3.斷言沒有登入錯誤

如果登入失敗，回應包含指向錯誤頁面的Location標頭。讓我們加入另一個Response Assertion ：

• Response Headers ：這定義了我們要檢查其中一個回應頭中的值。我們不需要設定標題名稱。
• Contains + Not ：標題值不應包含Patterns to Test欄位中指定的字串。
• Patterns to Test ： Location標頭包含單字“ error ”，並在此處匹配。
• Custom failure message ：我們還可以在此處引用當前username變量，產生更具描述性的 JMeter 錯誤訊息。

5. 存取受保護的資源

有了 cookie 管理器，所有後續請求都會自動包含會話 cookie，從而授予對受保護資源的存取權：

然後，我們將檢查響應是否與預期值相符。在我們的例子中，我們指定的安全端點Path會傳回目前登入的使用者的姓名。我們將保留其他選項的預設值。

因此，讓我們在Patterns to Test欄位中的新Response Assertion中包含username變數：

• Text Response ：我們將以純文字形式檢查回复
• Matches ：我們想要精確匹配

6. 建立註銷請求

在迭代結束時，我們將新增指向註銷端點的註銷請求：

並使用與登入斷言類似的邏輯來檢查我們是否成功註銷，其中我們檢查其中一個標題是否包含「 logout 」：

現在我們有一個經過身份驗證的用戶與應用程式同時互動的完整測試週期。

7. 探索請求

為了直觀地了解內部發生的情況，我們右鍵單擊Thread Group ，然後Add > Listener > View Results Tree 。執行測試並檢查登入請求後，我們可以在點擊Response data > Response headers時看到JSESSIONID ：

我們也可以看到，當點擊Request > Request Body時，cookie 會在我們的請求中發送回受保護的資源：

最後，我們可以在Response Data > Response Body下驗證預期的回應：

8. 結論

在本文中，我們探討了 JMeter 如何處理會話和 cookie 管理，使我們能夠模擬真實的身份驗證場景。我們配置了一個測試計劃，包括登入、存取受保護的資源和登出，確保我們的應用程式正確維護並使用戶會話無效。

與往常一樣，原始碼可在 GitHub 上取得。