Architecture Decision Record架構決策記錄:用於端到端測試的瀏覽器自動化框架(Playwright 與 Selenium)
1. 背景
我們正在為端到端(E2E)測試流水線選擇瀏覽器自動化框架。該框架將是我們 CI/CD 流程中不可或缺的一部分,用於執行模擬真實使用者在我們平臺上互動的測試。具體而言,測試將涵蓋使用者註冊/登入、檔案上傳、儀表板互動和報表下載等場景。
作為一家初創公司,我們的重點是敏捷開發,需要快速迭代和演進。我們的團隊主要使用 TypeScript 和 Python,因此能夠用這些語言編寫測試至關重要。此外,平臺包含互動式圖表和儀表板,因此自動化工具必須能很好地支援豐富的動態 UI。
這項任務的兩個競爭者是 Playwright 和 Selenium,各有其優勢和權衡。我們需要根據下文列出的功能和需求來評估這兩個框架。
2. 考慮過的選項
- Playwright(由 Microsoft 開發)
- Selenium(由 Selenium 專案開發)
3. 決策驅動因素
影響我們決策的因素如下:
- 敏捷開發:所選工具必須支援快速、靈活的開發週期。
- 語言支援:我們的團隊需要同時支援 TypeScript 和 Python。
- 互動式 UI 測試:能夠可靠地測試互動式圖表、儀表板和動態元素至關重要。
- 執行速度:雖然不是首要關注點,但在 CI/CD 流水線中的效能也是一個考慮因素。
- 可擴充套件性:我們近期並不打算大規模擴充套件,但希望確保該方案能應對未來的增長。
- 向後相容性:遺留系統和對舊版瀏覽器的相容性目前對我們的專案並不關鍵。
- 移動端測試:雖然不是當前的重點,但該框架應能夠測試移動端響應式功能,或可擴充套件以支援此類場景。
- 多顯示器測試:對多顯示器配置的支援是次要需求,特別是如果我們將來擴充套件到測試更復雜的使用者工作流。
- 檔案上傳測試:框架必須高效地處理檔案上傳,這是我們測試需求的核心要求。
4. 評估標準
- 易用性:編寫和維護測試有多容易?
- 語言支援:框架是否支援 TypeScript 和 Python,即我們團隊最常用的兩種語言?
- 互動式 UI 測試:框架處理圖表、檔案上傳和動態資料等複雜互動式使用者介面的能力如何?
- CI/CD 整合:框架與常見的 CI/CD 工具和服務的整合程度如何?
- 跨瀏覽器支援:支援哪些瀏覽器,表現如何?
- 效能和速度:測試執行得有多快,特別是在 CI/CD 流水線中?
- 可擴充套件性:如果新增更多測試或更復雜的場景,框架的擴充套件能力如何?
- 社群和生態系統:框架的社群有多活躍?是否有大量可用的整合和擴充套件?
5. 考量
5.1 Playwright
優點:
- 更智慧的本地檔案上傳 API:Playwright 用於與本地檔案互動和執行檔案上傳的 API 更簡單、更直觀。這將使檔案上傳測試更易於實現和維護。
- 語法和程式碼生成:Playwright 的語法更短、更簡潔。這減少了樣板程式碼,從而提高了可維護性和開發效率。此外,這種較短的語法還提升了 OpenAI 程式碼生成的品質,使自動生成測試指令碼更加容易。
- 互動式 UI 測試:Playwright 擅長測試動態、互動式的 Web 應用,例如具有豐富圖表、複雜使用者互動和實時更新的應用。它能非常有效地處理 WebSocket、WebRTC、Shadow DOM 及其他現代 Web 技術。
- 跨瀏覽器支援:Playwright 支援 Chromium、WebKit 和 Firefox。它在這些瀏覽器上表現一致,應能滿足我們大部分的測試需求。
- CI/CD 整合:Playwright 可與現代 CI/CD 平臺(GitHub Actions、Jenkins 等)無縫整合。它可以在不同的瀏覽器上並行執行測試,最佳化測試執行時間,適合快速開發。
- 快速且可靠:Playwright 總體上比 Selenium 更快,尤其是在無頭模式下,並且在處理非同步 Web 元素時更具彈性。
缺點:
- 移動端測試有限:雖然 Playwright 確實支援瀏覽器的移動端模擬,但它缺乏原生移動端測試能力,不像 Selenium 那樣可透過與 Appium 整合實現真正的移動端測試。
- 生態系統較小:Playwright 仍較新,不如 Selenium 成熟。雖然它的社群增長迅速,文件也不錯,但它可能還沒有 Selenium 所提供的龐大外掛和整合生態系統。
- 瀏覽器支援有限:雖然 Playwright 涵蓋了主要的現代瀏覽器(Chrome、Safari、Firefox),但它對舊版瀏覽器(例如 Internet Explorer)的支援不如 Selenium 穩健。
5.2 Selenium
優點:
- 歷史更長、更成熟:Selenium 已經存在很長時間,有著久經驗證的業績記錄。它被許多團隊和行業廣泛使用,從而形成了龐大的外掛、整合和資源生態系統。
- 跨瀏覽器和跨平臺支援:Selenium 支援種類繁多的瀏覽器及其版本,包括 Internet Explorer,還可以與 Docker、Selenium Grid 和雲服務等各種工具整合,用於分散式測試。
- 移動端測試:Selenium 透過與 Appium 整合,在移動端測試(包括 Android 和 iOS 應用)方面要穩健得多。這使它成為移動優先或以移動為主的專案的更佳選擇。
- 多顯示器測試:Selenium 對涉及多顯示器或複雜多視窗互動的場景提供了更好的支援。
缺點:
- 複雜性:Selenium 的 API 更冗長、更顯式。雖然這在某些情況下是優勢,但也意味著需要編寫和維護更多程式碼,這可能會降低開發敏捷性——這在初創環境中尤為重要。
- 效能:Selenium 通常比 Playwright 執行得慢,尤其是在無頭模式下。這可能會影響 CI/CD 流水線,特別是隨著測試數量的增加。
- 互動式 UI 測試:在測試現代互動式 Web UI(尤其是帶有圖表和實時資料更新的 UI)方面,Selenium 不如 Playwright 流暢。要可靠地與動態內容互動,它需要更多的設定和處理。
6. 對比總結
| 特性 | Playwright | Selenium |
|---|---|---|
| 易用性 | 語法更短,對現代 UI 更直觀 | 更顯式,需要更多樣板程式碼 |
| 語言支援 | TypeScript、Python、JavaScript | TypeScript、Python、Java、Ruby、C# |
| 互動式 UI 測試 | 非常適合動態、實時的 UI | 可處理基本 UI,但對豐富互動更冗長、更復雜 |
| 檔案上傳測試 | 更智慧的檔案上傳 API | 更冗長,API 不夠直觀 |
| CI/CD 整合 | 易於與 GitHub Actions、Jenkins 整合 | 與許多 CI 工具有很強的整合 |
| 移動端測試 | 有限,僅支援模擬 | 透過 Appium 提供完整支援 |
| 跨瀏覽器支援 | Chromium、WebKit、Firefox | 完整支援主流和舊版瀏覽器 |
| 效能 | 快速,針對無頭測試進行了最佳化 | 較慢,尤其是在無頭模式下 |
| 多顯示器測試 | 有限 | 對多顯示器配置支援良好 |
| 社群和生態系統 | 不斷增長,文件良好 | 龐大、成熟、生態系統廣泛 |
7. 決策
在考慮了需求和權衡之後,Playwright 是滿足我們當前需求的更好選擇。其更智慧的本地檔案上傳測試 API、簡潔的語法以及對互動式 UI 測試的強力支援,使其非常適合我們的敏捷開發週期。它同時支援 TypeScript 和 Python,這對我們的團隊至關重要,而且該框架的現代測試方式將使我們能夠編寫整潔、可維護的程式碼。
雖然 Selenium 仍然是一個很好的工具,尤其是在移動端測試、舊版瀏覽器支援和多顯示器設定方面,但它不太適合我們當前的需求。它的冗長、較慢的效能,以及對圖表等動態 UI 更復雜的處理方式,使其對我們的用例而言不那麼理想。
8. 後果
- 即時行動:我們將採用 Playwright 進行 E2E 測試,重點測試涉及註冊、登入、檔案上傳、儀表板和報表下載的使用者流程。
- 長期考慮:我們將密切關注 Playwright 生態系統的演進。如果我們的需求發生變化,特別是在移動端測試或舊版瀏覽器支援方面,我們可能會重新考慮 Selenium。
- 培訓和文件:開發團隊需要熟悉 Playwright 的 API,特別是用於處理動態 UI 和檔案上傳的部分。
- 遷移:現有的 Selenium 測試(如有)將逐步遷移到 Playwright。