Selenium Visual Testing："一种利用 Selenium WebDriver 框架捕获 Web 界面图像并与视觉基准进行比较的方法，旨在检测应用程序外观中的非预期回归。"
Selenium 是全球使用最广泛的自动化测试框架。仅 "selenium webdriver" 一词每月就有超过 22,000 次搜索，这清楚地表明全球 QA 社区在很大程度上仍然围绕这个工具运转。这是有充分理由的：自 2004 年以来，Selenium 定义了"浏览器自动化"的含义。
但这里有一个没人愿意真正听到的问题：Selenium 并非为视觉测试而设计。 它在功能测试方面表现出色——验证按钮是否可用、表单是否提交数据、页面是否正确加载。但当涉及验证页面看起来是否如预期时，Selenium 就像一个被要求评判选美比赛的机器人一样茫然。
本文不是一个承诺 Selenium 能做所有事情的教程。它是一份诚实的指南，探索什么是可行的、什么是痛苦的、以及什么值得更好的解决方案。
目录
- 为什么视觉测试已成为必需
- Selenium 能做什么（不能做什么）
- 方法一：截图与外部比较
- 方法二：第三方插件和库
- 方法三：与 Applitools 集成
- 结论：Selenium 是为功能测试而生的
- 专用的视觉测试替代方案
- 常见问题
为什么视觉测试已成为必需
很长时间以来，软件测试归结为一个二元问题："能用吗？"按钮是否提交了表单？页面是否显示了正确的数据？用户旅程是否以成功支付结束？
这些问题仍然至关重要。但在 2026 年，它们已经不够了。
现代用户在不到 50 毫秒内就会对一个应用做出判断——这是人类大脑形成第一视觉印象所需的时间，来自加拿大卡尔顿大学的一项研究。一个按钮能用但偏移了 20 像素、文字溢出容器、深色主题在灰色背景上显示黑色文字——所有这些在功能意义上都"能用"，但会摧毁用户体验。
视觉测试弥补了这一差距。它验证的不是应用做了什么，而是它展示了什么。在一个界面每个迭代都在变化的世界里，自动检测视觉回归不再是奢侈品——而是必需品。
问题是？像 Selenium 这样的功能测试工具从未为此设计。
Selenium 能做什么（不能做什么）
Selenium WebDriver 在其设计用途上是一个出色的工具：驱动浏览器并与 Web 元素交互。它能点击、输入、导航、等待，并验证 DOM 中元素的存在或内容。
Selenium 在视觉方面能做的事情恰好只有一件：takeScreenshot()。这个方法将浏览器当前状态捕获为 PNG 图像。仅此而已。没有比较、没有差异、没有容差阈值、没有动态区域遮罩。
这就像给你一台相机然后告诉你"好了，你是专业摄影师了"。捕获工具有了，但所有创意和技术工作还得你自己做。
以下是 Selenium 原生不能做的事情：
- 比较两张截图
- 检测页面两个版本之间的视觉差异
- 管理参考图像（baselines）
- 过滤视觉噪声（anti-aliasing、动画、动态内容）
- 生成视觉差异报告
- 在变更是有意的时候自动更新参考
要实现这些，需要自建或集成。让我们看看有哪些选择。
方法一：截图与外部比较
最基本的方法——也是最痛苦的——是使用 Selenium 的 takeScreenshot() 捕获图像，然后用图像处理库进行比较。
原理
你用 Selenium 对页面截图，将其存储为参考。下次运行测试时，再截一张新图并与参考逐像素比较。如果差异超过特定阈值，测试就失败。
常用比较工具
多个开源库支持图像比较：pixelmatch（JavaScript）、Pillow 或 scikit-image（Python）、ImageMagick（命令行）。每个都有其优势，但没有一个是专门为 Web 界面测试设计的。
你需要自己构建的部分
实际上，这种方法迫使你成为一个迷你视觉测试框架的架构师。你必须管理参考图像的存储和版本控制、可配置阈值的比较逻辑、动态区域的遮罩（日期、广告、个性化内容）、不同分辨率和视口大小的处理、展示差异的可操作报告，以及在变更是有意的时候更新参考的工作流。
局限性
这是控制力最强的方法，但也是投入最大的。你花在维护视觉测试基础设施上的时间比写真正的测试还多。而每次浏览器更新、每次字体渲染变化都可能产生淹没真实回归的误报。
想象一个助手，不是帮你找文档中的错误，而是花时间在每个逗号下画线问你它是否在正确的位置。技术上严谨，实际上无法忍受。
方法二：第三方插件和库
为了避免从零开始构建一切，社区创建了在 Selenium 之上添加视觉测试能力的库。其中最知名的有：
Ashot（Java）
Ashot 是一个 Java 库，扩展了 Selenium 的截图能力。它支持全页截图（包括通过滚动获取屏幕外的内容）、带差异高亮的图像比较，以及按特定元素裁剪。
它是 Java/Selenium 生态系统中最流行的选择，但仍然是一个底层工具。你有了砖块，但房子得自己建。
needle（Python）
needle 是一个 pytest 插件，将 Selenium 与图像比较集成。它比较整页或特定元素的截图，使用 Pillow 进行比较，并与 pytest 干净地集成。
该项目经历过不活跃期，文档可能不完善。对于简单需求是一个合理的选择，但在实际项目中显示出其局限性。
BackstopJS
BackstopJS 并不完全是 Selenium 插件——它是一个独立工具，底层使用 Puppeteer 或 Playwright。但值得一提，因为许多 Selenium 团队将其作为视觉测试的补充。
BackstopJS 提供 JSON 声明式配置、多视口截图、交互式 HTML 报告，以及变更的 approve/reject 工作流。
它可能是最成熟的视觉测试开源工具。但它不与你现有的 Selenium 测试直接集成——它是一个有自己 pipeline 的独立工具。
插件的共同局限
所有这些工具都有共同的基本局限。它们需要开发技能来设置和维护。依赖于无法保证持续性的开源项目——一个维护者换工作，整个生态系统就会减速。它们在你的技术栈中增加复杂性，却不解决逐像素比较的结构性问题。最重要的是，它们仍然是开发者工具，团队其他人无法使用。
方法三：与 Applitools 集成
第三条路是与专门的视觉测试 SaaS 集成。Applitools Eyes 是这个类别中最知名的。
原理
Applitools 提供直接与 Selenium 集成的 SDK。你现有的 Selenium 测试通过 Applitools API 调用得到增强，将截图发送到他们的云端进行比较。
Applitools 带来的价值
Applitools 使用基于 AI 的比较技术（他们的 "Visual AI"），比逐像素比较智能得多。它理解页面结构，忽略无关紧要的差异，以极低的误报率检测真实回归。
云端仪表板允许整个团队（不仅仅是开发者）查看结果、批准变更和跟踪视觉测试状态。
局限性
舒适是有代价的。Applitools 是付费云服务，成本随截图量增长。你的界面图像离开你的基础设施到他们的服务器处理——对某些组织来说是敏感问题。而且你依赖于第三方服务：如果 Applitools 宕机，你的视觉测试也会中断。
SDK 集成还意味着你仍然需要编写和维护 Selenium 测试。你简化了比较，但没有简化截图场景的创建。比自己做一切要好，当然——就像用 GPS 代替纸质地图，路线一样但不容易迷路。
结论：Selenium 是为功能测试而生的
探索了三种方法后，结论很明确：Selenium 是一个功能测试工具，试图给它嫁接视觉测试能力，就像在摩托车上装自行车架——能撑住，但这不是原始设计。
每种方法都有其优点，但没有一个解决根本问题：视觉测试和功能测试是两个不同的学科，值得拥有不同的工具。
功能测试验证行为。它问的是"它做了它该做的事吗？"DOM、事件、数据——这是 Selenium 的领地，它在这里表现出色。
视觉测试验证外观。它问的是"它看起来像它该有的样子吗？"像素、布局、渲染——这是 Selenium 以游客身份访问的领地。
继续用 Selenium 做功能测试吧。它是合适的工具。但对于视觉测试，认真考虑一个从一开始就为此任务设计的工具。
专用的视觉测试替代方案
Delta-QA 的存在正是因为视觉测试不应该是功能测试的临时拼凑副产品。它是一个专用工具，从第一行代码就为视觉回归检测而设计。
以下是专用方法带来的改变：
真正的无代码：你不需要 Selenium、WebDriver 或任何编程技能。你指向你的页面，Delta-QA 完成剩下的工作。你的 QA 分析师、设计师、产品负责人——每个人都可以启动和解读视觉测试。
智能比较：Delta-QA 不仅仅比较像素。它理解有意义的差异并过滤技术噪声（anti-aliasing、渲染差异、动态内容）。结果：更少的误报，检测到更多真实回归。
本地执行：你的截图留在你的基础设施上。没有数据发送到第三方云端，没有对外部服务的依赖，没有随量增长的账单。
免费且无人为限制：没有解锁基本功能的 "enterprise" 层级，没有迫使你限制测试的截图计数器。
与 Selenium 互补：Delta-QA 不替代你的 Selenium 功能测试。它通过覆盖 Selenium 无法原生处理的视觉维度来补充它们。
视觉测试太重要了，不能被当作最后一刻的附加品。用户在与界面交互之前先看到它。如果界面在视觉上是坏的，他们不会停留足够长的时间来发现你所有的功能测试都通过了。
常见问题
Selenium 能原生进行视觉测试吗？
不能。Selenium WebDriver 允许通过 takeScreenshot() 截图，但不提供任何原生的图像比较、视觉参考管理或回归检测功能。一切都需要自建或与第三方工具集成。
与 Selenium 配合使用的最佳视觉测试库是什么？
取决于你的生态系统。Java 中，Ashot 是最常见的选择。Python 中，needle 提供 pytest 集成。更完整的解决方案通常首选 BackstopJS（它使用 Puppeteer/Playwright 而非 Selenium）。这些解决方案都不如 Playwright 原生提供的那样集成。
Applitools 的视觉测试值得其成本吗？
Applitools 的 Visual AI 技术令人印象深刻，显著减少误报。对于预算充裕、要求高的大型企业，这是一个可靠的选择。对于较小的团队或关注数据隐私的团队，成本和云依赖可能是不可接受的。存在像 Delta-QA 这样本地、免费的替代方案。
应该为了视觉测试而放弃 Selenium 吗？
不应该。Selenium 在功能测试方面仍然出色，应该继续扮演这个角色。理念不是替换 Selenium，而是用专用的视觉测试工具来补充它。两个学科是互补的，最好的结果来自为每个需求使用正确的工具。
如果有完善的功能测试，视觉测试真的还有必要吗？
绝对有必要。功能测试验证行为（按钮能用吗？）但不验证外观（按钮可见吗？位置正确吗？颜色对吗？）。根据 HTTP Archive 的 Web Almanac，布局问题占用户报告的 bug 中很大比例——这些 bug 功能测试永远无法检测到。
Delta-QA 与 Selenium + Applitools 方法相比如何？
Delta-QA 是无代码的（不需要 Selenium 或 SDK）、本地的（没有第三方云）且免费。Selenium + Applitools 方法需要开发技能，将数据发送到 Applitools 云端，并涉及持续成本。Delta-QA 专为希望视觉测试对所有人可用、无外部依赖的团队而设计。
延伸阅读
准备好将视觉测试从功能测试中分离出来了吗？