使用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（不是一個虛擬的例子）。您能夠在學習本教程的同時下載示例JMX。

準備好學習？咱們走吧！

休息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規範

首先，讓咱們看看如何登陸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。從響應中提取變量的過程以下：

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咱們是一個給定的用戶。

從新註冊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端點服務器響應中提取了。如今，是時候重用它來檢索訪問受保護的資源了：

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的格式化可使您的生活不少容易經過格式化輸出。