我確定你在這裏是因為你需要加載測試Json Rest API。這並不奇怪，因為Rest API現在越來越受歡迎。

這本指南的目的：幫助您進行負載測試一個Json的 REST API 通過一個具體的例子，OctoPerf的Json的REST API。

本指南將完全為您提供以下知識：

• 使用Http POST請求處理Rest API API登錄，
• 從Json Response中提取變量，稍後在腳本中重用它，
• 並使用JMeter Json Assertion（在JMeter 4中引入）驗證Json響應。

這裏沒有理論，只有實踐：一切都基於一個現實的Rest API（不是一個虛擬的例子）。您可以在學習本教程的同時

準備好學習？我們走吧！

休息API登錄

OctoPerf平臺基於Json Rest API。我們將看看如何使用JMeter模擬我們的API登錄。

但是身份驗證如何運作？我們如何使用JMeter模擬登錄？大多數Rest API使用以下登錄工作流程：

1. 登錄使用HTTP POST請求通過提供username和password，
2. 接收臨時身份驗證令牌，以便以後請求標識自己，
3. 發送身份驗證令牌的後續請求中，典型地經由HTTP標頭一樣Authorization: Bearer AUTH_TOKEN。

OctoPerf API也是如此。這與Oauth身份驗證非常接近。

登錄API規範

首先，讓我們看看如何登錄

Doc指定如何通過OctoPerf的API登錄

好！現在讓我們來看看使用JMeter進行偽造所需的請求：

• Http方法：必須是POST請求，帶有一些post參數，（參見GET vs POST）
• Http Scheme：https由於我們的Rest API 受SSL保護，
• 主機名：api.octoperf.com，
• 路徑 :( /public/users/login登錄端點路徑），

• 發布參數：

  • 用戶名：帳戶用戶名，如果你沒有，你可以在這裏輕松註冊，
  • 密碼：關聯的密碼。

然後我們應該從服務器接收一個Json Response，它看起來像：

{
  "token": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

在這裏看到令牌？這是我們稍後將用於在Rest API上識別自己的東西。但是，首先讓我們來看看JMeter HTTP請求。

執行登錄

通過Rest API登錄OctoPerf

在這裏，我們已準備好將Login Http Request發送到我們的服務器。我剛剛隱藏了敏感信息，但這基本上就是您的帳戶信息。為了調試登錄，我們將使用View Results Tree Listener。

登錄請求發送到服務器

我們可以看到，發送的請求是一個POST表單-urlencoded，其中包含我們的登錄名和密碼。這裏沒什麽難的！現在，我們對服務器發送的Json響應感興趣。

從服務器收到響應

精細！現在我們已經收到了身份驗證令牌，我們可以提取它以在後續請求中重用它。

提取身份驗證令牌

基於令牌的身份驗證是一種簡單的機制，其中令牌唯一地標識用戶會話。我們需要處理這個問題dynamic parameter以正確模擬與Json API交互的用戶。

使用Json Extractor

要從服務器響應中提取身份驗證令牌，我們將使用JMeter JsonPath Extractor。從響應中提取變量的過程如下：

1. 服務器發回對我們的登錄請求的響應，
2. 甲後處理器，像JsonPath提取是繼執行
3. 提取器提取服務器響應的一部分並將其放入變量中${token}。

從服務器響應中提取身份驗證令牌

我們已經使用這些設置配置了JMeter Json Extractor：

• 創建變量的名稱：token，這將導致帶有語法的可重用變量${token}，
• Json Path表達式：$.token，有關詳細信息，請參閱示例JsonPath表達式，
• 並且匹配Nr：簡單地說1，第一次出現。但我們可以把它留空。

看看我放置提取器的位置？在loginHTTP請求下。我們還添加一個Debug Sampler來查看是否正確提取了變量。

啟用調試

在Debug Sampler中啟用JMeter變量

通過設置JMeter的變量來true，我們啟用了采樣器輸出變量的試運行期間。

測試提取

使用Json Extractor從服務器響應中成功提取令牌

大！Json提取器完美無缺。它token從Json響應中提取字段的值。我們現在可以${token}在後續請求中使用表達式來執行經過身份驗證的請求。

讓我們看看我們如何重用此令牌來告訴我們的Rest API我們是一個給定的用戶。

重新註冊驗證令牌

我們的Rest API有許多需要身份驗證的端點。這些端點提供用戶工作區，項目，虛擬用戶等數據。要訪問受用戶保護的端點，必須：

• 登錄以獲取身份驗證令牌（就像我們之前所做的那樣），
• Authorization: Bearer TOKEN對於每個後續請求，在http請求標頭內發送身份驗證令牌。

這正是我們要在這裏做的。

檢索用戶工作區

我們現在特別感興趣的是查詢用戶的工作空間。這是Workspaces API端點的一部分。

工作區從Swagger API文檔中休息API端點

我們將GET使用路徑向端點執行請求/workspaces/member-of。它應該返回包含用戶工作空間的Json響應。這是一個示例響應：

[
  {
    "created": "2018-04-23T12:40:00.133Z",
    "description": "This is my personal workspace.",
    "id": "workspaceId",
    "lastModified": "2018-04-23T12:40:00.133Z",
    "name": "Personal",
    "userId": "myUserId"
  }
]

讓我們在JMeter中創建一個HTTP請求來查詢它們。這很簡單，如下面的截圖所示。

從JMeter調用端點成員

在這裏，我們設置了一個HTTP請求來查詢用戶的工作區：

• Http方法：必須是GET請求，不涉及參數，
• Http Scheme：https由於我們的Rest API 受SSL保護，
• 主機名：api.octoperf.com，
• 路徑：/workspaces/member-of。

完了嗎？還沒。目前，如果我們不提供身份驗證令牌，服務器將拒絕我們的請求。

服務器返回錯誤

服務器以Http 4xx錯誤拒絕請求：401 Unauthorized。

與403 Forbidden類似，但專門用於需要身份驗證且已失敗或尚未提供的情況。

我們需要通過Authorization在請求中包含標頭來提供身份驗證令牌。怎麽樣？通過向請求添加HTTP標頭管理器。

添加授權標頭

在Authorization標頭中設置提取的令牌

請記住：我們之前已經token從/public/users/login端點服務器響應中提取了。現在，是時候重用它來檢索訪問受保護的資源了：

1. 首先，在getWorkspaces HTTP Request 下添加一個Http Header Manager，
2. 添加Authorization帶有值的標頭Bearer ${token}。

從服務器獲得工作區

太好了！它現在正在工作！我們擁有屬於已登錄用戶的所有工作空間。

授權標頭已在請求中發送

授權標頭已成功包含在請求標頭中。但是，有一點令人討厭的是：Json格式不正確。為什麽？

大多數服務器以緊湊格式發送json，跳過縮進。這是出於性能原因（減少帶寬使用和服務器CPU使用）

格式化Json響應

為了解決這個問題，JSON Formatter PostProcessor能夠很好地完成這項工作。

JMeter Json Formatter後處理器

請參閱我們的JMeter插件安裝指南，了解如何安裝Json插件。另一個選擇是使用JSR223腳本自己格式化Json 。

Json現在打印得很漂亮！

現在，我們可以利用Json Assertion（在JMeter 4.0中引入）的強大功能來檢查服務器響應。

使用Json Assertion

我們將確保服務器響應包含Personal工作區。這是Json斷言的工作。要添加Json斷言，請右鍵單擊HTTP Request采樣器，然後選擇Add > Post Processor > Json Assertion。

組態

斷言響應包含個人工作空間

Json斷言配置如下：

• 斷言的Json路徑存在：$.[1][‘name‘]指第二工作區返回，並采取了name，
• 另外Assert Value：選中以檢查name字段的值，
• 預期價值：應該是Personal。

執行

假設我們斷言期望值是Other不是Personal。

查找名為Other的 workspaced時，Json Assertion失敗

正如預期的那樣，斷言失敗並顯示以下消息：

Assertion error: false
Assertion failure: true
Assertion failure message: Value expected to be ‘Other‘, but found ‘Personal‘

性能

當然，您不僅限於使用Json Assertion。如果您願意，也可以使用JMeter Response Assertion。它在性能方面甚至是有益的，因為根據我們的斷言性能比較表，響應斷言比Json斷言消耗更少的CPU /內存資源。

模擬動態行為

現在我們知道如何登錄Json Rest API並發送訪問受保護端點的請求，讓我們看看如何dynamically behaving使用JMeter 模擬用戶。

這是本教程的最後一部分：

• 首先，我們將提取隨機工作區ID，（將${workspaceId}）
• 其次，我們將使用端點查詢該工作空間的項目/projects/by-workspace/${workspaceId}/DESIGN。

OctoPerf的Projects Rest API端點

最後一個Rest API端點讓我們感興趣。我們將從JMeter調用它，但首先我們需要提取一個隨機workspaceId。

提取WorkspaceId

提取隨機workspaceId

提取器配置為getWorkspaces請求的後處理器，具有以下設置：

• 創建變量的名稱：workspaceId，
• Json Path表達式：$..id，
• 匹配號：0，這是隨機的。

這將提取隨機workspaceId，並將其放入${workspaceId}變量中。

查詢項目

最後，我們需要根據之前提取的內容查詢項目workspaceId。為此，我復制並修改了之前的請求以獲得一些時間。

使用workspaceId變量查詢項目

在這裏，我們設置了一個HTTP請求來查詢工作區的項目：

• Http方法：必須是GET請求，不涉及參數，
• Http Scheme：https由於我們的Rest API 受SSL保護，
• 主機名：api.octoperf.com，
• 路徑：/design/projects/by-workspace/${workspaceId}/DESIGN。DESIGN工作空間中包含的項目的狀態。（而不是結果，這將是RESULT）

我想我們已經準備好進行快速叠代來試試這個了！

查看結果

執行導致查詢項目

如果我們多次執行用戶，我們會看到響應因提取的隨機workspaceId 而異。

最後的話

JMeter非常適合Rest API測試，特別是那些基於Json格式的測試。使用JMeter測試Json API非常簡單。

基本上，如果你掌握了上面提到的JMeter組件，那麽你很高興！

如果你想進一步挖掘，我強烈建議你閱讀我們的文章：

• JMeter JsonPath Extractor：從Json響應中提取任何內容，了解有關JsonPath語法的更多信息，
• JMeter Json Assertion：專門斷言json響應，
• 和JMeter的插件，如Json的格式化可以使您的生活很多容易通過格式化輸出。

如果您發現它有用，請隨時分享本指南！

使用JMETER進行REST API測試