一、JaCoCo簡介
JaCoCo是Eclipse平臺下的開源產品，以小型，輕量化著稱，常見集成在Eclipse Workbench中，除此之外的啟動方式包括對接Ant和Maven，或是命令列的方式進行，Jacoco近兩年在軟體測驗行業的被關注度比較高，其主要原因是：在新一代精準測驗技術流的影響中，各大型單位對覆寫率的追求越來越迫切，作為一款開源產品，它主機面向Java語言，能夠在位元組碼層面給出覆寫率，同時也能將位元組碼關聯到對應的源代碼，這種半精準的測驗方式，在小型團隊中，對于某些場景的覆寫率訴求，起到了一定的回應，但它也有很強的局限性，尤其在支撐大型系統應用中，其表現能力弱，準確率不夠達標，這是它致命的缺點，也為它在大型系統中應用的 失敗埋下了伏筆，如何下此結論？本文作者將從應用者的角度，并參照國外用戶的總結文獻做一綜合分析羅列，因本人的學識所限，歸納的肯定不夠全面，如有不準確之處，還請同行拍磚、指正，
二、JaCoCo的技術內核
JaCoCo覆寫率的采集，主要是通過插裝及裝點的執行來收集程式運行的特征資料，JaCoCo的插裝，是通過agent在位元組碼中插入boolean[]陣列，來標記每句可執行代碼，只要執行過相應陳述句，boolean[]陣列會產生相應標記(True or False)，這個boolean陣列連同產生的標記稱之為探針（Probe），
當原始碼被編譯為位元組碼時，原始碼的邏輯指令，例如條件判定，回圈等，會被編譯為特殊指令，JaCoCo在動態插裝的程序中，當處理到這些指令時，會根據不同的邏輯進行不同的插裝方式，
圖表 1 Java源代碼（左）和對應位元組碼 （右）
圖1中IFEQ和G0T0都是JUMP(跳轉)指令，通過JUMP指令直接能從一個節點，跳轉到另一個節點，針對JUMP指令的插裝方式，有多種選擇，有些是在指令前插入探針，有些是在指令后插入探針（見表格1），類似的，在面對其他特殊指令時，例如ENTRY（程式啟動）， SEQUENCE（序列執行），或者EXIT（程式終止）等，均有不同的插裝操作，圖2以面對JUMP型別指令的插裝作為示例，其中左圖為未插裝的位元組碼，右圖為裝點位置的示意圖，
圖表 2針對JUMP型別指令的插裝示意
表格 1面對不同型別指令的插裝方式
JaCoCo的這種插裝方式，特別需要指出的是：
- 看似針對不同型別的指令，通過不同的插裝方式，反映了不同的邏輯關系，但由于其對整體的結構沒有把控，當程式較為復雜時，十分容易產生誤差，并且難以反映真實的呼叫關系，
- 除了表1列出的幾種指令外，JaCoCo對于其他的指令視為Exception，并不予處理，整個插裝程序，以及插裝位置對于用戶而言均不可見，無法通過人工干預合理和調整插裝問題，導致即使用戶有排查問題的需求和能力，也無從有效研究問題的根源，
- 這種無序的混亂插裝方式，也造成不必要的性能開銷，比如：使用JaCoCo會使代碼的膨脹率增加約30%，并增加約10%的性能消耗，（由于JaCoCo的設計初衷是針對民用專案，因此優化程度較低，當專案規模較小時，其影響并不顯著，但是對于資源十分寶貴的商業專案，會產生較大的負荷，）
三、JaCoCo的覆寫率實作
比較常見的覆寫率標準，按粒度從粗到細依次是：陳述句覆寫，分支覆寫，條件覆寫，路徑覆寫，JaCoCo可以實作陳述句覆寫,以及部分情況下的分支覆寫，一些研究表明，JaCoCo在分支覆寫層級，對結構控制只研究了if-else的情況，因此該層級的評估無法保證所有可執行陳述句的正確執行[1]，同時，JaCoCo所謂支持的條件覆寫結果其實不適合商用，由于位元組碼和原始碼之間的資訊差，它只能衡量條件真偽是否覆寫的比率，但無法有效確定某個具體條件執行的精確結果，而在企業級應用場景下，實作精確的條件覆寫是剛性需求，JaCoCo因為沒有代碼靜態分析輔助永遠無法純粹通過位元組碼獲取精確的條件和分支覆寫，
因此，JaCoCo優點是，可以進行粗粒度的覆寫率度量，比較適用于對于專案的整體初步評估，
在真正的精準測驗的體系中，對于覆寫率的計算和展示，其實作基礎是測驗資訊到原始碼，再從原始碼到測驗用例的精準關聯和資訊映射，與其相比，Jacoco最大的弱點是：易產生覆寫率的計算偏差，
- JaCoCo原生不支持和測驗用例的關聯，因此只能在手動執行測驗用例后，給出當前測驗用例所對應的整體覆寫率資訊，受限于設計理念，JaCoCo的覆寫率是在位元組碼層級統計，為了用戶的可讀性和可研究性，需要和原始碼進行關聯，關聯的程序通過一種映射機制（mapping）來實作，而在這種映射的程序中，會損失大量的資訊，因此，會進一步造成覆寫率資訊的誤差，
- 在覆寫率的應用端，商業適配性較差，第一，JaCoCo不支持多專案并行或者多版本累計的覆寫率統計，其覆寫率只針對某個用例對于某個專案的評估，JaCoCo的理念更偏向于傳統白盒測驗工具，在敏捷迭代的場景下，JaCoCo無法對版本/輪次/里程碑版本/專案之間的差異或者總體覆寫率計算進行支持，第二，JaCoCo原生不支持真正意義上的精準測驗，其內部資料表達都是聚合的陣列，不支持區分不同執行緒的覆寫率統計，第三，JaCoCo不支持實時的覆寫率展示，其覆寫率結果只能在該測驗任務結束后生成，第四，JaCoCo不支持結果的自動保存和累計，一旦退出環境，所有未經保存的結果都會被清空，
- 對于程式的邏輯結構和呼叫關系，JaCoCo除了在動態插裝的程序中進行實時分析以外，并無其他的獲取方式，而對于覆寫率的JaCoCo能夠在Java檔案的基礎結構層級的基礎上，從四類資料：覆寫率，被覆寫行數，未覆寫行數，以及總行數，實作覆寫程度的評估和展示，其界面如圖3所示，同時，在實作原始碼和位元組碼的映射后，統計的覆寫率資訊也會相應的在原始碼端的代碼行上進行展示，界面如圖4所示，其中綠色代表完全覆寫，黃色代表部分覆寫（一些指令或者分支未覆寫），紅色代表未覆寫，這些顏色也支持用戶自定義，針對覆寫結果的匯出，JaCoCo支持HTML，XML，CSV等檔案格式，用戶也可以在Eclipse內進行查看，
圖表 3 JaCoCo覆寫率展示界面
圖表 4 JaCoCo在原始碼端的覆寫率展示
四、應用局限性
JaCoCo天生缺陷的內核設計和定位，帶來了應用的局限，作為一款熱門開源工具，雖然被愛好者們在小范圍及初步資訊判斷中使用較多，但是卻因為大量的誤差，不能被應用更大、更復雜的大型核心系統上，否則用戶可能將面臨著很大的技術風險，
覆寫率誤差：JaCoCo的插裝程序具有一定的技術局限性，其裝點并非明文可見，存在大量的資訊差，發表在IEEE上的文章：“Negative effects of bytecode instrumentation on Java source code coverage”，對JaCoCo的誤差情況以及可能原因進行了詳盡的評估與分析[2]，
JaCoCo與標準基線對比結果顯示：針對不同的專案，在類（Method）層級，JaCoCo的覆寫率評估就已產生了0.2%-8.5%左右的絕對誤差和0.7%-23.859%的相對誤差，在更細化的陳述句行和分支層級，其誤差將會被指數級放大，
表格 2 JaCoCo覆寫率評估的相對誤差[2]
誤差產生的具體成因：
- 復雜系統通常由大量子模塊組成，JaCoCo無法實作對于內部被呼叫的子模塊進行插裝，因此對于子模塊覆寫率的評估會產生顯著的誤差，
- 如果某個子模塊沒有被呼叫，那么對于JaCoCo來說，該模塊內的方法等同于不存在，JaCoCo需要呼叫該子模塊，才能將該子模塊內的代碼計入覆寫率計算的“分母”，
- 除了幾種既定的邏輯意外事件，JaCoCo無法正確處理例外情況（Exception），如果在控制流程中遇到Exception，JaCoCo會把這種情況直接標記為未覆寫，這種判定方式直接的影響到了對程式邏輯關系的把控，造成對于覆寫率無法準確評估，
誤差引發的后果：
- 偽瓶頸的產生，以及對測驗質量的錯誤高估，第一種情況，測驗人員投入大量作業之后，卻無法進一步提升覆寫率，造成對資源和實踐的浪費；第二種情況，會讓用戶誤將未達標的系統判定為達標，有可能引發嚴重的生產事故，
- 無法實作缺陷定位，大量的演算法和應用依托覆寫率的輸入，而缺陷定位更是其中最主要的實踐，
- 回歸測驗的精準度，受到了嚴重的影響，
五、對接能力分析
JaCoCo對于Ant和Maven有較完整的插件支持啟動方案，但是只能和Eclipse或者SonarCube集成，無法實作和測驗管理軟體，或是上下游測驗工具的完整對接，
對于開發流程，JaCoCo依然是傳統白盒測驗的思維，即瀑布式的開發模式，需要在代碼更新后重新進行測驗，每次版本迭代的作業量都十分龐大，
自動化層面，JaCoCo支持與Jenkins的對接，
六、結語
JaCoCo能夠有效的在位元組碼層級提供覆寫率的初步評估和計算，并且有實作從位元組碼關聯到原始碼的能力，但是，JaCoCo只是一款提供粗略評估工具，無法自動關聯用例、無法有效提升測驗效率，沒有作為測驗中臺的對接和支持能力，JaCoCo的定位和實踐，表明其更適用于偏向輔助個人開發者和小型專案組對專案覆寫率進行非常基礎的評估，對于支撐大型企業級應用的精準測驗需求，依然路途漫長，
參考文獻：
[1] N. Li, X. Meng, J. Offutt, and L. Deng, “Is bytecode instrumentation as good as source code instrumentation: An empirical study with industrial tools (Experience Report),” 2013 IEEE 24th Int. Symp. Softw. Reliab. Eng. ISSRE 2013, pp. 380–389, 2013, doi: 10.1109/ISSRE.2013.6698891.
[2] D. Tengeri, F. Horváth, á. Beszédes, T. Gergely, and T. Gyimóthy, “Negative effects of bytecode instrumentation on Java source code coverage,” 2016 IEEE 23rd Int. Conf. Softw. Anal. Evol. Reengineering, SANER 2016, vol. 1, pp. 225–235, 2016, doi: 10.1109/SANER.2016.61.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/343931.html
標籤：其他