API 測試就是介面測試。

對於現在大多的網際網路公司來說，API 測試可以實現良好的投入產出比，因此應該成為網際網路產品的測試重點，也就是形成了菱形的測試策略。

原則是：

• 重量級 API 測試。
• 輕量級 GUI 測試。
• 輕量級單元測試。

一、API 測試的基本步驟

API 測試說簡單也很簡單，基本上就是三步走：

• 準備測試資料（也可能有現成的）。
• 使用工具，對待測試 API 發起請求。
• 驗證返回的結果 response。

請求工具就很多了，常見的有：Postman、JMeter、cURL，還有程式碼裡的請求庫，比如 python 中的 requests、java 中的 okhttp 等等。我們通常根據業務特點和所處階段，選用最適合的測試工具。

二、多 API 呼叫的複雜場景

除了我們最常見的單介面測試之外，還會遇到某些業務涉及呼叫多個 API 來完成的場景。

通常這個時候，我們需要知道多個 API 的呼叫順序，這些可以藉助工具（比如fiddler）或者系統日誌來輔助我們完成。

對於有值傳遞的情況，比如 介面B 需要先呼叫介面A 並且使用 A的返回，當做入參。現在也是很好處理，不管是使用 GUI 工具，或者程式碼都可以完成。

我個人偏向使用程式碼，更加靈活輕便。

三、API 對第三方有依賴

API 之間是存在依賴關係的，比如你的被測物件是介面 A，但是介面 A 的內部呼叫了介面 B。此時如果由於某種原因，介面 B 處於不可用狀態，那麼介面 A 的測試就會受到影響。

在單體應用裡，通常只有涉及到第三方 API 整合的場景中才會遇到這個問題，數量不會很多。

但是在當下的微服務架構下，API 間相互耦合的依賴問題就會非常嚴重。

如何解耦，還是得用Mock Server。核心思路是，啟用 Mock Server 來代替真實的 API。

現在也有不少開源的 mock 引擎，可以根據需要進行選用。當然了，有條件的話也可以自研一個，方便實現定製化。

四、非同步 API 的測試

這裡之前還跟奇哥討論過一番，給了我一些不錯的建議。

非同步 API 是指，呼叫後會立即返回，但是實際任務並沒有真正完成，而是需要稍後去查詢或者回調（Callback）的 API。

比如，被測 API A 完成的是下訂單的操作。這個 API A 完成下訂單操作要通過呼叫另外一個 API B 將訂單資訊寫入到訊息佇列中去。

而真正下訂單成功指的是訊息佇列中的訊息被後續服務正確處理並且成功了。此時，這裡的後續訊息處理就是非同步的操作了。

那麼現在測試這個 API A，通常情況下：

• 我只需要驗證它是否正確地發起了對 API B 的呼叫即可。
• 不用關心 API B 的具體行為結果。

具體點描述就是，只關注 API A 是否以正確的引數呼叫了 API B 即可。而無需關注 API B 是否正確地執行了將訂單資訊寫入訊息佇列的操作。更不用關注，訊息佇列中的訊息被非同步處理的結果。

而對於非同步處理的結果，我覺得可以放在一些典型的測試場景裡去覆蓋。

本文參考：
茹炳晟 老師《軟體測試52講》