介面自動化測試
一、分層自動化測試
分層自動化測試是最近曝光度比較高的概念，傳統的自動化測試更關注的是UI層的自動化測試，而分層自動化測試則倡導產品的不同層次都要進行自動化測試。
單元測試：關注程式碼的實現邏輯，比如一個if分支或者一個for迴圈的實現；
服務層測試：關注的程式碼所提供的介面是否可靠；
UI層測試：關注的是介面層的測試；
單元測試和服務層測試，可以通過junit、testNG、unittest等一些測試框架來實現自動化測試。
UI層的測試可以藉助selenium、appium模擬頁面操作實現自動化測試。
我們看這個模型為什麼要設計成金字塔形，而不是長方形或者倒三角形呢，這是為了表示不同階段投入自動化測試的比例，越往上層，其維護成本越高，尤其是ui層的元素會時常發生變化，所以我們應該把更多的自動化測試放在單元測試和介面測試階段。
在這裡我們不是說不提倡大家做UI測試，而是不應該投入太多精力去做UI層的自動化測試。
什麼是介面
介面：外部系統與本系統之間以及系統內部的各個子系統間，以約定標準提供的服務，包括對外提供的介面/對內提供的介面。
在這塊我們舉一個比較生活化的例子，我們平常使用的筆記本，在筆記本的兩端有很多小插口，最常見的就是USB插口，我們可以把滑鼠連線在USB插口上，也可以把鍵盤、U盤連線在USB插口上，為什麼同一個USB介面可以連線這麼多裝置呢，其實這個介面，他就有一個統一對外的連線標準。
在我們開發當中，也有一個對外暴露的介面，因為他們服務的協議都是統一的，最常見的就是hhtp協議，我們規定好一種格式，讓客戶端來呼叫我們。
這裡面鍵盤滑鼠屬於呼叫方，插到筆記本的USB上，就可以連線裝置，就可以進行操作了。對外暴露的一個統一的一個規範，這樣去理解介面，更形象一些。
什麼是介面測試
在瞭解完什麼是介面之後，我們來說一下什麼是介面測試。
介面測試測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等，保證對外提供介面的正確性和健壯性。
我們在具體測試過程中，我們不用關心介面呼叫方和接收方的實現邏輯，我們只需要知道傳入什麼資料，返回什麼的結果是否達到我們的預期。介面測試其實也是黑盒測試，他與UI測試的區別就是沒有介面互動，是不視覺化的。
我們為什麼要做介面測試
測試前置：我們不能等到整個系統全部開發完成才能進行測試，我們可以通過呼叫介面來進行測試，把問題攔截在前期，降低問題修復成本。
Bug更容易定位：因為我們按介面進行測試，出現問題後在被測介面中排查就可以了，它比系統整合之後，發現問題更容易定位，系統整合之後有各種模組的呼叫，出現bug之後再排查，排查的鏈路非常的長。另外從機制上更接近出問題的地方更容易命中問題。
前後端分離結構：現在很多系統都採用前後端分離架構，各服務之間更多的是通過介面來實現資訊互通，對介面進行直接測試，可以更全面的覆蓋各類測試場景。
自動化測試落地價效比高：比UI自動化測試更穩定，我們上面已經說了UI層的元素時常發生變化，有時改一個簡單的元素，都有可能導致我們的自動化測試走不下去，寫一套自動化測試指令碼比較容易的，但是維護起來，會耗費很大的時間精力，相對來說，介面就比較穩定，一個專案沒有大的改造，入參和出參就是固定的，變化的概率比較小，這樣維護起來也比較方便。
減少安全隱患：比如我們在平常的測試過程中，測試使用者名稱和密碼，密碼格式要求不能輸入特殊字元，前端做了校驗，而後端沒有處理，這樣我們只測試頁面，這條case就預設通過了，但一些黑客可能通過抓包的方式進行登入，這樣安全隱患就比較大了。我們對介面進行安全測試，可以避免安全隱患。
介面測試用例如何設計
自動化測試如何落地
藉助工具： Postman、Jmeter、jsf平臺、jsf測試工具、easytest
編寫測試指令碼：Java+TestNG