使用PostMan進行API測試

Jiasm發表於2019-03-02

最近在進行一個老專案的升級,第一步是先將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最基礎的一個用法,用來傳送一個請求。 可以設定HeaderBody等資訊。

使用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 二級介面根據ListID進行獲取對應資訊。

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

針對單個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同學之前,自己進行一遍測試,想必一定能節省一部分的時間。

相關文章