我在之前的文章裏提到過有些情況不適合跑UI測試的，而適合用接口測試來覆蓋，我是傳送門。
尺有所短，寸有所長。接口測試是UI自動化測試的一個強有力的補充。
- 首先接口測試較UI測試效率更高，速度更快
- 其實接口測試較UI測試穩定性更高
打個比方，請求某API，正常情況下它返回一堆數據。如果走UI測試，可能需要登錄>去到相應頁面>把相應條件設置好>點擊某按鈕觸發請求>等待頁面響應，直至加載完成>然後去DOM Tree裏面檢索相應元素，把數據提取出來，有可能數據量太大導致分了很多頁，提取速度不快，中間頁面操作可能還出問題。
這種情況就十分適合走接口測試。Web接口測試（Web API測試）一般都是去Request某個URL（Get或Post），同時傳遞必須的參數，拿到Response後對它進行解析，將我們感興趣的部分提取出來，跟預期的結果比對。Web接口測試需要API文檔支持，如果缺失，開發GG應予以說明。
各類開發語言裏都有HTTP模塊，用於構造HTTP請求>Request>Get Response。都是大同小異。常見的HTTP返回值對應的狀態如下：
- 200 OK是最常見的，表明請求已被受理，Response已返回
- 300開頭的一般指重定向，比較少見
- 400開頭一般是Client端錯誤，比如，請求的URL不對，
- 500開頭的一般都是Server端錯誤，比如Server端這個服務掛了
具體的返回值釋義請看我是傳送門。
本着數據驅動測試的精神，接口測試的參數以及預期的結果放到文件裏比較好，維護起來也明瞭方便。
在這裏推介一個工具：Telerik公司出品的小而美的Fiddler。在它被啓動時，它就將自己註冊爲Windows Internet Service（WinINet）的系統代理，位於HTTP層，Internet Explorer, Chrome, Firefox, Safari, Opera…等等應用在發送請求及接收返回時都是要調用WinINet的。所以，不管用什麼瀏覽器，只要啓動了Fiddler，那麼它發送的所有請求都會先到Fiddler，經由Fiddler將請求傳至服務端，服務端返回的Response也會先到Fiddler，再由Fiddler將Response傳給瀏覽器。
Fiddler功能很強大，開發們可以用它進行Web Debug或者性能分析，測試人員亦可以用它來模擬HTTP請求，並觀察返回值。
因爲我們項目的UI自動化用的就是Telerik的測試框架，所以，天然無縫地會Fiddler很親和 ;-)
網上有太多Fiddler的帖子，同學們自己搜吧，Fiddler官方文檔在這裏我是傳送門，英語沒問題的自己去看吧。