Postman是一款我們在工作中使用頻率非常高的API調試工具，估計很多童鞋在使用它時也比較粗暴，填好接口位址、參數，直接send就完事了，估計大家要說了，這麼簡單的東西還能玩出什麼花來。今天就和大家安利幾個非常實用、但是可能一直被忽視的功能，用完之後，簡直不要太香！
環境變量
我們通過一個例子來看一下環境變量的用法，在一個項目的生命周期中，可能會有開發環境、測試環境、預上線環境、線上環境等衆多的不同環境，這時候就可以通過環境變量來管理接口的位址以及端口。
點選左側的
Environments
，系統中預設已經存在了一個
Globals
的全局環境，在這裡可以存放一些通用的公共變量的值。先在這裡寫入
host
和
port
資訊：
在需要使用變量時，可以在通路接口時使用雙大括号包裹變量，以
{{variable}}
的方式進行引用：
除了預設的全局環境外，也可以自己建立新的環境來存放變量。在下面的例子中，建立了
local
和
test
兩個環境，這樣我們可以直接在兩個環境間進行切換激活，簡化了開發中測試接口的過程，不再需要頻繁的改動接口的位址。
如果激活的環境和全局環境中有名稱重複的變量，那麼目前激活的環境中的變量具有更高的優先級，它會直接覆寫
globals
環境中變量的值：
在上面，我們将環境變量分為了兩類，普通環境變量和全局變量。總的來說，全局變量具有更高的使用範圍，即使切換到自己建立的環境，全局變量仍然可用。但是我們自己建立的環境之間是互相隔離的，如果切換到一個環境，那麼其他環境中的變量将不再可用。
像上面這樣手動寫入變量的值，在某些時候可能不太友善滿足一些需求，是以postman提供了一種方法，允許使用腳本來改變環境變量的值。我們來看一下發送請求中的
Pre-request Script
和
Tests
子產品，它們是在請求發送前或完成後執行的腳本，具體的使用在後面具體介紹，現在我們隻需要知道能在這裡執行js代碼就可以了。
下面，在
Pre-request Script
中加入兩行js代碼：
pm.globals.set("key1","value1");
pm.environment.set("key2","value2");
執行完成請求後再次檢視環境變量，全局環境和目前環境中都寫入了新的值：
同樣，也可以使用腳本删除變量：
pm.globals.unset("key1");
pm.environment.unset("key2");
除了上面的兩類變量外，postman中的
Collection
也可以存儲變量。
Collection
可以了解為一個集合，通常在使用中我們會将一個應用系統中的接口放在一個集合中，集合中的變量擁有更小的使用範圍，僅在目前集合内可用：
同樣，也可以在腳本中對它進行操作：
pm.collectionVariables.set("key3","value3");
pm.collectionVariables.unset("key3");
在有了環境變量的基礎後，再回頭看一下上面提到的
Pre-request Script
和
Tests
，它們是兩個比較類似的功能，用處也非常廣泛。
Pre-request Script
運作js腳本
Pre-request Script
可以翻譯為預請求腳本，是在請求發送前被執行的代碼邏輯，可以在這裡執行一些
js
代碼。通過下面的簡單例子進行一下示範，先準備一個背景接口，将前端傳遞過來的時間戳轉換為時間并列印：
@GetMapping("test1")
public void time(@RequestParam("time") String time){
Date date = new Date(Long.parseLong(time));
System.out.println(date);
}
在
Pre-request Script
中利用js代碼擷取目前時間，并放到集合變量中，在請求中傳給後端：
發送請求，控制台列印了前端接口的調用時間：
Tue Aug 01 14:14:29 CST 2021
發送get請求
Pre-request Script
的另一大用途就是，在請求目前接口前，通過執行腳本來先請求一下其他接口。在postman中，已經内置了
sendRequest
方法來發送
get
方法請求。我們在這裡調用一個本地接口，并将資訊列印到
console
控制台（可以通過
Show Postman Console
開啟）。
通過控制台的列印順序，也可以看到，是在先執行了
Pre-request
中的請求後，才去執行的真正目标接口的請求。直接像上面這樣調用
sendRequest
時，預設發送的
get
的請求，如果需要使用
post
請求、配置請求
header
或使用
json
傳參的話，可以使用下面單獨封裝請求的方式。
發送post請求
在這裡，我們通過一個例子來示範
Pre-request Script
在具體的工作中能夠怎樣應用。有一個很普遍的場景，通常在調試需要權限認證的接口時，需要提前通過一個接口擷取token，然後再通路目标接口時攜帶這個token。
這時就可以在
Pre-request Script
中先調用擷取token的接口，再将token設定到集合的環境變量中，在之後的接口調用中引用它。在這裡先準備了一個應用了
Shiro+JWT
的項目，其中通過登入接口擷取token，之後的其他接口都需要帶上這個token用于認證 。
我們在
sendRequest
發送
get
請求的基礎上，進行一些修改。首先定義一個變量，在其中使用
url
指定請求位址，
method
指定請求方法，
body
攜帶參數，最後使用
sendRequest
進行請求的發送。
在擷取完成token後，通過下面的代碼将擷取的token放入了
Collection
的變量中：
pm.collectionVariables.set("TOKEN",response.json().data.token);
檢視
Collection
中的變量，已經儲存了剛才擷取的token：
在需要認證的接口
header
中，引用這個token，就可以正常的調用接口了：
在上面的例子中，我們使用的是
urlencoded
的表單傳參方式，如果接口定義是使用json方式傳參，可以寫成下面的格式：
body: {
mode: 'raw',
raw: JSON.stringify({ key: 'value' })
}
如果需要傳遞
header
請求頭資訊，也可以在自定義的請求中添加：
const loginRequest = {
url: '...',
header: [
'Key1 : Value1',
'Key2 : Value2'
],
...
};
具體的使用中需要添加什麼字段非常的靈活，可以由我們自行進行配置。
Tests
和
Pre-request Script
相對，
Tests
是在請求完成後執行的操作。這裡我們回顧一下上面
Pre-request Script
中發送
post
請求的例子，其實可以通過
Tests
來進行改進。
因為在上面的例子中，擷取到的token是
JWT
生成的，具有一定有效時間，在一段時間内是都可以複用的。是以我們可以先手動調用一次
login
接口擷取token，完成後在
Tests
中使用腳本将擷取的token放入
Collection
的變量中，就不需要在每次調用接口前都調用
login
接口重複擷取token了。
調用
login
接口并存入緩存的過程：
之後在調用其他需要攜帶這個token的接口時，使用
{{TOKEN}}
的方式，就會自動填充剛才儲存的
TOKEN
值。這樣在擷取到新的token後，每個接口中的token都會自動更新，就不需要再手動複制到每個接口了，極大的減少了工作量。
在postman中，在
Collection
中可以建立
Folder
檔案夾，并且集合和檔案夾上也可以添加
Pre-request Script
和
Tests
腳本。我們來看一下位于
Folder
中的請求，在執行
Pre-request Script
和
Tests
時順序是怎樣的，在每個環節中加入對應的列印語句，最後輸出的結果是這樣的：