vivo基于JaCoCo的測試覆蓋率設(shè)計(jì)與實(shí)踐

　　本文主要介紹vivo內(nèi)部研發(fā)平臺使用JaCoCo實(shí)現(xiàn)測試覆蓋率的實(shí)踐，包括JaCoCo原理介紹以及在實(shí)踐過程中遇到的新增代碼覆蓋率統(tǒng)計(jì)問題和頻繁發(fā)布導(dǎo)致覆蓋率丟失問題的解決辦法。

　　一、為什么需要測試覆蓋率

　　1.1 在日常研發(fā)過程中，經(jīng)常發(fā)現(xiàn)一些問題

　　測試案例的設(shè)計(jì)憑經(jīng)驗(yàn)，當(dāng)研發(fā)一個(gè)新功能時(shí)，經(jīng)常對測試場景估計(jì)不足，到上線后發(fā)現(xiàn)bug;

　　開發(fā)經(jīng)常做一些需求之外的代碼變更(代碼小范圍內(nèi)重構(gòu)或在開發(fā)過程中發(fā)現(xiàn)小缺陷隨手改掉)，導(dǎo)致測試任務(wù)無法測試到對應(yīng)的場景，引起線上問題;

　　對測試效果無法量化考核，導(dǎo)致測試工作的質(zhì)量無法進(jìn)一步提升。

　　1.2. 有沒有技術(shù)手段能夠盡可能的避免上面的問題呢?

　　在業(yè)內(nèi)已經(jīng)在普遍使用代碼覆蓋率來提升測試質(zhì)量，那什么是代碼覆蓋率?

　　代碼覆蓋率是軟件測試中的一種度量，描述程序中源代碼被測試的比例和程度，所得比例稱為代碼覆蓋率 。

　　代碼覆蓋率指標(biāo)通常包含下面幾類：

　　函數(shù)/方法覆蓋率：函數(shù)/方法中有多少被調(diào)用到

　　分支覆蓋率：有多少控制結(jié)構(gòu)的分支(例如if語句)被執(zhí)行

　　條件覆蓋率：有多少布爾子表達(dá)式被測試為真值和假值

　　行覆蓋率：有多少行的源代碼被測試過

　　1.3 在使用測試覆蓋率的過程中，經(jīng)常發(fā)現(xiàn)的場景

　　if/else語句中，if{}內(nèi)的代碼被覆蓋到，else{}內(nèi)的代碼沒有被覆蓋到，可以得出部分分支場景沒有測試到;

　　try/catch語句中，try{}內(nèi)的代碼被覆蓋到，catch{}內(nèi)的代碼沒有被覆蓋到，可以得出異常場景沒有測試到;

　　if (條件1 || 條件2 || 條件3)語句中，條件1被覆蓋到，條件2和條件3沒有被覆蓋到，可以得出部分條件場景沒有測試到;

　　測試人員對代碼覆蓋率的指標(biāo)正確使用，能有效提升測試的質(zhì)量，進(jìn)而提升版本的上線質(zhì)量。

　　二、JaCoCo在測試覆蓋率場景中的使用

　　2.1 JaCoCo介紹

　　當(dāng)前主流的代碼覆蓋率工具：

　　C/C++→Gcov ，Java→JaCoCo，JavaScript→ Istanbul。

　　考慮到服務(wù)器端主要是Java語言，所以CICD平臺優(yōu)先使用JaCoCo來支持 Java 語言的代碼覆蓋率統(tǒng)計(jì)能力。

　　通過JaCoCo官網(wǎng)，我們可以看到JaCoCo的使命是為Java VM 的環(huán)境中的代碼覆蓋分析提供標(biāo)準(zhǔn)技術(shù)。重點(diǎn)是提供一個(gè)輕量級、靈活且有據(jù)可查的庫，用于與各種構(gòu)建和開發(fā)工具集成。

　　2.2 JaCoCo優(yōu)點(diǎn)

　　JaCoCo支持指令(C0)、分支(C1)、行、方法、類和圈復(fù)雜度等多維度的覆蓋分析;

　　基于 Java 字節(jié)碼，也可以在沒有源文件的情況下工作;

　　性能良好，運(yùn)行時(shí)開銷很小，尤其是對于大型項(xiàng)目;

　　比較完整的API，很方便與其他工具進(jìn)行集成;

　　遠(yuǎn)程協(xié)議和 JMX 控制可在任何時(shí)間點(diǎn)從代理請求執(zhí)行數(shù)據(jù)下載。

　　2.3 JaCoCo原理

　　主要來自于JaCoCo官方網(wǎng)站

　　JaCoCo支持幾種不同的方法來收集覆蓋信息，對于每種方法，由不同技術(shù)實(shí)現(xiàn)的，下圖橙色路徑部分是JaCoCo 推薦使用的方式，即通過On-The-Fly方式收集覆蓋率信息：

　　通過上圖我們知道，JaCoCo 是通過對Java字節(jié)碼(Byte Code)插入探針的方式來收集覆蓋率信息的，探針是可以插入現(xiàn)有指令之間的附加指令。它們不會改變方法的行為，但會記錄它們已被執(zhí)行的事實(shí)。

　　下面以一段簡單的 程序?yàn)槔�進(jìn)行說明：

　　這段代碼經(jīng)過Java編譯以后轉(zhuǎn)化為以下字節(jié)碼：

　　因?yàn)镴ava 字節(jié)碼指令的線性序列，控制流是通過條件或無條件指令實(shí)現(xiàn)跳轉(zhuǎn)的，跳轉(zhuǎn)目標(biāo)在技術(shù)上是相對于目標(biāo)指令的偏移量。這個(gè)跟大學(xué)學(xué)習(xí)的匯編指令的跳轉(zhuǎn)方式類似，為了更好的可讀性，使用符號標(biāo)簽 (L1，L2 ) 代替實(shí)際的指令地址。

　　上圖中橙色的部分為插入的探針，理論上我們可以在控制流圖的每個(gè)邊緣插入一個(gè)探針，由于探針實(shí)現(xiàn)本身需要一些字節(jié)碼指令，這將會使類文件的大小增加數(shù)倍;幸運(yùn)的是，這不是必需的，實(shí)際上我們只需要根據(jù)方法的控制流為每個(gè)方法插入幾個(gè)探針。例如，沒有任何分支的方法只需要一個(gè)探針。

　　如果已經(jīng)執(zhí)行了探測，我們就知道相應(yīng)的邊已經(jīng)被訪問過。從這條邊我們可以得出結(jié)論到其他前面的節(jié)點(diǎn)和邊：

　　如果一條邊被訪問過，我們就知道這條邊的源節(jié)點(diǎn)已經(jīng)被執(zhí)行了;

　　如果一個(gè)節(jié)點(diǎn)已經(jīng)被執(zhí)行并且該節(jié)點(diǎn)是只有一條邊的目標(biāo)，我們知道這條邊已經(jīng)被訪問過。

　　如果我們在正確的位置有探針，遞歸地應(yīng)用這些規(guī)則可以確定方法的所有指令的執(zhí)行狀態(tài)，探針只是需要在控制流邊緣插入的一小段附加指令。

　　三、CICD平臺關(guān)于測試覆蓋率的解決方案

　　通過上面對JaCoCo原理的介紹，結(jié)合我們公司內(nèi)部的研發(fā)流程，在CICD平臺對代碼覆蓋率功能的設(shè)計(jì)如下：

　　從上面 CICD 平臺對測試覆蓋率的設(shè)計(jì)圖，大概可以看出來，整個(gè)過程包含三個(gè)階段

　　3.1 測試前

　　測試前由測試人員(開發(fā)人員/運(yùn)維人員)在流水線上開啟測試覆蓋率功能，在流水線執(zhí)行發(fā)布時(shí)，會在測試環(huán)境上下載JaCoCo Agent包，并在Java進(jìn)程啟動時(shí)配置JavaAgent參數(shù);

　　在進(jìn)程啟動過程或啟動之后，有class文件被加載時(shí)被Agent攔截，對class文件進(jìn)行插樁處理，在必要的路徑下插入探針(插入探針的原理在上一節(jié)已經(jīng)介紹)。

　　3.2 測試中

　　在測試過程中，測試人員在測試環(huán)境執(zhí)行測試案例(手動執(zhí)行或自動化腳本)，被調(diào)用到的代碼會被探針記錄下來，探針數(shù)據(jù)保存在Java進(jìn)程的內(nèi)存中。

　　3.3 測試后

　　測試人員可以多次發(fā)布測試環(huán)境，針對同一個(gè)分支的代碼，可以合并多次測試的結(jié)果數(shù)據(jù)，形成全量的覆蓋率數(shù)據(jù);

　　在測試結(jié)束后，CICD平臺通過JaCoCo的API，手動/自動下載(dump)覆蓋率數(shù)據(jù)，合并(merge)歷史覆蓋率數(shù)據(jù)，生成測試覆蓋率報(bào)告;

　　測試人員根據(jù)測試覆蓋率報(bào)告的結(jié)果，查看測試遺漏的場景，進(jìn)行補(bǔ)充測試，事后總結(jié)遺漏的原因，提高測試效率。

　　四、在實(shí)踐過程中遇到的問題及解決辦法

　　測試覆蓋率在上線運(yùn)行一段時(shí)間后，在實(shí)踐過程中發(fā)現(xiàn)了一些問題，總結(jié)為以下幾點(diǎn)：

　　4.1 在不同機(jī)器編譯會導(dǎo)致classid不一致的問題

　　在實(shí)踐過程中，經(jīng)常遇到這樣一個(gè)問題，用戶反饋并確認(rèn)案例已經(jīng)正常執(zhí)行，但是生成的報(bào)告顯示未覆蓋，經(jīng)過調(diào)查發(fā)現(xiàn)在測試環(huán)境中的class和生成報(bào)告時(shí)的class不一致導(dǎo)致的。

　　在 JaCoCo內(nèi)部，覆蓋率數(shù)據(jù)是以classid作為key來存儲的，classid是根據(jù)class的字節(jié)碼hash算法得出來的，看JaCoCo源碼中關(guān)于classid的算法如下：

　　出現(xiàn)不一致的情況包括：

　　發(fā)布時(shí)編譯的機(jī)器和生成報(bào)告的機(jī)器環(huán)境上有差異，比如操作系統(tǒng)版本、JDK版本等，導(dǎo)致編譯的class不一致;

　　發(fā)布時(shí)編譯的代碼版本與生成報(bào)告時(shí)的代碼版本有差異，導(dǎo)致編譯的class不一致。

　　要解決上面環(huán)境的問題，需要保持在測試覆蓋率過程中編譯的機(jī)器環(huán)境保持一致，或者做到只編譯一次，使用同一份class文件，考慮到存儲空間的問題，vivo采用保持環(huán)境一致的辦法來解決。

　　對于第二種情況，常見于采用敏捷研發(fā)的團(tuán)隊(duì)，在一個(gè)版本中按功能點(diǎn)轉(zhuǎn)測，經(jīng)常導(dǎo)致測試在測試過程中，源代碼已經(jīng)發(fā)生了修改，生成報(bào)告時(shí)代碼版本和發(fā)布時(shí)的代碼版本已經(jīng)不一致，這種情況比較復(fù)雜，我們在下面會介紹。

　　4.2 在研發(fā)過程中更加關(guān)注增量代碼的覆蓋率

　　在我們?nèi)粘５难邪l(fā)活動中，對于全量代碼更多使用自動化腳本來回歸，而新研發(fā)的功能主要表現(xiàn)為增量代碼，對于增量代碼的覆蓋率情況更加關(guān)注， JaCoCo本身不支持增量代碼的覆蓋率。

　　對于這個(gè)問題網(wǎng)上也有不少解決方案，基本都是基于git的版本差異，在生成報(bào)告時(shí)過濾掉沒有差異的類，形成兩份覆蓋率報(bào)告，一份是全量代碼覆蓋率報(bào)告，一份是增量代碼覆蓋率報(bào)告，而我們更希望在一份覆蓋率報(bào)告中呈現(xiàn)增量代碼和全量代碼的覆蓋情況，結(jié)合代碼在全量報(bào)告中的覆蓋路徑分析遺漏的場景，同時(shí)能在報(bào)告中標(biāo)注增量代碼和增量代碼的覆蓋情況，期望的效果如下圖所示：

　　為了達(dá)到上述效果，需要幾個(gè)改造步驟：

　　計(jì)算出當(dāng)前代碼分支的變動情況，需要精確到代碼行

　　改造JaCoCo計(jì)算邏輯，針對增量代碼單獨(dú)統(tǒng)計(jì)覆蓋率指標(biāo)值

　　改造JaCoCo報(bào)告格式，在報(bào)告中兼容全量代碼和增量代碼的覆蓋情況

　　對于計(jì)算代碼分支的變動情況，放棄 GitLab 提供的代碼比對功能來獲取不同版本之前的差異信息，如果版本之間差異太多的話，經(jīng)常發(fā)生GitLab 的API接口調(diào)用超時(shí);

　　并且GitLab 的比對功能無法滿足定制場景，比如一行代碼僅僅因?yàn)楦袷交�被識別為變更代碼等等，采用借助Linux自帶的diff命令，實(shí)現(xiàn)代碼差異比對的能力：

　　對于改造 JaCoCo計(jì)算邏輯，增加針對增量代碼的覆蓋率指標(biāo)統(tǒng)計(jì)，在CoverageNodeImpl類中增加新的Counter，用于統(tǒng)計(jì)新增類、方法、行、指令覆蓋率指標(biāo);在SourceNodeImple類中increment方法中增加新增代碼行的統(tǒng)計(jì)邏輯。

　　4.3 重談關(guān)于classid的問題

　　在上面已經(jīng)談到關(guān)于classid的問題，如果是環(huán)境問題是比較好解決，但是現(xiàn)在互聯(lián)網(wǎng)團(tuán)隊(duì)基本都使用敏捷模式，基本不太可能等開發(fā)工作全部完成再轉(zhuǎn)測，這樣必然會導(dǎo)致最新的覆蓋率報(bào)告，會出現(xiàn)以類為單元的覆蓋率數(shù)據(jù)丟失，需要測試人員來回重復(fù)的執(zhí)行測試案例，否則測試覆蓋率數(shù)據(jù)不會很好看。

　　既然知道問題所在，那有沒有辦法解決呢?是不是可以直接找到以前的classid，把以前的classid對應(yīng)的探針數(shù)據(jù)復(fù)制到當(dāng)前的classid下就可以?當(dāng)然是不行的，因?yàn)樵创�碼發(fā)生變動，導(dǎo)致探針的數(shù)量發(fā)生變化，會出現(xiàn)下面的情況：

　　或者這樣

　　出現(xiàn)這樣的情況，會無法判斷具體哪些探針是新增的或者刪除的;即使出現(xiàn)前后探針一致的情況，也有可能因?yàn)榇�碼修改，探針位置發(fā)生變化：

　　那么這個(gè)問題是否就無解了呢?這里給出一個(gè)大概思路，現(xiàn)在的覆蓋率數(shù)據(jù)是以類為單位存儲的，我們可以修改存儲的粒度，細(xì)化到方法級別，這樣可以保留一個(gè)類的大部分探針數(shù)據(jù)，這樣如果只是修改一個(gè)方法的話，那么其他方法的測試數(shù)據(jù)可以繼續(xù)保留，只需要重新測試這個(gè)方法就行，這樣可以有效的降低測試人員對整個(gè)類的所有方案重復(fù)測試的情況。

　　五、總結(jié)

　　對于測試覆蓋率功能，有沒有給測試的質(zhì)量帶來提升，答案是顯而易見的。

　　當(dāng)然也因?yàn)樯厦嫣岬降膯栴}，給測試人員帶了些麻煩，為了提升測試覆蓋率數(shù)據(jù)，導(dǎo)致測試人員對同一個(gè)功能重復(fù)多次測試;同時(shí)也給測試人員帶來了好處，很多測試人員在面對測試覆蓋率指標(biāo)嚴(yán)格要求下，被迫去看代碼的實(shí)現(xiàn)邏輯，提升了自己業(yè)務(wù)水平和閱讀代碼的水平，甚至出現(xiàn)測試人員和開發(fā)人員當(dāng)面對質(zhì)，關(guān)于代碼邏輯是否合理的場景。

　　最后，測試覆蓋率不是衡量測試質(zhì)量的唯一標(biāo)準(zhǔn)，要合理利用測試覆蓋率來提升測試質(zhì)量。