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