本文內容節選自第六屆全球軟件案例研究峰會，時任美團點評酒旅質量團隊工具鏈負責人王鵬老師分享的《微服務架構下的自動化測試和持續集成工具鏈實踐》實錄，重點分享：微服務架構下解決自動化測試、開發聯調、測試環境、持續集成方面遇到的問題及解決方案。（PPT+文稿）。

王鵬老師時任美團點評酒旅質量團隊工具鏈負責人，在軟件開發，自動化測試，研發流程改進，持續集成/交付基礎設施，敏捷開發等領域有近10年的開發實施和推廣經驗。

編者按：2017年11月9-12日，第六屆全球軟件案例研究峰會在北京國家會議中心盛大開幕，現場解讀2017年「壹佰案例榜單」。時任美團點評酒旅質量團隊工具鏈負責人王鵬老師分享的《微服務架構下的自動化測試和持續集成工具鏈實踐》實錄的案例分享。

【內容簡介】微服務化為自動化測試和持續集成工具鏈等基礎設施帶來了新難題，本案例通過在酒旅研發測試團隊中實施持續集成，敏捷開發工具鏈和自動化測試的實踐，分享工具團隊如何實現高效的研發質量保證體系保駕護航，提供質量和效率方面的工具支持。希望能為“急速”增長中的研發團隊在提升開發測試質量和工程效率方面提供一些啟發和參考。

1

從Monolithic到Microservices

在2008年時，市場軟件形式大多為CS架構。當時存在的問題在於，開發耗時1-2年且內部的解耦度低；而優點在於對測試團隊十分友好。

後來軟件形式又經歷了從SOA分布式架構到現在的微服務架構。

對於微服務架構來說，它並非像開發者們想象中的井井有條。下圖是一個微服務架構化的典型示例，從綠色的線可以看出服務之間的關系錯綜復雜。

由於微服務架構把系統功能細分，團隊會在各個方面都碰到了挑戰。那麽微服務架構下工程質量面對的問題，該如何解決？接下來我們將會從四個方面講述。

2

問題的發現與解決

自動化測試

1.存在的問題

• 服務數量多，以HTTP和RPC接口為主：鏈路長依賴多。

• 服務交付周期變短：從以前的大模塊開發，花費幾個月時間交付。到現在的一到兩周交付上線，但自動化測試開發速度跟不上交付的速度。

• 框架使用不規範，多種方式並存。

• 自動化測試代碼的擴展性和可維護性不夠

2.解決方案

通過提供相應的自動化測試框架工具，可以實現標準化、規範化、快速交付測試代碼。具體操作如下。

• 統一的框架archetype自動生成整個項目框架。

• 數據、配置、代碼分離進行數據的驅動。

• 單接口+場景化，確保做到無參數傳遞。

• 把一些常用的Lib庫打包，在POM文件裏面引用。

• HTTP和Thrift接口封裝，提高代碼的復用率。

API-Lib

下圖是自動化測試框架圖示。

• 在數據校驗時，自動化設計框架會自頂層生成測試項目結構，測試環境動態配置。

• 在測試數據，會由數據驅動來完成，只需要維護裏面的數據即可，無需改變代碼；

• 在Testcase層，引入了Json Schema、Json Path做數據校驗；

• 把HTPP和Thrift做了相應的封裝，方便調用；

• 最底層使用了Thrift，封裝相應的Lib庫。

自動化示例

如下圖，左邊是之前的Test代碼，右邊是通過統一測試框架自動生成後的代碼。

分為data和內部環境數據，子文件裏是單接口和多場景，在內可以復用API接口。

如何做到無參數

對於代碼而言，多一個參數含義，整體復雜度和冗余度都會提升。

團隊從框架引用，生成框架，到case的編寫，生成Thrift寫法；在數據維護上自動生成數據格式。做到了測試框架+測試代碼+測試數據，實現了自動化。

自動化之後可以做到相應的專項代碼測試，大量的數據變化和驗證會在文件裏直接做相應的要求。

開發聯調

1.存在的問題

• 多個服務同時開發， 聯調耗時日益增長：從內部看聯調的占比大概在20%-50%之間。這種情況主要有兩方面。一是，聯調自測環境不穩定，服務多。另一方面是，多人開發，從一開始的簡單接口約定到中間PM需求改變，導致接口互相之間數據格式上有變化，雙方難做同步。

• 聯調測試環境不穩定：需要找合作方調試，浪費時間。

• 自測時需要部署和維護多個依賴方服務。

2.解決方案

開發未動，Mock先行，隨時聯調。

在開發開始時，多方定義好相應的接口，接口文件，數據格式和規則。通過Mock工具生成服務，發布到聯調測試環境中。

使用Moka工具自動生成Mock Server，指定相應的Thrift定義，根據相應規則，生成Mock Server，在內配置聯調服務，指向Mock Server，再配置相應的數據規則和匹配規則。

通過Moka能夠做到開發剛開始時就可以提供相應的聯調服務，流程基本如下。

一鍵生成獨立Mock優於平臺的點在於，適用性好。也支持Thrift的註解方式使用和Mock數據管理。

測試環境

1.存在的問題

• 由於服務數量增多，鏈路變長，調用依賴增多，整個環境的搭建會十分吃力。

• 多人共用一套環境，互相影響，容易影響測試結果。

• 穩定性差。

2.解決方案

解決的問題主要集中在，資源的申請，申請後的環境隔離與數據隔離，測試環境的維護，恢復測試環境等。

環境搭建可以從三個方面考慮，環境隔離、按需創建、描述依賴。

美團團隊選擇了通過HULK+泳道提供環境隔離，Cargo按需創建測試環境。骨幹+泳道復制全新的環境，隨後打通發布系統和代碼倉庫，發布大的測試環境，做穩定性與可控性的監控和三個9穩定性測試環境。

環境監控：

原則：泳道可以調骨幹，骨幹不可調泳道。

環境建好後，要保證隨時可以使用。在穩定性監控下，只要提供服務，列表就可以進行監控，定時部署最新的分值代碼。

整個環境都處於監控之中，每半個小時發送一次環境整體概況。如果某個服務穩定性降低，團隊會直接@負責人查看原因。

持續集成

1.存在的問題

• 一次提測服務增多，提測了多個倉庫，使得CI Job經歷了爆炸性增長。

• 提測質量無法得到保證，測試不過關；缺乏前置測試，無效溝通太多。

2.解決方案

微服務環境中兩個關鍵點：Merge到主分支前，提測前自動檢測。

關鍵節點1：

代碼提交和Merge到主分支，拉分支會自動創建CI Job，Push代碼觸發掃描，PR Merge到主分支觸發掃描，PR更新觸發再次掃描，通過允許Merge到主分支。

這樣可以做到不把問題帶到線上分支，並且前置的方式約束RD在上線前就解決問題。

關鍵節點2：

提測前還要再次自動檢測。當需求提測的時候，根據提供的發布信息自動創建對應的Pipeline，點擊提測之後會自動出發Pipeline的執行，自動部署，並做冒煙測試。Pipeline會明確的顯示冒煙測試結果是什麽，問題在哪裏。

大大減少了無效的溝通。

工具鏈流程：

通過後臺的CI服務，工具鏈從RD拉分支開始，拉分支會創建一個Pipeline Job，做Push代碼的時候同時做Sonar掃描，由大象通知結果。

在工具鏈上共提供四個服務：

1. 單測覆蓋率CI服務。在Pom無侵入修改引入Jar包；一鍵接入單測覆蓋率服務。

2. 靜態代碼掃描CI服務，Sonar服務器進行線上監測。

3. 自動部署，做冒煙測試。

4. 內存掃描分析CI服務。Valgrind提供了Pipeline插件 開發，通過修改了插件，可以解決了許多相關的問題。在Pipeline上使用，可以一步分析，自動推送。

3

經驗總結與反思

啟示

• 理解用戶需求的完整場景：源頭，原因和原理。

• 堅持工具設計的主線和願景，短期服從長期。

• 只有在用戶需要時才出現。

• 從工具和服務做起，不要一開始就做平臺。

• 跨團隊合作，互補長短。

總結

我們在自動化測試方面，開發了規範化、標準化的LIPS自動化測試框架；開發聯調方面，開發了Moka；Cargo來創建測試環境，做三個9的穩定性和可用性服務的測試環境；在持續集成方面，使用Pipeline，提供相應的CI服務且不做任何配置；PUSH代碼會自動獲取相應的信息，幫助大家做持續集成。

Q&A

Q：手工測試和自動化測試占比是怎麽樣的？

A：目前來講，在工具應用之前，手工測試占比非常高，應該在60%以上，自動化測試應用的很不好，主要原因是整個標準化程度不夠，維護起來很麻煩。根本的原因在於沒有一個很好的框架工具支持它。

Q：Sonar掃描歷史債怎麽處理呢？

A：Sonar掃描每個團隊都積累了很多關於怎樣解決這個問題的經驗。我們的解決方法一方面是依靠團隊技術leader，有團隊的支持，另外做好前置掃描，禁止有問題的代碼上線。只有解決問題才可以上線。

以上內容來自王鵬老師的分享。

美團點評：打造微服務自動化測試與持續集成工具鏈實踐