介面自動化1 概要

介面型別：

3.dubbo介面

dubbo 介面是阿里巴巴開源的致力於提供高效能和透明化的rpc遠端服務呼叫方案，以及soa服務治理方案，dubbo框架告別了傳統的web service的服務模式，進而改用provider和consumer模式進行服務。

可以在某個伺服器集群中提供單一專注的服務，這樣不與其他服務混雜，同時dubbo介面有soa排程通過監控每台伺服器而實現負載均衡。consumer端無需關注provider端如何實現，只需在註冊中心訂閱即可到相應伺服器請求服務，這樣就實現了高效能和透明化。

dubbo介面就是乙個分布式服務框架。

介面測試

定義：介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

目的：測試介面的正確性和穩定性。　　

原理：http介面測試：是模擬客戶端向伺服器傳送請求報文，伺服器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端接收應答的過程； dubbo介面測試：是模擬使用者呼叫介面，檢查返回值的過程。　　

重點：檢查資料的交換，傳遞和處理結果的正確性，還包括效能穩定。　　

核心：持續整合是介面測試的核心

介面測試選取原則：

1.優先測試外部介面（暴露在外面的介面）

2.根據介面被呼叫頻次

3.需要重點保障的核心功能

介面測試收益

實現測試左移，可以讓測試提前，縮短整個專案的研發週期

現在很多業務前後端架構是分離的，前端ui變動頻繁，介面測好了，後端不用變，提高團隊協同工作的效率

檢查系統的安全性、穩定性比如購物**，前端**不可能傳入-1元，但是通過介面可以傳入-1元

介面測試相對容易實現自動化持續整合，相對ui自動化也比較穩定，可以減少人工回歸測試人力成本與時間，介面持續整合是低成本高收益的根源。

前後端配合

同乙個功能模組，很可能被前端web測試和後端介面測試重複測試，此時會存在一定的人力浪費，我們如何協調前後端測試，達成測試效果最大化呢？

1. 理想情況，業務功能基本上都由後端測試，前端人員僅關心ui和使用者體驗友好性。

2. 實際情況，我們需要分析業務上功能穩定性相對比較高的模組，此部分用例指令碼編寫一次後，相對穩定，可持續自動化回歸驗證，效率提公升最明顯。可以僅做介面測試，前端簡單驗證；

另外，也要考慮核心功能模組，核心功能模組則通過介面+前端雙層驗證，不同的人驗證，可能發現問題的角度不同，能夠更加保障質量。

流量回放是如何進行服務介面回歸驗證的？

通過把線上的真實流量複製到線下環境，解決測試環境模擬不夠真實，或覆蓋不夠全面的問題。

什麼情況下要採用流量回放：

1.介面數量非常龐大

2.沒有完整的設計文件和系統功能用例，測試場景在測試過程中覆蓋不全

3. 出現同一介面在某種特定場景下返回結果並不是業務方所期望的（歷史遺留問題，該介面沒有記錄該場景）

4. 沒有充足的時間導致回歸不充分

介面超時怎麼測試（斷網），請求重複怎麼測試，請求併發怎麼測試（效能）