作者簡介

wr_zhang25，攜程資深前端開發工程師，關注前端代碼覆蓋率、JavaScript開源方向。

Liang， 攜程資深研發經理，質量專家，專注質量工程領域。

一、背景

istanbuljs 是一款優秀的JavaScript代碼覆蓋率工具，主要用于單元測試的代碼覆蓋率檢測和生成本地覆蓋率報告。然而，隨著現代前端技術和UI自動化測試的發展，對端到端測試的代碼覆蓋率檢測需求逐漸增加，istanbuljs提供的功能顯得捉襟見肘。

在攜程內部JavaScript代碼覆蓋率使用的是gitlab內置的coverage上報，也是只支持單元測試的覆蓋率收集和概覽數據展示。隨著攜程的前端技術日益精進，我們有了自己的前端流量錄制平臺，并且部署了相當大規模的模擬器集群進行UI自動化(flybirds)回放。這種場景下，需要對端到端測試的代碼覆蓋率進行收集和展示，以便開發同學更好的了解到自己的代碼質量。

傳統的istanbuljs提供的功能已經無法滿足我們的需求。我們需要處理UI自動化過程中來自前端高并發的覆蓋率上報，實時的覆蓋率聚合，以及覆蓋率數據的聚合展示。因此，我們在Istanbuljs的基礎上開發了Canyon，解決端到端測試覆蓋率難收集的問題。

目前，攜程的多個部門已經開始使用Canyon，并在持續集成流水線構建階段插入探針代碼，在UI自動化測試階段收集和上報覆蓋率數據。服務端實時生成詳盡的覆蓋率報告，為UI自動化測試用例提供全面的覆蓋率數據指標。

二、介紹

Canyon 通過簡單的 Babel 插件配置即可實現代碼插裝、覆蓋率上報和實時報告生成。其技術棧完全基于 JavaScript，只需 Node.js 環境即可運行，部署方便，適用于云原生環境的部署（如 Docker、Kubernetes）。

應用的架構設計適用于處理高頻、大規模的覆蓋率數據上報，能夠應對 UI 自動化測試中的各種場景。同時，Canyon 與現有的 CI/CD 工具（如 GitLab CI、Jenkins）無縫集成，使用戶能夠輕松地在持續集成流水線中使用。

架構圖如下：

下面會根據以下幾個部分來介紹 Canyon 的主要功能：

• 代碼覆蓋率
• 代碼插樁
• 測試與上報
• 覆蓋率聚合
• 覆蓋率報告
• 變更代碼覆蓋率
• react native 覆蓋率收集方案
• 覆蓋率提升優先級列表

三、代碼覆蓋率

隨著編寫更多的end-to-end測試case，你會發現有一些疑問，我需要寫更多的測試用例嗎？究竟還有哪些代碼沒測到？用例會不會重復了？這個時候代碼覆蓋率就派上用場了，它的原理是在代碼執行前將代碼探針插入到源代碼中（其實就是上下文加計數器），這樣每當case執行的時候就可以觸發其中的計數器。

在代碼中插入代碼探針的步驟稱為代碼插樁（instrument）。插樁前的代碼：

// add.js
function add(a, b) {
  return a + b
}
module.exports = { add }

插樁過程是對代碼解析以查找所有函數、語句和分支，然后將計數器插入代碼中。對于上面的代碼，插樁完成后：

// 這個對象用于計算每個函數和每個語句被執行的次數
const c = (window.__coverage__ = {
  // "f" 記錄每個函數被調用的次數
  f: [0],
  // "s" 記錄每個語句被調用的次數
  // 我們有3個語句，它們都從0開始
  s: [0, 0, 0],
})


// 第一個語句定義了函數
c.s[0]++
function add(a, b) {
  // 函數被調用后是第二個語句
  c.f[0]++
  c.s[1]++


  return a + b
}
// 第三個語句即將被調用
c.s[2]++
module.exports = { add }

我們希望確保文件中的每個語句和函數add.js都已被我們的測試至少執行一次。因此我們編寫一個測試：

// add.cy.js
const { add } = require('./add')


it('adds numbers', () => {
  expect(add(2, 3)).to.equal(5)
})

當測試調用時add(2, 3)，執行“add”函數內的計數器遞增，覆蓋范圍對象變為：

{
  f: [1],
  s: [1, 1, 1]
}

這個測試用例覆蓋率達到了100%，每個函數和每個語句都至少執行了一次。但是在實際應用中，要達到100%的代碼覆蓋率需要多次測試。

這是覆蓋率的基本介紹，有了這個前置知識，方便大家理解下面的內容。

四、代碼插樁（instrumenting-code）

代碼覆蓋率最重要的一環就是代碼插樁

istanbuljs 是久經沙場的js代碼插樁黃金標準。Canyon主要為端到端測試提供解決方案，經過大量的實驗驗證，現代化前端工程的覆蓋率插樁必須要編譯時插樁。具體原因是istanbuljs提供的nyc插樁工具只能對原生js進行插樁，然而前端模版語法層出不窮，例如ts、tsx、vue，雖然nyc也可以插樁，但是結構實踐證明直接插樁的覆蓋率效果不盡人意，無法精確到該插樁到的函數、語句、分支。

幸運的是經過調研，我們發現了babel-plugin-istanbul、vite-plugin-istanbul(experimental)、swc-plugin-coverage-instrument(experimental)。等類型工程的插樁解決方案。這些方案無一例外都是在前端工程編譯階段在將代碼分析成ast抽象語法樹的時候在適當時機進行插樁方法調用，更精確的插樁到的函數、語句、分支。

適用的工程類型：

用戶可以根據自己的工程類型選擇合適的插樁方案，只需要在工程中安裝對應的插件，然后就會在編譯時自動插樁。

以babel.config.js為例：

module.exports = {
  plugins: [
    [
      'babel-plugin-istanbul',
      {
        exclude: ['**/*.spec.js', '**/*.spec.ts', '**/*.spec.tsx', '**/*.spec.jsx'],
      },
    ],
  ],
};

插樁完成后，代碼中會插入一些代碼探針，這些代碼探針會在運行時收集覆蓋率數據，然后上報到Canyon服務端。

檢查是否插樁成功，可以在編譯后的產物中搜索__coverage__，如果有則說明插樁成功。

為了緊密關聯插樁代碼的源代碼，我們適配了各種provider，將環境變量發送到Canyon服務端，兌換到reportID，方便覆蓋率數據聚合計算完成后的覆蓋率源文件的關聯展示。

我們還提供了babel-plugin-canyon的babel插件，可以在各種流水線內（aws，gitlab ci）讀取環境變量(branch、sha)，以供后續覆蓋率數據與對應的gitlab源代碼關聯。

babel.config.js

module.exports = {
  plugins: [
    [
        'babel-plugin-canyon',
        {
          provider: 'gitlab',
          branch: process.env.CI_COMMIT_REF_NAME,
          sha: process.env.CI_COMMIT_SHA,
        },
    ],
  ],
};

支持的提供商：

• Azure Pipelines
• CircleCI
• Drone
• Github Actions
• GitLab CI
• Jenkins
• Travis CI

需要特別注意的是，代碼探針的插樁會在構建產物上下文加上代碼探針，會是代碼整體產物增大30%，建議不要上生產環境。

五、測試與上報

當插樁完成發布到測試環境后，我們就可以進行測試了。拿playwright舉例，對于插樁成功的前端應用站點，window對象上面都會掛載__coverage__和__canyon__對象，我們需要在playwright測試過程中收集并上報這些數據到canyon的服務端。

playwright示例：

const {chromium} = require('playwright');
const main = async () => {
  const browser = await chromium.launch()
  const page = await browser.newPage();
  // 進入被測頁面
  await page.goto('http://test.com')
  // 執行測試用例
  // 用例1
  await page.click('button')
  // 用例2
  await page.fill('input', 'test')
  // 用例3
  await page.click('text=submit')
  const coverage = await page.evaluate(`window.__coverage__`)
  // 收集上報覆蓋率
  upload(coverage)
  browser.close()
}


main()

攜程內部有自己的UI自動化平臺 flybirds，我們在flybirds內部集成了Canyon覆蓋率數據的收集和上報。真實的瀏覽器UI自動化測試的覆蓋率收集場景較為復雜，主要體現在多頁面（MPA）的覆蓋率收集時機不確定性。

單頁面（SPA）與多頁面（MPA）

當測試用例執行完成后，對于單頁面應用(SPA)或者多頁面應用而言，上報步驟是將頁面window對象上的__coverage__對象上報到Canyon服務端，對于單頁面應用來說，相對來說比較簡單，在所有測試內容都在單頁面應用內，覆蓋率數據會常駐在window對象中，對于多頁面應用而言，路由的跳轉會導致window對象的重制，丟失coverage對象。所以這個時機是至關重要的，經過大量實踐驗證，我們找到了瀏覽器的onvisiblechange方法。

• visibilitychange

在瀏覽器可見性改變的時候上報覆蓋率數據，值得一提的是，對于visibilitychange這種可能會導致重復數據上報，但是對于覆蓋率統計來說，未執行到的代碼多次合并來說不會影響覆蓋率的具體指標數據統計。

• fetchLater

Chrome 瀏覽器正在積極引入一個革命性的 JavaScript API——fetchLater()。這個全新的 API 旨在徹底簡化關閉頁面時的數據發送過程，確保即使在頁面關閉后或用戶離開的情況下，請求也能在未來某個時刻被安全、可靠地發出。

這個API的推出時令人振奮的，可以很好的解決多頁面（MPA）收集難的問題，只需要在瀏覽器關閉時收集。

注：fetchLater() 已在 Chrome 中提供，用于在版本 121（2024 年 1 月發布）開始的原始試驗中供真實用戶測試，該試驗將持續到 Chrome 126（2024 年 7 月）。

六、聚合

覆蓋率數據的來源是同一版本的代碼，覆蓋率數據是可以聚合的，Canyon內部使用reportID來關聯測試用例和細分聚合維度。這樣做可以讓海量的覆蓋率數據聚合成有限個，即Case的數量。

/**
 * 合并兩個相同文件的文件覆蓋對象實例，確保執行計數正確。
 *
 * @method mergeFileCoverage
 * @static
 * @param {Object} first 給定文件的第一個文件覆蓋對象
 * @param {Object} second 相同文件的第二個文件覆蓋對象
 * @return {Object} 合并后的結果對象。請注意，輸入對象不會被修改。
 */
function mergeFileCoverage(first, second) {
  const ret = JSON.parse(JSON.stringify(first));


  delete ret.l; // 移除派生信息


  Object.keys(second.s).forEach(function (k) {
    ret.s[k] += second.s[k];
  });


  Object.keys(second.f).forEach(function (k) {
    ret.f[k] += second.f[k];
  });


  Object.keys(second.b).forEach(function (k) {
    const retArray = ret.b[k];
    const secondArray = second.b[k];
    for (let i = 0; i < retArray.length; i += 1) {
      retArray[i] += secondArray[i];
    }
  });


  return ret;
}

端到端測試的覆蓋率數據特點之一是單體數據體積大，在項目整體插樁的情況下相當于整體源代碼體積的30%。攜程Trip.com flight站點的預定頁UI自動化case上報次數每次可達2000次，每次10M數據，這樣的數據量對于Canyon服務端來說是一個巨大的挑戰。

對于單條數據大且高頻次的數據上報場景，很難做到實時數據聚合計算。Canyon采用消息隊列的形式來消費數據，并且設計成無狀態服務，適用于云原生時代的容器化部署，可通過HPA彈性伸縮容來應用不同場景下的測試覆蓋率上報。

七、報告

對于覆蓋率報告展示，我們沿用了istanbul-report的界面風格，但是由于istanbul-report只提供了靜態html文件的生成，不適合現代化前端水合數據生成html的模式，為此我們參考了它的源碼，使用了monaco-editor標記源代碼覆蓋率。

const decorations = useMemo(() => {
    if (data) {
        const annotateFunctionsList = annotateFunctions(data.coverage, data.sourcecode);
        const annotateStatementsList = annotateStatements(data.coverage);
        return [...annotateStatementsList, ...annotateFunctionsList].map((i) => {
            return {
                inlineClassName: 'content-class-found',
                startLine: i.startLine,
                startCol: i.startCol,
                endLine: i.endLine,
                endCol: i.endCol,
            };
        });
    } else {
        return [];
    }
}, [data]);

經過著色后的效果：

八、變更代碼覆蓋率

對于變更代碼覆蓋率，我們統計的公式是覆蓋到的新增代碼行/所有新增代碼行。

通過配置compareTarget來指定對比目標，再聯合gitlab的git diff接口獲取變更代碼行結合覆蓋率數據計算。

/**
 * returns computed line coverage from statement coverage.
 * This is a map of hits keyed by line number in the source.
 */
function getLineCoverage(statementMap:{ [key: string]: Range },s:{ [key: string]: number }) {
  const statements = s;
  const lineMap = Object.create(null);


  Object.entries(statements).forEach(([st, count]) => {
    if (!statementMap[st]) {
      return;
    }
    const { line } = statementMap[st].start;
    const prevVal = lineMap[line];
    if (prevVal === undefined || prevVal < count) {
      lineMap[line] = count;
    }
  });
  return lineMap;
}

九、react native 覆蓋率收集方案

攜程的移動端技術棧主要是react native，好消息是對于我們的插樁方案一樣適用，因為都是基于babel編譯。并且得力于得力于公司內部的react native項目結構統一，我們將編譯時插樁做到了流水線中，在流水線中分別打包“正常包”和”插樁包“，這樣搭配UI自動化可以形成一套完整的錄制回放覆蓋率指標收集的測試體系。

利用websocket暴露模擬器內覆蓋率數據：

// 創建WebSocket連接
const socket = new WebSocket('ws://localhost:8080');


// 當WebSocket連接打開時觸發
socket.onopen = () => {
    console.log('Connected to coverage WebSocket server');
};


// 當收到WebSocket消息時觸發
socket.onmessage = event => {
    try {
      if (JSON.parse(event.data).type === 'getcoverage') {
        // 發送覆蓋率數據
        socket.send(JSON.stringify(payload));
      }
    } catch (e) {
      console.log(e);
    }
};


// 當WebSocket連接關閉時觸發
socket.onclose = () => {
    console.log('Disconnected from coverage WebSocket server');
};

目前攜程機票部門的APP模塊均已接入Canyon，經過實踐istanbuljs可以很好的對其進行插樁及覆蓋率數據收集，測試團隊在每次生產發布前會以Canyon的覆蓋率數據指標來衡量此次發布的質量情況。

十、覆蓋率提升優先級列表

在用戶最初接入Canyon系統時，會面臨一個挑戰：如果沒有大量的UI自動化測試用例，大型應用的代碼覆蓋率會顯得尤為低下。一開始，僅僅提供一個Istanbul代碼覆蓋率報告，并不能有效指導團隊如何提高覆蓋率，這讓大家感到困惑和無所適從。

為了解決這個問題，我們進行了深入的調研，并發現公司已經有了一個成熟的生產環境代碼覆蓋率收集系統。基于這一發現，我們決定將這個系統的數據與我們自己的覆蓋率數據相結合，創建了一個“覆蓋率提升優先級列表”。這個列表的目的是為開發團隊提供明確的指引，幫助他們了解在哪些方面可以優先提升代碼覆蓋率。

為了使這個指引更加科學和實用，我們制定了一個覆蓋率權重公式：

生產環境覆蓋率×100×0.3 + (1 - 測試覆蓋率)×100×0.3 + 函數數量×0.2

通過這個公式，我們能夠優先識別出那些生產環境使用率高、行數多，測試覆蓋率低的代碼文件，從而為開發團隊提供針對性的提升建議。這樣的方法不僅提高了代碼質量，也增強了我們對整體覆蓋率的掌控。

十一、社區推廣

從這篇文章發表時起，我們將正式開源Canyon。JavaScript是時下最流行的編程語言，但是端到端測試覆蓋率收集領域一直空白，我們的代碼開發基于了istanbuljs，monaco editor等優秀開源項目，我們有信心推出Canyon開源可以贏得社區的反響，并且可以有大量JavaScript開發者參與進來。

Canyon在未來還有很大發展空間，例如生產環境插樁收集還未有待驗證嘗試，與playwright、puppeteer、cypress等自動化測試的工具還沒有深度鏈接，這些都已經規劃到了未來的開發計劃中。希望在未來Canyon可以在攜程及社區里有更多人參與建設。