做过Web/App测试的人，应该都遇到过这种场景：
接口是200。
DOM存在。
按钮能点。
自动化Case全部通过。
结果产品打开页面看了一眼：
“这个按钮都被挡住一半了，你们没测出来？”
测试工程师再打开自动化报告：
login_test PASS
checkout_test PASS
payment_test PASS
全部绿得很漂亮。
但真实页面里：
按钮确实被遮挡了。
文字确实截断了。
金额确实重叠了。
这就是传统UI自动化一直存在的一个天然盲区：
它很擅长判断“元素在不在、能不能点”，却不一定知道“用户最终看到的页面到底对不对”。
而8月21日，DeepSeek上线首个V4系列多模态视觉理解实验模型 V4-Flash-Vision-Exp。
它真正值得测试工程师关注的，不只是“DeepSeek也能看图了”。
而是：
截图，开始有机会成为AI测试里一个真正低成本、可工程化的输入。
一、先说一个大家都遇到过、但很少想深的问题
假设你现在负责一个商城登录页面。
传统Playwright代码可能是这样：
from playwright.sync_api import expect
def test_login(page):
page.goto("https://test.example.com/login")
page.get_by_label("用户名").fill("tester")
page.get_by_label("密码").fill("123456")
page.get_by_role(
"button",
name="登录"
).click()
expect(page).to_have_url(
"https://test.example.com/home"
)
这段代码能证明什么？
很简单：
用户能够完成登录流程。
但是假设页面因为CSS问题，变成了这样：
用户名 [__]
密码 [__]
登 录 登 录 登...
按钮文字被截断。
或者移动端出现：
┌────────────────────┐
│ │
│ 提交订单 │
│ │
████████ 固定底栏 █████
提交按钮有一部分被Fixed Footer挡住。
但DOM里：
按钮存在。
Playwright也能定位。
甚至脚本仍然能成功执行：
page.get_by_role(
"button",
name="提交订单"
).click()
最后Case：
PASS
可真实用户看到的页面：
已经出了问题。
二、所以面试官问“UI自动化能不能覆盖所有UI问题”，别只回答“不能”
这道题很多初级测试工程师都会遇到。
最常见的回答是：
不能，有些样式问题自动化测不到。
没错。
但如果面试里只回答到这里，基本还是停留在表面。
更深一层其实是：
传统UI自动化主要验证DOM、交互行为和业务状态，而用户看到的是浏览器最终渲染结果，两者并不是同一个测试对象。
换句话说：
DOM正确
≠
页面一定正确
再进一步：
按钮可点击
≠
用户一定能正常看到
以及：
文字存在
≠
文字没有发生截断
很多UI Bug，本质上不是“元素不存在”。
而是：
元素之间的视觉关系错了。
这也是为什么视觉回归测试一直有价值。
三、那传统视觉回归为什么一直让测试工程师又爱又恨？
Playwright其实很早就支持截图断言。
比如：
await expect(page).toHaveScreenshot(
'login-page.png'
)
如果页面变化，就会生成Diff。
还可以允许一定误差：
await expect(page).toHaveScreenshot(
'login-page.png',
{
maxDiffPixelRatio: 0.01
}
)
也可以把动态区域Mask掉：
await expect(page).toHaveScreenshot({
mask: [
page.getByTestId('avatar'),
page.getByTestId('timestamp')
]
})
看起来已经很完善。
但真正落地以后，很多团队会遇到一个痛点：
误报太多。
字体渲染变化。
浏览器版本变化。
时间戳变化。
头像变化。
广告位变化。
一个像素位置轻微偏移。
最后：
100条视觉Case
48 FAILED
测试工程师人工打开48张Diff图。
发现：
47张其实不是Bug。
这就是传统Pixel Diff最大的问题：
它知道哪里“不一样”，却不知道这个“不一样”到底重不重要。
四、这正是多模态模型开始有价值的地方
以前视觉回归更像：
页面截图
↓
Pixel Diff
↓
PASS / FAIL
现在可以多加一层：
页面截图
↓
视觉变化检测
↓
DeepSeek Vision
↓
语义判断
↓
风险分级
最重要的一点是：
不要让视觉大模型完全替代Pixel Diff。
更合理的思路应该是：
Pixel负责找不同，视觉模型负责理解“这个不同有没有业务意义”。
举个最简单的例子。
基线图：
订单金额：¥999
新页面：
订单金额：¥999
只是字体位置偏了2像素。
传统视觉Diff：
FAILED
但其实业务完全正常。
反过来：
基线：
确认支付 ¥999
新页面：
确认支付 ¥99
可能只少了一个数字。
像素变化比例不一定很大。
但这是非常严重的业务Bug。
所以：
像素差异大小，不等于业务风险大小。
这恰恰是多模态视觉模型可以补上的能力。
五、最小实战：截图直接交给视觉模型分析
第一步还是Playwright。
from playwright.sync_api import sync_playwright
def capture_page():
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page(
viewport={
"width": 1440,
"height": 900
}
)
page.goto(
"https://test.example.com/login"
)
page.screenshot(
path="login.png",
full_page=True
)
browser.close()
接下来，把截图变成模型可以消费的输入。
import base64
def image_to_base64(path):
with open(path, "rb") as f:
return base64.b64encode(
f.read()
).decode("utf-8")
然后给视觉模型一个明确的测试任务。
例如：
你是一名UI测试工程师。
请检查截图中是否存在：
- 文本截断
- 控件重叠
- 按钮被遮挡
- 输入框显示异常
- 间距严重错误
- 文案显示不完整
- 影响正常操作的视觉问题
请返回JSON结构。
我们期待模型给出的不是一句：
“页面看起来有问题。”
而是更结构化的结果：
{
"passed": false,
"issues": [
{
"type": "button_occlusion",
"element": "提交订单按钮",
"severity": "high",
"description": "按钮底部区域被固定导航遮挡",
"impact": "可能影响移动端用户点击"
}
]
}
这时候测试报告的价值就完全不同了。
过去：
Pixels differ: 18273
现在：
提交订单按钮存在遮挡风险
严重级别：High
可能影响：移动端点击
对测试工程师来说，显然后者更接近真实工作。
六、但这里马上又会出现一道更重要的面试题
面试官：
视觉模型说按钮被遮挡了，你直接提Bug吗？
答案一定应该是：
不能。
因为大模型也是概率模型。
它可能：
误判。
漏判。
幻觉。
所以真正的AI视觉测试绝对不能设计成：
模型说有Bug
↓
自动提Bug
而应该变成：
视觉模型发现异常
↓
程序继续取证
↓
确定性规则验证
↓
风险分级
↓
输出缺陷报告
例如模型说：
“提交按钮可能超出可视区域。”
那我们继续用Playwright取Bounding Box。
button = page.get_by_role(
"button",
name="提交订单"
)
box = button.bounding_box()
viewport = page.viewport_size
print(box)
print(viewport)
假设得到：
button y = 780
button height = 70
viewport height = 800
那么就可以计算：
button_bottom = (
box["y"] + box["height"]
)
if button_bottom > viewport["height"]:
raise AssertionError(
"提交按钮超出可视区域"
)
这时候证据链就完整了。
模型负责：
发现问题。
程序负责：
证明问题。
七、这才是多模态模型进入测试的正确姿势
很多人看到视觉模型，会自然想到：
以后是不是可以不用写UI自动化了？
我反而觉得完全不是。
真正合理的组合应该是：
Playwright
+
截图
+
Pixel Diff
+
视觉模型
+
确定性断言
其中：
Playwright负责执行。
Pixel Diff负责低成本筛查。
视觉模型负责语义理解。
传统断言负责最终事实验证。
这几个东西不是互相替代关系。
而是：
互相补盲区。
尤其对于测试开发工程师来说，真正值得研究的不是：
“DeepSeek能不能看懂一张图。”
而是：
如何把视觉能力接进原来的自动化测试工程体系里。
写在最后
过去UI自动化最擅长回答的是：
“这个按钮存在吗？”
以后我们有机会继续往前问一步：
“用户真正看到的按钮，到底是不是正常的？”
这两个问题看起来差别不大。
背后其实是两类完全不同的测试能力。
以前：
Selector
+
Action
+
Assert
接下来可能越来越多变成：
Screenshot
+
Vision Model
+
Semantic Assertion
+
Evaluator
但有一条原则始终不会变：
不要把所有判断权交给大模型。
让AI去做它擅长的：
看。
理解。
发现异常。
让程序继续负责：
取事实。
做计算。
验状态。
给证据。
真正有价值的AI视觉测试，不是：
“大模型帮测试工程师看截图。”
而是：
让视觉模型发现过去自动化根本不知道应该看的问题，再用传统测试工具证明它到底是不是Bug。
这可能才是DeepSeek视觉模型对测试开发真正值得关注的地方。
而下一篇，我们会进入一个更复杂、更接近真实业务的问题：
接口正确、数据库正确、DOM也正确，为什么电商结算页依然可能出现P1级Bug？
那才是多模态视觉测试真正开始体现业务价值的地方。
