本文內容節選自第六屆全球軟體案例研究峰會，時任美團點評酒旅質量團隊工具鏈負責人王鵬老師分享的《微服務架構下的自動化測試和持續整合工具鏈實踐》實錄，重點分享：微服務架構下解決自動化測試、開發聯調、測試環境、持續整合方面遇到的問題及解決方案。（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，有團隊的支援，另外做好前置掃描，禁止有問題的程式碼上線。只有解決問題才可以上線。

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