《軟件測試52講》讀書筆記 —— API測試怎麼作

前言

文章中還介紹了測試工具，好比cURL、postman，單API如何測試；但這些都是偏基礎的東西，且網上教程各式各樣，就再也不贅述了；這裏主要講的就是關於複雜場景的API測試要如何應對

 

API測試的流程

1. 準備測試數據（這是可選步驟，不必定全部 API 測試都須要這一步）
2. 經過 API 測試工具，發起對被測 API 的 request
3. 驗證返回結果的 response

 

如何應對複雜場景的API測試？

測試場景一：被測業務操做是由多個API調用協做完成

背景

一個單一的前端操做可能會觸發後端一系列的API調用，此時API的測試用例就再也不是簡單的單個API調用，而是一系列API的調用

 

存在的狀況

• 存在後一個API須要使用前一個API返回結果的狀況
• 須要根據前一個API的返回結果決定後面應該調用哪一個API

 

存在問題

高效地獲取單個前端操做所觸發的API調用順序

 

解決上述問題思路

1. 經過網絡監控手段，捕獲單個前端操做時所觸發的API調用順序，譬如Fiddler、Charles等抓包工具
2. 也能夠經過用戶行爲日誌，經過大數據手段來獲取調用順序

 

測試場景二：API 測試過程當中的第三方依賴

背景

• API 之間是存在依賴關係的，好比你的被測對象是 API A，可是 API A 的內部調用了 API B，此時若是因爲某種緣由，API B 在被測環境中處於不可用狀態，那麼 API A 的測試就會受到影響。
• 在單體架構下，一般只會在涉及到第三方 API 集成的場景中才會遇到這個問題，因此還不算嚴重。可是，在微服務架構下，API 間相互耦合的依賴問題就會很是嚴重。

 

解決問題的核心思路

啓用 Mock Server 來代替真實的 API

 

測試場景三：異步 API 的測試

什麼是異步API

調用後會當即返回，可是實際任務並無真正完成，而是須要稍後去查詢或者回調（Callback）的 API

 

對異步 API 的測試主要分爲兩個部分

1. 測試異步調用是否成功：檢查返回值和後臺工做線程是否被建立兩個方面就能夠了
2. 測試異步調用的業務邏輯處理是否正確

 

測試異步調用的業務邏輯複雜性

由於異步 API 一般發生在一些比較慢的操做上，好比數據庫 I/O、消息隊列 I/O 等，此時測試每每須要去驗證數據庫中的值、消息隊列中的值等，這就須要測試代碼具備訪問和操做數據庫或者消息隊列的能力。在實際工程項目中，這些能力通常會在測試框架級別提供，也就是說要求 API 測試框架中包含對應的工具類去訪問和操做數據庫或者消息隊列等