馬蜂窩技術原創內容，更多幹貨請關注公眾號：mfwtech

測試覆蓋率常被用來衡量測試的充分性和完整性，也是測試有效性的一個度量。「敏捷開發」的大潮之下，如何在快速迭代的同時保證對被測程式碼的覆蓋度和產品質量，是一個非常有挑戰性的話題。

在馬蜂窩大交通、酒店等交易相關業務中，專案的開發和測試實踐同樣遵循敏捷的原則，迭代週期短、速度快。因此，如何依據測試覆蓋率資料幫助我們有效判斷專案質量、瞭解測試狀態、提升迭代效率，是我們一直很重視的工作。

Part.1 測試覆蓋率統計中的挑戰

對於功能測試而言，通常可以通過充分了解需求、完善的測試用例、介面測試、Review 技術方案等來保證測試充分性。但隨著業務規模快速發展，業務邏輯越來越複雜，系統級別互動越來越多，這些方法都不能保證所有的程式碼一定被全部測試過，也給測試人員帶來極大挑戰。

說到這兒和大家分享一個因為測試覆蓋不充分，影響到線上業務的真實案例。事件起因是專案提測階段一個微服務 Sonar 掃描沒通過，開發同學為了修復 Sonar 發現的問題而重構了一部分歷史程式碼，卻導致一個原有發券需求的錯誤。當天下午運營觸發發券後 Bug 出現直接導致生單不可用，並且持續了將近一個小時。這裡的問題就是發券功能與此次需求無關，開發人員修改程式碼後測試人員不知道，也沒有經過測試，但跟隨本次需求一起上線了，測試用例無法覆蓋到。

通過這個例子可以明顯地看到正確統計被測程式碼覆蓋率的重要性。當前市面上統計覆蓋率的工具很多，但應用到我們的實際場景中通常存在以下問題：

1. 大部分第三方工具都是以支援提測前單元測試的覆蓋率統計為主，而支援提測後測試覆蓋率的工具則比較缺乏；

2. 第三方工具提供的覆蓋率基本都是展示全量的，但大部分情況下，測試人員重點關注的應該是本次新增和修改的部分，而不是耗費過多精力在未修改的部分上；

3. 為了支援多需求並行測試，大交通後端服務採用 QA 隔離環境，而市面上還沒有支援多需求隔離環境並行測試的測試覆蓋率統計工具。

因此，大交通測試組決定自研工具進行被測程式碼的覆蓋率統計，用程式碼覆蓋結果反向地檢查測試人員測試用例的覆蓋度和開發人員程式碼的冗餘度，更精準地定位和分析問題，保證產品質量。

Part.2 覆蓋率統計工具設計

結合我們的實際場景，覆蓋率統計工具的實現目標如下：

1. 大交通業務後端程式碼使用 Java 語言開發，主要的業務處理邏輯都在後端，所以工具要優先支援 Java 程式碼覆蓋率統計

2. 可以統計提測後測試過程中不同型別測試的覆蓋率，包括：手工測試、迴歸測試、介面測試、UI 自動化測試等等

3. 支援全量、增量覆蓋率統計

4. 支援多需求多環境並行測試，同時統計覆蓋率

5. 使用者不侷限於測試人員，而是所有有測試需求的人員，包括開發和測試等

6. 支援自動化統計，簡化操作步驟，無需學習成本，報告簡單易懂

我們將覆蓋率統計工具命名為 jCover，並將其引入 CI/CD 體系，與內部 Java 平臺專案管理及持續整合系統 MONE 打通。工具設計如下圖所示：

圖 1：覆蓋率工具整體架構圖

覆蓋率統計的大致流程為首先通過獲取多環境服務的配置資訊，生成指定環境服務的測試覆蓋率檔案，然後根據需要生成全量覆蓋率報告和增量覆蓋率報告，最後，儲存測試覆蓋率報告到指定環境目錄下。

Part.3 主要功能及實現方式

jCover 的主要功能包括：

• 支援多需求多環境並行測試下，同時統計覆蓋率

• 支援全量覆蓋率統計

• 支援增量覆蓋率統計

• 支援自動/手動統計覆蓋率

• 覆蓋率報告統一管理

下面圍繞以上功能點，為大家介紹 jCover 的作用、特點和具體實現方式。

1. 覆蓋率工具平臺化

為了簡化操作步驟降低學習成本、報告簡單易懂，jCover 支援介面化操作，可以手動生成測試覆蓋率報告和查詢測試覆蓋率報告；查詢測試覆蓋率報告入口統一，程式碼測試覆蓋率資料清晰，方便資料統計和量化。

圖 2：覆蓋率報告查詢頁面

2. 支援多需求多環境下的並行測試

由於使用敏捷迭代，專案多、並行率高，大交通所有微服務均引入測試環境隔離外掛，同時支援多專案並行測試。因此，jCover 需要支援多環境並行的測試覆蓋率統計。

具體來說，每個測試專案都會有一個單獨的環境標識，以隔離環境標識+環境型別+服務名稱唯一確定一個覆蓋率統計單元；每一個覆蓋率統計單元都會生成對應的測試覆蓋率統計報告，測試覆蓋率統計報告被儲存到 jCover 部署的伺服器中，儲存位置是環境標識對應的服務目錄下；同一個服務的不同提測分支同時在多專案中測試時相互間的覆蓋率報告不會被覆蓋。

多環境並行流程圖見下圖（目前只支援 QA 環境覆蓋率統計）：

圖 3：多環境並行流程圖

例如：隔離環境 gjssqz 和隔離環境 supplyrefund 可以同時進行測試覆蓋率統計，隔離環境標識+環境型別+服務名稱指定了每個環境下的單個服務測試覆蓋率統計結果。

覆蓋率工具 UI 展示如下圖：

圖 4：用「隔離環境標識+環境型別+服務名稱」來標識和統計覆蓋率

3. 全量覆蓋率統計

在測試時有時候需要關注全量程式碼的測試覆蓋率，程式碼全量覆蓋率統計過程如下：

（1）查詢服務資訊

jCover 通過內部 Java 平臺專案管理及持續整合系統 MONE 來查詢被測微服務的資訊：

• 為了減輕對 MONE 系統的壓力，設定每日一次定時拉取全量服務資訊，將隔離環境標識、服務名稱、容器 IP、監聽埠、環境型別和狀態儲存到資料庫。

• 生成覆蓋率報告時根據隔離環境標識和服務名稱從 MONE 單服務資訊拉取介面查詢最新的容器 IP。如果資料庫沒有就新增服務資訊，如果資料庫有就更新服務對應 IP。

（2）收集覆蓋率資料

為了做覆蓋率統計，需要從微服務部署的容器中下載測試覆蓋率 Dump 檔案。我們採用的解決方案是使用 JavaAgent 代理，首先對微服務部署的容器進行了改造，使得容器支援 JavaAgent 功能；其次為了動態插樁記錄被測程式碼的執行結果，在被測微服務的 JVM 啟動指令碼中增加 JavaAgent 引數。

覆蓋率工具根據 IP 和監聽埠通過 JavaAgent 代理從容器中下載 Dump 檔案，以環境和服務標識唯一 Dump 檔案，並存儲到 jCover 所在的伺服器。在下載覆蓋率資料時採用追加方式，如果該 Dump 覆蓋率檔案已存在，那麼該輪的覆蓋率資料會直接在文字末尾進行追加，便於統計整個測試過程的程式碼覆蓋結果。

（3）根據全量覆蓋率檔案生成全量覆蓋率報告

1. MONE 從微服務容器中拷貝 Class 檔案到 jCover 所在伺服器指定目錄

2. jCover 通過 Class 檔案和 Dump 檔案生成全量覆蓋率檔案

3. 根據全量覆蓋率檔案生成全量的測試覆蓋率報告，把全量的測試覆蓋率報告以「隔離環境標識+服務名稱+順序 ID」的維度儲存到 jCover 所在伺服器的指定目錄

4. 最後配置靜態資源對映規則生成測試覆蓋率報告 URL 並把測試覆蓋率報告 URL 儲存到資料庫中

使用者開啟測試覆蓋率工具前端介面就可以在瀏覽器中檢視步驟 D 生成的覆蓋率報告了，綠色表示被覆蓋，紅色表示未被覆蓋，黃色表示部分覆蓋：

圖 5：全量測試覆蓋率報告展示

4. 增量覆蓋率統計

業務發展到一定階段後，程式碼量級很大。主幹程式碼我們預設是正確的程式碼。當一個新需求提測後，測試人員更關注的其實是針對本次需求更改的程式碼的覆蓋率而不是全部程式碼的覆蓋率，想從全量覆蓋率報告中找出本次更改的增量程式碼的覆蓋率是非常困難的。基於此問題我們開發了增量覆蓋率統計功能。

增量覆蓋率統計和全量覆蓋率統計有三個相同的步驟：查詢服務資訊、收集覆蓋率資料、生成全量覆蓋率檔案。生成全量覆蓋率檔案後，增量覆蓋率統計的不同點是增加了以下處理：增量程式碼獲取、生成增量覆蓋率報告，具體實現如下：

（1）Diff 增量程式碼

1. 分別獲取每個微服務的 master 主幹和測試分支內容，Diff 測試分支物件和 Master 分支物件，得到增量程式碼

2. 濾除增量程式碼中的非.java 檔案

3. 迴圈遍歷增量程式碼得到變化行，標識行變化型別包括：新增、更新

（2）生成增量覆蓋率報告

• 根據增量程式碼變化行標識無變化的方法

• 在改變的程式碼行（改變包括增加和更新）行首加上對應的標識：「增加」的程式碼以「+++」標識，「更新」的程式碼以「U」標識，同時刪除無變化的方法，生成增量程式碼覆蓋率報告

圖 6：增量覆蓋率流程

下圖是交易服務增量覆蓋率報告的截圖示例，從圖中清晰看出增量行和更新行的測試覆蓋率情況。

圖 7：增量覆蓋率報告展示

5. 支援手動/自動統計覆蓋率

當測試人員需要檢視最新的測試覆蓋率時，可以通過「jCover - 生成測試覆蓋率報告」的入口手動觸發生成測試覆蓋率報告。

圖 8：手動統計覆蓋率圖形化介面

在一個需求的實際測試中被測的微服務通常有多個。因為修改 Bug 等原因，被測微服務經常需要重啟，重啟後容器銷燬，JavaAgent 插樁後的檔案也會被刪除導致重啟前覆蓋的程式碼無法被統計。

如果每次重啟每個被測微服務前都需要測試人員手動生成覆蓋率報告的話，是個很大的工作量也會經常被遺忘。因此 jCover 通過和釋出系統結合實現了覆蓋率自動統計功能。具體實現方法為 jCover 提供了自動生成覆蓋率檔案介面，在服務重啟部署時後端釋出系統呼叫此介面，實現自動統計覆蓋率，不管服務重啟多少次都可以把每次測試時覆蓋的程式碼全部統計到。

之前大交通的後端服務釋出系統為 Jenkins，後續升級為了 MONE，兩種釋出系統下均支援服務部署時自動統計覆蓋率。

Part.4 工具效果

經過一段時間推廣使用和優化，現在大交通所有的需求提測後均使用 jCover，主要體現出以下幾點優勢：

• 可以支撐不同型別的覆蓋率測試。jCover 可以統計手工測試、介面測試、迴歸測試、UI 自動化測試等各種型別測試的全部覆蓋率，展示為一份覆蓋率報告。

• 及時發現漏測程式碼。通過使用測試覆蓋率工具可以發現測試用例未覆蓋的程式碼，反推測試用例缺失。例如在「虛艙管理」專案中國際交易支付前校驗失敗傳送 MQ 訊息沒有覆蓋，測試人員補充了支付前校驗失敗發訊息的測試用例；在「國際搜尋坑位供應商及價格優先順序設定」專案中發現由於 Mock 資料的侷限性, 帶有輔營的加價程式碼未覆蓋，補充了機票+輔營的測試用例，提高測試覆蓋度。

• 發現開發的冗餘程式碼。例如：在「國際機票重複預訂優化專案」中發現冗餘程式碼，getBaseOrderDetail 方法無呼叫方，開發進行了刪除。

• 及時發現測試中的問題並改進，提高測試效率。在「國內供應商資源統一化」專案中測試人員執行了很多測試用例後，使用 jCover 檢視覆蓋率報告發現應該覆蓋的程式碼未被覆蓋，與開發溝通後發現控制這部分程式碼邏輯的開關是「關閉」狀態，此開關應該是在「開啟」狀態進行測試

• 為上線程式碼審批提供資料參考。當團隊成員申請程式碼上線時，開發 TL 可以重點關注未覆蓋部分程式碼，減少線上問題發生。

• 輔助提升測試人員對被測程式碼的熟悉度。

Part.5 近期規劃

目前 jCover 只支援檢視每一個類覆蓋行和未覆蓋行是什麼，但是對於一個微服務整體行覆蓋率是多少沒有統計，我們正在開發增量覆蓋率百分比，幫助開發和測試做出準確的判斷。目前也在調研前端的覆蓋率統計，下一步將實現前端的覆蓋率統計工具 jCover。

在日常需求測試中可以採用測試（手工測試、介面測試、迴歸測試等）+jCover 覆蓋分析的測試方法來完善測試場景，減少測試遺漏，確保測試的充分性，但需要注意的是 jCover 統計只能展示哪些程式碼被覆蓋了，程式碼的正確性還是需要用例的執行結果正確來保障；還有時候開發會漏開發某部分需求，此時依靠 jCover 是無法發現這部分遺漏程式碼的，因此除了 jCover 之外可以通過參與技術評審、編寫用例時參考產品功能矩陣圖等多種手段發現問題，全方位保障被測程式碼的質量。

以上就是對馬蜂窩大交通測試覆蓋率統計工具 jCover 的分享。當然，統計程式碼覆蓋率僅僅是一種手段，覆蓋率高不一定代表質量好，但覆蓋率不高的程式碼質量風險肯定很高。只有清楚在覆蓋率統計資料背後反映出的問題，才能從根本上保證軟體整體的質量。

本文作者：代春美，馬蜂窩測試部-交易測試工程師；孫海燕，馬蜂窩測試部-交易測試團隊負責人。

相關推薦