簡單的Postman,還能玩出花?

碼農參上發表於2021-08-06

Postman是一款我們在工作中使用頻率非常高的API除錯工具,估計很多童鞋在使用它時也比較粗暴,填好介面地址、引數,直接send就完事了,估計大家要說了,這麼簡單的東西還能玩出什麼花來。今天就和大家安利幾個非常實用、但是可能一直被忽視的功能,用完之後,簡直不要太香!

環境變數

我們通過一個例子來看一下環境變數的用法,在一個專案的生命週期中,可能會有開發環境、測試環境、預上線環境、線上環境等眾多的不同環境,這時候就可以通過環境變數來管理介面的地址以及埠。

點選左側的Environments,系統中預設已經存在了一個Globals的全域性環境,在這裡可以存放一些通用的公共變數的值。先在這裡寫入hostport資訊:

在需要使用變數時,可以在訪問介面時使用雙大括號包裹變數,以{{variable}}的方式進行引用:

除了預設的全域性環境外,也可以自己建立新的環境來存放變數。在下面的例子中,建立了localtest兩個環境,這樣我們可以直接在兩個環境間進行切換啟用,簡化了開發中測試介面的過程,不再需要頻繁的改動介面的地址。

如果啟用的環境和全域性環境中有名稱重複的變數,那麼當前啟用的環境中的變數具有更高的優先順序,它會直接覆蓋globals環境中變數的值:

在上面,我們將環境變數分為了兩類,普通環境變數和全域性變數。總的來說,全域性變數具有更高的使用範圍,即使切換到自己建立的環境,全域性變數仍然可用。但是我們自己建立的環境之間是相互隔離的,如果切換到一個環境,那麼其他環境中的變數將不再可用。

像上面這樣手動寫入變數的值,在某些時候可能不太方便滿足一些需求,因此postman提供了一種方法,允許使用指令碼來改變環境變數的值。我們來看一下傳送請求中的Pre-request ScriptTests模組,它們是在請求傳送前或完成後執行的指令碼,具體的使用在後面具體介紹,現在我們只需要知道能在這裡執行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 ScriptTests,它們是兩個比較類似的功能,用處也非常廣泛。

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 ScriptTests指令碼。我們來看一下位於Folder中的請求,在執行Pre-request ScriptTests時順序是怎樣的,在每個環節中加入對應的列印語句,最後輸出的結果是這樣的:

也就是說,在傳送請求前,postman會先執行所有Pre-request Script,並且順序是集合最先、資料夾次之、最後是請求中的,在執行完成真正的請求後執行所有的Tests,順序同上。這也就要求我們在使用Pre-request ScriptTests功能前,首先要求我們對介面的呼叫順序、資料的流向有一個明確的瞭解,這樣才能保證不會出現空值或更新錯誤的情況。


如果文章對您有所幫助,歡迎關注公眾號 碼農參上

相關文章