API Testing(Using Postman Script)—上

由於公司新購辦公室，適逢疫情期間，WFH以及Mobile Office的需要，為最大化辦公室資源的利用率，決定導入座位預約系統讓往來兩處的同仁可以預約。最後選擇搭配既有產品—Vitals RBS(Resource Booking Service)來當做後台，另再客製化前台預約畫面，將其延伸成適合公司內部使用的系統。這樣不僅能夠加快開發進度，還能利用該團隊產品的穩定性和可靠性，降低開發風險。

但由於兩個系統是使用API來溝通處理資料，因此API的測試尤為重要。確保API的穩定性和可靠性是系統正常運作的關鍵之一。為此，開發團隊將使用Postman來進行全面的API測試，包括功能測試、流程測試。

而Postman作為一款強大的API測試工具，能夠幫助團隊設計和執行各種測試用例，檢驗API的各項功能和性能指標。這樣可以確保在實際使用中，系統能夠高效、穩定地運行，並能快速響應和處理各種請求，從而提供優質的用戶體驗。

接下來我們就開始介紹怎麼把Postman運用在我們的系統吧！ 

API 呼叫流程

如下圖，將Vitals RBS API轉換成符合座位預約系統需求的API，並進行測試：

• 準備3個測試案例=> API FLOW 1/2/3

API FLOW-1(UI呈現)

• Step 1: 取得某大樓的樓層座位數量
• Step 2: 再去取得對應樓層各區域的座位數量

API FLOW-2(UI呈現)

• Step 3: 取得樓層某區域的座位數量
• Step 4: 再去 選取此區域中的某個座位進行新增預約動作

API FLOW-3(UI呈現)

• Step 5: 將上述成功的預約資料進行刪除

如何 使用Postman進行腳本測試 ？

主要分為：

1.Pre-request Script (預先請求指令稿)

簡單來說，就是在執行Request前就要跑的指令

• 範例
  • 設定/取得參數

• 開啟Console並執行，就可以看見先執行上面的指令後，才接著執行POST Request

2.Tests Script (測試指令稿)

進行測試案例的指令

• 範例
  • 在Tests分別撰寫3個測試，在執行時就會顯示Test Results成功或者失敗

單一腳本測試

範例1.取得樓層數量

• API資訊

• 建立 Tests Script(測試指令稿)
  • 若API回傳資料非筆，即可通過測試案例
    • 其實寫法不難，把回傳的responseBody轉為JSON，再去判斷data的length是否>0 即可

範例2.取得區域數量

• API資訊

• 建立 Tests Script(測試指令稿)
  • 若API回傳資料非筆，且座位為選擇的區域，即可通過測試案例
    • 把回傳的responseBody轉為JSON，再去判斷data的length是否>0
    • 若>0，再取得座位資料是否為指定區域的座位

範例3.取得資源數量

• API資訊

• 建立 Tests Script(測試指令稿)
  • 若API回傳資料非筆，且為選擇的座位，即可通過測試案例
    • 把回傳的responseBody轉為JSON，再去判斷data的length是否>0
    • 若>0，再確認回傳的座位資料是否含指定的某個座位編號

單一腳本測試

步驟1. 準備測試腳本&資料

• 將Request裡要測試的的參數改為環境變數
• 準備測試案例JSON格式(多種情境的參數)

步驟2. Run Collection

• 左側選單將要測試的Collection右鍵選擇"Run Collection", 勾選要測試的Requests
• 右側Select File選擇上個步驟所準備的JSON測試案例資料(也允許CSV檔) 
• 右方Preview可以先檢視要測試的資料

步驟3. 查看執行結果

• 前述步驟勾選3個Requests且有4個案例, 所以總共會有12個Tests, 但卻顯示只有10個Tests
• 發現Interation2有Error, 便沒再執行第2&3個Request
• Check Console點進去查看發現回傳的data為null, 導致錯誤

步驟4. 修正發生錯誤導致的問題

• 調整: 若data為null就直接回傳"測試失敗"的結果

步驟5. 重新Run Collection

• 調整: 確認執行完沒有再發生語法相關錯誤

以上是介紹使用Postman進行單一腳本和批次測試內容！有興趣的朋友可以尋找相關案例來親自操作體驗。

在下一個階段，我們將介紹如何在這個系統中進行流程測試，以及後續的CI/CD設定和實作。敬請期待！