前端精準測試探索：覆蓋率實時統計工具

背景

隨著業務增長，隨之而來的前端需求激增，如何在有限的時間內保證前端代碼的質量。通過測試同學單方面的保障，還是免不了前端線上問題，存在回歸不到位或者測試遺漏的地方，同時測試質量的高低沒有客觀數據可量化。

通過單測方法補充，可以提前發現一部分問題，減少問題解決的成本，但是由于業務形態的原因， 需求變更頻繁，功能迭代快，補充和維護單測的成本比較高， 在業務方的大部分前端工程中暫時沒有單測方法，因此開發在自測時， 感知比較薄弱，無量化數據， 在項目提測前也沒有統一指標可以把關，測試對開發的自測狀況也不了解。

同時前端缺少像 jacoco 這樣的集成測試覆蓋率統計框架，無法通過集成測試收集覆蓋率，對于測試階段的質量仍然沒有數據量化。

結合上面說的幾點，我們提出了前端集成測試覆蓋率統計工具的需要，以此來提升開發自測質量以及項目提測質量，同時幫助補充回歸不到位或測試遺漏的場景，提升上線質量。

一、技術選型

首先，覆蓋率收集的前提，需要完成代碼插樁工作，插樁方法來自于兩個開源覆蓋率統計框架，istanbul.js 以及 istanbul-middleware (以下稱 im)，提供了若干個插樁方法，而 im 其實也是在 istanbul.js 的基礎上做了封裝, 能力來自于 istanbul-lib-instrument

所有的插樁方法，大致分為兩種類型：

• 運行前插樁
• 運行時插樁

1.1 運行前插樁

nyc instrument

針對編譯之后的 JS 文件 , 進行手動插樁 , 形成插樁后的新 JS 文件。

babel-plugin-istanbul

istanbul 提供的 babel 插件 , 能夠在代碼編譯打包階段直接植入插樁代碼。適用于使用 babel 的前端工程，基于 react 和 vue 的工程都可以。

1.2 運行時插樁

im.hookLoader：適用于服務端的文件掛載 比如 node 應用。

當應用啟動時，會在 require 入口處添加 hook 方法，使得應用啟動時加載到的都是插樁后的代碼。

im.createClientHandler：適用于客戶端的 JS 掛載，比如 react 和 vue 的 js。

通過指定 root 路徑，會把所有該路徑的 js 文件請求攔截，返回插樁后的代碼，即瀏覽器請求靜態資源的動作。效果與 babel-plugin-istanbul 類似，區別在于該方法是在瀏覽器請求 js 時才會返回插樁代碼，是一個動態過程。

最后我們所使用的插樁方法：

App（node）—— istanbulMiddleware.hookLoader

Client（react & vue）—— babel-plugin-istanbul

二、模塊設計

主要分為三個模塊，先通過代碼插樁獲得可追蹤的代碼，然后實時上報用戶行為產生的代碼行覆蓋記錄，最后呈現覆蓋率相關信息。

2.1 代碼插樁

Client 端：使用 babel-plugin-istanbul 插件，在 babel 編譯階段即可完成。

Node 端：依賴 istanbuljs 提供的能力 - istanbul-lib-hook 、istanbul-lib-instrument

重寫 istanbulMiddleware.hookLoader 方法，node 啟動前掛載文件，會在 require 方法前增加鉤子函數，增加代碼插樁。

插樁結果舉例：

被插樁的 JS 會新增一個 coverage 方法，維護并指向覆蓋率信息歸屬，并用來獲取該文件的覆蓋率信息。

同時該 JS 中的方法在執行過程的路徑上會留下標記，被執行到之后實時更新覆蓋率信息中相對應的行或者塊信息。

2.2 數據上報

Node 端：應用發布時，寫入對應的工程和分支信息，創建定時器，實時上傳 _global.coverage 變量，即覆蓋率信息。

Client 端：客戶端的上報比較特殊，客戶端不像服務端，在發布后可以全局保持 coverage 變量以及定時器方法，client 端所有的數據生成和消耗都跟隨頁面的生命周期，所以不太可控，因此需要一個額外容器進行處理，我們選擇了通過 chrome 插件來上報，通過全局管理覆蓋率信息對象，以及通知下發來實現上報流程。該插件詳細的工作流程如下：

覆蓋率服務端

• 繼承 istanbul middleware 的功能
• 支持分支維度接收和查詢覆蓋率
• 代碼變更時覆蓋率替換, 支持存儲和查看歷史版本

主要基于 istanbul-middleware 做了二次開發，擴展了 istanbulMiddleware.createHandler 方法：

/:ns/:repo /:ns/:repo/show

兩個覆蓋率展示接口，新增了 ns、repo、branch 三個入參，用來區別不同的覆蓋率

同時增加額外參數 history 傳入該變量，標志獲取的是歷史覆蓋率。

/client/:ns/:repo?branch={}&source={} body

攜帶覆蓋率信息，根據應用和分支信息上報，接收到上報信息之后，會先獲取該分支下的已有覆蓋率，然后和此次上報的信息做合并。

合并是根據文件名字遍歷合并的。如果發現某個文件新舊兩份覆蓋率結構不同，即發生了代碼變更，則會丟棄舊的覆蓋率，以新覆蓋率為準，同時把舊的覆蓋率存儲到歷史版本中。

2.3 頁面展示

全量覆蓋率展示：使用 istanbulmiddle 原生報告生成。

增量覆蓋率展示：通過 gitlab 接口對比 master 差異，分文件展示各自的覆蓋率，同全量覆蓋率，只是細化了，整體頁面用 vue + muse-ui 完成。

三、工作流程

主要分為 3 部分：對應上一節說的接入 、上報 、展示。

通過 babel 插件完成客戶端代碼插樁，提供給 node 端使用的插樁插件，可以一步完成服務端的代碼插樁以及定時上報功能。

配合提供的 chrome 插件，完成客戶端的覆蓋率上報任務。

覆蓋率服務端負責信息的接收和存儲，并返回給前端數據信息。

前端負責數據信息展示。

四、業務實踐

接入測試環境發布平臺，實現以應用和分支維度的多版本實時覆蓋率收集和展示功能，無縫對接項目測試環境，項目中各應用發布后，自動開啟覆蓋率上報，在項目測試過程中實時記錄，可實時查看。在項目提測前，給予開發量化指標，項目測試結束后可以給出最終覆蓋率數據，幫助測試同學檢查以及完善未覆蓋的功能。

目前在電商教育和行業兩條業務線中已有接入，由于該工具限制在 qa 環境使用，僅限收集在 qa 環境測試的項目數據。 在功能測試階段，從使用數據上來看，增量行代碼覆蓋率達到 80% 以上 (目前的增量只到文件維度 ，未到行維度)，未覆蓋的行主要包括四種: 異常捕獲、防御性編碼、非本次新增無需關心的代碼以冗余代碼，屬于可允許的范圍。

原文轉自：https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760043&idx=1&sn=cc6884ff2b87637e8d22369e6a9974b7&chksm=8c686a8ebb1fe39891cc3abe94dfb7fb2ffb74c7d3d13df45f7e9114e5ba92bde37a088ad96f