最近在進行一個老專案的升級，第一步是先將node版本從
4.x升級到8.x，擔心升級會出現問題，所以需要將服務的介面進行驗證；
如果手動輸入各種URL，人肉check，一個兩個還行，整個服務。。大幾十個介面，未免太浪費時間了-.-；
因為是一個純介面服務的專案，所以打算針對對應的API進行一波自動化測試；
所以就開始尋找對應的工具，突然發現，平時使用的PostMan貌似也是支援寫測試用例的-.-，所以就照著文件懟了一波；
一下午的時間，很是激動，之前使用PostMan僅限於修改Header，新增Body傳送請求，從來沒有考慮過拿PostMan來進行測試，一下午的使用，感覺發現了新大陸。
PostMan的安裝
貌似下載和使用PostMan必須要翻牆-.-
因為現在提供兩種形態的App：
chrome的外掛 （已經快要被廢棄了，推薦使用獨立App）- 獨立的App
而且在使用時需要登入賬號，我這邊是直接登入的Google賬號-。-貌似有其它方式，但是我並沒有去嘗試。
獨立App版雲盤地址（Mac版本，今天剛下載的6.0.10，需要的請自取）：
連結:https://pan.baidu.com/s/18CDp… 密碼:mrpf
下載完畢解壓後直接執行即可，然後就是註冊賬號之類的，目測賬號這一塊主要是用於後續的小組分享需要（可以直接將你的呼叫記錄分享給其他人）。
傳送一個請求
這是PostMan最基礎的一個用法，用來傳送一個請求。
可以設定Header，Body等資訊。
Collections
我們可以將每次傳送的請求進行儲存，方便下次請求該介面時，直接呼叫即可，
如果儲存請求的話，會被儲存到一個Collections裡去，類似一個集合。
PostMan提供了方法，能夠一鍵執行整個Collections中所有的請求。
然後我們就可以在需要的時候，直接執行集合中所有的請求了。
儲存請求記錄的時候，在下邊選擇對應的Collection即可
開始API測試
測試指令碼位置
PostManJavaScript語法，右側是一些預先配置的程式碼片段。
以及我們可以在Pre-request Script中編寫指令碼，用於在傳送請求前執行。
一些簡單的語法
PostMan也提供了一種斷言，來幫助做一些驗證。
|
1 2 3 |
tests['Status code is 200'] = responseCode.code === 200 tests['Data length >= 10'] = JSON.parse(responseBody).data.length >= 10 |
賦值為true即表示通過，false為失敗。
tests的直接賦值作用比較侷限，如果在指令碼中進行一些其他非同步操作，則需要用到pm.test了。
|
1 2 3 4 5 |
setTimeout(() => { pm.test("test check", function () { pm.expect(false).to.be.true }) }) |
只用上邊的tests賦值+pm.test/pm.expect已經能夠滿足我們的需求了，其餘的一些只是在這之上的語法糖而已。
各種語法示例
在測試指令碼中傳送請求
我們可以在拿到一個API返回結果後，根據該結果傳送一些新的請求，然後新增斷言。
|
1 2 3 4 5 6 7 8 9 10 |
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以及下層的資料夾中，我們可以直接編寫針對這個目錄下的所有請求的斷言指令碼。
這裡的指令碼會作用於目錄下所有的請求。
這樣我們就可以將一些通用性的斷言挪到這裡了，在每個請求的Tests下編寫針對性的斷言指令碼。
變數的使用
PostMan提供了兩種變數使用，一個是global，一個是environment。
global
程式碼操作的方式：
|
1 2 3 |
pm.globals.set("variable_key", "variable_value") // set variable pm.globals.get("variable_key") // get variable pm.globals.unset("variable_key") // remove variable |
通過GUI設定：
設定完後我們就可以這樣使用了：
基本上在所有的可輸入的地方，我們都能夠使用這些變數。
environment
環境變數，這個是權重比global要高一些的變數，是針對某些環境來進行設定的值。
操作方式類似。
在使用程式碼操作的方式時，只需將globals替換為environment即可。
在發起一個請求，或者一鍵傳送所有請求時，我們可以勾選對應的環境，來使用不同的變數。
在針對大量API測試時，拿environment來設定一個domain將是一個不錯的選擇。
這樣在請求中我們只需這樣寫即可：
|
1 2 3 4 |
{{domain}}/res1 {{domain}}/res2 domain: https://api.github.com |
一個簡單的示例：
通過直接執行一個Collection，我們可以很直觀的看到所有的介面驗證情況。
參考資料
https://www.getpostman.com/do…
之前使用PostMan，最多就是模擬一下POST請求，最近剛好碰到類似的需求，發現原來PostMan還可以做的更多。
這篇只是使用PostMan進行API測試的最基礎操作，還有一些功能目前我並沒有用到，例如整合測試、生成API文件之類的。
介面相當於是獲取和操作服務資源的方式，肯定屬於產品的核心。
所以測試是必須的，在交付QA同學之前，自己進行一遍測試，想必一定能節省一部分的時間。