使用JMETER進行REST API測試（分步指南）
我確定你在這裡是因為你需要載入測試Json Rest API。這並不奇怪，因為Rest API現在越來越受歡迎。
這本指南的目的：幫助您進行負載測試一個Json的 REST API 通過一個具體的例子，OctoPerf的Json的REST API。
本指南將完全為您提供以下知識：
- 使用Http POST請求處理Rest API登入，
- 從Json Response中提取變數，稍後在指令碼中重用它，
- 並使用JMeter Json Assertion（在JMeter 4中引入）驗證Json響應。
這裡沒有理論，只有實踐：一切都基於一個現實的Rest API（不是一個虛擬的例子）。
準備好學習？我們走吧！
休息API登入
OctoPerf平臺基於Json Rest API。我們將看看如何使用JMeter模擬我們的API登入。
但是身份驗證如何運作？我們如何使用JMeter模擬登入？大多數Rest API使用以下登入工作流程：
- 登入使用HTTP POST請求通過提供
username和password， - 接收臨時身份驗證令牌，以便以後請求標識自己，
- 傳送身份驗證令牌的後續請求中，典型地經由HTTP標頭一樣
Authorization: Bearer AUTH_TOKEN。
OctoPerf API也是如此。
登入API規範
首先，讓我們看看如何登入OctoPerf Application。值得慶幸的是，我們的API有一個Swagger規範：Swagger是一個提供Rest 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。從響應中提取變數的過程如下：
- 伺服器發回對我們的登入請求的響應，
- 甲後處理器，像JsonPath提取是繼執行
- 提取器提取伺服器響應的一部分並將其放入變數中
${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我們是一個給定的使用者。
重新註冊Auth Token
我們的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端點伺服器響應中提取了。現在，是時候重用它來檢索訪問受保護的資源了：
- 首先，在getWorkspaces HTTP Request 下新增一個Http Header Manager，
- 新增
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的格式化可以使您的生活很多容易通過格式化輸出。