本文的介面只是限於HTTP的介面，其他的介面由於沒有業務上的需求，也沒有多做研究。關於介面測試，本人嘗試過很多的方法，下面是過程中的一些想法，隨感而發。

      

介面測試概念

1.     Q：什麼是介面？

A：子模組或者子系統間互動並互相作用的部分； WindowsAPI， 資料庫訪問介面；WebService；Http Rest

2.     Q：Http介面是什麼？包括哪些部分？

A：http介面就是一種基於http服務的api，是系統之間互動的一種約定，所謂的webservice其實也就是一種http介面，只不過它是比較規範的、通用的。

      主要包括Http協議，請求值，返回值，呼叫方式，實現方式等

3.     Q：為什麼要測試介面？

A:  移動網際網路；產品迭代加快，測試需要提速，前端介面修改頻繁

4.     Q：為什麼可以提前測試介面？

A：不需要前端頁面完成，可以直接模擬一個前端請求，測試介面，驗證返回結果，能提早發現問題；而且還可以測試一些不容易在介面產生的請求，比如壓力和效能測試等，可以提前測試介面的效能。還可以明確產品的狀態，方便管理。

5.     Q： 怎麼測試介面？

A： 有很多開源的介面測試工具，比如postman,還有線上的http介面測試工具；SoapUI；開發指令碼等。

6.     Q：介面應該測試什麼？

A：單一介面測試：測試某個介面的功能

      組合介面測試： 類似於業務流程測試

       結構檢查： 驗證傳送和返回資料的結構

介面測試的必要性

1.     Q:  我們需要做介面測試麼？

A:   我們屬於大型的網際網路產品，結構複雜，功能繁多，迭代快速； 那麼在有限的測試時間裡面，要完成新功能的測試以及原有功能的迴歸測試將是一個很有挑戰性的工作，這還不算中間可能會出現的突發性問題。 因此，本人認為，介面測試可以做到兩點：第一，在前端介面完全做好前，測試app介面的正確性；第二，快速的迴歸測試，那麼測試人員就可以把精力放在UI層面和業務層面。

2.     Q：介面測試的投入產出比，即維護成本很大麼？

A： 我們一直在做web自動化測試，並且為之付出了很多的努力，但是投入產出比仍然不高，主要原因有兩個： 第一，前端頁面變化太頻繁；第二，人員不夠，需要大量投入。但是如果做介面測試，那麼工作量和維護成本就會下降至少2倍，而且由於不涉及到前端顯示，只要介面不變，那麼維護成本也不會很高。

3.     Q:  做了介面測試，web自動化怎麼辦呢？

A:   其實這兩個不衝突，還可以做到互補，雖然不是沒有交集，但是也可以設計得交集很少，並且各有針對性。Web自動化主要針對前端比較穩定的功能，既不會頻繁改動的頁面，可以做迴歸測試；而介面測試則可以補充web的空缺，並且可以模擬一些前端不好模擬的測試場景。並且，介面測試的執行速度更快些。

未完待續... ...