本文根據(jù)Song Jiachao老師在“2021 vivo開發(fā)者大會"現(xiàn)場演講內(nèi)容整理而成。公眾號回復(fù)【2021VDC】獲取互聯(lián)網(wǎng)技術(shù)分會場議題相關(guān)資料骡湖。
[圖片上傳失敗...(image-4bf909-1641782716283)]
一充石、背景
1.1 項目特點
隨著互聯(lián)網(wǎng)科技的飛速發(fā)展莫换，越來越多的公司將敏捷開發(fā)的流程引入到項目迭代中，所以越來越多的項目呈現(xiàn)出三個特點：
[圖片上傳失敗...(image-d8db95-1641782716283)]
1）迭代周期短：各種倒排骤铃，壓排期拉岁，一周一小版本，兩周一大版本惰爬，甚至有的項目每天都在發(fā)版喊暖，苦不堪言。
2）需求變更頻繁：我們的產(chǎn)品經(jīng)理不是在推翻自己撕瞧，就是在推翻自己的路上陵叽，所以我們經(jīng)常也會開玩笑跟產(chǎn)品經(jīng)理說：來來來狞尔，你立個字據(jù)，保證一下以后再也不改需求了巩掺。產(chǎn)品經(jīng)理這時候信誓旦旦的說：好好好偏序，你把這個需求改了，我保證給你立字據(jù)胖替，下次再也不改了研儒。可是并沒有什么作用独令，需求依然改的很頻繁端朵。當然了，這也不能怪產(chǎn)品經(jīng)理燃箭，面對著瞬息萬變的市場環(huán)境逸月，我們有時候需要用這種試錯的方式來快速的找到正確的方案。
3）系統(tǒng)復(fù)雜度高：前端已經(jīng)不僅僅是畫畫頁面那么簡單了遍膜，大家可以從現(xiàn)在的前端招聘信息中就可以看出來。分布式瓤湘、微服務(wù)瓢颅、中間層虏杰、各種琳瑯滿目的架構(gòu)憋肖，讓本就復(fù)雜的業(yè)務(wù)爷光，變得更加復(fù)雜别垮。
隨著項目的這些特點越來越明顯堕汞，對我們開發(fā)和測試的挑戰(zhàn)也變得越來越大溯职。
1.2 煩惱
所以我們會有如下的一些煩惱：
[圖片上傳失敗...(image-458943-1641782716283)]
有這樣的煩惱但两，歸根結(jié)底有兩方面的原因：
測試人員：他們不知道開發(fā)代碼的改動點在哪里舆声，影響點在哪里醒第，很難用精準化的測試方案渔嚷，來提升測試效率，所以為了保險起見稠曼，只能把相關(guān)功能全部測一遍
開發(fā)人員：他們無法全面的知道每一行代碼的執(zhí)行情況形病，很難通過執(zhí)行數(shù)據(jù)，來分析哪些代碼是有用的霞幅，哪些代碼是沒用的漠吻，哪些代碼測試已經(jīng)驗證過，哪些代碼還沒有被驗證
[圖片上傳失敗...(image-e3b39e-1641782716283)]
所以我們迫切的需要一個平臺司恳，能夠方便的看出代碼的改動點和執(zhí)行情況途乃，而這個平臺就是集成代碼覆蓋率平臺。
1.3 方案
所謂的集成代碼覆蓋率平臺扔傅，是指在集成測試期間耍共，采集代碼覆蓋率烫饼，并上報到系統(tǒng)中進行合并展示的平臺。
1.4 難點
既然有解決方案划提，為什么現(xiàn)在市面上很少有這樣的產(chǎn)品推出呢枫弟？我們在研究這方面的時候，發(fā)現(xiàn)了兩個非常大的技術(shù)難點鹏往。
第一個難點是：數(shù)據(jù)合并難淡诗。我們都知道，前端所有的測試都是在各端進行的伊履，測試產(chǎn)生的數(shù)據(jù)留在各個終端韩容，很難將這些留在各個終端的數(shù)據(jù)進行收集和合并。
第二個難點是：數(shù)據(jù)失效快唐瀑。前端代碼發(fā)版非常頻繁群凶，在測試的時候，每天可能發(fā)版好多次哄辣，發(fā)版代表雖然是同一份文件请梢，但里面的內(nèi)容可能完全不一樣了，這樣就會導致之前采集的覆蓋率完全失效了力穗。
通過不斷的嘗試毅弧，我們終于解決了這兩個問題，于是就誕生了馬可代碼覆蓋率平臺当窗。
二够坐、馬可平臺的優(yōu)勢及亮點
2.1 優(yōu)勢及亮點
馬可平臺是一個完備的代碼覆蓋率平臺，具有以下幾個亮點：
支持一鍵接入：不挑業(yè)務(wù)崖面，框架元咙，對現(xiàn)有代碼零侵入，一鍵即可接入巫员；
支持增量報告：能夠讓使用者更加精準的了解代碼覆蓋率情況庶香；
支持多種語言：馬可平臺不局限于前端，也能服務(wù)后端简识；
支持多種工具：方便用戶使用脉课，比如代碼對比，gitblame等财异；
支持多個用戶：多種報告的實時合并與查看倘零；
支持大盤監(jiān)控：通過大盤實時查看覆蓋率走勢，了解項目質(zhì)量趨勢戳寸；
支持消息通知：定時推送項目覆蓋率情況呈驶；
支持獨立部署：不僅支持第三方直接接入，還支持一鍵私有化部署疫鹊。
2.2 體驗
2.2.1 詳情頁
下圖上的第一點：當前版本改動了哪些文件袖瞻，我們會將所有的改動文件通過樹狀結(jié)構(gòu)圖展示在第一個區(qū)域司致，讓用戶一眼就能清楚當前版本到底改了多少個文件
下圖上的第二點：當前文件改動哪些地方，我們通過代碼對比的方式聋迎，直觀的將每一個文件的改動點顯示在第二個區(qū)域脂矫，讓用戶一眼就能看到這個文件到底改了哪幾行代碼
下圖上的第三點：當前改動是否被測試驗證過，剛剛第二點我們標記出了一份文件的到底哪幾行發(fā)生了變更霉晕，那么第三點就是將變更的代碼標記出來是否被驗證過庭再。
有了這三點標記，我們就將改動點和測試過程進行了完美的結(jié)合牺堰，讓測試結(jié)果一目了然拄轻。
[圖片上傳失敗...(image-ea1cf2-1641782716283)]
2.2.2 趨勢圖
通過項目趨勢圖，我們可以清楚的看出項目覆蓋率走勢伟葫，了解項目質(zhì)量趨勢恨搓。
2.2.3 概覽
目前馬可平臺已經(jīng)穩(wěn)定運行近3個月了，服務(wù)了39個項目筏养，生成了133分報告斧抱。
2.3 價值
通過馬可平臺我們就將測試關(guān)注的四個點即：修改點、影響點渐溶、測試點和測試結(jié)果辉浦，給緊密的聯(lián)系起來，同時將之前的缺乏數(shù)據(jù)的評估轉(zhuǎn)化成精確的掌猛，有客觀依據(jù)可量化的評估。
三眉睹、馬可平臺的技術(shù)方案
馬可平臺的技術(shù)方案共有4個小部分：首先會介紹馬可平臺的整體架構(gòu)荔茬，然后分別從接入層、服務(wù)層和展示層竹海，三個方面加以詳細的說明慕蔚。
3.1 整體架構(gòu)圖
馬可平臺分為三個層：接入層、服務(wù)層和展示層斋配；
接入層：我們的目標是一鍵接入孔飒，多語言適配，區(qū)分環(huán)境和智能上報艰争。目前針對Web端的適配已經(jīng)全部完成了坏瞄，正在適配其他技術(shù)棧，比如小程序甩卓、Node.js鸠匀、Typescript。同時我們還規(guī)劃了其他語言的接入方式逾柿，讓馬可平臺變成全語言的代碼覆蓋率平臺缀棍。
服務(wù)層：主要是對報告的各種處理宅此，比如報告管理、用戶管理爬范、項目管理等功能父腕。
展示層：主要是對服務(wù)層的一個延伸，通過可視化的方式青瀑，提供更加便捷的報告查看和管理等功能璧亮。
3.2 數(shù)據(jù)流向圖
通過數(shù)據(jù)流向圖，我們將一份報告從接入層到服務(wù)層再到展示層給串聯(lián)起來形成一個完美的閉環(huán)狱窘。
[圖片上傳失敗...(image-9b61ab-1641782716283)]
3.3 接入層
接入層主要就是接入和上報這兩點杜顺；
針對接入：我們提供各語言插樁方案、插樁規(guī)范蘸炸、以及接入指導躬络。
針對上報：主要有各語言的采集方案，上報數(shù)據(jù)標準和上報方案搭儒。
[圖片上傳失敗...(image-f14882-1641782716283)]
3.3.1 接入
插樁維度：
通常我們會將插樁分為4個維度：語句覆蓋率穷当，函數(shù)覆蓋率，分支覆蓋率淹禾，和行覆蓋率馁菜。
[圖片上傳失敗...(image-59002-1641782716283)]
插樁過程
馬可插樁
這是馬可平臺，js插樁的部分代碼铃岔，主要做了三件事汪疮；
- 第一步：獲取文件相對路徑
為啥是相對路徑？因為馬可代碼覆蓋率是一個平臺毁习，所以我們需要獲取相對路徑智嚷，讓文件路徑和項目進行關(guān)聯(lián)，而不是與打包機器關(guān)聯(lián)纺且。
第二步：調(diào)用了istanbul-lib-instrument進行插樁我們沒有完全重寫插樁代碼盏道，而是借助了開源的力量，讓馬可平臺更加輕量化载碌、通用化猜嘱。
第三步：添加自定義參數(shù)這些參數(shù)都非常重要，指明了當前報告的重要信息嫁艇。
這樣我們就簡單完成了js語言的插樁適配朗伶，其他語言可以同樣參考這樣的思路。
3.3.2 上報
上報就是采集和發(fā)送的過程步咪。
針對采集：主要獲取兩個信息腕让，覆蓋率信息和項目信息，兩者缺一不可。
針對發(fā)送：各個端會有很大的差異纯丸，我們提供了一定的建議偏形。比如在web中可以監(jiān)聽Visibilitychange事件，而在小程序中可以監(jiān)聽onShow和onHide事件觉鼻，如果是在Node等其他服務(wù)端中可以通過定時任務(wù)進行上報俊扭。
3.4 服務(wù)層
馬可的服務(wù)層提供了很多的功能，這里我們挑報告管理和用戶管理坠陈，這兩個比較典型的功能進行介紹萨惑。
3.4.1 報告管理
報告三要素：首先一份完整的報告需要有三個基本要素：覆蓋率信息，項目信息仇矾，和文件信息庸蔼。
覆蓋率信息包括：語句、分支贮匕、函數(shù)姐仅、行四個覆蓋率。
項目信息包括：項目配置刻盐，分支信息掏膏，文件hash，構(gòu)建時間敦锌。
文件信息包括：文件地址馒疹、文件內(nèi)容和Git信息。
通過接入層采集的覆蓋率信息和項目信息乙墙，然后關(guān)聯(lián)Git平臺的文件信息颖变，通過這種方式才能讓馬可變成一個多用戶、多報告支持的覆蓋率平臺听想。
[圖片上傳失敗...(image-ef64e3-1641782716283)]
3.4.2 合并流程
上一個步驟我們采集到了覆蓋率腥刹，下面我們聊一聊馬可平臺是如何進行報告合并的，我們先來考慮兩種情況：
- 第一種情況：文件沒有變更哗魂；
就是我們下圖左邊的部分肛走，文件沒有變更的時候漓雅，有兩個測試录别，小美和小花分別產(chǎn)生了兩個報告信息，這種情況改如何進行合并呢邻吞？
- 第二種情況是：文件發(fā)生了變更组题；
同一份文件，文件的內(nèi)容發(fā)生了變更抱冷，變更文件的行號前后無法一一對應(yīng)崔列，比如變更前文件的第10行，到了變更后的文件，就變成了第6行赵讯，這兩行其實是一樣的盈咳，但因為其他行的刪減導致了，這一行的行號也發(fā)生了變化边翼，這種情況又該如何合并呢鱼响？
帶著上面兩個問題，我們來整理一下報告的和合并流程组底。
比較復(fù)雜的就是對報告構(gòu)建時間進行對比丈积，構(gòu)建時間比較會有三個結(jié)果，分別對應(yīng)不同的合并流程债鸡。
3.4.3 變更內(nèi)容獲取
在主流的git托管平臺江滨，都提供了API接口的方式，返回Git的信息厌均，比如可以通過Gitlab的compare接口就可以將兩個分支的對比信息給拿到唬滑，通過解析返回的信息，我們就可以知道文件的變更內(nèi)容莫秆。
3.4.4 用戶管理
為了能夠讓馬可平臺盡可能的簡單化间雀，我們登錄使用了通用Oauth登錄方式，通過這種方式镊屎，不僅解決了登錄問題惹挟，同時也解決了代碼權(quán)限的問題，真是一舉多得缝驳，當然我們在設(shè)計登錄的時候连锯，充分考慮了主流的Git平臺，比如Gitlab用狱、Github运怖、Gitee等，也就是說托管在這些平臺中的代碼夏伊，都可以一鍵接入馬可代碼覆蓋率平臺摇展。
3.5 展示層
這就是馬可平臺報告展示的細節(jié)，支持實時刷線報告溺忧，支持代碼對比咏连。通過對比可以我們詳細看到文件變更的內(nèi)容，以及便跟內(nèi)容的覆蓋率情況鲁森。
3.5.1 代碼對比
那馬可平臺是如何做代碼對比的呢祟滴？
[圖片上傳失敗...(image-4beafd-1641782716283)]
我們借助了一個開源庫，叫做jsdiff歌溉，通過這個庫我們可以對比出兩個文件的差異信息垄懂。對比出來的結(jié)果是一個對象數(shù)組，這是個對象數(shù)組，數(shù)組包含4個內(nèi)容：
count:行數(shù)草慧；
Value：具體代碼桶蛔；
Added：是否新增；
Removed：是否刪除漫谷。
通過解析這個數(shù)組羽圃，我們可以將對比的結(jié)果一一還原到頁面中來，比如右下角抖剿，就是我們通過這個數(shù)組進行還原的結(jié)果朽寞。
[圖片上傳失敗...(image-799eba-1641782716283)]
四、總結(jié)規(guī)劃
到這里我們對于馬可代碼覆蓋率平臺的技術(shù)方案斩郎，基本聊完了脑融，對于馬可代碼覆蓋率平臺，我們接下來有兩個比較大的規(guī)劃缩宜。
1）一是豐富各端語言的接入：
前端包括小程序肘迎，Node.js，Typescript锻煌；
其他語言包括妓布，Go，Java等宋梧。
2）二是要做開源：
- 我們會將馬可平臺整體打包開源匣沼，擁抱開源社區(qū)，希望和大家一起共建馬可平臺捂龄。
[圖片上傳失敗...(image-db95d3-1641782716283)]
上面就是我們對代碼覆蓋率的一些探索释涛，代碼覆蓋率可以當做是測試質(zhì)量的一個指標，提供了相對合理倦沧、客觀的數(shù)據(jù)唇撬。但100%的代碼覆蓋率，并不能代表100%沒有bug展融，代碼覆蓋和用例是否正確沒有一個明確的對應(yīng)關(guān)系窖认，僅僅是測試質(zhì)量過程中的一個補充。不能盲目追求代碼覆蓋率告希，而應(yīng)該想辦法設(shè)計更多更好的用例扑浸，讓用例和代碼覆蓋率相互補充，提升項目質(zhì)量暂雹。
作者：vivo官網(wǎng)商城前端團隊-Song Jiachao
