更新WordPress或佈景主題後,即使首頁正常,也可能只有智慧型手機的預訂按鈕被遮住,或客房頁面的表格向側邊溢出。
每次手動開啟所有頁面相當費力。使用可自動操作瀏覽器的Playwright,就能以相同畫面寬度拍攝指定URL,比較更新前後的圖片。
本文不要求旅宿主人背誦Playwright程式碼,而是說明如何請Codex或Claude Code協助準備與重複作業,由人員確認通過標準與預訂資訊。
結論:AI負責拍攝與整理差異,人員決定正常範本
畫面比較的基本流程如下。
決定重要URL與畫面寬度
↓
將更新前的正常畫面保存為基準圖片
↓
在測試環境只更新一項
↓
以相同條件拍攝更新後畫面
↓
Playwright與AI整理差異
↓
人員確認預訂、費用與使用便利性
AI能快速找出差異。但若更新前的畫面本身有誤,就會以錯誤作為基準。「這個畫面才正常」的判斷,保留給旅宿主人與維護負責人。
什麼是Playwright
Playwright是自動操作Chromium、Firefox、WebKit等瀏覽器的工具。可重複開啟頁面、按下按鈕、改變畫面寬度、保存截圖等操作。
Playwright官方的Visual comparisons介紹先建立基準截圖,再與後續執行圖片比較的方法。Screenshots說明除了目前顯示範圍,也可保存整個頁面。
Playwright並非WordPress專用。旅宿官方網站、靜態頁面、預訂說明等,只要能在瀏覽器開啟,就能用來確認畫面。
畫面比較較容易發現的問題
- 頁首選單的位置與折行
- 標誌與照片的長寬比
- 標題、正文與側邊欄重疊
- 表格與長URL向側邊溢出
- 預訂按鈕被其他組件遮住
- 智慧型手機選單無法開啟
- 圖片、地圖與影片未顯示
- 字型改變造成換行與高度變化
- Cookie提示遮住畫面
另一方面,只靠截圖無法確認表單送出、可預訂房量、付款、郵件接收,以及費用是否正確。
一開始5個頁面、3種畫面寬度就夠
若從所有頁面開始,光確認差異就會疲累。先選較接近預訂的5個頁面。
- 首頁
- 客房與費用
- 預訂說明
- 聯絡
- 交通
畫面寬度可參考以下範例。
| 預期裝置 | 寬度範例 | 想找出的問題 |
|---|---|---|
| 電腦 | 1440px | 橫向排列、選單與側邊欄 |
| 平板 | 768px | 配置切換過程的版面錯亂 |
| 智慧型手機 | 390px | 橫向溢出、按鈕與行動選單 |
Playwright的Emulation可模擬畫面尺寸、裝置與色彩設定等。但實際智慧型手機有瀏覽器介面、文字設定、連線速度等差異,最後仍需用實機確認。
初學者需準備的東西
- 可用VS Code開啟的測試專用資料夾
- 可使用Codex或Claude Code的環境
- 待確認的公開URL或受保護的測試URL
- 能判斷為正常的更新前畫面
- 確認執行結果的人員
若不清楚開啟資料夾的意義或如何安裝擴充功能,請先閱讀旅宿主人的VS Code入門。
不必直接將測試放進正式網站的佈景主題資料夾。放在與網站營運分開的測試資料夾,讓執行內容處於可確認的狀態。
先讓AI確認的事項
導入Playwright前,請AI調查以下事項。
- 是否已使用Node.js或Playwright
- 是否有既有測試與配置檔
- 對象是正式環境還是Staging
- 是否有Basic驗證等存取限制
- 哪些頁面不需登入就能確認
- 截圖是否可能出現個人資訊
- 基準圖片與測試結果要保存在哪裡
- 是否影響既有檔案或設定
不要請AI「先安裝再說」,而應先讓它列出會變更的檔案、所需容量與移除方法。
Playwright的最小配置
官方Installation介紹建立Playwright Test專案,再安裝所需瀏覽器的流程。
請AI建立時,一般會是以下配置。
website-check/
├─ package.json
├─ playwright.config.js
├─ tests/
│ └─ visual.spec.js
└─ tests/visual.spec.js-snapshots/
└─ 基準圖片
檔案名稱與保存位置依環境而異。基準圖片是「判斷為通過的畫面」,不要每次自行重新製作,而應記錄變更原因與核准者。
測試程式碼的概念
以下是用來理解機制的虛構網站範例。直接在正式環境執行前,請AI或負責人配合自己的環境調整。
import { test, expect } from '@playwright/test';
test('首頁的智慧型手機顯示', async ({ page }) => {
await page.setViewportSize({ width: 390, height: 844 });
await page.goto('https://example.com/', { waitUntil: 'networkidle' });
await expect(page).toHaveScreenshot('home-mobile.png', {
fullPage: true,
});
});
此測試示範以390px寬度開啟指定URL,將整個頁面與基準圖片比較的概念。
建立基準圖片時的注意事項
首次執行產生的圖片,不一定自動就是正確的。
- 人員確認公開頁面
- 確認旅宿名稱、費用、照片與預訂目標正確
- 確認電腦與手機外觀
- 核准該圖片作為基準
- 記錄核准日與確認者
不要以錯誤費用、舊預訂按鈕或已錯亂的版面作為基準。
每次改變的部分也會產生差異
畫面比較中,有些部分即使不是問題,也會改變。
- 今天的日期與天氣
- 空房、費用與剩餘房量
- 輪播與影片
- SNS嵌入
- 瀏覽數與排名
- 隨機顯示文章
- Cookie提示
- Web字型載入時間
- 游標與動畫
不處理這些部分,測試就會每次失敗。
處理方法
- 等動作停止後再拍攝
- 只在測試時停用動畫
- 遮罩日期、房量等變動部分
- 固定Cookie提示狀態
- 使用安全測試資料,避免使用正式資料
- 只比較重要組件,而非整個頁面
減少差異的設定不是為了隱藏問題,而是區分「每次都改變的正常部分」與「因更新改變的異常部分」。注意不要將預訂按鈕本身遮罩,排除於確認對象之外。
在相同環境拍攝
Playwright官方資料說明截圖可能因OS、瀏覽器、設定、硬體等而不同。
比較時,請統一以下條件。
- Playwright與瀏覽器版本
- OS或執行環境
- 畫面寬度與高度
- 字型
- 語言與時區
- 色彩設定
- 登入狀態
- URL與測試資料
分別在旅宿主人的電腦、製作公司的電腦與伺服器拍攝,可能產生大量微小文字差異。請選定一處定期執行。
出現差異時如何判讀
將差異分為以下3種。
| 判斷 | 範例 | 處理 |
|---|---|---|
| 問題 | 按鈕消失、重疊與橫向溢出 | 停止追加更新,調查原因 |
| 預期變更 | 新標題、已核准設計 | 人員確認後更新基準圖片 |
| 暫緩判斷 | 字型、動態房量與外部嵌入 | 統一條件後重新確認 |
不可只為了讓測試通過就更新基準圖片。應解釋改變了什麼,旅宿主人核准後才更新。
請AI調查圖片差異
請AI報告以下事項。
- 失敗的URL與畫面寬度
- 改變的位置
- 消失、增加或移動的組件
- 對預訂與詢問的影響
- 屬於預期變更的可能性
- HTML、CSS與JavaScript的候選原因
- 修正前需追加確認的事項
不要只憑圖片斷定原因,也需確認瀏覽器錯誤、載入失敗與變更檔案。Trace Viewer有時能追蹤測試中的操作、畫面與網路等。為避免在追蹤紀錄保存驗證資訊或個人資訊,請決定對象頁面與保存期間。
Basic驗證與登入畫面的處理
Staging受Basic驗證保護時,需有向AI或測試提供驗證資訊的途徑。
- 不直接將密碼寫在程式碼
- 不放入Git或截圖
- 使用環境變數等安全保存方法
- 不在紀錄輸出驗證標頭
- 限定作業人員與有效期間
不要從WordPress管理畫面或可看到預訂者資訊的頁面開始,先只測試一般公開頁面。也請參考WordPress登入的BASIC驗證與2階段驗證。
不可出現在截圖的內容
- 預訂者姓名、電子郵件地址與電話
- 詢問正文
- 管理畫面的使用者清單
- API金鑰、付款資訊與備用碼
- 未公開費用與合約資訊
- 瀏覽器的密碼通知
向AI提供測試結果或追蹤紀錄前,確認沒有個人資訊與秘密資訊。即使是公開頁面,若預訂確認URL包含個人資訊,也不要列為對象。
不只靠畫面比較判定通過
即使截圖一致,也需另外確認以下事項。
- 預訂按鈕前往正確旅宿與方案
- 能送出詢問
- 旅宿通知與自動回覆能收到
- 電話與地圖正確
- 費用、休館與招牌貓資訊最新
- 能以鍵盤或螢幕閱讀器操作
- 實際智慧型手機容易點按
畫面比較是版面錯亂檢查,不是旅宿營業資訊或整體功能的保證。
可直接複製的提示詞1:先規劃,不導入
我想用Playwright比較旅宿WordPress更新前後畫面。
我不熟悉IT。先不要安裝或變更檔案。
請只以唯讀方式確認以下事項,建立導入計畫。
- 是否有Node.js、Playwright與既有測試
- 新增、變更的檔案與所需容量
- 測試專用資料夾與移除方法
- 首先確認的5個頁面
- 電腦1440px、平板768px、智慧型手機390px的拍攝方法
- 日期、房量與輪播等每次變動部分
- 拍到個人資訊或驗證資訊的風險
- 人員核准基準圖片的步驟
- 更新後的差異報告格式
不要修改正式網站、WordPress、預訂與付款。
不要推測不明事項,執行前請向我確認。
可直接複製的提示詞2:在測試環境建立
請在已核准的測試專用資料夾,建立Playwright畫面比較。
不要修改正式WordPress或佈景主題檔案。
對象只限測試環境的一般公開頁面。
- 首頁
- 客房與費用
- 預訂說明
- 聯絡
- 交通
請以電腦1440px、平板768px、智慧型手機390px拍攝。
列出動態部分,在變更前解釋要等待、固定或遮罩什麼。
不要將預訂按鈕與聯絡路徑排除於確認對象。
不要自動核准基準圖片,在我確認前先以候選圖片保存。
最後,請報告新增檔案、執行方法、移除方法與是否有秘密資訊。
可直接複製的提示詞3:調查更新後差異
請調查測試環境進行一項更新後的Playwright結果。
先不要修正、追加更新、更新基準圖片或反映到正式環境。
請將失敗分為以下類型。
- 問題
- 可能是預期變更
- 因動態顯示等而暫緩判斷
每項差異,請列出URL、畫面寬度、改變位置、對預訂路徑的影響、
HTML、CSS與JavaScript的候選原因,以及追加確認。
不要輸出個人資訊或驗證資訊。
最後,請報告人員應確認的圖片與URL、修正方案與還原方法。
完成檢查清單
- [ ] 在測試專用資料夾管理
- [ ] 已決定對象URL與畫面寬度
- [ ] 人員已核准正常基準圖片
- [ ] 在相同環境拍攝更新前後
- [ ] 已記錄動態部分的處理
- [ ] 未將預訂按鈕排除於差異確認
- [ ] 截圖與追蹤紀錄沒有秘密資訊
- [ ] 已將差異分為問題、預期變更與暫緩判斷
- [ ] 基準圖片更新保留人員核准
- [ ] 已另外確認實機、預訂、詢問與費用
總結
使用Playwright的目的不是增加測試數量,而是保存更新前的正常畫面,以相同URL、相同畫面寬度與相同環境比較更新後畫面,比住客更早發現版面錯亂。
先從5個頁面與3種畫面寬度開始,一邊整理誤判一邊改進。若沒有測試環境,請閱讀WordPress的Staging入門;發現版面錯亂後的判斷,請閱讀使用AI調查WordPress更新後版面錯亂的方法。
參考資料
- Playwright:Installation
- Playwright:Screenshots
- Playwright:Visual comparisons
- Playwright:Emulation
- Playwright:Trace Viewer
※Playwright、Node.js與瀏覽器的支援版本及安裝方法會更新。實際導入時,請確認Playwright官方資料,以及使用中OS與維護環境的步驟。

