表单视觉测试：您 QA 中代价最高的盲区
核心要点
- 表单是您界面中视觉状态最丰富的组件，每一个状态都必须视觉正确，才能引导用户
- 功能测试验证表单提交了正确的数据，但完全忽略错误、验证与加载状态的外观
- 表单视觉测试是 QA 团队最被忽视的测试，却对转化率有最直接的影响
- 一个视觉上破碎的表单是没人填的表单，无论它在技术上多么完善
根据 W3C HTML 规范，Web 表单是*「Web 文档中允许用户输入要发送到服务器进行处理的数据的组件，由文本字段、复选框、单选按钮和提交按钮等表单控件构成」*（W3C, HTML Living Standard, 「Forms」一节）。
这一定义是功能性的。它描述了表单做什么。它对表单展示什么只字未提。而正是在「功能」与「外观」之间的这条缝隙里，潜藏着 Web 质量中被最低估的问题之一。
表单不是一个静态组件。它是与用户的视觉对话。每一个字段、每一种状态、每一条验证消息，都是引导、安抚或令人挫败的视觉信号。当这些视觉信号被破坏时，对话就中断了。用户随之放弃。
表单视觉状态的冰山
来看一个基础的联系表单。三个字段：姓名、邮箱、消息。一个提交按钮。看起来简单。现在，让我们来数一数它的视觉状态。
空状态：所有字段显示其 placeholder。聚焦状态：某个字段被选中，其轮廓发生变化。已填状态：某个字段包含文本，placeholder 消失。按钮的 hover 状态。客户端验证错误状态：某个字段无效，下方出现错误消息。服务端验证错误状态：出现全局错误消息。提交进行中状态：按钮显示加载指示器。成功状态：确认消息替换表单。禁用状态：字段变灰，按钮失效。
一个三字段表单就有九种不同的视觉状态。对一个有十个字段、每个字段有特定验证条件、字段之间有依赖关系并且带有上下文帮助状态的注册表单，您轻易就会超过五十种视觉状态。
应当让您警觉的问题是：在这些状态中，您当前测试了多少？
对大多数团队的诚实回答是：两到三种。空表单。成功提交后的表单。也许再加上一种错误状态。这只是冰山一角。另外四十七种状态正存在于生产环境中，未经验证，其中任何一种都可能在视觉上破碎而无人知晓。
为什么功能测试对表单是盲的
针对表单的功能测试无处不在。每一套端到端测试套件都包含填写表单并验证数据是否到达服务器的场景。这是必要的。这是不充分的。
针对表单的典型 Selenium 或 Cypress 测试通常会做这件事：用一个无效值填充 email 字段、点击提交、验证 DOM 中出现一个带 "error" 类名的元素。测试通过。所有人都安心了。
但这个测试不验证错误消息是否可读。它不验证错误消息是否定位在正确字段的下方。它不验证字段边框是否变红。它不验证消息是否覆盖了下一个字段。它不验证在移动端，错误消息是否把提交按钮推出了屏幕。
功能测试验证元素是否存在。视觉测试验证它是否可见、可读、定位正确，以及是否破坏了其周围的内容。这两种验证之间的区别，正是「能工作的表单」与「人们真正能用的表单」之间的区别。
表单视觉 bug 的七大类别
在多年观察 Web 表单视觉问题后，某些模式以令人担忧的频率反复出现。
重叠的错误消息
最常见的表单视觉 bug。错误消息出现并与下一个元素重叠。错误文本盖住了下方的字段。或者更糟，它溢出表单容器并覆盖了外部元素。
这个 bug 尤其阴险，因为它取决于错误消息的长度。您的开发者用「必填字段」做的测试。在生产环境，消息变成了「请输入格式为 name@domain.com 的有效电子邮件地址」。这条更长的消息塞不进所分配的空间，于是溢出。
卡住的浮动标签
浮动标签是流行的设计模式：标签起初作为 placeholder 在字段内部，当用户开始输入时「浮」到上方。当它出问题时，是一场视觉灾难。标签可能没有正确上移，仍然叠加在已输入的文字上。
无法访问的提交按钮
在移动端，一个带有错误消息（这些消息会增加内容高度）的表单可能把提交按钮推出可视区域。用户看到错误，却找不到按钮去修正并重新提交。在移动端 viewport 上的视觉测试能以用户视角捕获页面。
不一致的聚焦状态
每个表单字段必须以视觉方式提示自己处于聚焦状态。这是一个无障碍要求（WCAG 2.4.7）。但这种聚焦指示在所有字段类型间的一致性很少被验证。视觉测试可以捕获每种字段类型的聚焦状态并验证视觉一致性。
样式不当的预填字段
当浏览器自动填充表单（autocomplete）时，会施加自己的样式。Chrome 会加一种淡黄色背景，Safari 是蓝色，Firefox 则是更亮的黄色。这些被强加的颜色可能造成对比度不足，或破坏您的设计协调。
不同步的实时验证
现代表单实时验证字段。当这种验证与视觉脱节时：值正确而字段却显示错误消息、在服务端验证之前就出现成功指示、用户在修正时错误消息却不消失。
失去视觉状态的多步表单
多步表单（wizards）必须在步骤间保持视觉一致：正确的进度指示器、回退导航时保留的内容、统一的样式。复现完整流程的视觉测试能检测到这些回归。
视觉破碎的表单真实成本
表单不是普通的组件。它们是您站点的转化点。注册表单把访客变成用户。联系表单把潜在客户变成 leads。结账表单把购物车变成销售。
当一个表单视觉上破碎时，代价不是审美层面的。是财务层面的。根据 Baymard Institute（2024），平均结账放弃率为 70.19%，而界面问题（令人困惑的错误消息、不清晰的导航）占将近四分之一。完成率上每提升一个百分点都对收入有直接影响。
如何构建您表单的视觉测试
从基础状态开始
对每个表单，至少捕获以下六种基础状态：空表单、聚焦中的字段、部分填充、验证错误、提交状态（loading）、成功提交后。
添加错误组合
一个字段错误的表单与五个字段同时错误的表单渲染不同。测试关键组合：所有字段都错、相邻字段错、带有长错误消息的字段。
测试每一个 Viewport
表单是对响应式最敏感的组件。对每个关键表单，至少在三个 viewport 上测试：移动端（375px）、平板（768px）和桌面端（1440px）。
测试视觉无障碍性
错误消息的对比度、聚焦指示器的可见性、标签的可读性、移动端 tap target 的尺寸。一个验证 WCAG AA 对比度阈值的视觉测试能在投入生产前捕获无障碍回归。
您的表单值得更多视觉关注
一个在技术上能工作但视觉上让人困惑的表单，未能完成它的使命。它的使命不是把数据提交到服务器。它的使命是引导用户、安抚用户、帮助他们在没有挫败感的情况下完成目标。这是一项视觉使命，与功能使命同等重要。
自动化视觉测试弥合了功能测试所验证的内容与用户实际体验之间的差距。它把您表单的视觉质量从一种希望转变为一种保证。
因为没人填写的表单，无论技术上多完美，都没有意义。
常见问题
如何在自动化视觉测试中捕获不同的表单状态？
每种状态通过捕获前的模拟交互来触发。对空状态，立即捕获。对聚焦状态，先点击一个字段再捕获。对错误状态，用无效数据提交并在错误消息出现后捕获。对成功状态，用有效数据提交并捕获。
视觉测试能检测错误消息中的对比度问题吗？
通过图像比较的视觉测试能检测任何外观变化，包括影响对比度的颜色变化。对于主动的对比度检查，一些工具集成了直接分析对比度比率的自动 WCAG 检查。
覆盖一份标准表单需要多少视觉测试？
对一个带验证的五字段表单，预计十到十五张视觉截图能提供稳健的覆盖。基础状态六张，关键错误组合三到五张，主要 viewport 三张。
表单视觉测试与 Material UI 或 Ant Design 等组件框架兼容吗？
绝对兼容。视觉测试与框架无关。如果您想要一种快速、无需配置的方式以视觉化方式验证 HTML 渲染，您还可以使用在线 HTML 视觉比较工具。它在与组件库一起使用时尤为有用，因为库的更新（即便很小）可能会在您的代码不变的情况下改变字段外观。
如何处理表单视觉测试中的动态数据？
动态数据应在测试环境中替换为确定性数据。对日期、标识符以及动态生成的内容使用固定值。或者，配置排除区域以忽略带有可变数据的区域。
表单视觉测试是否有助于 GDPR 合规？
间接但显著有助。GDPR 合规要求同意机制清晰可见且易于理解。视觉测试可以验证同意复选框是否显示、其标签是否可读、隐私政策链接是否可见，以及勾选/未勾选状态在视觉上是否清晰区分。
您的表单转化率低于预期？答案可能在视觉上。