更新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与维护环境的步骤。

