Postman 有兩個好物 Pre-request 與 Tests，提供我們在送出Request 前與收到 Response 後，
可以設定參數(前)或驗証回傳值(後)是否滿足期待，亦或是取 token 及測試案例設計都很方便
針對這兩者發生的位置，如下圖所示，這就是為什麼可以在前後加工
以下簡單介紹使用方式
Pre-request
有這項目的地方如 Collection、Folder、Request 等等，如下圖
可以在這個區塊填上 script，來試試填上變數的值，先設計 request url 及參數，如下
接著，設定 q 變數的值，如下所示，頁籤切到 pre-equest，設定參數並使用 console 印出值
開起 console 檢視相關值，可以看出實際 url 的值後面有 q=test，代表成功置換
其中，由於 pre-request 的作用是在送出 request 之前發生的，所以可以在這邊 ajax 取得
第三方相關資源，如 token 等等，可參考
Tests
看名稱很明顯就是測試，針對response 內容，可以設計一些語法來驗證是否符合期待；這邊示
範若成功送出 request 後，應該會得到一個 status code = 200 的值；如下圖，首先切到 Tests
頁籤，並且輸入 pm.test 相關內容來驗證期待值
點選「send」按鈕後，待傳送完成，下方視窗有個 Test Results 頁籤，可以看到 PASS 綠燈，代表
測試的項目符合期待
Scope
前面有提到過，postman 很多地方都可以支援 pre-request 或 tests，如Collection、Folder、
Request 等等...，若相關區塊存在相同設定，則權重就是越裡面的越高，意即
Request > Folder > Collection ，以下透過簡單的示範來觀察這特性
透過 Collection 設定
若我們將 pre-request 內容放到 collection，則該 collection 所屬的項目且未設定 pre-request
者，都將套用，如下圖所示
此時 new request 的 pre-request 項目沒有設定
點選送出後，可以得到以下結果
其中，原本 pre-request 內容的 search 變數，重新設定為 from collection pre-request，如下圖
所以，透過 collection 的設定確實發揮效用
透過 Request 設定
若此時在 request 再次設定，同樣的內容，我們再次設定 search 變數 為 from request only，如下圖
最後，點選送出，得到以下結果，最後的url 確實帶了正確的參數 from request only
以上就是 pre-request 與 tests 的設定，以自己的經驗，大都一開始先設定在 request 任務，等到任務
漸漸多了，且邏輯一致，就會整理到 collection 或 folder 中。
沒有留言:
張貼留言