作者：京東云質量部
背景
隨著前端技術發展，已經轉變為資料系結為主流的框架方式，與后端服務一樣，前端代碼實作也會涉及相互依賴，參考這些場景，那么應該如何準確的評估前端代碼改動的影響范圍？依賴開發評估？依靠經驗評估？或者直接前端自動化全回歸？手工測驗全回歸？顯然以上的策略都不是最優策略，本文敘述了通過對前端代碼進行靜態分析，找到改動檔案影響的功能范圍，從實作了一種前端精準測驗的思路，
如何進行精準分析
前端對外可直接感知的就是頁面，最終目標是要確定影響哪個功能，整個前端精準測驗劃分為4步：
第一步，確定影響的頁面，
第二步，確定影響的功能，
第三步，根據分析結果，找到對應的自動化用例集合，并觸發運行
第四步，對比前端代碼增量覆寫率，確認改動覆寫完成
前端頁面與路由直接相關，從路由入手，建立路由與展示頁面的關系，再依據入口檔案的import關系，建立前端代碼檔案依賴樹，再通過git diff對比找到改動的檔案，從而反查到影響的前端頁面，
精準分析實作
設計思路
決議路由檔案，建立路由檔案中每個選單的依賴樹，從而根據改動檔案反查影響頁面
實作邏輯
鑒于上述設計思路，結合目前技術支撐現狀及快速實驗的目標，開發了前端精準分析的第一版方案，
（路由檔案分析暫時未找到規律，且實際場景中，路由檔案變更不會頻繁，維護成本不高，所以此步驟暫由人工維護）
關鍵邏輯：檔案依賴樹的分析及存盤
應用
webhook自動觸發分析
在代碼平臺上配置webhook觸發分析介面，即可實作代碼提交，自動觸發分析
平臺手動觸發分析
規劃
目前平臺僅僅實作了前端精準測驗4步中第一步的80%（路由與入口檔案的關聯還未實作自動分析），推薦僅僅到了頁面級別，還未達到按鈕級別，此處還需要再研究一下前端開發的相關技術，找到自動決議路由的方法，第二步計劃嘗試借助istanbul前端覆寫率工具，做一下增量覆寫率對比，保證手動回歸可覆寫改動，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/539414.html
標籤：其他