1 背景

本文要介紹的環境在我司已經投入使用，舉個簡單的真實使用場景，開發提供了300多個API，每個API都有各種引數，所以我們會先在postman中為這300多個API編寫300*n個testcase，然後在jenkins上跑；到此有人可能會問，都在postman中寫好testcase了，怎麼還要去jenkins中跑，豈不是多此一舉？答案是否定的，試想，當開發一直在不停的維護這300多個介面時，難道需要開發每次都告訴我們測試人員該進行測試了嗎？顯然不是的，這就是jenkins+postman的自動化之處了，開發可以實現一個jenkins的上游job指令碼（當介面程式碼有修改時觸發我們這個testcase的下游job），當他們每次修改維護介面時不需要進行任何操作與交流，程式碼一旦提交jenkins就能自動化個性化地開始執行我們預定於的那些testcase了，然後我們只用關注最終的測試結果郵件即可，這樣大大的提高了開發測試效率。

鑑於國內很少測試工程師用postman來測試API，於是寫本篇文章分享下。前一個月用postman寫了API自動化測試指令碼，並用newman命令列執行所有測試案例，覺得沒有達到全自動化測試，於是配置jenkins job來執行API自動化測試指令碼，使API達到完全自動化測試！

2 環境配置與執行

這部分依次展示瞭如何安裝設定及執行一個基於Postman的自動化工具，具體如下。

2.1 postman 安裝

在谷歌瀏覽器下載postman外掛，並安裝，下載路徑（Chrome應用商店需要翻牆）：https://chrome.google.com/webstore/search/postman?hl=en

2.2 newman 的安裝

第一步，安裝nodejs。
第二步，在nodejs命令列安裝newman，即命令列輸入如下命令：

npm install -g newman

2.3 jenkins 安裝

去官網（https://jenkins.io/index.html）下載jenkins，各種下一步點選安即可（官網wiki等目錄下一般都有不同平臺的安裝文件，依據文件安裝即可）。

2.4 postman 使用與匯出

第一步，建立一個放置testCase的資料夾Test，如下：

第二步，建立第一個testcase，點選下圖1處的加號新增一個case，在2處選擇你的API請求方式，在3處寫上api請求的url，在4處填寫該請求的相關引數，具體如下圖：

下面展示了一個依據上圖步驟配置後的郵箱地址請求示例，如圖：

第三步，對一個testCase的判斷可以寫在如下所示位置（判斷的意思是指譬如返回的狀態碼、內容等是不是你期望的值）：

第四步，點選send按鈕即可傳送一個請求，同時可以看到請求的結果，如圖：

當然，一般Test目錄可能有很多的testCase，這種情況下我們可以選中資料夾，然後點選start Test按鈕，這樣就會自動執行資料夾內的所有testcase並顯示測試結果，如圖：

第五步，匯出上面在postman中寫的testCase檔案和設定的環境變數檔案（如下圖匯出testCase alarm detail 檔案 和 environment 檔案）。這是最重要最核心的一步，自動化的源頭依賴於此步，請務必注意。

至此postman的基本使用和匯出就完事了，關於postman的其他主題設定、登入等等其他功能請自行摸索，其實很多開發也非常喜歡用postman，譬如移動端開發喜歡用postman去請求服務端提供的API，以此來簡單快捷驗證介面的正確性和Json、xml等資料格式。

2.5 jenkins 配置

在jenkins上配置如下圖，這個路徑就是上面通過postman匯出檔案的路徑。

剩下的就是jenkins的常規操作了，譬如設定好郵箱後點擊立即構建或者設定多久構建一次，這樣自動化就跑起來了，等待自動化測試結束後我們就可以收到測試成功或者失敗的測試報告郵件（依賴於你的設定）了。

通過上面這些步驟即可完成基於postman和Jenkins的自動化介面測試。

3 總結

可以看見，其實postman就是一個GUI的工具，我們完全可以手動用它驗證介面，但是當有海量介面且有序執行時就比較麻煩了，所以我們可以通過postman將所有介面的測試案例進行編寫實現及匯出；而由於postman匯出的檔案想在jenkins上通過命令列執行依賴於newman環境，所以我們安裝配置了newman，以此就能解決jenkins只能執行命令列或者指令碼的弊端；他們幾個的結合就實現了一次測試案例的編寫實現個性化自動化的介面測試。