去哪兒自動測試框架：基於Mock的應用模塊及分散式運行平台模塊

Qunit自動化測試框架中針對Mock第三方介面數據開發的零侵入切面技術的應用模塊和加速自動化用例測試執行速度開發的分散式運行平台模塊。

Qunit是去哪兒網基於Junit框架自助研發的介面自動化測試框架，目前支持的被測介面協議類型包括：HTTP介面、Dubbo RPC介面和Hessian介面。

該自動化測試框架將常用功能的代碼實現（測試數據準備、遠程執行SQL、調用被測介面等）封裝成一個個標籤，測試人員編寫自動化測試用例時，只需要按照測試步驟進行規範格式XML文件編寫，不必關心具體功能代碼的實現，將更多的精力放到自動化測試用例的設計上。

同時Qunit自動化測試框架對介面響應的斷言也進行完美的封裝，通過將介面響應與基線數據（之前錄製的介面響應數據）進行diff的方式進行自動斷言，大大提高了自動化測試用例編寫的效率。

大家在編寫介面自動化測試用例時必然會涉及到Mock第三方介面數據，遇到以下幾個問題應該是家常便飯：

• 第三方介面數據結構複雜，需要通過查看介面文檔、日誌和實現代碼等手段進行拼接

• 被測試介面響應結果對第三方介面的數據有很強的依賴，我們編寫一個介面的自動化用例需要準備好多份Mock數據用來支持

• 一個第三方介面影響多個介面的邏輯，測試時修改Mock數據后，這個自動化介面跑成功了，另一個介面的測試用例沒法執行了，需要不斷修改Mock數據地址進行測試

以上問題的存在，增加了自動化測試用例的編寫的時間成本，影響自動化測試用例的編寫效率。那麼有沒有一種方式可以動態的更改第三方數據呢？

下面介紹Qunit自動化測試框架如何引入零侵入切面技術的應用模塊來解決這個問題的。

Java Agent是擁有修改應用運行代碼的一個軟體組件。在agent的上下文中，instrumentation提供了重新定義和修改裝載在運行時的類（class）的能力。

Qunit自動化化框架基於該技術開發了Catcher agent模塊，通過修改CLASS位元組碼文件實現動態錄製和回放第三方介面數據的功能，服務於自動化測試。

該技術方案最大的優點就是不需要對被測系統進行代碼修改，即完全無代碼入侵的方式實現了對被測系統和第三方模塊或構件交互的監視和mock功能。Catcher agent模塊的相關代碼也不需要布置到線上環境，和線上生產環境是絕對隔離的，不會造成任何影響。

Catcher agent怎麼實現了對第三方介面數據的錄製和回放功能呢？下面通過Catcher agent修改CLASS位元組碼前後的代碼對比進行介紹。

修改位元組碼前：

修改位元組碼后：

通過對比可以看出以下幾點：

• Catcher Agent將被測試代碼進行重新封裝增加相關代碼實現

• 通過needMock函數控制當前應用是使用Mock數據，還是調用真實的介面；

• 通過needCollect函數控制是否對數據進行錄製

• 需要注意的是collect是非同步存儲不會對程序運行造成影響

Qunit自動化框架中零侵入切面技術的應用包括錄製模式和回放模式兩個模式：

• 錄製模式：錄製第三方數據，將第三方報文數據保存到本地，用來編寫自動化用例使用，可以對錄製下來的數據進行參數化配置；

• 回放模式：使用本地準備好的Mock數據對第三方介面進行Mock，支撐自動化測試。

錄製模式：

回放模式：

進行回放模式時，大多數情況下都會對本地存儲的第三方測試數據進行參數化，更靈活的應用錄製下來的測試數據，因此測試執行時，會先將本地存儲的第三方數據和測試用例中配置的變數參數組織成一份完整的測試數據發送給Catcher Agent進行mock第三方介面。

在service中定義catcher切點

自動化測試用例中的使用方法

執行測試TestCatcher被測介面時，對test-fetchPost第三方介面進行Mock，執行測試時，第三方介面的mock數據為通過傳入json格式的賦值，設置respCode=「00」，respMsg=「成功」

錄製的測試數據

錄製后的測試數據對respCode和respMsg進行參數化，Qunit編寫自動化測試用例時，可以通過json的數據格式對參數化的欄位進行重新賦值，使得mock數據使用更靈活。

隨著Qunit自動化測試框架逐步完善，所能支撐的自動化測試場景更加全面，同學們感受到了自動化測試帶來的福利，就擴大了自動化測試用例的覆蓋，自動化測試用例的場景設計的也越來越複雜，測試用例數量隨之暴增，隨之測試執行時間的問題就暴露了，原來一次全量用例執行需要10分鐘，後來每次自動化測試需要坐等1個小時，測試執行成本增加了。這就是去哪兒網某事業部的使用Qunit自動化框架時遇到的問題。

Qunit的測試執行方式繼承了Junit的測試執行方式，通過執行mvn test命令進行單線程執行的，試想如果可以多個線程并行執行測試用例，6個線程并行執行測試，那麼10分鐘就是執行完畢，測試執行時間成本不就可以降低很多嗎？

針對這個問題，我們開發了分散式運行平台模塊進行并行執行Qunit的自動化測試用例。

要并行執行自動化測試用例，需要解決以下問題：

• 并行執行使用什麼策略進行分配測試用例？

• 并行執行測試用例，測試結果怎麼收集到一起？

• 多個測試用例并行執行，如果測試用例之間有相互影響怎麼辦？

使用過Junit的同學都知道，Junit的執行原理是先將所有待執行的測試用例載入到內存中，再逐個循環進行執行，最終匯總測試結果生成測試報告。Qunit的執行原理也是這樣的，那麼我們是否可以對Qunit循環執行測試用例的邏輯進行重寫，使其按照我們指定的測試文件進行執行測試呢？ 是否可以每執行一個測試用例后，就將測試結果實時發送到一個平台中，讓平台對其進行匯總展示呢？測試用例之間的相互影響是否可以通過多套獨立的測試環境進行解決呢？

在去哪兒網做QA是幸福的，因為公司有個穩定Noah環境管理平台，可以按照自己定義的測試環境模板，動態創建多套獨立的測試環境（包括部署被測應用所需的機器、資料庫、memeched、redis等），每套測試環境相互對立。

分散式運行平台通過調用Noah環境管理平台的介面創建多套獨立的測試環境，按照測試用例文件維度分發測試用例到不同的測試環境中進行執行，並且分發策略參考了每個測試用例文件上次執行時間的長短，優先執行消耗時間最長的測試用例文件，進一步縮短整體測試執行的時間。

下圖為分散式運行平台的執行自動化測試用例的流程

分散式運行平台做為去哪兒網統一執行Qunit自動化測試用例的平台，還做調度模板管理、調度任務管理、測試環境管理、測試報告展示、代碼覆蓋率統計、通過介面調用創建測試任務等功能，用來更友好、更高效的支撐Qunit自動化測試用例執行。

零侵入切面技術是使用java agent的技術進行開發，基於這個技術點我們還開發了Catcher系統，可以支持java工程的任何一個類的方法的返回值進行錄製和回放，目前已經在功能測試進行試用。

分散式運行平台的核心功能是通過創建多套環境并行執行自動化測試用例及匯總測試結果的方式，達到縮短整體測試執行時間的目的，該平台除支撐Qunit自動化測試用例的執行外，後續會支撐去哪兒網其他自動化測試框架的測試執行，最終成為一個公司級通用的分散式運行平台。

作者介紹

毛京超，任職去哪兒網酒店事業部，負責代理商對接業務線相關的測試工作，參與去哪兒Qunit自動化測試框架的開發。

蔣承君，去哪兒網金融事業部測試工程師，負責金融事業部主系統的測試工作及測試工具研發。

本文來自其在「攜程技術沙龍——移動互聯背景下的測試技術創新」上的分享。本文首發於攜程技術中心，微信ID：ctriptech。

2017 年，有哪些值得關注的運維技術熱點？智能化運維、Serverless、DevOps ......CNUTCon 全球運維技術大會將於 9 月上海舉辦，12 位大牛聯合出品，揭秘最前沿運維技術，推薦學習！

點擊閱讀原文，移步了解詳情。