API測試有什么特殊的地方？
上文說過API的測試變成了被踢來踢去的皮球，游走在單元測試、系統(tǒng)測試之間；游走于白盒測試和黑盒測試之間（另一種歸類法）。來看看為什么會這樣呢，我們可以從下面Twitter的架構簡圖說起。
從圖中我們可以看到幾點：
API是分層的，一個讀服務（Timeline Service）會通過Redis API讀取數(shù)據(jù)；它又會暴露出API被前端（web，app等）讀取。這張圖沒有關注組件調用的依賴關系，實際情況下，調用層次可能會超過個位數(shù)。
如果API是分層的，存在調用關系，測試的時候就要考慮這些調用關系。你需要真實的調用所依賴的API還是需要Mock，這是一個非常有學問的策略，不同的策略會造成測試成本、測試效率、測試有效性數(shù)倍的或者數(shù)十倍的差距。除了最基礎的CURD功能，API會有很多非功能特性，比如圖中強調的異步和push/pull策略等；twitter的API肯定還會有負載均衡，數(shù)據(jù)路由，防黑特性等；目前大部分網(wǎng)絡的服務都是基于Http的web服務http的特性需要考慮（get/post、auth、https等等）,建立在http上的各種標準,協(xié)議（rest/webservice/xml-rpc/wireless-json等等）、各種數(shù)據(jù)格式（plain text，xml，json等）總之，采用不同技術實現(xiàn)的API的測試需要關注對應的技術。
設計不易、測試也不簡單，你要保證做出來的東西實現(xiàn)了設計意圖不是？-
API測試不僅僅要關注單API的業(yè)務，還需要關注API是否能夠很好的協(xié)同工作。很多API的調用是有狀態(tài)（上下文）的，這也給API測試帶來了很大的挑戰(zhàn)。設計API組成的測試場景有時候是接口測試的一個很大難題。
如需轉載，請注明出處和作者@skytraveler （新浪微博）
