測試非常重要。向使用者提供建構的內容 (無論是整個網站或應用程式，或是新功能) 前，這是確認功能是否正常運作的關鍵步驟。不過，許多測試仍會手動進行，且同事或測試工程師要求查看新功能並回報問題。
雖然手動測試可以顯示特定類別的問題，但可能會遺漏許多問題。執行測試的人員可能會錯過極端案例，或是完全無法在應用程式中測試特定歷程。此外，他們也沒有您在編寫程式碼時取得的所有資訊，也無法知道您為了防止其中發生的特定問題。隨著時間經過，並加入新功能之後，這些元件是否會回頭重新測試先前執行的所有工作，確保這些變更不會損毀？
因此 Chrome 團隊深信自動化測試的重要性。只要使用可靠且重複執行的測試套件，即可針對故障情形測試功能，確保在開發現在及日後開發後，每個小細節都經過測試。您身為功能開發人員的知識已經封裝在測試中。
不過，我們知道自動化測試並不容易。因此，Chrome 團隊提供下列工具和指南，以盡可能提供流暢的使用體驗。
布偶操作員
Puppeteer 是 Node.js 程式庫，透過簡單易用的高階 API，您可以自動執行 Chrome、Chromium 和 Firefox 操作。
這個 API 最初是以 Chrome 開發人員工具通訊協定為基礎，但目標是在年底前讓 Puppeteer 奠定基礎，更先進的全新進階 WebDriver BiDi 通訊協定。WebDriver BiDi 是由所有主要瀏覽器廠商共同打造，可簡化許多自動化用途，並支援許多新技術，並且能夠跨瀏覽器相容。
但不需等待。Puppeteer 的 API 目前已支援許多自動化用途，但只會透過 WebDriver BiDi 改善。無論是測試、視覺檢索及程序自動化，都能利用頁面互動、要求攔截和螢幕截圖等功能實現。您甚至可以使用 WebGPU 和 WebGL，在雲端測試網頁 AI 模型。
Puppeteer 也會用於 WebdriverIO、完善的瀏覽器測試架構和 Privacy Sandbox 分析工具等工具，協助您進一步瞭解網站上的 Cookie 和使用者資料使用情形。
Chrome 無頭
如果您曾使用 Puppeteer 自動化 Chrome，可能會發現測試執行時沒有顯示瀏覽器視窗。根據預設，Puppeteer 會以「無頭」模式啟動 Chrome。這表示執行自動化動作時沒有實際的瀏覽器視窗。
但是，您知道 Chrome 的無頭模式不只是 Chrome 無視窗模式，而且是完全獨立維護的 Chrome 版本嗎？這長期會導致混淆，難以追蹤錯誤和問題。
自 Chrome 112 版起，我們推出了全新的無頭模式，現在採用與一般 Chrome 相同的程式碼集。這不僅能夠減少先前造成的混淆，還會帶來先前不可能實現的功能，例如在自動化期間使用擴充功能。
自 22 版起，Puppeteer 一直預設使用這種新的無頭模式。如果您透過其他自動化解決方案使用 Chrome 無頭版，可以透過 --headless=new 指令列開關強制使用新的無頭模式。
雖然 Chrome 全新的無頭模式功能更強大，但比舊的無頭模式更輕巧。如果您的資源嚴重不足，或不需要 Chrome 的所有功能，您可以使用舊版無頭模式做為 chrome-headless-shell。
Chrome for Testing
測試時，您需要精細地控管測試環境，例如作業系統、瀏覽器和瀏覽器版本。Chrome 的自動更新 很難解決這個問題
因此，我們建立了 Chrome for Testing，這是一個不自動更新的 Chrome 版本，與所有主要作業系統一起發布的 Chrome 版本，可透過版本化封存檔取得。如此一來，您就能針對特定 Chrome 版本執行自動化工作流程，而且無須過多模擬。
您可以透過 Chrome for Testing 可用性資訊主頁、JSON API 或 Puppeteer 指令列公用程式，存取 Chrome for Testing 的二進位檔。
Puppeteer、Chrome 的新版無頭模式和 Chrome for Testing 只是我們的團隊正在努力執行的任務，目的是讓瀏覽器自動化和執行測試能夠讓一切變得順暢。此外，DevTools Recorder 等相關工具也能協助您建立測試：記錄 Chrome 中的使用者流程，並在 Puppeteer 中重播。
前往 web.dev 學習測試
本文介紹的工具可協助您改善自動化測試。但如果您才剛開始使用，聽起來似乎有點複雜。因此，我們建立了新的 10 個單元課程：在 web.dev 上學習測試。這個深入課程涵蓋測試的核心概念、執行測試的位置和方式、測試類型，以及實際測試的內容。這是進行測試的起點取得基本知識後，歡迎繼續前往「測試自動化集合」，參閱有關更特定測試問題的深入說明和實用提示。