背景
隨著業務增長, 隨之而來的前端需求激增, 如何在有限的時間內保證前端程式碼的質量.
通過測試同學單方面的保障, 還是免不了前端線上問題, 存在迴歸不到位或者測試遺漏的地方, 同時測試質量的高低沒有客觀資料可量化.<br/>
通過單測方法補充, 可以提前發現一部分問題, 減少問題解決的成本, 但是由於業務形態的原因, 需求變更頻繁, 功能迭代快, 補充和維護單測的成本比較高, 在業務方的大部分前端工程中暫時沒有單測方法, 因此開發在自測時, 感知比較薄弱, 無量化資料, 在專案提測前也沒有統一指標可以把關, 測試對開發的自測狀況也不瞭解;<br/>
同時前端缺少像jacoco這樣的整合測試覆蓋率統計框架, 無法通過整合測試收集覆蓋率, 對於測試階段的質量仍然沒有資料量化
結合上面說的幾點, 我們提出了前端整合測試覆蓋率統計工具的需要, 以此來提升開發自測質量以及專案提測質量, 同時幫助補充迴歸不到位或測試遺漏的場景, 提升上線質量.
技術選型
首先, 覆蓋率收集的前提, 需要完成程式碼插樁工作, 插樁方法來自於兩個開源覆蓋率統計框架, istanbul.js以及istanbul-middleware (以下稱im) , 提供了若干個插樁方法, 而im其實也是在istanbul.js的基礎上做了封裝, 能力來自於istanbul-lib-instrument
所有的插樁方法, 大致分為兩種型別 —— 1、執行前插樁 2、執行時插樁
執行前插樁
nyc instrument <br/>
針對編譯之後的JS檔案 , 進行手動插樁 , 形成插樁後的新JS檔案 <br/><br/>
babel-plugin-istanbul <br/>
istanbul提供的babel外掛 , 能夠在程式碼編譯打包階段直接植入插樁程式碼
適用於使用babel的前端工程，基於react和vue的工程都可以
執行時插樁
im.hookLoader <br/>
適用於服務端的檔案掛載 比如node應用
當應用啟動時 , 會在require入口處新增hook方法 , 使得應用啟動時載入到的都是插樁後的程式碼<br/><br/>
im.createClientHandler <br/>
適用於客戶端的JS掛載 ，比如react和vue的js
通過指定root路徑，會把所有該路徑的js檔案請求攔截，返回插樁後的程式碼，即瀏覽器請求靜態資源的動作
效果與babel-plugin-istanbul類似，區別在於該方法是在瀏覽器請求js時才會返回插樁程式碼，是一個動態過程
| 插樁方式 | 功能 | 優勢 | 劣勢 |
|---|---|---|---|
| nyc | 本地手動插樁源js檔案, 生成插樁後檔案 | 編譯後的js都可手動插樁, 不限工程框架 | 手動插樁後的檔案需要自己上傳, 對原打包釋出流程有影響; 不適用於服務端插樁 |
| babel-plugin-istanbul | 在babel編譯時 , 自動生成插樁程式碼 | 改造成本低 , 自動插樁快捷 | 限定於使用babel的工程 |
| im.hookLoader | require入口處新增鉤子方法，返回已插樁程式碼 | 改造成本低 , 自動插樁快捷 | 僅適用於服務端插樁 |
| im.createClientHandler | 攔截瀏覽器請求靜態資原始檔的GET方法, 返回插樁後的JS | 自動插樁 , 無須改造原打包流程和指令碼 | 僅適用於客戶端插樁; 該方法基於express, 限定於使用express的工程 |
最後我們所使用的插樁方法
App（node）—— istanbulMiddleware.hookLoader
Client（react & vue）—— babel-plugin-istanbul
模組設計
主要分為三個模組 , 先通過程式碼插樁獲得可追蹤的程式碼 , 然後實時上報使用者行為產生的程式碼行覆蓋記錄 , 最後呈現覆蓋率相關資訊.
程式碼插樁
<br/>Client端
使用babel-plugin-istanbul外掛, 在babel編譯階段即可完成
Node端 <br/>
依賴istanbuljs提供的能力 - istanbul-lib-hook 、istanbul-lib-instrument
重寫istanbulMiddleware.hookLoader方法 , node啟動前掛載檔案 , 會在require方法前增加鉤子函式, 增加程式碼插樁
插樁結果舉例 <br/>
被插樁的JS 會新增一個coverage方法, 維護並指向覆蓋率資訊歸屬, 並用來獲取該檔案的覆蓋率資訊
同時該js中的方法在執行過程的路徑上會留下標記, 被執行到之後實時更新覆蓋率資訊中相對應的行或者塊資訊
資料上報
<br/>Node端
應用釋出時 , 寫入對應的工程和分支資訊 , 建立定時器 , 實時上傳_global.coverage變數 , 即覆蓋率資訊
<br/>Client端
客戶端的上報比較特殊 , 客戶端不像服務端 , 在釋出後可以全域性保持coverage變數以及定時器方法 , client端所有的資料生成和消耗都跟隨頁面的生命週期 , 所以不太可控 , 因此需要一個額外容器進行處理 , 我們選擇了通過chrome外掛來上報 , 通過全域性管理覆蓋率資訊物件 , 以及通知下發來實現上報流程 . 該外掛詳細的工作流程如下
覆蓋率服務端 <br/>
- 繼承istanbul middleware的功能<br/>
- 支援分支維度接收和查詢覆蓋率<br/>
- 程式碼變更時覆蓋率替換, 支援儲存和檢視歷史版本
主要基於istanbul-middleware做了二次開發 , 擴充套件了istanbulMiddleware.createHandler方法
/:ns/:repo /:ns/:repo/show
兩個覆蓋率展示介面 新增了ns、repo、branch三個入參, 用來區別不同的覆蓋率
同時增加額外引數history 傳入該變數 標誌獲取的是歷史覆蓋率
/client/:ns/:repo?branch={}&source={} body攜帶覆蓋率資訊
根據應用和分支資訊上報 接收到上報資訊之後 會先獲取該分支下的已有覆蓋率 然後和此次上報的資訊做合併
合併是根據檔名字遍歷合併的 如果發現某個檔案 新舊兩份覆蓋率結構不同
即發生了程式碼變更 則會丟棄舊的覆蓋率 以新覆蓋率為準 同時把舊的覆蓋率儲存到歷史版本中
頁面展示
<br/>全量覆蓋率展示
使用istanbulmiddle原生報告生成
增量覆蓋率展示<br/>
通過gitlab介面對比master差異 , 分檔案展示各自的覆蓋率 , 同全量覆蓋率 , 只是細化了 , 整體頁面用vue + muse-ui完成
<center>以master分支為基準, 增量檔案覆蓋率</center>
<center>全量檔案覆蓋率目錄結構</center>
工作流程
主要分為3部分 , 對應上一節說的接入 、上報 、展示
通過babel外掛完成客戶端程式碼插樁 , 提供給node端使用的插樁外掛 , 可以一步完成服務端的程式碼插樁以及定時上報功能
配合提供的chrome外掛 , 完成客戶端的覆蓋率上報任務
覆蓋率服務端負責資訊的接收和儲存 , 並返回給前端資料資訊
前端負責資料資訊展示
業務實踐
接入測試環境釋出平臺, 實現以應用和分支維度的多版本實時覆蓋率收集和展示功能 , 無縫對接專案測試環境 , 專案中各應用釋出後 , 自動開啟覆蓋率上報 , 在專案測試過程中實時記錄 , 可實時檢視. 在專案提測前 , 給予開發量化指標 , 專案測試結束後可以給出最終覆蓋率資料 , 幫助測試同學檢查以及完善未覆蓋的功能.<br/>
目前在電商教育和行業兩條業務線中已有接入,由於該工具限制在qa環境使用 , 僅限收集在qa環境測試的專案資料. 在功能測試階段，從使用資料上來看 , 增量行程式碼覆蓋率達到80%以上(目前的增量只到檔案維度 , 未到行維度), 未覆蓋的行主要包括四種: 異常捕獲、防禦性編碼、非本次新增無需關心的程式碼以冗餘程式碼 , 屬於可允許的範圍.