API測試有什么特殊的地方懒鉴？
上文說過API的測試變成了被踢來踢去的皮球，游走在單元測試瞻离、系統(tǒng)測試之間腾仅；游走于白盒測試和黑盒測試之間（另一種歸類法）。來看看為什么會這樣呢套利，我們可以從下面Twitter的架構(gòu)簡圖說起推励。
從圖中我們可以看到幾點(diǎn)：
API是分層的，一個讀服務(wù)（Timeline Service）會通過Redis API讀取數(shù)據(jù)肉迫；它又會暴露出API被前端（web验辞，app等）讀取。這張圖沒有關(guān)注組件調(diào)用的依賴關(guān)系喊衫，實(shí)際情況下跌造，調(diào)用層次可能會超過個位數(shù)。
如果API是分層的格侯，存在調(diào)用關(guān)系鼻听，測試的時候就要考慮這些調(diào)用關(guān)系财著。你需要真實(shí)的調(diào)用所依賴的API還是需要Mock联四，這是一個非常有學(xué)問的策略，不同的策略會造成測試成本撑教、測試效率朝墩、測試有效性數(shù)倍的或者數(shù)十倍的差距。除了最基礎(chǔ)的CURD功能伟姐，API會有很多非功能特性收苏，比如圖中強(qiáng)調(diào)的異步和push/pull策略等；twitter的API肯定還會有負(fù)載均衡愤兵，數(shù)據(jù)路由鹿霸，防黑特性等；目前大部分網(wǎng)絡(luò)的服務(wù)都是基于Http的web服務(wù)http的特性需要考慮（get/post秆乳、auth懦鼠、https等等）,建立在http上的各種標(biāo)準(zhǔn),協(xié)議（rest/webservice/xml-rpc/wireless-json等等）钻哩、各種數(shù)據(jù)格式（plain text，xml肛冶，json等）總之街氢，采用不同技術(shù)實(shí)現(xiàn)的API的測試需要關(guān)注對應(yīng)的技術(shù)。
設(shè)計不易睦袖、測試也不簡單珊肃，你要保證做出來的東西實(shí)現(xiàn)了設(shè)計意圖不是？-
API測試不僅僅要關(guān)注單API的業(yè)務(wù)馅笙，還需要關(guān)注API是否能夠很好的協(xié)同工作伦乔。很多API的調(diào)用是有狀態(tài)（上下文）的，這也給API測試帶來了很大的挑戰(zhàn)董习。設(shè)計API組成的測試場景有時候是接口測試的一個很大難題评矩。
如需轉(zhuǎn)載，請注明出處和作者@skytraveler （新浪微博）
