本文根據Song Jiachao老師在“2021 vivo開發者大會"現場演講內容整理而成。公眾號回覆【2021VDC】獲取網際網路技術分會場議題相關資料。
一、背景
1.1 專案特點
隨著網際網路科技的飛速發展，越來越多的公司將敏捷開發的流程引入到專案迭代中，所以越來越多的專案呈現出三個特點：
1）迭代週期短：各種倒排，壓排期，一週一小版本，兩週一大版本，甚至有的專案每天都在發版，苦不堪言。
2）需求變更頻繁：我們的產品經理不是在推翻自己，就是在推翻自己的路上，所以我們經常也會開玩笑跟產品經理說：來來來，你立個字據，保證一下以後再也不改需求了。產品經理這時候信誓旦旦的說：好好好，你把這個需求改了，我保證給你立字據，下次再也不改了。可是並沒有什麼作用，需求依然改的很頻繁。當然了，這也不能怪產品經理，面對著瞬息萬變的市場環境，我們有時候需要用這種試錯的方式來快速的找到正確的方案。
3）系統複雜度高：前端已經不僅僅是畫畫頁面那麼簡單了，大家可以從現在的前端招聘資訊中就可以看出來。分散式、微服務、中間層、各種琳琅滿目的架構，讓本就複雜的業務，變得更加複雜。
隨著專案的這些特點越來越明顯，對我們開發和測試的挑戰也變得越來越大。
1.2 煩惱
所以我們會有如下的一些煩惱：
有這樣的煩惱，歸根結底有兩方面的原因：
測試人員：他們不知道開發程式碼的改動點在哪裡，影響點在哪裡，很難用精準化的測試方案，來提升測試效率，所以為了保險起見，只能把相關功能全部測一遍
開發人員：他們無法全面的知道每一行程式碼的執行情況，很難通過執行資料，來分析哪些程式碼是有用的，哪些程式碼是沒用的，哪些程式碼測試已經驗證過，哪些程式碼還沒有被驗證
所以我們迫切的需要一個平臺，能夠方便的看出程式碼的改動點和執行情況，而這個平臺就是整合程式碼覆蓋率平臺。
1.3 方案
所謂的整合程式碼覆蓋率平臺，是指在整合測試期間，採集程式碼覆蓋率，並上報到系統中進行合併展示的平臺。
1.4 難點
既然有解決方案，為什麼現在市面上很少有這樣的產品推出呢？我們在研究這方面的時候，發現了兩個非常大的技術難點。
第一個難點是：資料合併難。我們都知道，前端所有的測試都是在各端進行的，測試產生的資料留在各個終端，很難將這些留在各個終端的資料進行收集和合並。
第二個難點是：資料失效快。前端程式碼發版非常頻繁，在測試的時候，每天可能發版好多次，發版代表雖然是同一份檔案，但裡面的內容可能完全不一樣了，這樣就會導致之前採集的覆蓋率完全失效了。
通過不斷的嘗試，我們終於解決了這兩個問題，於是就誕生了馬可程式碼覆蓋率平臺。
二、馬可平臺的優勢及亮點
2.1 優勢及亮點
馬可平臺是一個完備的程式碼覆蓋率平臺，具有以下幾個亮點：
-
支援一鍵接入：不挑業務，框架，對現有程式碼零侵入，一鍵即可接入；
-
支援增量報告：能夠讓使用者更加精準的瞭解程式碼覆蓋率情況；
-
支援多種語言：馬可平臺不侷限於前端，也能服務後端；
-
支援多種工具：方便使用者使用，比如程式碼對比，gitblame等；
-
支援多個使用者：多種報告的實時合併與檢視；
-
支援大盤監控：通過大盤實時檢視覆蓋率走勢，瞭解專案質量趨勢；
-
支援訊息通知：定時推送專案覆蓋率情況；
-
支援獨立部署：不僅支援第三方直接接入，還支援一鍵私有化部署。
2.2 體驗
2.2.1 詳情頁
-
下圖上的第一點：當前版本改動了哪些檔案，我們會將所有的改動檔案通過樹狀結構圖展示在第一個區域，讓使用者一眼就能清楚當前版本到底改了多少個檔案
-
下圖上的第二點：當前檔案改動哪些地方，我們通過程式碼對比的方式，直觀的將每一個檔案的改動點顯示在第二個區域，讓使用者一眼就能看到這個檔案到底改了哪幾行程式碼
-
下圖上的第三點：當前改動是否被測試驗證過，剛剛第二點我們標記出了一份檔案的到底哪幾行發生了變更，那麼第三點就是將變更的程式碼標記出來是否被驗證過。
有了這三點標記，我們就將改動點和測試過程進行了完美的結合，讓測試結果一目瞭然。
2.2.2 趨勢圖
通過專案趨勢圖，我們可以清楚的看出專案覆蓋率走勢，瞭解專案質量趨勢。
2.2.3 概覽
目前馬可平臺已經穩定執行近3個月了，服務了39個專案，生成了133分報告。
2.3 價值
通過馬可平臺我們就將測試關注的四個點即：修改點、影響點、測試點和測試結果，給緊密的聯絡起來，同時將之前的缺乏資料的評估轉化成精確的，有客觀依據可量化的評估。
三、馬可平臺的技術方案
馬可平臺的技術方案共有4個小部分：首先會介紹馬可平臺的整體架構，然後分別從接入層、服務層和展示層，三個方面加以詳細的說明。
3.1 整體架構圖
馬可平臺分為三個層：接入層、服務層和展示層；
-
接入層：我們的目標是一鍵接入，多語言適配，區分環境和智慧上報。目前針對Web端的適配已經全部完成了，正在適配其他技術棧，比如小程式、Node.js、Typescript。同時我們還規劃了其他語言的接入方式，讓馬可平臺變成全語言的程式碼覆蓋率平臺。
-
服務層：主要是對報告的各種處理，比如報告管理、使用者管理、專案管理等功能。
-
展示層：主要是對服務層的一個延伸，通過視覺化的方式，提供更加便捷的報告檢視和管理等功能。
3.2 資料流向圖
通過資料流向圖，我們將一份報告從接入層到服務層再到展示層給串聯起來形成一個完美的閉環。
3.3 接入層
接入層主要就是接入和上報這兩點；
針對接入：我們提供各語言插樁方案、插樁規範、以及接入指導。
針對上報：主要有各語言的採集方案，上報資料標準和上報方案。
3.3.1 接入
插樁維度：
通常我們會將插樁分為4個維度：語句覆蓋率，函式覆蓋率，分支覆蓋率，和行覆蓋率。
插樁過程
馬可插樁
這是馬可平臺，js插樁的部分程式碼，主要做了三件事；
- 第一步：獲取檔案相對路徑
為啥是相對路徑？因為馬可程式碼覆蓋率是一個平臺，所以我們需要獲取相對路徑，讓檔案路徑和專案進行關聯，而不是與打包機器關聯。
-
第二步：呼叫了istanbul-lib-instrument進行插樁我們沒有完全重寫插樁程式碼，而是藉助了開源的力量，讓馬可平臺更加輕量化、通用化。
-
第三步：新增自定義引數這些引數都非常重要，指明瞭當前報告的重要資訊。
這樣我們就簡單完成了js語言的插樁適配，其他語言可以同樣參考這樣的思路。
3.3.2 上報
上報就是採集和傳送的過程。
針對採集：主要獲取兩個資訊，覆蓋率資訊和專案資訊，兩者缺一不可。
針對傳送：各個端會有很大的差異，我們提供了一定的建議。比如在web中可以監聽Visibilitychange事件，而在小程式中可以監聽onShow和onHide事件，如果是在Node等其他服務端中可以通過定時任務進行上報。
3.4 服務層
馬可的服務層提供了很多的功能，這裡我們挑報告管理和使用者管理，這兩個比較典型的功能進行介紹。
3.4.1 報告管理
報告三要素：首先一份完整的報告需要有三個基本要素：覆蓋率資訊，專案資訊，和檔案資訊。
-
覆蓋率資訊包括：語句、分支、函式、行四個覆蓋率。
-
專案資訊包括：專案配置，分支資訊，檔案hash，構建時間。
-
檔案資訊包括：檔案地址、檔案內容和Git資訊。
通過接入層採集的覆蓋率資訊和專案資訊，然後關聯Git平臺的檔案資訊，通過這種方式才能讓馬可變成一個多使用者、多報告支援的覆蓋率平臺。
3.4.2 合併流程
上一個步驟我們採集到了覆蓋率，下面我們聊一聊馬可平臺是如何進行報告合併的，我們先來考慮兩種情況：
- 第一種情況：檔案沒有變更；
就是我們下圖左邊的部分，檔案沒有變更的時候，有兩個測試，小美和小花分別產生了兩個報告資訊，這種情況改如何進行合併呢？
- 第二種情況是：檔案發生了變更；
同一份檔案，檔案的內容發生了變更，變更檔案的行號前後無法一一對應，比如變更前檔案的第10行，到了變更後的檔案，就變成了第6行，這兩行其實是一樣的，但因為其他行的刪減導致了，這一行的行號也發生了變化，這種情況又該如何合併呢？
帶著上面兩個問題，我們來整理一下報告的和合並流程。
比較複雜的就是對報告構建時間進行對比，構建時間比較會有三個結果，分別對應不同的合併流程。
3.4.3 變更內容獲取
在主流的git託管平臺，都提供了API介面的方式，返回Git的資訊，比如可以通過Gitlab的compare介面就可以將兩個分支的對比資訊給拿到，通過解析返回的資訊，我們就可以知道檔案的變更內容。
3.4.4 使用者管理
為了能夠讓馬可平臺儘可能的簡單化，我們登入使用了通用Oauth登入方式，通過這種方式，不僅解決了登入問題，同時也解決了程式碼許可權的問題，真是一舉多得，當然我們在設計登入的時候，充分考慮了主流的Git平臺，比如Gitlab、Github、Gitee等，也就是說託管在這些平臺中的程式碼，都可以一鍵接入馬可程式碼覆蓋率平臺。
3.5 展示層
這就是馬可平臺報告展示的細節，支援實時刷線報告，支援程式碼對比。通過對比可以我們詳細看到檔案變更的內容，以及便跟內容的覆蓋率情況。
3.5.1 程式碼對比
那馬可平臺是如何做程式碼對比的呢？
我們藉助了一個開源庫，叫做jsdiff，通過這個庫我們可以對比出兩個檔案的差異資訊。對比出來的結果是一個物件陣列，這是個物件陣列，陣列包含4個內容：
-
count:行數；
-
Value：具體程式碼；
-
Added：是否新增；
-
Removed：是否刪除。
通過解析這個陣列，我們可以將對比的結果一一還原到頁面中來，比如右下角，就是我們通過這個陣列進行還原的結果。
四、總結規劃
到這裡我們對於馬可程式碼覆蓋率平臺的技術方案，基本聊完了，對於馬可程式碼覆蓋率平臺，我們接下來有兩個比較大的規劃。
1）一是豐富各端語言的接入：
-
前端包括小程式，Node.js，Typescript；
-
其他語言包括，Go，Java等。
2）二是要做開源：
- 我們會將馬可平臺整體打包開源，擁抱開源社群，希望和大家一起共建馬可平臺。
上面就是我們對程式碼覆蓋率的一些探索，程式碼覆蓋率可以當做是測試質量的一個指標，提供了相對合理、客觀的資料。但100%的程式碼覆蓋率，並不能代表100%沒有bug，程式碼覆蓋和用例是否正確沒有一個明確的對應關係，僅僅是測試質量過程中的一個補充。不能盲目追求程式碼覆蓋率，而應該想辦法設計更多更好的用例，讓用例和程式碼覆蓋率相互補充，提升專案質量。
作者：vivo官網商城前端團隊-Song Jiachao