有贊前端質量保障體系

前言

最近一年多一直在作前端的一些測試，從小程序到店鋪裝修，基本都是純前端的工做，剛開始從後端測試轉爲前端測試的時候，對前端東西茫然無感，並且團隊內沒有人作過純前端的測試工做，只能一邊踩坑一邊總結經驗，而後將容易出現問題的點造成體系、不斷總結摸索，最終造成了目前的一套前端測試解決方案。在此，將有讚的前端質量保障體系進行總結，但願和你們一塊兒交流。

先來全局看下有贊前端的技術架構和針對每一個不一樣的層次，主要作了哪些保障質量的事情：

有讚的 Node 技術架構分爲業務層、基礎框架層、通用組件和基礎服務層，咱們平常比較關注的是基礎框架、通用組件和業務層代碼。Node 業務層作了兩件事情，一是提供頁面渲染的 client 層，用於和 C 端用戶交互，包括樣式、行爲 js 等；二是提供數據服務的 server 層，用於組裝後臺提供的各類接口，完成面向 C 端的接口封裝。

對於每一個不一樣的層，咱們都作了一些事情來保障質量，包括：

• 針對整個業務層的 UI 自動化、核心接口|頁面撥測；
• 針對 client 層的 sentry 報警；
• 針對 server 層的接口測試、業務報警；
• 針對基礎框架和通用組件的單元測試；
• 針對通用組件變動的版本變動報警；
• 針對線上發佈的流程規範、用例維護等。

下面就來分別講一下這幾個維度的質量保障工做。

1、UI自動化

不少人會認爲，UI 自動化維護成本高、性價比低，可是爲何在有讚的前端質量保證體系中放在了最前面呢？

前端重用戶交互，單純的接口測試、單元測試不能真實反映用戶的操做路徑，而且從以往的經驗中總結得出，由於各類不可控因素致使的發佈 A 功能而 B 功能沒法使用，特別是核心簡單場景的不可用時有出現，因此每次發佈一個應用前，都會將此應用提供的核心功能執行一遍，那隨着業務的不斷積累，須要迴歸的測試場景也愈來愈多，致使迴歸的工做量巨大。爲了下降人力成本，咱們亟需經過自動化手段釋放勞動力，因此將核心流程迴歸的 UI 自動化提到了最核心地位。

固然，UI 自動化的最大痛點確實是維護成本，爲下降維護成本，咱們將頁面分爲組件維度、頁面維度，並提供統一的包來處理公用組件、特殊頁面的通用邏輯，封裝通用方法等，例如初始化瀏覽器信息、環境選擇、登陸、多網點切換、點擊、輸入、獲取元素內容等等，業務迴歸用例只須要關注本身的用例操做步驟便可。

1.框架選擇

-- puppeteer^[1]，它是由 Chrome 維護的 Node 庫，基於 DevTools 協議來驅動 chrome 或者 chromium 瀏覽器運行，支持 headless 和 non-headless 兩種方式。官網提供了很是豐富的文檔，簡單易學。

UI 自動化框架有不少種，包括 selenium、phantom；對比後發現 puppeteer 比較輕量，只須要增長一個 npm 包便可使用；它是基於事件驅動的方式，比 selenium 的等待輪詢更妥當、性能更佳；另外，它是 chrome 原生支持，能提供全部 chrome 支持的 api，同時咱們的業務場景只須要覆蓋 chrome，因此它是最好的選擇。

-- mocha^[2] + mochawesome^[3]，mocha 是比較主流的測試框架，支持 beforeEach、before、afterEach、after 等鉤子函數，assert 斷言，測試套件，用例編排等。
mochawesome 是 mocha 測試框架的第三方插件，支持生成漂亮的 html/css 報告。

js 測試框架一樣有不少能夠選擇，mocha、ava、Jtest 等等，選擇 mocha 是由於它更靈活，不少配置能夠結合第三方庫，好比 report 就是結合了 mochawesome 來生成好看的 html 報告；斷言能夠用 powser-assert 替代。

2.腳本編寫

• 封裝基礎庫

  • 封裝 pc 端、h5 端瀏覽器的初始化過程
  • 封裝 pc 端、h5 端登陸統一處理
  • 封裝頁面模型和組件模型
  • 封裝上傳組件、日期組件、select 組件等的統一操做方法
  • 封裝 input、click、hover、tap、scrollTo、hover、isElementShow、isElementExist、getElementVariable 等方法
  • 提供根據 「html 標籤>>頁面文字」 形式獲取頁面元素及操做方法的統一支持
  • 封裝 baseTest，增長用例開始、結束後的統一操做
  • 封裝 assert，增長斷言日誌記錄

• 業務用例

  • 安裝基礎庫
  • 編排業務用例

3.執行邏輯

• 分環境執行

  • 增長預上線環境代碼變動觸發、線上環境自動執行

• 監控源碼變動

  • 增長 gitlab webhook，監控開發源碼合併 master 時自動在預上線環境執行
  • 增長 gitlab webhook，監控測試用例變動時自動在生產環境執行

• 每日定時執行

  • 增長 crontab，每日定時執行線上環境

QF6)

2、接口測試

接口測試主要針對於 Node 的 server 層，根據咱們的開發規範，Node 不作複雜的業務邏輯，可是須要將服務化應用提供 dubbo 接口進行一次轉換，或將多個 dubbo 接口組合起來，提供一個可供 h5/小程序渲染數據的 http 接口，轉化過程就帶來了各類數據的獲取、組合、轉換，造成了新的端到端接口。這個時候單單靠服務化接口的自動化已經不能保障對上層接口的全覆蓋，因此咱們針對 Node 接口也進行自動化測試。爲了使用測試內部統一的測試框架，咱們經過 java 去請求 Node 提供的 http 接口，那麼當用例都寫好以後，該如何評判接口測試的質量？是否徹底覆蓋了所有業務邏輯呢？此時就須要一個行之有效的方法來獲取到測試的覆蓋狀況，以檢查有哪些場景是接口測試中未覆蓋的，作到更好的查漏補缺。

istanbul^[4] 是業界比較易用的 js 覆蓋率工具，它利用模塊加載的鉤子計算語句、行、方法和分支覆蓋率，以便在執行測試用例時透明的增長覆蓋率。它支持全部類型的 js 覆蓋率，包括單元測試、服務端功能測試以及瀏覽器測試。

可是，咱們的接口用例寫在 Java 代碼中，經過 Http 請求的方式到達 Node 服務器，非 js 單測，也非瀏覽器功能測試，如何才能獲取到 Node 接口的覆蓋率呢？

解決辦法是增長 cover 參數：--handle-sigint，經過增長 --handle-sigint 參數啓動服務，當服務接收到一個 SIGINT 信號（linux 中 SIGINT 關聯了 Ctrl+C），會通知 istanbul 生成覆蓋率。這個命令很是適合咱們，而且所以造成了咱們接口覆蓋率的一個模型：

1. istanbule --handle-sigint 啓動服務
2. 執行測試用例
3. 發送 SIGINT結束istanbule，獲得覆蓋率

最終，解決了咱們的 Node 接口覆蓋率問題，並經過 jenkins 持續集成來自動構建

固然，在獲取覆蓋率的時候有需求文件是不須要統計的，能夠經過在根路徑下增長 .istanbule.yml 文件的方式，來排除或者指定須要統計覆蓋率的文件

verbose: false
instrumentation:
    root: .
    extensions:
        - .js
    default-excludes: true
    excludes:['**/common/**','**/app/constants/**','**/lib/**']
    embed-source: false
    variable: __coverage__
    compact: true
    preserve-comments: false
    complete-copy: false
    save-baseline: false
    baseline-file: ./coverage/coverage-baseline.json
    include-all-sources: false
    include-pid: false
    es-modules: false
reporting:
    print: summary
    reports:
        - lcov
    dir: ./coverage
    watermarks:
        statements: [50, 80]
        lines: [50, 80]
        functions: [50, 80]
        branches: [50, 80]
    report-config:
        clover: {file: clover.xml}
        cobertura: {file: cobertura-coverage.xml}
        json: {file: coverage-final.json}
        json-summary: {file: coverage-summary.json}
        lcovonly: {file: lcov.info}
        teamcity: {file: null, blockName: Code Coverage Summary}
        text: {file: null, maxCols: 0}
        text-lcov: {file: lcov.info}
        text-summary: {file: null}
hooks:
    hook-run-in-context: false
    post-require-hook: null
    handle-sigint: false
check:
    global:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []
    each:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []

3、單元測試

單元測試在測試分層中處於金字塔最底層的位置，單元測試作的比較到位的狀況下，能過濾掉大部分的問題，而且提前發現 bug，也能夠下降 bug 成本。推行一段時間的單測後發現，在有讚的 Node 框架中，業務層的 server 端只作接口組裝，client 端面向瀏覽器，都不太適合作單元測試，因此咱們只針對基礎框架和通用組件進行單測，保障基礎服務能夠經過單測排除大部分的問題。好比基礎框架中店鋪通用信息服務，單測檢查店鋪信息獲取；好比頁面級商品組件，單測檢查商品組件渲染的 html 是否和原來一致。

單測方案試行了兩個框架：

• Jest^[5]
• ava^[6]

比較推薦的是 Jest 方案，它支持 Matchers 方式斷言；支持 Snapshot Testing，可測試組件類代碼渲染的 html 是否正確；支持多種 mock，包括 mock 方法實現、mock 定時器、mock 依賴的 module 等；支持 istanbule，能夠方便的獲取覆蓋率。

總之，前端的單測方案也愈來愈成熟，須要前端開發人員更加關注 js 單測，將 bug 扼殺在搖籃中。

4、基礎庫變動報警

上面咱們已經對基礎服務和基礎組件進行了單元測試，可是單測也不能徹底保證基礎庫的變動徹底沒有問題，伴隨着業務層引入新版本的基礎庫，bug 會進一步帶入到業務層，最終影響 C 端用戶的正常使用。那如何保障每次業務層引入新版本的基礎庫以後能作到全面的迴歸？如何讓業務測試同窗對基礎庫變動更加敏感呢？針對這種狀況，咱們着手作了一個基礎庫版本變動的小工具。實現思路以下：

1. 對比一次 master 代碼的提交或 merge 請求，判斷 package.json 中是否有特定基礎庫版本變動
2. 將對應基礎庫的先後兩個版本的代碼對比發送到測試負責人
3. 根據 changelog 判斷這次迴歸的用例範圍
4. 增長 gitlab webhook，只有合併到合併發佈分支或者 master 分支的代碼才觸發檢查

這個小工具的引入能及時通知測試人員針對什麼需求改動了基礎組件，以及此次基礎組件的升級主要影響了哪些方面，這樣能避免相對黑盒的測試。

初版實現了最簡功能，後續再深挖需求，能夠作到前端代碼變動的精準測試。

5、sentry報警

在剛接觸前端測試的時候，js 的報錯沒有任何追蹤，對於排查問題和定位問題有很大困擾。所以咱們着手引入了 sentry 報警監控，用於監控線上環境 js 的運行狀況。

sentry^[7] 是一款開源的錯誤追蹤工具，它能夠幫助開發者實時監控和修復崩潰。

開始咱們接入的方式比較簡單粗暴，直接全局接入，帶來的問題是報警信息很是龐大，全局上報後 info、warn 信息都會打出來。

更改後，使用 sentry 的姿式是：

• sentry 的全局信息上報，並進行篩選

  • 錯誤類型: TypeError 或者 ReferenceError
  • 錯誤出現用戶 > 1k
  • 錯誤出如今 js 文件中
  • 出現錯誤的店鋪 > 2家
• 增長核心業務異常流程的主動上報

最終將篩選後的錯誤信息經過郵件的形式發送給告警接收人，在固定的時間集中修復。

6、業務報警

除了 sentry 監控報警，Node 接口層的業務報警一樣是必不可少的一部分，它能及時發現 Node 提供的接口中存在的業務異常。這部分是開發和運維同窗作的，包括在 Node 框架底層接入日誌系統；在業務層正確的上報錯誤級別、錯誤內容、錯誤堆棧信息；在日誌系統增長合理的告警策略，超過閾值以後短信、電話告警，以便於及時發現問題、排查問題。

業務告警是最能快速反應生產環境問題的一環，若是某次發佈以後發生告警，咱們第一時間選擇回滾，以保證線上的穩定性。

7、約定規範

除了上述的一些測試和告警手段以外，咱們也作了一些流程規範、用例維護等基礎建設，包括：

• 發佈規範

  • 多個平常分支合併發佈
  • 限制發佈時間
  • 規範發佈流程
  • 整理自測核心檢查要點

• 基線用例庫

  • 不一樣業務 P0 核心用例按期更新
  • 項目用例按期更新到業務迴歸用例庫
  • 線上問題場景及時更新到迴歸用例庫

目前有讚的前端測試套路基本就是這樣，固然有些平時的努力沒有徹底展開，例如接口測試中增長返回值結構體對比；增長線上接口或頁面的撥測^[8]；給開發進行自測用例設計培訓等等。也還有不少新功能探索中，如接入流量對比引擎，將線上流量導到預上線環境，在代碼上線前進行對比測試；增長UI自動化的截圖對比；探索小程序的UI自動化等等。

參考連接：

• [1] https://github.com/GoogleChro...
• [2] https://www.npmjs.com/package...
• [3] https://www.npmjs.com/package...
• [4] https://github.com/gotwarlost...
• [5] https://github.com/facebook/jest
• [6] https://github.com/avajs/ava
• [7] https://docs.sentry.io
• [8] https://tech.youzan.com/youza...