postman的GUI介面以及各個元件介紹

主介面如下

開啟postman的GUI介面以及各個元素元件介紹

分為下三部分：

1、Head navigation bar （頭部導航欄）：此部分有以下選項內容需要了解：

（1）New（新建按鈕）：可以用來新建集合、請求、mock服務、監聽器、測試環境等（重要);

（2）import（匯入按鈕）：可以用來匯入檔案 資訊、集合、資料夾、以及連結（tab）；

（3）Runner（執行按鈕）：用於執行集合（重要）；

（4）新視窗增加按鈕：可以用來增加新的postman視窗、執行視窗、以及請求頁籤（tab）；

（5）：構建器和團隊選項，可以用於團隊庫和當前檢視的轉換；

（6）抓取api請求圖示：可以通過次按鈕抓取api（不常用）

（7) 同步狀態圖示：同步apid 請求已達到共享；

（8）設定圖示：管理postman的應用程式，設定postman主介面；

2、Side navigation bar ：次部分包含內容如下：

（1）History：用postman發起過的任何請求，都會儲存在歷史選項卡里；；

（2）Collections：集合選項卡，可以是每個請求的集合、也可以是URL的集合；

3、work space：工作空間是postman使用的重點，對其務必熟悉；postman通過選項卡的形式在構建器中傳送和管理的請求資訊；

上部分是請求構建器，下部分是相應構建器；具體說明如下：

面對post請求如何使用postman進行測試：

用postman進行get請求：

如何在postman中進行引數化

 postman支援子啊介面請求中，對某個請求欄位，或者url進行引數化。對url進行引數化只需要將其配置成環境變數，然後在url中對其進行引用即可。

對url進行引數化

對介面中的某個請求欄位進行引數化

例項介面：

通過postman請求和響應如下：

此時我們想更換100個人，迭代請求apply介面，此時就需要name、certicode、age這三個key值進行引數化。postman本身支援三種引數化的方式。通過.text文件、通過.csv檔案以及json檔案。對於我而言，推薦大家採用第一種方式即.text方式進行引數化。因為操作簡單，json檔案的組織比較繁瑣，不太適用於多個引數需要引數化的場景，而.csv檔案對格式要求過高，會浪費精力。具體實現步驟如下：

1、組織需要的引數化的引數檔案，檔案內容展示如下：

引數之間需要用英文字元下單逗號間隔，編碼需要utf-8,儲存的檔案字尾為.text即可；

2、在Apply介面的Pre-request Script出寫入如下指令碼，讀取text引數化檔案。

var apply="apply.text";   //宣告引數化檔案

var name=apply.name;  //讀取第一個引數name

pm.environment.set("name","name");   //將name的值依次賦給請求中的name

var age=apply.age;

pm.environment.set("age","age");

var certicode=apply.certicode;

pm.environment.set("certicode","certicode");

3、將原請求中的具體值分別進行引數替換：替換後的請求為：

{

　　“interfaceType”:"apply",

　　"name":{{name}}",

　　"age":"{{age}}",

　　"certicode":"{{certicode}}"

}

4、開啟runner，設定迭代次數且匯入引數化檔案；

5、點選“Run 360足球聯賽”可以看到總計數迭代的次數為我設定的10，當然如果各個次數個數為100，就設定為100即可；執行完成後，效果圖如下：

6、開啟控制檯，可以檢查下每次請求是否按照引數進行取值；

上圖知識截了第一次迭代、第二次迭代的請求，可見取的是引數化檔案對應的第二行、第三行的值，不從第1行讀取，是因為第一行是引數化列表；

使用runner對定時任務、請求進行迭代配置

配置定時任務的思路其實就是引數化介紹的runner介面控制，選擇迭代次數以及每個定時任務之間的間隔時間即可；

用js指令碼設定檢查點（斷言）

以上宣告postman支援引數迭代，那麼在結合上其身的js指令碼，我們還可以用postman做介面的自動化驗證，當然其有不足之處，體現在不能實現錯誤重試、生成測試報告以及錯誤資訊的實時採集。但是滿足日常的流程驗證（現在也叫契約測試）是綽綽有餘的。

在runner下執行準備好的apply 、sign、login三個介面，點選：Run Summary

執行結束後，不難看出，三個介面只是運行了，或者說滿足了被呼叫的條件，但無法通過這個執行判斷出介面到底是不是按照要求來做的、也就是響應時間、響應碼、響應引數等是否滿足約束。為了解決這個問題，我們為其新增斷言（或者叫檢查點）；拿apply介面為例，學習檢查點相關內容：

以下介紹常用的指令碼：

1、設定環境變數

pm.environment.set("variable_key","variable_value");

2、檢查http請求的狀態碼是否於預期一致

pm.test("Status code is 200",function() {

　　pm.response.to.have.status(200);

});

3、檢查JSON響應中包含某個欄位

pm.test("Your test name",function () {

　　var jsonData=pm.response.json();

　　pm.expect(jsonData.value).to.eql("欄位名稱");

});

4、檢查響應體中可以解析某個指定欄位的值

pm.test("Body matches string",function () {

　　pm.expect(pm.response.text ()).to.include("string_you_want_to_search");

});

 5、檢查響應時間的長短

pm.test("Response time is less than 200ms",function () {

　　pm.expect(pm.response.responseTime).to.be.below(200);

});

下面在apply介面中加入上面的檢查點：

此時，可以發現執行結果飽滿了很多，不單單是介面的執行，還有相應的檢查點判斷，如上為apply介面設定的檢查點定時pass的，這樣的話，後續介面發生變更，想要驗證介面是否滿足約束，直接執行次檢查點案例即可；