1. 基本功能介紹
網上有很多介紹基本功能文章，大家可以自己找來看看，下面是我覺得比較好的一篇
2.Postman工作原理
在使用一款工具前，了解它的工作原理才能讓你更快更有效的上手。我們知道對於一個API來說，輸入的請求（Request）包括URL、method、Request Cookies、Request Headers和Request Body；收到請求后，API會回復響應（Response）,包括Response Headers和Response Body。我們之所以可以用Postman作為我們的API自動化測試工具，是因為它能很好的模擬並向API發送Request，接收API發回的Response，並通過寫在Test中的JS函數來對Response做斷言。當然，Postman還有環境變量、Pre-request Script等更高級的功能，不過只要有了這些最基本功能就可以成為一個合格的API測試工具了。
3.常用功能詳解
3.1 Request部分
Request部分用於組合Request的各部分並向API發送。
3.1.1請求URL
不管發送任何請求，確定要填寫的URL是第一件事，尤其是當你習慣復制一個類似的用例改寫成新用例的時候，很容易忽略URL是否完全一致，有時候出了問題排查半天發現原來少了一級URL……
有些URL中會自帶請求參數（一般都是key=value的形式），點擊URL后面的Params按鈕可以打開參數編輯器，Postman會自動將網址分成鍵-值對兩部分。
注意：如果沒有為URL指定協議，Postman會自動將http://添加到URL的開頭。
3.1.2 請求方法
根據不同的API操作需要使用不同的請求方法，Postman有很齊全的方法類型。同時，不同的請求方法也會影響Request Body的編輯區，比如選擇GET方法時，Body區會處於無法編輯狀態。
3.1.3 Authorization
Authorization（鑒權信息）其實是Headers的一部分，但由於這個參數的形式多變且非常重要，Postman將其獨立出來方便用戶進行設置。當在postman中選擇Authorization的類型的時候，可以看到一共有10個類型，這里簡單介紹一下常見類型，以后用到某種的時候可以再詳細了解：可參考https://www.jianshu.com/p/8bb80594d126
a Inherit auth from parent （從父類繼承身份驗證）
當用戶在一個集合內添加文件夾時，這個新添加的文件夾會默認使用Inherit auth from parent，即這個子文件夾內的每個Authorization類型都與父類的一致。比如在下圖中，我在塊網關中的Authorization類型是Bearer Token，則test_add中的所有請求將使用Bearer Token。
b. No Auth
如果不需要授權參數發送請求時，使用“No Auth”
c. Bearer Token
Bearer Token是安全令牌。任何帶有Bearer Token的用戶都可以使用它來訪問數據資源，而無需使用加***。
d. Basic Auth
Basic Auth是一種授權類型，需要驗證用戶名和密碼才能訪問數據資源
3.1.4 請求Headers
在Headers區域可以以鍵值對的形式來設置請求頭內容，包括發送內容格式，要求返回消息語言等等。如果設置了Authorization，在發送請求時也會將鑒權信息自動填入Headers中
3.1.5 請求Cookies
在Postman的Native App中，我們可以通過Cookie管理器管理每個域名對應的Cookie。（我目前接觸到的內部產品中還沒有需要使用Cookie的部分）。
3.1.6 請求Body
Request的主要內容在Body的輸入區中編輯。在輸入區上方有四個選項，根據請求體類型有不同的輸入UI：
a.form-data
Web表單用於傳輸數據的默認編碼，一般模擬網站上填寫表單並提交時使用這個選項。
b. x-www-form-urlencoded
該編碼與URL參數中使用的編碼相同。
c. raw
RAW請求可以包含任何內容，Pstman只會替換其中的環境變量而不會改變其中的編輯內容。
d. binary
二進制數據可讓我們發送Postman中無法輸入的內容，例如圖像，音頻或視頻文件。
3.2 Script部分
在Postman中，Script部分被放在最前面和最后執行，可以完成預處理和斷言的功能，順序如下：
Pre-request Script → Request → Response→ Tests
3.2.1 Pre-request Script
前置請求腳本中的代碼段會在Request發送前執行，一般會在需要設置Request內容包含動態/隨機值時使用。Postmna中給出了幾種常用模板，可以根據實際情況改寫模板內容，如下圖中的代碼段會在Request發送前向環境變量中新增一個名為random_number的參數，它的值是0~1之間的隨機數：
pm.environment.set('random_number', Math.random());
3.2.2 Tests
相較於Pre-request Script，Tests的應用場景更常見，建議每個用例中都在Tests至少添加一條函數作為斷言。像之前介紹的，Tests中的代碼段會在收到Response后執行，並根據Response的內容與之前的預期值作比較。Postman在Tests中給出的常用模板更多，下面舉例幾種常見的用法：
a. 判斷返回碼
用如下函數判斷返回的狀態碼是否正常，一般成功消息的返回碼是200
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
b. 判斷Response消息體中是否包含預期字符串
用如下函數判斷Response Body中是否含有字符串"object already exists"
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include("object already exists");
});
c. 添加環境變量
先定義變量獲取body中返回的所有參數，再把返回參數中的token設置為環境變量Authorization。
var jsonData =JSON.parse(responseBody);
postman.setEnvironmentVariable("Authorization",jsonData.data.token);
注意：JS代碼段中不能直接引用環境變量，需要時可以先定義變量並用pm.environment.get()方法獲取環境變量，然后引用該變量。
斷言結果會在Response部分展示出來：
3.3 環境變量
在編輯Request和Script各部分時，我們常常會發現某些固定值需要使用許多次，一旦這些值需要發生變化時可能需要修改每一個用例。最常見的是URL中的IP值，幾乎會出現在一個Collection中的每個用例中。我們可以將這樣的值以鍵值對的形式在環境變量中定義，並在需要使用時直接引用環境變量的key值。這樣，后續發生變化時，我們只需要直接修改環境變量中的值即可。
添加環境變量：
引用環境變量只需要用{{變量名}}替換原來的值就可以了，當鼠標移動到變量上方時會顯示當前的變量值。
與代碼中的變量相同，Postman中的環境變量也有作用域的概念。一般建議為一組Collection設置一組環境作用域變量，如果有需要的話可以在查看環境變量界面編輯全局變量，全局變量默認對所有用例都生效。
切換環境變量：
查看環境變量：
3.4 Response部分
API響應由正文，響應頭和狀態碼組成。Postman將響應體和響應頭放在不同的標簽中顯示；API調用所需時間、API響應狀態碼顯示在選項卡旁邊。如下圖所示：
3.5 執行用例
編輯好每個用例后，可以統一執行一個Collection中的用例：
在彈出的窗口左側可以選擇執行的環境變量、設置每條用例前的延時時間等操作，右側是之前的測試結果。
完成測試后會生成測試報告，包括每個用例中每個斷言是否執行成功：
3.6 導出用例
當需要將用例共享給其他人時，可以將Collection和環境變量導出，其他人導入后就可以正常使用。
導出Collection：
導出環境變量：
