企业官网建设流程全解析

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

前两天聊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测试：

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异常。

效果一般。

你优化成：

检查： 1. 元素遮挡 2. 文本截断 3. 金额展示 4. 按钮可见性 5. 信息层级 重点关注影响用户完成核心业务流程的问题。

感觉效果变好了。

然后直接上线？

还是不行。

应该：

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测试开发”的真正分界线。