多模态大模型怎么用于测试？只回答“看截图找Bug”，面试基本就说浅了
关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集
前两天聊DeepSeek视觉模型的时候，有个问题我觉得特别适合拿出来单独说。
如果现在面试AI测试开发岗位，面试官问你：
“多模态大模型怎么应用到软件测试？”
很多人的第一反应可能是：
可以把页面截图传给大模型，让AI识别UI异常，比如按钮遮挡、文字截断、页面错位，还可以做视觉回归。
这当然没错。
但如果我是面试官，听到这里，大概只能给：
50～60分。
因为这证明你知道多模态模型“能干什么”。
却没有回答真正困难的问题：
公司每天跑5000条自动化Case，产生上万张截图，你准备全部扔给大模型吗？
模型说页面有Bug，你敢直接阻断发布吗？
今天准确率90%，明天换了模型变成85%，你怎么知道？
视觉模型一天误报300次，测试团队还会继续用吗？
这几个问题，才是多模态AI测试从：
“我会调用API”
走向：
“我能设计AI测试系统”
真正的分水岭。
一、先算一笔很多Demo不会算的账
假设你负责一个中型电商系统。
每天夜间回归：
2000条 Web Case
+
1000条 App Case
平均每条Case在5个关键节点截图。
那么一天就是：
3000 × 5
= 15000张截图
如果还有：
Chrome。
Edge。
iOS。
Android。
不同分辨率。
图片数量很容易继续翻倍。
最简单粗暴的方案是什么？
15000张截图
↓
全部调用视觉模型
↓
让AI判断PASS / FAIL
Demo当然可以这么做。
企业里很快就会碰到三个问题：
成本。
速度。
误报。
所以真正的工程化第一步，不是研究一个更复杂的Prompt。
而是：
别让AI看所有图片。
二、第一层：传统自动化能解决的，别调用大模型
比如：
按钮存不存在。
expect(
page.get_by_role(
"button",
name="提交订单"
)
).to_be_visible()
接口金额是不是860。
assert response["pay_amount"] == 860
订单状态是不是PAID。
assert order["status"] == "PAID"
数据库有没有数据。
assert order_record is not None
这些全部属于：
确定性问题。
没必要问大模型：
“你觉得订单是不是支付成功了？”
程序明明可以100%确定。
为什么要交给一个概率模型？
所以第一条原则就是：
能用确定性断言解决的问题，不要为了AI而AI。
三、第二层：先用Pixel Diff做便宜的“门卫”
视觉回归也是一样。
假设有10000张截图。
可以先跑传统视觉Diff。
伪代码：
def visual_pipeline(
baseline,
actual
):
diff_ratio = pixel_diff(
baseline,
actual
)
if diff_ratio < 0.002:
return {
"status": "PASS",
"reason": "视觉变化极小"
}
return vision_review(
baseline,
actual
)
逻辑非常简单：
截图
↓
Pixel Diff
↓
变化很小？
↙ ↘
YES NO
↓ ↓
PASS 视觉模型
假设：
10000张截图
经过第一层过滤，只剩：
800张
需要视觉模型分析。
这时候成本结构已经完全不同了。
所以传统视觉回归不会因为多模态模型出现就消失。
恰恰相反：
它会成为AI视觉测试非常重要的第一层过滤器。
四、但Pixel Diff大，也不代表一定是Bug
比如一个商城首页。
昨天推荐商品是：
iPhone
MacBook
耳机
今天变成：
相机
显示器
键盘
截图变化巨大。
Pixel Diff：
35%
但这是正常业务数据。
还有：
用户名。
头像。
时间。
订单号。
广告Banner。
库存数量。
倒计时。
这些区域天然是动态的。
所以自动化里本来就应该：
Mask动态区域。
例如Playwright：
await expect(page).toHaveScreenshot({
mask: [
page.getByTestId('avatar'),
page.getByTestId('timestamp'),
page.getByTestId('banner')
]
})
这件事情看起来很传统。
但非常重要。
因为一个AI测试系统真正成熟的标志，不是：
“什么都让AI处理。”
而是：
尽量减少需要AI处理的问题。
五、第三层：真正高风险的页面，反而应该主动让AI看
并不是所有页面价值都一样。
比如：
个人中心背景图发生轻微偏移。
和：
支付金额发生轻微偏移。
显然不是一个风险等级。
所以可以给页面建立风险标签：
PAGE_RISK = {
"home":
"LOW",
"product_detail":
"MEDIUM",
"checkout":
"HIGH",
"payment":
"CRITICAL"
}
然后设计策略：
def need_vision_check(
page_name,
diff_ratio
):
risk = PAGE_RISK[
page_name
]
if risk == "CRITICAL":
return True
if risk == "HIGH":
return diff_ratio > 0.001
if risk == "MEDIUM":
return diff_ratio > 0.01
return diff_ratio > 0.05
这样：
支付页。
结算页。
风控提示。
合同确认。
订单提交。
这类高风险区域可以强制进入：
视觉语义检查。
而普通页面只在变化超过阈值以后才调用。
这就是：
Risk-Based Visual Testing
测试工程师应该很熟悉。
因为本质上还是我们一直在讲的：
基于风险分配测试资源。
只不过现在资源从：
“测试人员时间”
变成了：
“模型Token和推理成本”。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
六、还有一个特别容易踩坑的问题：长截图
很多人第一次做视觉AI测试：
page.screenshot(
path="page.png",
full_page=True
)
然后直接：
整张图扔给模型。
一个5000像素高的电商页面里面可能有：
Header。
搜索。
Banner。
商品。
优惠券。
地址。
支付方式。
金额。
Footer。
你真正想检查的是：
支付金额。
却让模型分析整个页面。
这其实非常浪费。
更好的方式是：
按业务区域截图。
比如：
payment_panel = page.locator(
"[data-testid='payment-summary']"
)
payment_panel.screenshot(
path="payment-summary.png"
)
优惠区域：
coupon_panel = page.locator(
"[data-testid='coupon-panel']"
)
coupon_panel.screenshot(
path="coupon-panel.png"
)
提交区域：
submit_panel = page.locator(
"[data-testid='submit-area']"
)
submit_panel.screenshot(
path="submit-area.png"
)
于是：
一个巨大页面
↓
支付区域
优惠区域
提交区域
↓
分别做语义检测
不仅成本更低。
模型判断通常也会更聚焦。
七、做到这里还不够：视觉模型自己也必须被测试
这是我认为AI测试开发岗位未来特别容易出现的一道面试题：
你怎么证明你的视觉测试模型是可靠的？
不能回答：
“我拿十几张截图试了一下，感觉挺准。”
企业不会接受“感觉挺准”。
必须建立：
Evaluation Dataset
例如准备1000张经过人工标注的截图：
dataset = [
{
"image":
"normal_login.png",
"label":
"normal"
},
{
"image":
"button_occluded.png",
"label":
"bug"
},
{
"image":
"price_overlap.png",
"label":
"bug"
},
{
"image":
"dynamic_banner.png",
"label":
"normal"
}
]
里面故意放各种情况：
按钮遮挡。
文字截断。
金额错误。
字体轻微变化。
Banner变化。
动态时间。
正常响应式变化。
真正CSS异常。
然后让模型全部跑一遍。
八、这时候Precision和Recall就来了
假设：
真正有Bug：
100张
模型找到：
90张
那么：
Recall = 90%
意味着：
还有10%的Bug没发现。
反过来。
模型判断：
120张有Bug
其中真正有Bug只有：
90张
那么：
Precision = 75%
意味着：
测试工程师收到120条报警。
里面：
30条是假警报。
这两个指标哪个重要？
要看业务。
如果是：
支付金额页面。
你可能更关心Recall。
宁可多报几个，也不能漏掉严重问题。
如果是：
普通内容页面。
你可能更在意Precision。
否则每天几百条假告警，测试人员很快就会产生：
告警疲劳。
最后真正的Bug来了，大家也懒得看了。
九、所以AI测试真正需要监控的，绝不只是“准确率”
我建议至少关注这些：
metrics = {
"precision": 0.91,
"recall": 0.94,
"f1_score": 0.925,
"false_positive_rate": 0.06,
"false_negative_rate": 0.04,
"avg_latency": 1.8,
"avg_token_cost": 320
}
为什么还要看：
Latency？
因为你的CI/CD不能因为视觉模型：
每张图片等30秒。
为什么看：
Token Cost？
因为：
100张图
和：
每天10万张图
完全不是一个工程问题。
这也是为什么DeepSeek这次视觉模型把调用成本继续往下压，对测试行业其实很重要。
模型能力决定“能不能做”。
但：
模型成本决定“能不能大规模做”。
十、还有一个很多初级工程师容易忽略的问题：Prompt也要回归测试
假设原来Prompt：
判断截图是否存在UI异常。
效果一般。
你优化成：
检查：
- 元素遮挡
- 文本截断
- 金额展示
- 按钮可见性
- 信息层级
重点关注影响用户完成核心业务流程的问题。
感觉效果变好了。
然后直接上线？
还是不行。
应该：
Prompt V1
↓
固定数据集
↓
Precision / Recall
Prompt V2
↓
同一数据集
↓
Precision / Recall
例如：
V1 V2
Precision 82% 91%
Recall 94% 92%
现在问题来了。
V2：
误报少了。
但是漏报变多了。
到底换不换？
这就是：
AI测试开发真正开始有意思的地方。
因为Prompt已经不再只是几句话。
它开始变成：
一个需要版本管理和回归测试的测试资产。
十一、模型升级也不能直接换
DeepSeek今天：
Vision Model A
以后升级：
Vision Model B
不能看到官方说：
Benchmark提升10%。
然后：
model = "B"
直接上线。
因为Benchmark更高：
不代表你的业务场景一定更准。
必须重新跑自己的：
Visual Evaluation Dataset
比较：
Model A
Precision
Recall
Latency
Cost
VS
Model B
Precision
Recall
Latency
Cost
这件事和传统软件测试特别像：
模型升级，本质上也是一次版本升级。
也需要回归。
十二、所以面试官问“多模态大模型怎么用于测试”，现在可以怎么回答？
如果只回答：
“可以分析截图，做UI视觉回归。”
属于入门回答。
如果想回答得更像一个AI测试开发工程师，可以这样组织：
第一，多模态模型可以作为传统UI自动化的视觉语义层，与Playwright、Appium等框架结合，用于发现元素遮挡、文字截断、布局异常、视觉层级和业务信息表达错误。
然后继续：
第二，不建议让视觉模型直接替代传统断言。接口、数据库、DOM等确定性状态仍然应该使用程序验证，视觉模型主要解决传统自动化难以表达的非结构化视觉问题。
再往下：
第三，工程上可以使用Pixel Diff、Mask、页面风险等级等机制进行前置过滤，只把真正需要语义判断的截图送给VLM，从而控制Token成本和执行时间。
最后补一句：
第四，还需要建立视觉评测集，持续监控Precision、Recall、误报率、漏报率、Latency和Cost，并对Prompt和模型升级进行回归。
如果能回答到这里：
面试官听到的就不再是：
“我玩过多模态API。”
而是：
“这个人理解怎么把多模态模型接进测试工程体系。”
差别非常大。
十三、再往前走一步：未来甚至可能出现“语义基线”
传统视觉回归保存的是：
baseline.png
以后我们可能同时保存：
{
"page": "checkout",
"visual_rules": [
"最终支付金额必须是页面最突出的金额",
"提交订单按钮必须完整可见",
"优惠金额必须清晰对应优惠来源",
"错误提示不得遮挡支付按钮",
"原价不得与实付价形成视觉歧义"
]
}
那么未来的视觉回归就不只是：
昨天截图
VS
今天截图
而是：
当前截图
+
历史基线
+
业务视觉规则
然后问：
页面虽然变了，但有没有违反真正重要的业务规则？
这可能才是视觉AI测试真正值得期待的方向。
因为UI本来就不是不能变化。
真正不能变化的是：
核心业务含义。
写在最后
这三篇写下来，其实我们一直在讨论同一件事：
多模态大模型到底给测试行业带来了什么？
第一篇，我们讲：
传统自动化会点按钮、查DOM，但它不一定真正“看得见”页面。
第二篇，我们讲：
视觉模型即使发现问题，也不能直接相信它，必须结合API、DOM、数据库建立证据链。
而到了这一篇，真正的问题变成：
当AI视觉测试从10张截图扩展到每天10000张截图以后，这套东西还能不能跑？
答案最终并不取决于一个更炫的Prompt。
而取决于：
确定性测试
+
Pixel Diff
+
多模态模型
+
风险分层
+
Evaluator
+
成本治理
能不能真正组合起来。
所以我反而越来越不赞同一句话：
“AI时代，传统自动化测试没用了。”
真正的情况可能完全相反。
AI越深入测试：
越需要扎实的传统测试工程能力给它兜底。
因为视觉模型可以告诉你：
“我觉得这个页面有问题。”
但真正的测试开发工程师还要继续回答：
为什么有问题？
是不是Bug？
严重程度多高？
证据是什么？
能不能稳定复现？
模型判断到底准不准？
10000张图怎么把成本控制下来？
当你能够回答这些问题的时候，你掌握的才不是某一个DeepSeek视觉模型。
而是一套可以随着模型变化继续使用的：
AI测试工程能力。
模型会继续换。
价格会继续降。
多模态能力也一定会越来越强。
但我觉得未来几年，AI测试开发工程师真正拉开差距的，可能恰恰不是：
谁最早调用了新的模型API。
而是：
谁能把一个“看起来很聪明”的模型，变成一个可验证、可评估、可回归、成本可控，并且真正敢接进CI/CD的测试系统。
这一步，才是从“会用AI测试”走向“会做AI测试开发”的真正分界线。
推荐学习
DeepSeek Harnesst智能体公开课：
🔥 DeepSeek Agent架构深度拆解——“一切皆插件”到底怎么实现🔥 四大主流Agent横向对比：Opencode/Codex/Claude Code/Openclaw🔥 Harness插件体系全解析：Web自动化+App自动化+视觉驱动自动化
一夜5万星的Agent框架，到底能做什么？一次讲透。
扫码进群，报名学习！
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。
学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。
我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。
在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。
同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。
浙公网安备 33010602011771号