背景

在 基於pywebview搭建企業級桌面端 這篇中記錄了多種webview桌面端的框架，並記錄了pywebview的使用和相關的坑。本篇記錄如何在pywebview中實現自動化測試。

由於pywebview沒有提供測試套件，只有幾個基礎的操作接口，所以需要結合一些測試框架來實現。

如果pywebview中不涉及bridge通信，那可以當做普通瀏覽器來測試，以上框架都支持。但pywebview中涉及bridge通信，那有特定接口無法模擬，比如自實現的系統文件操作或者窗體調整等超出了瀏覽器的功能，只能考慮變通的方式，比如CDP(chrome devtools protocol) 或者 BiDi (browser-to-browser protocol) 或者圖形化識別。

CDP和BiDi

兩者都是用過websocket通信，差異體現在：

• 設計目標：BiDi 協議旨在成為一種通用的、標準化的瀏覽器自動化和調試協議，注重跨瀏覽器的兼容性和簡潔性。CDP 最初是為 Chrome 瀏覽器的開發者工具調試功能設計的，更側重於滿足 Chrome 瀏覽器的特定調試需求，功能豐富且細緻，但相對複雜，並且主要適用於基於 Chromium 內核的瀏覽器。
• 功能範圍：BiDi 協議提供了一些高級的、通用的功能，如頁面導航、元素交互、腳本執行、監聽 DOM 事件、捕獲 JavaScript 錯誤和控制枱消息、記錄網絡流量等。CDP 除了包含上述功能外，還提供了對瀏覽器渲染引擎、緩存策略、Cookie 管理等更底層的調試功能。

在常見基礎操作上命名稍微有點區別：

具體文檔可以參考cdp 和 BiDi

讓pywebview支持CDP或BiDi

首先官網web engine 列舉了pywebview在不同平台下的web engine

查看changelog 發現 pywebview 5.4增加特性：

• windows下支持 EdgeChromium通過添加遠程調試支持設置webview.settings['REMOTE_DEBUGGING_PORT'] 來打開cdp.源碼位置

  #https://github.com/r0x0r/pywebview/blob/master/webview/platforms/edgechromium.py
  if webview_settings['REMOTE_DEBUGGING_PORT'] is not None:
    props.AdditionalBrowserArguments += f' --remote-debugging-port={webview_settings["REMOTE_DEBUGGING_PORT"]}'

但是實測發現即使設置了也沒有效果，端口並不通。

隨後查找其他方式，避免直接修改庫源碼。發現支持通過環境變量來設置,回退到pywebivew 4.3.3並啓動前執行

os.environ["WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS"] = "--remote-debugging-port=9222"

至此selenium,playwright,pyppeteer都可以使用cdp操作了。

代碼示例

各大框架比對見附錄。考慮到playwright支持瀏覽器廣，上層sdk支持多種語言，且測試報告，調試，錄製，vscode插件等都支持，這裏以playwright為例。

線性執行

playwright默認是併發執行的，假設應用場景是這個桌面應用不支持多開，或者測試場景是線性執行，比如登錄，操作，退出。需要做如下配置：

• playwright.config.js配置workers: 1使得單個線程執行

• 多個test用serial 標記，使得test之間串行執行

  test.describe.serial('測試集合',()=>{
      test.describe('測試A',()=>{})
      test.describe('測試B',()=>{})
  })

• 用一個page實例,避免每次重連

  let page;
  
  test.beforeAll(async () => {
      const browser = await playwright.chromium.connectOverCDP('http://127.0.0.1:9222');
      const defaultContext = browser.contexts()[0];
      page = defaultContext.pages()[0];
  });

  文件

• 獲取本地路徑

  const directory = path.join(__dirname, `../fixtures/test.json`);

  模擬pywebview.api

• 執行腳本覆蓋pywebview的bridge通信

  注意變量只能通過函數入參的形式傳入，因為可執行的腳本作用域在瀏覽器而不是測試腳本，兩者是隔離的

  await page.evaluate((directory) => {
      // @ts-ignore
      window.pywebview = {
          api: {
              choosePath: () => Promise.resolve(JSON.stringify({ status: 'ok', directory })),
              getFileSize: () => Promise.resolve(1024)
          }
      };
  }, directory);

  操作行為

• 常見操作

  await page.goto('http://localhost:5000/');
  await page.getByText('選擇文件').click()
  await page.waitForTimeout(4000);
  await page.getByRole('radio', { name: config.radioValue, exact: true }).check();
  await page.locator('select').selectOption('value')
  await page.locator('.col:last-child').textContent();//querySelector
  await page.locator('//div[@class=".btn" and text()="確定"]').click();//xpath

• 可選的操作

  try {
      // 等待 1 秒，如果元素出現則點擊，超時則跳過
      await page.waitForSelector(':text("×")', { timeout: 1000 });
      await page.getByText('×').click();
  } catch (error) {
  }

斷言

@playwright/test 是 Playwright 官方提供的測試框架，它自帶的 expect 斷言風格簡潔，與 Playwright 的 API 配合良好。

const { test, expect } = require('@playwright/test');

test('測試頁面標題', async ({ page }) => {
    // 導航到頁面
    await page.goto('https://www.example.com');
    // 斷言頁面標題是否包含指定字符串
    await expect(page).toHaveTitle(/Example/);

    // 獲取頁面上某個元素（假設存在一個id為myElement的元素）
    const element = page.locator('#myElement');
    // 斷言元素是否可見
    await expect(element).toBeVisible();

    // 斷言元素的文本內容
    const text = await element.textContent();
    await expect(text).toContain('Some text');
});

測試報告

playwright提供了豐富的報告選項，包括 HTML、JSON等格式，可以自定義報告的樣式和內容。

// playwright.config.js
reporter:  [
    ['json', { outputFile: 'test-results.json' }],
    ['html',{open: 'never'}],
  ]

上述配置會生成一個包含測試結果的 HTML 報告，以及一個 JSON 文件，其中包含測試結果的詳細信息。
如果接入CI,可以通過json獲取關鍵信息，便於判斷計數。這邊給出關鍵部分代碼

// 初始化計數器
let allCount = 0;
let passedCount = 0;
let failedCount = 0;
let flakyCount = 0;
let skippedCount = 0;

// 遞歸函數，用於遍歷所有測試用例
function traverseSuites(suites) {
  suites.forEach((suite) => {
    if (suite.specs) {
      suite.specs.forEach((spec) => {
        spec.tests.forEach((test) => {
          allCount++;
          const result = test.results[0];
          if (result.status === "passed") {
            passedCount++;
          } else if (
            result.status === "timedOut" ||
            result.status === "failed"
          ) {
            failedCount++;
          } else if (result.status === "flaky") {
            flakyCount++;
          } else if (result.status === "skipped") {
            skippedCount++;
          }
        });
      });
    }
    if (suite.suites) {
      traverseSuites(suite.suites);
    }
  });
}

錄製腳本

官方提供的錄製是彈出瀏覽器，不能直接在cdp的場景下錄製。所以不適用。但能通過 --ui的方式審查元素，比純手動簡單一些。

關於圖像識別的自動化測試

此外還調研了sikuli 基於圖像識別的自動化測試框架，直接執行sikuli的jar包很方便，但基於圖像識別不同操作系統會有差異，識別率要微調，不能做到一端開發，多端執行。但好處是跨平台，可以操作任何桌面應用。

附錄

框架對比