使用PostMan進行API測試

Jiasm發表於2019-03-02
PostmanAPI

最近在進行一個老專案的升級，第一步是先將node版本從4.x升級到8.x，擔心升級會出現問題，所以需要將服務的介面進行驗證； 如果手動輸入各種URL，人肉check，一個兩個還行，整個服務。。大幾十個介面，未免太浪費時間了-.-； 因為是一個純介面服務的專案，所以打算針對對應的API進行一波自動化測試； 所以就開始尋找對應的工具，突然發現，平時使用的PostMan貌似也是支援寫測試用例的-.-，所以就照著文件懟了一波； 一下午的時間，很是激動，之前使用PostMan僅限於修改Header，新增Body傳送請求，從來沒有考慮過拿PostMan來進行測試，一下午的使用，感覺發現了新大陸。

PostMan的安裝

貌似下載和使用PostMan必須要翻牆-.- 因為現在提供兩種形態的App：

  1. chrome的外掛 （已經快要被廢棄了，推薦使用獨立App）
  2. 獨立的App

而且在使用時需要登入賬號，我這邊是直接登入的Google賬號-。-貌似有其它方式，但是我並沒有去嘗試。

獨立App版雲盤地址（Mac版本，今天剛下載的6.0.10，需要的請自取）： 連結:https://pan.baidu.com/s/18CDp2MUQCLgk_USlmVc-Gw 密碼:mrpf

下載完畢解壓後直接執行即可，然後就是註冊賬號之類的，目測賬號這一塊主要是用於後續的小組分享需要（可以直接將你的呼叫記錄分享給其他人）。

傳送一個請求

這是PostMan最基礎的一個用法，用來傳送一個請求。 可以設定Header，Body等資訊。

使用PostMan進行API測試

Collections

我們可以將每次傳送的請求進行儲存，方便下次請求該介面時，直接呼叫即可， 如果儲存請求的話，會被儲存到一個Collections裡去，類似一個集合。 PostMan提供了方法，能夠一鍵執行整個Collections中所有的請求。

使用PostMan進行API測試
使用PostMan進行API測試

然後我們就可以在需要的時候，直接執行集合中所有的請求了。

使用PostMan進行API測試

儲存請求記錄的時候，在下邊選擇對應的Collection即可

使用PostMan進行API測試

開始API測試

測試指令碼位置

使用PostMan進行API測試
PostMan針對請求編寫的測試指令碼，在這個位置，採用的是JavaScript語法，右側是一些預先配置的程式碼片段。 以及我們可以在Pre-request Script中編寫指令碼，用於在傳送請求前執行。

一些簡單的語法

PostMan也提供了一種斷言，來幫助做一些驗證。

tests['Status code is 200'] = responseCode.code === 200

tests['Data length >= 10'] = JSON.parse(responseBody).data.length >= 10
複製程式碼

賦值為true即表示通過，false為失敗。 tests的直接賦值作用比較侷限，如果在指令碼中進行一些其他非同步操作，則需要用到pm.test了。

setTimeout(() => {
  pm.test("test check", function () {
    pm.expect(false).to.be.true
  })
})
複製程式碼

只用上邊的tests賦值+pm.test/pm.expect已經能夠滿足我們的需求了，其餘的一些只是在這之上的語法糖而已。 各種語法示例

在測試指令碼中傳送請求

我們可以在拿到一個API返回結果後，根據該結果傳送一些新的請求，然後新增斷言。

let responseJSON = JSON.parse(responseBody)

// 獲取關注的第一個使用者，並請求他的使用者資訊
pm.sendRequest(responseJSON[0].url, function (err, response) {
  let responseJSON = response.json()

  pm.test('has email', function () {
    pm.expect(responseJSON.email).is.be.true // 如果使用者email不存在，斷言則會失敗
  })
});
複製程式碼

如果我們有一些動態介面要進行測試，可以嘗試這種寫法。 一級介面返回List 二級介面根據List的ID進行獲取對應資訊。

如何處理大量重複的斷言邏輯

針對單個API，去編寫對應的斷言指令碼，這個是沒有什麼問題的。 但是如果是針對一個專案的所有API去編寫，類似於判斷statusCode這樣的斷言就會顯得很冗餘，所以PostMan也考慮到了這點。 在我們建立的Collection以及下層的資料夾中，我們可以直接編寫針對這個目錄下的所有請求的斷言指令碼。

使用PostMan進行API測試
使用PostMan進行API測試
這裡的指令碼會作用於目錄下所有的請求。 這樣我們就可以將一些通用性的斷言挪到這裡了，在每個請求的Tests下編寫針對性的斷言指令碼。

變數的使用

PostMan提供了兩種變數使用，一個是global，一個是environment。

global

程式碼操作的方式：

pm.globals.set("variable_key", "variable_value") // set variable
pm.globals.get("variable_key") // get variable
pm.globals.unset("variable_key") // remove variable
複製程式碼

通過GUI設定：

使用PostMan進行API測試
使用PostMan進行API測試

設定完後我們就可以這樣使用了：

使用PostMan進行API測試

基本上在所有的可輸入的地方，我們都能夠使用這些變數。

environment

環境變數，這個是權重比global要高一些的變數，是針對某些環境來進行設定的值。 操作方式類似。

在使用程式碼操作的方式時，只需將globals替換為environment即可。 在發起一個請求，或者一鍵傳送所有請求時，我們可以勾選對應的環境，來使用不同的變數。

使用PostMan進行API測試

在針對大量API測試時，拿environment來設定一個domain將是一個不錯的選擇。 這樣在請求中我們只需這樣寫即可：

{{domain}}/res1
{{domain}}/res2

domain: https://api.github.com
複製程式碼

一個簡單的示例：

通過直接執行一個Collection，我們可以很直觀的看到所有的介面驗證情況。

使用PostMan進行API測試
使用PostMan進行API測試

參考資料

www.getpostman.com/docs/v6/

之前使用PostMan，最多就是模擬一下POST請求，最近剛好碰到類似的需求，發現原來PostMan還可以做的更多。 這篇只是使用PostMan進行API測試的最基礎操作，還有一些功能目前我並沒有用到，例如整合測試、生成API文件之類的。

介面相當於是獲取和操作服務資源的方式，肯定屬於產品的核心。 所以測試是必須的，在交付QA同學之前，自己進行一遍測試，想必一定能節省一部分的時間。

相關文章