背景
隨着業務增加, 隨之而來的前端需求激增, 如何在有限的時間內保證前端代碼的質量. 經過測試同窗單方面的保障, 仍是免不了前端線上問題, 存在迴歸不到位或者測試遺漏的地方, 同時測試質量的高低沒有客觀數據可量化.<br/> 經過單測方法補充, 能夠提早發現一部分問題, 減小問題解決的成本, 可是因爲業務形態的緣由, 需求變動頻繁, 功能迭代快, 補充和維護單測的成本比較高, 在業務方的大部分前端工程中暫時沒有單測方法, 所以開發在自測時, 感知比較薄弱, 無量化數據, 在項目提測前也沒有統一指標能夠把關, 測試對開發的自測情況也不瞭解;<br/> 同時前端缺乏像jacoco這樣的集成測試覆蓋率統計框架, 沒法經過集成測試收集覆蓋率, 對於測試階段的質量仍然沒有數據量化 結合上面說的幾點, 咱們提出了前端集成測試覆蓋率統計工具的須要, 以此來提高開發自測質量以及項目提測質量, 同時幫助補充迴歸不到位或測試遺漏的場景, 提高上線質量.html
技術選型
首先, 覆蓋率收集的前提, 須要完成代碼插樁工做, 插樁方法來自於兩個開源覆蓋率統計框架, istanbul.js以及istanbul-middleware (如下稱im) , 提供了若干個插樁方法, 而im其實也是在istanbul.js的基礎上作了封裝, 能力來自於istanbul-lib-instrument 全部的插樁方法, 大體分爲兩種類型 —— 一、運行前插樁 二、運行時插樁前端
####運行前插樁 nyc instrument <br/> 針對編譯以後的JS文件 , 進行手動插樁 , 造成插樁後的新JS文件 <br/><br/> babel-plugin-istanbul <br/> istanbul提供的babel插件 , 可以在代碼編譯打包階段直接植入插樁代碼 適用於使用babel的前端工程，基於react和vue的工程均可以vue
####運行時插樁 im.hookLoader <br/> 適用於服務端的文件掛載 好比node應用 當應用啓動時 , 會在require入口處添加hook方法 , 使得應用啓動時加載到的都是插樁後的代碼<br/><br/> im.createClientHandler <br/> 適用於客戶端的JS掛載 ，好比react和vue的js 經過指定root路徑，會把全部該路徑的js文件請求攔截，返回插樁後的代碼，即瀏覽器請求靜態資源的動做 效果與babel-plugin-istanbul相似，區別在於該方法是在瀏覽器請求js時纔會返回插樁代碼，是一個動態過程node
| 插樁方式 | 功能 | 優點 | 劣勢 |
|---|---|---|---|
| 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-istanbulreact
模塊設計
主要分爲三個模塊 , 先經過代碼插樁得到可追蹤的代碼 , 而後實時上報用戶行爲產生的代碼行覆蓋記錄 , 最後呈現覆蓋率相關信息.git
代碼插樁
<br/>Client端 使用babel-plugin-istanbul插件, 在babel編譯階段便可完成chrome
Node端 <br/> 依賴istanbuljs提供的能力 - istanbul-lib-hook 、istanbul-lib-instrument 重寫istanbulMiddleware.hookLoader方法 , node啓動前掛載文件 , 會在require方法前增長鉤子函數, 增長代碼插樁express
插樁結果舉例 <br/> 瀏覽器
被插樁的JS 會新增一個coverage方法, 維護並指向覆蓋率信息歸屬, 並用來獲取該文件的覆蓋率信息 同時該js中的方法在執行過程的路徑上會留下標記, 被執行到以後實時更新覆蓋率信息中相對應的行或者塊信息babel
###數據上報
<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%以上(目前的增量只到文件維度 , 未到行維度), 未覆蓋的行主要包括四種: 異常捕獲、防護性編碼、非本次新增無需關心的代碼以冗餘代碼 , 屬於可容許的範圍.
原文出處：https://www.cnblogs.com/YZ-coder/p/11576872.html