API測試基本步驟
1、準(zhǔn)備測試數(shù)據(jù)（這是可選步驟，不一定所有 API 測試都需要這一步）；
2、通過 API 測試工具，發(fā)起對被測 API 的 request；
3、驗(yàn)證返回結(jié)果的 response。
對 API 的測試往往是使用 API 測試工具，比如常見的命令行工具 cURL、圖形界面工具 Postman 或者 SoapUI、API 性能測試的 JMeter 等。
一、使用 cURL 命令行工具
需要下載安裝 cURL，然后通過以下命令發(fā)起 Account API 的調(diào)用。
curl -i -H "Accept: application/json" -X GET "http://127.0.0.1:8080/account/ID008"
調(diào)用結(jié)束后的界面如圖 4 所示。
- 參數(shù)“-i”，說明需要顯示 response 的 header 信息；
- 參數(shù)“-H”，用于設(shè)定 request 中的 header；
- 參數(shù)“-X”，用于指定執(zhí)行的方法，這里使用了 GET 方法，其他常見的方法還有 POST、PUT 和 DELETE 等，如果不指定“-X”，那么默認(rèn)的方法就是 GET。
- 鏈接 ，指明了被測 API 的 endpoint 以及具體的 ID 值是“ID008”。
當(dāng)使用 cURL 進(jìn)行 API 測試時，常用參數(shù)還有兩個：
- “-d”：用于設(shè)定 http 參數(shù)，http 參數(shù)可以直接加在 URL 的 query string，也可以用“-d”帶入?yún)?shù)。參數(shù)之間可以用“&”串接，或使用多個“-d”。
- “-b”：當(dāng)需要傳遞 cookie 時，用于指定 cookie 文件的路徑。
注：這些參數(shù)都是大小寫敏感的。
最常用的 cURL 命令以及使用的場景，包括 Session 的場景和 Cookie 的場景。
Session 場景
如果后端工程師使用 session 記錄使用者登錄信息，那么后端通常會傳一個 session ID 給前端。之后，前端在發(fā)給后端的 requests 的 header 中就需要設(shè)置此 session ID，后端便會以此 session ID 識別出前端是屬于具體哪個 session。
此時 cURL 的命令行如下所示：
curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"
Cookie 場景
如果是使用 cookie，在認(rèn)證成功后，后端會返回 cookie 給前端，前端可以把該 cookie 保存成為文件，當(dāng)需要再次使用該 cookie 時，再用“-b cookie_File” 的方式在 request 中植入 cookie 即可正常使用。
具體的 cURL 的命令行如下所示：
// 將 cookie 保存為文件
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"
// 載入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI"
總結(jié)：cURL 只能發(fā)起 API 調(diào)用，而其本身并不具備結(jié)果驗(yàn)證能力（結(jié)果驗(yàn)證由人完成），所以嚴(yán)格意義上說 cURL 并不屬于測試工具的范疇。但是由于 cURL 足夠輕量級，經(jīng)常被很多開發(fā)人員和測試人員使用。
二、使用Postman測試
具體可通過下方鏈接細(xì)讀
使用 Postman 進(jìn)行接口測試（入門）
使用 Postman 進(jìn)行接口測試（續(xù)）
使用 Postman 進(jìn)行接口測試（cookie設(shè)置）
Postman全局變量設(shè)置和運(yùn)用
Postman 搭建mock服務(wù)
如何應(yīng)對復(fù)雜場景的 API 測試？
1：被測業(yè)務(wù)操作是由多個 API 調(diào)用協(xié)作完成
很多情況下，一個單一的前端操作可能會觸發(fā)后端一系列的 API 調(diào)用，由于前端測試的相對不穩(wěn)定性，或者由于性能測試的要求，必須直接從后端通過模擬 API 的順序調(diào)用來模擬測試過程。
這時，API 的測試用例就不再是簡單的單個 API 調(diào)用了，而是一系列 API 的調(diào)用，并且經(jīng)常存在后一個 API 需要使用前一個 API 返回結(jié)果的情況，以及需要根據(jù)前一個 API 的返回結(jié)果決定后面應(yīng)該調(diào)用哪個 API 的情況。
如何才能高效地獲取單個前端操作所觸發(fā)的 API 調(diào)用序列？
核心思路是，通過網(wǎng)絡(luò)監(jiān)控的手段，捕獲單個前端操作所觸發(fā)的 API 調(diào)用序列。
比如，通過 Fiddler 之類的網(wǎng)絡(luò)抓包工具，獲取這個調(diào)用序列；
又比如，目前很多互聯(lián)網(wǎng)公司還在考慮基于用戶行為日志，通過大數(shù)據(jù)手段來獲取這個序列。
2：API 測試過程中的第三方依賴
API 之間是存在依賴關(guān)系的，比如被測對象是 API A，但是 API A 的內(nèi)部調(diào)用了 API B，此時由于某種原因，API B 在被測環(huán)境中處于不可用狀態(tài)，那么 API A 的測試就會受到影響。
在單體架構(gòu)下，通常只會在涉及到第三方 API 集成的場景中才會遇到這個問題，所以還不算嚴(yán)重。但是，在微服務(wù)架構(gòu)下，API 間相互耦合的依賴問題就會非常嚴(yán)重。
核心思路是，啟用 Mock Server 來代替真實(shí)的 API。
3、異步 API 測試
異步 API 是指，調(diào)用后會立即返回，但是實(shí)際任務(wù)并沒有真正完成，而是需要稍后去查詢或者回調(diào)（Callback）的 API。
對異步 API 的測試主要分為兩個部分
- 測試異步調(diào)用是否成功
異步調(diào)用是否成功，這個還比較簡單，主要檢查返回值和后臺工作線程是否被創(chuàng)建兩個方面就可以了 - 測試異步調(diào)用的業(yè)務(wù)邏輯處理是否正確
對異步調(diào)用業(yè)務(wù)邏輯的測試比較復(fù)雜，因?yàn)楫惒?API 通常發(fā)生在一些比較慢的操作上，比如數(shù)據(jù)庫 I/O、消息隊(duì)列 I/O 等，此時測試往往需要去驗(yàn)證數(shù)據(jù)庫中的值、消息隊(duì)列中的值等，這就需要測試代碼具有訪問和操作數(shù)據(jù)庫或者消息隊(duì)列的能力。
