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