jacoco的增量覆蓋率報告實現的邏輯和一些個人想法。

jacoco報告分析

從jacococli.jar的使用方法可以看到，導出的文件格式有csv，xml，html等多種格式。

進行嘗試后，可以看到xml是數據信息較全的一種類型。

下面對xml的報告構成過一個分析：

1、counter標簽

記錄了行覆蓋率、 類覆蓋率、 分支覆蓋率、 方法覆蓋率、指令覆蓋、 圈復雜度的具體覆蓋和未覆蓋數。其中，LINE行覆蓋率與jacoco的整體覆蓋率波形圖中的數據是一致的。

2、package標簽

...

包含主要信息：類、行覆蓋信息、包內行覆蓋率統計數據。

sourcefile中就是源碼中某一行的執行情況，與最終jacoco html的頁面樣式對應關系如下

處理jacoco的xml報告原始數據，生成增量報告

搞清楚xml報告和html報告中的邏輯關系后，就可以著手開始對xml中的數據進行處理定制自己的類型報告了。

由于前端開發能力有限，打算直接修改jacoco的原始報告的展示邏輯，達到展示增量報告的目的。

處理邏輯

處理的基本步驟說明

三個數據采集：代碼差異、覆蓋率exec文件、代碼文件(src目錄、class目錄)

整體處理步驟：

1、將代碼差異與代碼源文件進行比對，生成標記出代碼新增的java文件

2、通過jacococli的report方法將 exec文件轉成xml數據格式

3、分析覆蓋率報告xml文件，①計算各類覆蓋率；②生成帶有覆蓋率信息、新增代碼標識的仿jacoco html報告的網頁

實現說明

1、標記代碼差異

在jenkins中增加shell指令執行git diff。

根據研發人員對代碼上線的管理方式，挑選合適的比對對象。例如，主干上線，分支開發的，可以每次使用勾選的分支與上一次上線分支進行比對；如果是小項目直接主干開發的，可以選擇增加git參數，revision來標識比對的基準歷史版本。

git diff "origin/prod" ${branch} ./src/main/java > /gitdifffile/${JOB_NAME}.txt

git diff ${old_version} ${GIT_COMMIT} ./src/main/java > /gitdifffile/${JOB_NAME}.txt

根據獲取到的代碼差異信息，與src目錄下的原始文件比對，標記出代碼差異。

細節：

空行、符號的過濾；“import XXX”，“log”等不重要內容差異的過濾；

新增代碼、刪除代碼仍使用git比對結果的方式進行標記，“+”標識新增，“-”標識刪減

可根據需要過濾部分文件的差異。

基本上就是python的文本比對，文本讀取和寫入。

2、覆蓋率數據exec文件的保存

由于實際使用的場景，希望獲取的信息區間為某次迭代周期內。

增加啟停腳本入參isnewstory，

isnewstory=true 屬于新迭代的情況下：服務停止前不進行dump操作，且刪除保留的歷史exec文件。

isnewstory=False 非新迭代，每次項目停止的時候，進行dump保存執行數據。確保是完整的版本測試執行覆蓋率數據

3、報告的展示

報告分為覆蓋率數據報告和詳細代碼標識兩類，通過python的flask框架，全端仍使用jacoco的前端(前端不好，不想改了)

覆蓋率數據報告頁面

大概說下流程

刷新brief report頁面時，通過os.popen(jacococli.jar的命令)，實時獲取最新覆蓋率數據(dump)，并將多個exec合成一個(merge)，生成最新的jacoco xml報告(report)

根據gitdiff找到與上線版本不同的代碼，查找這部分代碼對應的覆蓋率數據，過濾掉不需要的。python讀寫文件，解析xml，并計算

詳細代碼標識頁面

每次在jenkins構建過程中，即調用腳本將gitdiff的數據轉為含有代碼增刪標識的java文件

調用詳細代碼標識頁面時，獲取對應的java文件，并實時分析jacoco xml報告的對應內容，添加與jacoco原始頁面一樣的樣式標識。

總結

當前的問題

1、為了提供更全面的代碼上下文進行參考，并未細化到具體方法。如果覆蓋率數據要提供更高效準確的覆蓋率判斷標準，則必須再細化和深入，實現難度比較大。

2、實際統計的數據與測試的覆蓋仍存在一定的差異。例如完全覆蓋也不能說明測試的全面。如果是漏了一種業務場景，那覆蓋率100%也沒有意義。

未覆蓋到怎么辦

根據從這套工具開始使用，到現在，幾乎每次在上線前都會遇到新增代碼標識為紅色，或者分支沒有覆蓋到的情況，除非是那種非常非常小的改動。

未覆蓋到有一些情況就比較無奈

1、部分異常捕獲的代碼段

try {

.......

}catch (Exception e) {

log.error("save to cache error", e.getMessage());

}

異常捕獲后并無其它處理邏輯，僅僅只是打印問題。

如果是普通的場景還比較好涉及測試用例，但很簡單的功能中，這個部分從接口、前端操作觸發的數據流向觸發不到的。確認這樣的情況，通常就會放棄這條未覆蓋。

2、修復bug，例如僅僅判斷的邊界值進行了修改等，則回歸范圍并不覆蓋完整邏輯的，也不會為了達到100% 的覆蓋率而執行完整用例。

3、很多業務漸漸使用頻率已經幾乎為0 ，歷史代碼還留著不刪(怕出問題)的。這種最坑。

個人想法

覆蓋率數據個人覺得更大的意義在于評估提測與實際代碼更改的信息是否相符，另外在確認業務場景和處理邏輯后，通過覆蓋率結果來進行查漏補缺。在某些簡單的場景下，可以當做是一個白盒測試的途徑。

總結

以上是生活随笔為你收集整理的python接口测试覆盖率统计_从 jacoco 报告数据分析，python 脚本实现增量覆盖率统计...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。