前言
文章中還介紹了測試工具，比如cURL、postman，單API如何測試；但這些都是偏基礎的東西，且網上教程各式各樣，就不再贅述了；這里主要講的就是關於復雜場景的API測試要如何應對
API測試的流程
- 准備測試數據（這是可選步驟，不一定所有 API 測試都需要這一步）
- 通過 API 測試工具，發起對被測 API 的 request
- 驗證返回結果的 response
如何應對復雜場景的API測試？
測試場景一：被測業務操作是由多個API調用協作完成
背景
一個單一的前端操作可能會觸發后端一系列的API調用，此時API的測試用例就不再是簡單的單個API調用，而是一系列API的調用
存在的情況
- 存在后一個API需要使用前一個API返回結果的情況
- 需要根據前一個API的返回結果決定后面應該調用哪個API
存在問題
高效地獲取單個前端操作所觸發的API調用順序
解決上述問題思路
- 通過網絡監控手段，捕獲單個前端操作時所觸發的API調用順序，譬如Fiddler、Charles等抓包工具
- 也可以通過用戶行為日志，通過大數據手段來獲取調用順序
測試場景二：API 測試過程中的第三方依賴
背景
- API 之間是存在依賴關系的，比如你的被測對象是 API A，但是 API A 的內部調用了 API B，此時如果由於某種原因，API B 在被測環境中處於不可用狀態，那么 API A 的測試就會受到影響。
- 在單體架構下，通常只會在涉及到第三方 API 集成的場景中才會遇到這個問題，所以還不算嚴重。但是，在微服務架構下，API 間相互耦合的依賴問題就會非常嚴重。
解決問題的核心思路
啟用 Mock Server 來代替真實的 API
測試場景三：異步 API 的測試
什么是異步API
調用后會立即返回，但是實際任務並沒有真正完成，而是需要稍后去查詢或者回調（Callback）的 API
對異步 API 的測試主要分為兩個部分
- 測試異步調用是否成功：檢查返回值和后台工作線程是否被創建兩個方面就可以了
- 測試異步調用的業務邏輯處理是否正確
測試異步調用的業務邏輯復雜性
因為異步 API 通常發生在一些比較慢的操作上，比如數據庫 I/O、消息隊列 I/O 等，此時測試往往需要去驗證數據庫中的值、消息隊列中的值等，這就需要測試代碼具有訪問和操作數據庫或者消息隊列的能力。在實際工程項目中，這些能力一般會在測試框架級別提供，也就是說要求 API 測試框架中包含對應的工具類去訪問和操作數據庫或者消息隊列等