AI生成的页面看着很漂亮，按一下Tab就露馅了
鼠标点开弹窗，输入内容，点击保存。自动化截图和设计稿也对得上。
换一种操作方式：把鼠标放到一边，只用Tab、Shift＋Tab、Enter和Escape再走一遍。
按钮可能根本接不到焦点；弹窗打开后，焦点还留在背景页面；按了关闭，下一次Tab又不知道跳到哪里。
这些现象不需要复杂模型才能发现，却很容易被一套只会“找到元素然后click”的测试漏掉。
页面能被看见、能被鼠标点击，还需要进一步验证能否被键盘和辅助技术正确操作。
先试一段最短的键盘路径
用“编辑订单备注”的教学页面举例。要检查的行为可以很具体：Tab到编辑按钮，Enter打开弹窗，焦点进入备注框；在弹窗内顺序移动，Escape关闭，焦点回到打开它的按钮。
先不要急着安装一堆扫描工具。这条路径一旦走不通，就已经有了可复现的用户阻塞。
常见根源是用div画出一个“像按钮”的控件，只绑定鼠标事件；或者给弹窗加了视觉遮罩，却没处理背景交互和焦点位置。加上role也不能自动补齐全部行为。
优先使用具有相应语义与交互能力的原生元素，可以减少需要自己实现的部分。下面是一份可保存为HTML的小演示：
<!doctype html>
<html lang="zh-CN"><meta charset="utf-8">
<button id="open-editor">编辑备注</button>
<dialog id="editor" aria-labelledby="editor-title">
<h2 id="editor-title">编辑订单备注</h2>
<form method="dialog">
<label>备注 <textarea id="note" autofocus></textarea></label>
<button>关闭</button>
</form>
</dialog>
<script>
const opener = document.querySelector("#open-editor");
const editor = document.querySelector("#editor");
opener.addEventListener("click", () => editor.showModal());
editor.addEventListener("close", () => opener.focus());
</script>
</html>
这段示例演示弹窗打开、焦点与关闭，不包含真实保存业务。生产里有危险操作、长正文或不同类型弹窗时，初始焦点应按任务选择，不能机械地全部放在第一个输入框。
自动化要按用户的动作走，才能发现这一层问题
如果测试直接调用locator.click，浏览器会帮你完成鼠标操作，测试可能绕开“用户能否用键盘到达它”的问题。
下面是Playwright Python的关键检查函数。调用前，page应已经打开上面的演示页：
from playwright.sync_api import expect
def check_keyboard(page):
opener = page.get_by_role("button", name="编辑备注", exact=True)
page.keyboard.press("Tab")
expect(opener).to_be_focused()
page.keyboard.press("Enter")
expect(page.get_by_role("dialog")).to_be_visible()
expect(page.get_by_label("备注", exact=True)).to_be_focused()
page.keyboard.press("Tab")
expect(page.get_by_role("button", name="关闭", exact=True)).to_be_focused()
page.keyboard.press("Escape")
expect(page.get_by_role("dialog")).not_to_be_visible()
expect(opener).to_be_focused()
这份页面的可交互元素和初始焦点是受控的，所以可以从第一次Tab开始验证。放进真实产品时，应先明确入口状态，再按实际顺序编排动作。
函数还只是最小检查。模态弹窗内的Tab与Shift＋Tab循环、背景是否不可操作、焦点样式是否可见，都要继续覆盖。不能因为对话框在DOM里有role，就宣称它已经满足全部可访问性要求。
看起来相同的两次“打不开”，处理方法可能不同
| 用户现象 | 应该检查什么 |
|---|---|
| Tab一直到不了按钮 | 元素语义、焦点顺序、是否被错误禁用 |
| Enter没有反应 | 键盘激活行为是否实现 |
| 弹窗打开，输入却落到背景 | 初始焦点、模态状态、背景交互 |
| 关闭后焦点消失 | 触发元素是否仍存在、返回位置如何约定 |
如果触发元素因业务操作被删除，关闭后也不能把焦点送到已经不存在的节点。应选择工作流里合理的后续位置，再据此设计测试。
AI生成界面之后，验收清单也得跟上
让AI生成一个“现代、好看”的页面，通常会把注意力引向颜色、间距和动效。可以给需求再加上可检查的行为：控件有可访问名称，键盘路径可完成任务，弹窗焦点管理符合任务，错误提示与相关输入关联。
这些要求应变成浏览器里的操作与断言。自动扫描能帮忙找到一部分结构问题；真实键盘路径、屏幕阅读器体验和复杂业务场景仍需要针对性验证。
对测试工程师来说，不必一开始就背完整规范。先挑一个团队最常用的弹窗，把这条路径录清楚：从哪里进、焦点在哪、怎样完成、怎样退出、退出后在哪里。
当一张精致的AI页面通过这条路径，它才多了一份“确实能被使用”的证据。
- 点赞
- 收藏
- 关注作者
评论（0）