首先，我們想，什麼是 API ？
簡單來說，API，是應用程式接口（Application Programming Interface，又稱為應用程式編程接口），是軟體系統不同組成部分銜接的約定。一個軟體系統越龐大，需要用到的接口相對越多，同時接口的複雜度和接口的設計都需更好的設計和提升。
那麼，什麼是 API 測試？
API 測試其實是一種用程序或工具來發送數據，同時驗收系統的返回值的方法。這種測試更偏向於業務實現邏輯。常見的網絡協議有 TCP、Http、webservice、socket 等，http?和 webservice 都是基於 TCP/IP 協議的應用層協議，webservice 是基於 http 的 soap 協議傳輸數據。我們今天主要說最常見的基於 http協議的API 的測試。
一般來說，API 測試是除去單元測試和白盒測試之外最能夠從底層發現問題的測試方法。那麼，API 測試需要注意哪些技術細節呢？換句話說，怎麼做一個好的 API 測試呢？
我們從以下四點說起：
1 、用例設計
如果把 API 看作一個黑盒的話，那麼我們首先可以設計基於邊界值法、等價類劃分法等的黑盒用例，這些設計思想其實佔據很大成分。常見的比如參數值的邊界，參數缺失/多餘，參數空/非空，特殊字符等；對於複雜的參數，比如結構體/數組鍊表等，可以考慮其最大長度限制/內置特殊字符等。
其次，請求方式/不合法的數據格式/不合法的cookie 也會影響到一個接口的返回值。還有，有些接口涉及到加密解密，需要傳一些密鑰值，一些非合法密鑰的檢驗，來觀察 API 的響應情況。最後，如果手裡有很詳細的接口文檔，把每個 return code 都覆蓋到，很有必要。比如正常是 200 OK，此外還有400(不合法請求)，401(未授權)，429(太多請求)等，或其它一些自定義的 error code，覆蓋的過程，也是把工程代碼分支覆蓋的過程。
2 、請求工具
一般用 Chrome 瀏覽器的話，postman 的使用頻次應該是最多的了。也可以下載postman 等位客戶端。之前用 Firefox 瀏覽器的時候，還用過 HttpRequester。不管用哪種，方法一樣。
首先，填寫好測試 URL，選擇測試方法(GET/POST/PUT/DELETE)，設置 Header(常用的有 content-type/Cookie 等)，設置 authorization type(Basic Auth等)，最後在 body 中填充測試數據。接下來，點擊 send 就好啦，這樣就發送了一個請求到你的目標 API 了。
這裡面比較複雜的可能就是 body 了，常用的格式有 form-data, x-www-form-urlencoded, applictaion/json 等。用哪種格式，正規的接口文檔裡開發同學就會註明。此外，postman 有一個功能很 nice，就是它可以配置環境變量。把配置信息抽象成類，不同環境對應不同的實例，初始化設定後，在 request 請求中通過實例成員變量來引用不同的值，從而在需要的時候通過切換環境來選擇不同的配置信息。比如：我配置了一個env1 環境，並添加了一組 key 和 value，那麼當我引用{{}}這個變量時，就會替換成你所配置的。
3 、程序設計
首先是選擇用哪種語言和相應的請求包，比如 python 的話常用的就是 requests 庫，而Golang 的話你可以使用 net/http 包或是 gorequest 包。拿 python 來說，短短十來行代碼就可以模擬發送一個請求。
但是難點並不於此。
如何組織用例？
一般來說，用例可以分為單個接口用例和場景用例，單個接口很簡單，針對一個接口的參數設置邊界值，對應校驗不同的返回；場景用例涉及到多個接口的調用，用以簡單模擬用戶行為。
測試數據應該放在哪裡？
測試數據可以放在用例裡，也可以放在 json/yaml 等配置文件中。如果涉及到圖片/視頻等比較大的測試文件，最好不要存在本地，可以在測試伺服器搭建一個簡單server，比如使用 ngnix，接下來只需要訪問這些測試文件的連結就好了。
使用哪種風格的測試框架？
現在基本有 BDD 和 TDD 兩種框架之分，我更傾向於使用 BDD，也就是「行為驅動測試」。這個風格有兩個優點：
1.場景分級，易讀清晰，方便定位失敗的用例
2.新手好上手，BDD 的過程就是寫 case 的過程。下面是它的一個流程圖。
4 、接口分析
如果你的團隊裡面，能夠維護一份完整細緻的接口文檔，當然是最好的。如果沒有的話，那麼，優先去推動開發生成一份合適的 API 說明文檔吧。如果達不到這個階段，但是也要做自動化，那麼你就要掌握基本的抓包分析工具，能夠自己去抓包分析形成API 文檔。
所以接口分析是很必要的，也屬於接口測試的高階提升。比如接口定義是否冗餘，接口的請求欄位是否冗餘，接口調用是否得到了所有期望的信息，接口調用是否合理方便，接口是否做到最資料庫進行了正確的變更，接口的平均響應速度是否在可接受範圍等。這些指標的分析，有時候可以反饋給開發同學，對優化整體性能也是有益處的。同時，這些分析可以幫助你更好理解這個過程的來龍去脈，理解這些 API 做了什麼，又產生了什麼影響。
總之，API 測試上手很簡單，但做得好，做成工程化還真需要費一點力氣，一些技術細節的把控和提升，會無形中提升整體的測試水準；而如何讓 API 測試真正在我們的日常工作中發揮出最大作用，也需慢慢研究和調整的。