关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集前两天聊DeepSeek视觉模型的时候有个问题我觉得特别适合拿出来单独说。如果现在面试AI测试开发岗位面试官问你“多模态大模型怎么应用到软件测试”很多人的第一反应可能是可以把页面截图传给大模型让AI识别UI异常比如按钮遮挡、文字截断、页面错位还可以做视觉回归。这当然没错。但如果我是面试官听到这里大概只能给5060分。因为这证明你知道多模态模型“能干什么”。却没有回答真正困难的问题公司每天跑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 / FAILDemo当然可以这么做。企业里很快就会碰到三个问题成本。速度。误报。所以真正的工程化第一步不是研究一个更复杂的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 Diff35%但这是正常业务数据。还有用户名。头像。时间。订单号。广告Banner。库存数量。倒计时。这些区域天然是动态的。所以自动化里本来就应该Mask动态区域。例如Playwrightawait 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( pathpage.png, full_pageTrue )然后直接整张图扔给模型。一个5000像素高的电商页面里面可能有Header。搜索。Banner。商品。优惠券。地址。支付方式。金额。Footer。你真正想检查的是支付金额。却让模型分析整个页面。这其实非常浪费。更好的方式是按业务区域截图。比如payment_panel page.locator( [data-testidpayment-summary] ) payment_panel.screenshot( pathpayment-summary.png )优惠区域coupon_panel page.locator( [data-testidcoupon-panel] ) coupon_panel.screenshot( pathcoupon-panel.png )提交区域submit_panel page.locator( [data-testidsubmit-area] ) submit_panel.screenshot( pathsubmit-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就来了假设真正有Bug100张模型找到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测试开发”的真正分界线。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。