基于微服務或者 SOA 的自動化測試系統每個公司都有自己的特有的，我今天就主要介紹一下，我們研發的一套 mock 測試系統。

我公司目前用的是基于 Dubbo 的微服務改造，服務之間的調用鏈路冗長，每個服務又是單獨的團隊在維護，每個團隊又在不斷的演進和維護各個服務，那么對測試人員將是非常大的挑戰。

測試人員每次進行功能測試的時候，測試用例每次都需要重新寫一遍，無法將測試用例的數據沉淀，尤其是做自動化測試的時候，測試人員準備測試數據就需要很長時間，效率非常低。

目前接口自動化測試框架也多種多樣，testng，junit，Fitnesse 等，但都需要測試人員具備測試代碼編寫能力，如果要做好和手工接口測試一樣效果的自動化測試更是需要大量的代碼堆積，后期維護代碼成本非常大。因此做成簡單配置用例流，無需編寫測試代碼的系統是更貼合實際工作要求。

舉個例子：拿互聯網支付系統來說，某個團隊新增了支付交易的需求，這時候要進行測試，測試人員除了要測試支付交易需求本身是否正確，同時也要結合上下游的服務整體進行回歸測試，這時候開發人員往往在支付交易系統中采用“硬編碼”的方式對上下游的系統進行“擋板”，如果測試人員對測試數據有所調整那么“擋板”也要跟著調整，同時在項目正式上線的時候，如果開發人員沒有將“擋板”程序去除干凈，將面臨嚴重的線上問題。

接口返回值

通過肉眼分析比對接口返回值的內容，判斷業務邏輯正確性。

數據庫驗證

測試接口的輸入值需要通過手工編寫數據庫 SQL 查詢獲取，接口調用完成后，需要通過大量的 SQL 驗證數據庫值的正確性。

日志驗證

通過返回值和數據庫不能確保代碼走到了預期的邏輯，只能通過肉眼觀察日志確認代碼的實際運行邏輯

測試報告

人工記錄用例結果，人工編寫報告，耗時耗力，難以準確定位代碼問題

業務系統調用眾多其他系統完成功能邏輯，而想要得到其他系統接口的特定輸出，需要做相應的運營配置，增加很多的溝通成本；甚至偶發性 bug 只能在特定的環境狀況下復現，只能作為不可測的邏輯。

以風控系統為例，如果業務系統需要測試某個商編某個商品類別下的累積限額，需要風控的同事配合不斷修改限額閾值，目前的情況是多個業務系統都在接入風控，配合測試的人力成本和時間成本是很高的。為此設計了擋板模擬系統，其功能結構如下：

針對測試人員測試用例數據無法沉淀和復用的問題，我們將采用“用例與日志錨點庫”方案：

• 用例庫的建立可以實現對以往測試規則的記錄與復用，改變每次回歸測試都要重復編寫用例與準備數據的現狀。

• 日志錨點庫是對代碼執行流程的有效驗證，除了可以應用在測試環境中，還可基于大數據日志中心對生產代碼的運行做日常監控。

• 交易與支付系統業務邏輯復雜，靠人腦和文檔記憶功能關系難免疏漏，而用例庫和日志錨點庫會隨著業務的變更測試而隨即維護，是一部活文檔。

說明： 上圖羅列了整個 Mock 測試系統的功能點有哪些，共分為：配置接口數據、創建測試用例、創建測試集、創建測試計劃、執行測試計劃以及生成測試報告等大功能。

配置接口數據界面圖

創建測試用例配置圖

擋板請求路由配置圖

測試執行結果

說明：依據上下文環境，利用工廠類動態注入 spring 對遠程接口的依賴，保持線上與測試的代碼一致。在測試環境中，通過 mock 系統管理端，可以隨時調整請求的流向，“指哪打哪”。

說明：執行某項測試用例， 利用 mock 將被測試接口與底層依賴接口隔離開來，可以方便的模擬數據，并監控輸入輸出。用例執行完畢后，使用返回斷言、SQL 查詢、日志標記等多種手段驗證。

Dubbo 自帶的 Mock 功能首先是為了做服務降級，比如某驗權服務，當服務提供方全部掛掉后，客戶端不拋出異常，而是通過 Mock 數據返回授權失敗。

我們從官網上舉一個例子來說明：

我們可以在期望的 reference 標簽上加一個 mock="force"，就可以將當前服務設置為 mock。但是設置完 mock 屬性后還沒有結束，需要有一個 Mock 類對應我們的服務接口類。

規則如下：

接口名 + Mock 后綴，服務接口調用失敗 Mock 實現類，該 Mock 類必須有一個無參構造函數。

對應到 com.foo.BarService 的話，則創建 BarServiceMock 類。

經過以上設置后，當調用 BarService 進行遠程調用的話，直接請求到 BarServiceMock 類上面進行模擬測試。

在 dubbo 的配置文件中

可以看到如下配置列表：

我們可以看到配置文件中實際上有五大路由策略：

• AvailableCluster: 獲取可用的調用。遍歷所有 Invokers 判斷 Invoker.isAvalible, 只要一個有為 true 直接調用返回，不管成不成功。

• BroadcastCluster: 廣播調用。遍歷所有 Invokers, 逐個調用每個調用 catch 住異常不影響其他 invoker 調用。

• FailbackCluster: 失敗自動恢復， 對于 invoker 調用失敗， 后臺記錄失敗請求，任務定時重發, 通常用于通知。

• FailfastCluster: 快速失敗，只發起一次調用，失敗立即保錯，通常用于非冪等性操作。

• FailoverCluster: 失敗轉移，當出現失敗，重試其它服務器，通常用于讀操作，但重試會帶來更長延遲。

Dubbo 中默認使用的是 FailoverCluster 策略，而在實際執行的過程中是 FailoverCluster 會被先被注入到 MockClusterWrapper 中，過程就是：

MockClusterWrapper 內部會創建一個 MockClusterInvoker 對象。實際創建是封裝了 FailoverClusterInvoker 的 MockClusterInvoker，這樣就成功地在 Invoker 之中植入了 Mock 機制。

我們來看 MockClusterInvoker 的內部實現：

如果在沒有配置之中沒有設置 mock，那么直接把方法調用轉發給實際的 Invoker(也就是 FailoverClusterInvoker)。

如果配置了強制執行 Mock，比如發生服務降級，那么直接按照配置執行 mock 之后返回。

如果是其它的情況，比如只是配置的是 mock=fail:return null，那么就是在正常的調用出現異常的時候按照配置執行 mock。

Dubbo 的 Mock 功能主要是為了做服務降級而使用的，服務提供方在客戶端執行容錯邏輯，在出現 RpcException(比如網絡失敗，超時等) 時進行容錯，然后執行降級 Mock 邏輯。自身并不適合做 Mock 測試系統。

為了基于 Dubbo 實現 Mock 功能，需要對 Dubbo 源碼進行一些必要的修改，通過上面的架構圖我們可以看到，實際上我們正是利用了 Dubbo 的 Filter chain 過濾器鏈這一機制實現的，為了方便大家更好的理解，下面將簡單介紹一下 Dubbo 的 Filter 機制。

Filter：是一種遞歸的鏈式調用，用來在遠程調用真正執行的前后加入一些邏輯，跟 aop 的攔截器 servlet 中 filter 概念一樣的。

Filter 接口定義：

Filter 的實現類需要打上 @Activate 注解, @Activate 的 group 屬性是個 string 數組，我們可以通過這個屬性來指定這個 filter 是在 consumer, provider 還是兩者情況下激活，所謂激活就是能夠被獲取，組成 filter 鏈。

關于 SPI 的詳細介紹請大家參考我之前寫的另一篇文章：

http://www.jianshu.com/p/46aa69643c97

ProtocolFilterWrapper：在服務的暴露與引用的過程中根據 KEY 是 PROVIDER 還是 CONSUMER 來構建服務提供者與消費者的調用過濾器鏈，Filter 最終都要被封裝到 Wrapper 中的。

構建 filter 鏈，當我們獲取激活的 filter 集合后就通過 ProtocolFilterWrapper 類中的 buildInvokerChain 方法來構建。

注：我們在中新加了自定義的“env=test”這樣的屬性配置用來標明當前環境是測試的還是正式的，用戶每次通過 Dubbo 請求的遠程服務的時候，都會首先經過我們自定義的 Filter，我們自定義的 Filter 會首先判斷當前的環境是 test 還是正式，如果是 test 的環境則直接訪問 Mock 配置中心獲取提前配置好的 Mock 數據并封裝成用戶定義的 Response 對象返回。

Mock 配置中心就是用戶將 mock 數據與應用環境建立關系的系統，整個系統就像一個工作流引擎：

環境設置 ->應用名稱設置 ->擋板規則設置 ->Facade 服務接口設置 ->方法規則設置

環境設置

注：如果尚未映射來源 IP 地址到環境，則點擊環境列表導航鏈接，進入環境列表頁面，點擊添加，輸入源 IP 及環境名，點擊確定按鈕，實現源 IP 到所設環境的映射。每個用戶都可以建立屬于自己的測試環境。

應用名稱設置

注：創建所使用系統的應用名稱，Mock 配置中心默認使用中的名稱作為應用名稱。

擋板規則

注：每一個擋板規則都是由一個環境名稱和應用名稱組成的唯一擋板，在擋板設置中選擇環境名稱和應用名稱，并且設置擋板的有效狀態。

Facade 規則

注：每一個 Facade 就是一個 Dubbo 的服務接口類，在這里將自己的 Facade 名稱與全路徑與擋板名稱對應，以標識哪些 Facade 服務接口類是屬于哪個擋板的。

方法規則

注：方法規則是用來設置每個 Facade 中的需要 mock 的方法的，可以對不同的方法設置方法執行時間、方法拋出的異常等等。

由于不少應用項目開發完后想對其進行單獨壓測，而很多時候應用系統和其他業務系統形成了依賴關系，如果不布署其他應用系統則無法完成壓測，為了更好的支持性能測試組進行擋板壓測，Mock 系統支持壓測功能，而 Mock 系統自身也可以達到單臺服務器 1000TPS 以上（8C8G)。

科技發展日新月異，我們一直在為更高效快速的開發而努力，無論是一線開發者，還是技術管理者，抑或是產品經理，都在為此不斷嘗試。QCon 邀請到具有實戰經驗的架構師和技術專家帶來最新前沿技術的探索進度，無論是架構還是前端，大數據或是軟件性能，編程語言還有安全風控，各領域全涵蓋，或許會對你有所啟發。

QCon 上海站目前 9 折優惠報名中，2017 年 09 月 17 日前，立減 680 元，團購報名更多優惠～點擊「 閱讀原文 」跟技術大咖零距離。欲購票或咨詢問題可聯系購票經理 Hanna ，電話／微信：15110019061。