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