接口全绿、数据库也对，页面还是出了P1：DeepSeek视觉模型到底在测什么？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

有一种Bug，最容易让测试工程师怀疑人生：

接口测过了。

数据库查过了。

自动化回归也是绿的。

甚至开发信誓旦旦地说：

“后端返回的数据肯定没问题。”

结果产品经理打开页面，只看了一眼：

“这个版本不能上。”

问题出在哪？

不是接口500。

不是数据库脏数据。

不是按钮点不了。

而是——

用户看到的东西错了。

这也是上一期我们聊完DeepSeek视觉模型之后，我觉得更值得继续往下讨论的问题：

当多模态模型开始进入UI自动化，它真正应该解决的，并不是“帮测试工程师看截图”，而是过去传统自动化很难理解的“页面业务语义”。

今天不讲Demo。

直接看一个真实业务里非常典型的场景。

一、一个很普通的电商结算需求
假设现在要测试一个商城结算页。

用户购买一件1000元的商品。

业务规则：

商品原价：1000元

VIP优惠：-100元

优惠券：-50元

运费：+10元

最终应付：860元
后端接口返回：

{
"original_price": 1000,
"member_discount": 100,
"coupon_discount": 50,
"shipping_fee": 10,
"pay_amount": 860
}
接口自动化怎么写？

非常简单：

def test_checkout_amount(data):

expected = (
data["original_price"]
- data["member_discount"]
- data["coupon_discount"]
+ data["shipping_fee"]
)

assert expected == data["pay_amount"]
结果：

expected = 860
actual = 860

PASS
再查数据库：

SELECT
order_id,
original_price,
discount_amount,
shipping_fee,
pay_amount
FROM orders
WHERE order_id = 'ORDER_10086';
结果：

original_price = 1000
discount = 150
shipping_fee = 10
pay_amount = 860
还是：

PASS。

到这里，大部分传统接口测试都会认为：

订单金额计算没问题。

二、再加一层UI自动化，还是绿的
我们继续用Playwright验证页面。

from playwright.sync_api import expect

def test_checkout_page(page):

page.goto(
"https://test.example.com/checkout"
)

expect(
page.get_by_test_id("original-price")
).to_have_text("¥1000")

expect(
page.get_by_test_id("discount")
).to_have_text("-¥150")

expect(
page.get_by_test_id("shipping")
).to_have_text("¥10")

expect(
page.get_by_test_id("pay-amount")
).to_have_text("¥860")
全部通过。

现在已经有三层证据：

API PASS

Database PASS

DOM PASS
按传统自动化测试的逻辑，这个Case基本可以结束了。

但是实际页面可能长这样：

商品原价 ¥1000

会员+优惠券 -¥150

运费 ¥10

---

应付金额 ¥860
¥1000

[ 提交订单 ]
问题来了。

¥860下面，又叠了一个¥1000。

对于测试脚本来说：

pay-amount = 860

确实存在。

所以PASS。

但是对于用户来说，他现在看到的是：

我到底要付860，还是1000？

如果这是支付确认页，这已经不是一个普通“样式不好看”的Bug。

它可能直接影响：

用户是否敢点击支付。

这就有可能升级成真正的高优先级问题。

三、为什么DOM正确，页面还能错？
这其实又是一道很适合测试开发面试的问题：

接口正确、DOM正确，能不能证明页面一定正确？

答案当然是：

不能。

但为什么？

因为页面最终呈现给用户的不是：

¥860

而是浏览器经过：

HTML
+
CSS
+
字体
+
布局
+
响应式规则
+
组件状态
+
浏览器渲染
最终生成的视觉结果。

所以：

数据正确
≠
DOM正确
≠
渲染正确
≠
用户理解正确
这四层其实是不同的测试对象。

而过去大量自动化测试主要覆盖的是前面两三层。

最后这一层：

用户看到以后会怎么理解？
一直非常依赖人工测试。

这恰恰是多模态模型真正有机会补上的地方。

四、DeepSeek视觉模型真正应该看的，不只是“有没有重叠”
如果我们只是问：

页面有没有元素重叠？

其实还是把多模态模型当成一个高级图像识别器。

更有价值的Prompt应该带上：

业务上下文。

例如把结算页截图交给模型，同时告诉它：

这是电商订单提交页面。

业务规则：

商品原价：1000元
优惠金额：150元
运费：10元
最终应付金额：860元。

请从真实用户支付决策的角度检查截图。

重点判断：

1. 最终支付金额是否明确
2. 原价、优惠、实付价的视觉层级是否合理
3. 是否存在金额重复、遮挡或重叠
4. 是否可能导致用户误解实际付款金额
5. “提交订单”按钮与支付金额之间是否存在歧义

请输出风险等级及原因。
模型如果识别到异常，可以返回：

{
"passed": false,
"severity": "P1",
"issue_type": "payment_amount_confusion",
"expected": "¥860应为唯一突出展示的实付金额",
"actual": "¥860下方同时出现¥1000",
"risk": "用户可能误认为最终付款金额为1000元"
}
这里就出现了一个非常重要的变化。

过去视觉测试问：

哪里变了？

现在开始问：

这个变化对业务意味着什么？

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

五、但AI说这是P1，你就真的提P1吗？
还是不能。

这一点特别重要。

多模态模型可以成为“异常发现器”，但不能天然成为最终裁判。

因为模型也可能看错。

所以真正企业级的AI视觉测试，需要建立：

证据链。
模型发现：

“页面存在两个可能的支付金额。”

下一步不是自动创建P1 Bug。

而是让测试系统继续调查。

第一步：确认后端金额到底是多少
import requests

def get_checkout(order_id):

response = requests.get(
f"https://test-api.example.com/orders/{order_id}"
)

response.raise_for_status()

return response.json()

order = get_checkout(
"ORDER_10086"
)

assert order["pay_amount"] == 860
后端：

860

PASS
说明：

金额计算没有问题。

第二步：检查DOM到底出现了几个金额
prices = page.locator(
"[data-testid*='price']"
).all_inner_texts()

print(prices)
得到：

[
"¥1000",
"-¥150",
"¥10",
"¥860",
"¥1000"
]
等等。

正常应该出现4个价格信息。

为什么现在有5个？

于是我们继续找。

price_elements = page.locator(
"[data-testid*='price']"
)

for i in range(price_elements.count()):

item = price_elements.nth(i)

print(
item.inner_text(),
item.get_attribute("data-testid"),
item.bounding_box()
)
发现最后一个：

text:
¥1000

testid:
legacy-original-price

position:
x=1180
y=682
而：

¥860

x=1178
y=670
两个元素几乎叠在一起。

到这里，我们已经基本知道问题在哪了：

旧版价格组件没有正确隐藏。

六、这才是“AI发现Bug”和“AI测试开发”的区别
如果只是：

截图
↓
DeepSeek
↓
发现金额重叠
这只能叫：

AI辅助测试。

但如果继续做到：

截图
↓
视觉模型发现异常
↓
API验证
↓
DOM取证
↓
元素定位
↓
组件归因
↓
缺陷报告
就开始进入真正的：

AI测试开发。
最终系统甚至可以自动生成这样的Bug：

{
"title": "结算页实付金额区域重复展示商品原价",

"severity": "P1",

"order_id": "ORDER_10086",

"expected_pay_amount": 860,

"actual_api_amount": 860,

"visual_issue": "¥1000与¥860在实付区域发生视觉重叠",

"backend_status": "正常",

"suspected_module": "CheckoutPriceSummary",

"suspected_cause": "legacy-original-price组件未正确隐藏",

"evidence": [
"checkout.png",
"api-response.json",
"dom-snapshot.json"
]
}
测试工程师第二天看到的不再只是：

“视觉模型认为页面可能有问题。”

而是：

问题在哪、业务影响是什么、后端是否正常、疑似哪个组件、证据在哪里。

这个价值完全不一样。

七、再往深一点：为什么这种Bug特别适合多模态AI？
因为它同时横跨了三种“正确”。

第一种：数据正确
1000 - 150 + 10 = 860
程序最擅长。

直接Assert。

第二种：功能正确
页面有没有860？

按钮能不能点？

流程能不能提交？

Playwright最擅长。

第三种：语义正确
用户能不能一眼知道：

到底应该支付多少钱？

这件事情传统自动化很难表达。

你当然可以写几十条CSS规则：

assert font_size(pay_amount) > font_size(original_price)
再写：

assert not overlap(
pay_amount,
original_price
)
再写：

assert color_contrast(...)
但是页面复杂以后，规则会越来越多。

而视觉模型真正擅长的恰恰是：

从整体页面理解信息之间的关系。

这才是它应该待的位置。

八、所以未来UI自动化，很可能会出现“双轨验证”
以前：

UI自动化
↓
DOM
↓
业务断言
以后可能逐渐变成：

Playwright
↓
页面真实执行
↓
┌─────────┴─────────┐
↓ ↓
事实验证 视觉验证
↓ ↓
API / DOM / DB Screenshot
↓ ↓
Deterministic Vision Model
↓ ↓
└─────────┬─────────┘
↓
Evaluator
↓
测试结论
左边回答：

系统事实上发生了什么？

右边回答：

用户实际上看到了什么？

最后再把两边合起来。

我认为这比单纯喊：

“AI要替代传统UI自动化。”

靠谱得多。

因为真正成熟的AI测试体系，反而会更依赖传统测试能力。

九、这也是初级测试工程师特别值得理解的一件事
现在很多人学AI测试，路线很容易变成：

Prompt
↓
RAG
↓
Agent
↓
MCP
↓
多模态
这些当然可以学。

但如果面试官突然问：

接口返回正确，为什么页面还能错？

DOM里金额正确，为什么还要做视觉测试？

大模型判断页面有Bug，为什么不能直接作为测试结论？

怎么证明一个视觉Bug到底是后端、前端数据还是CSS渲染问题？

如果这些问题讲不清楚，那么即使知道十个Agent框架，也很难真正做好AI测试开发。

AI时代没有让传统测试知识失效。

反而把一个优秀测试工程师最核心的能力重新放大了：

你到底会不会找证据。
写在最后
DeepSeek视觉模型进入测试以后，我觉得最容易出现的误区就是：

“以后截图扔给AI，让它帮我找Bug。”

这个想法做Demo没问题。

但距离企业级AI测试还差得很远。

真正有价值的链路应该是：

AI发现异常 → 自动化工具验证 → API/DOM/DB取证 → 判断业务影响 → 定位问题 → 输出报告。

AI负责：

发现过去自动化不容易发现的异常。

传统测试工具负责：

证明这个异常到底是不是真的。

而测试工程师负责的，是最重要的那一层：

定义什么才算真正的业务错误。

这也是为什么我一直觉得，多模态模型不会让测试开发的基本功变得不重要。

恰恰相反。

以前你只需要知道：

assert actual == expected
现在你还需要知道：

Expected到底应该从哪里来。

接口？

数据库？

需求？

设计稿？

业务规则？

还是用户最终看到的页面？

当一个测试工程师开始能够把这些东西组合成完整的证据链，他做的就已经不再只是：

“AI帮我看截图。”

而是在构建真正的：

AI视觉质量工程。
推荐学习
DeepSeek Harnesst智能体公开课：

🔥 DeepSeek Agent架构深度拆解——“一切皆插件”到底怎么实现🔥 四大主流Agent横向对比：Opencode/Codex/Claude Code/Openclaw🔥 Harness插件体系全解析：Web自动化+App自动化+视觉驱动自动化

一夜5万星的Agent框架，到底能做什么？一次讲透。

扫码进群，报名学习！

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。