隨著各種行動裝置與各式各樣的載體出現，API 讓前後端程式開發人員能夠更快速串接新功能，又能夠在不同裝置上帶給使用者不一樣的體驗。每每當程式要上線前，總是讓開發人員既期待又怕受傷害，一方面是辛辛苦苦的孩子終於要出世了，一方面又會怕會不會有新的 BUG 出現（我養 BUG，BUG 養我）

這時候測試就很重要啦，既能夠保證功能如需求完成，又能保護下次新加功能不會改 A 爛 B。

好的 API 讓前端輕鬆串接，專注呈現各式各樣的體驗；後端只需要專注於保證穩定功能的輸出，大家開開心心 ～ API 沒寫好，輕則資料呈現錯誤，重則 APP 閃退負評滿點…

Image

API 測試從這三個地方著手，一定面面到位

1. 功能：是否完成 API 主要的目的

以取得商品資料來說，輸入了商品編號作為查詢必要參數，是否有正確回應商品資料？回應的商品資料格式是否正確？是否支援像是顏色等選填參數？

如果沒有此商品，API 是否有正確回應找不到商品的錯誤？或者是否有非預期的情況發生？

⚠️ 測試通常都著重於正確的情況，但錯誤的情況也是很重要，至關使用者體驗與是否能夠透過此方式主動發現問題

另外，選填參數也是常常會忽略的地方，例如：頁數、每頁幾個、日期，這些是否有符合規定？數字是否負數？起始日期是否小於結束日期？

2.性能：是否能夠"及"時處理完？

這邊特別強調是及時，因為每隻 API 對於速度的要求不一，是否能夠在容許的請求時間內回應決定在使用情境上。

通常合理的要求回應時間多半低於 500 毫秒 (ms)。

3.安全性：牽涉到需要存取權限的 API 是否有驗證機制？

多半而言每個人只能夠查詢自己的個人資料，別人必須無法存取。那 API 應該透過什麼方式來實現權限控管？驗證機制會是使用什麼方式？

延伸說明

API 由三個部分組成

  1. Header

    通常包含常用且通用的參數：api-key, token, language …

  2. URL (Method)

    存取的位置，包含取用的方法：GET, POST, PUT, DELETE …

  3. Body

    最重要的資料本人，通常還會有不同的格式，但大多為 JSON

HTTP Response Code

  • 1xx：系統接收到了

  • 2xx：正確

  • 3xx：導頁

  • 4xx：客戶端錯誤（參數不對）

  • 5xx：伺服器端錯誤（非預期錯誤）

詳細資料可以參考：HTTP 狀態碼

一步一腳印，慢慢全面測試 API

讓上線成為一件幸福的事情

（這不是什麼名人錦句，這我自己說的）