关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集有一种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 860actual 860PASS再查数据库SELECTorder_id,original_price,discount_amount,shipping_fee,pay_amountFROM ordersWHERE order_id ‘ORDER_10086’;结果original_price 1000discount 150shipping_fee 10pay_amount 860还是PASS。到这里大部分传统接口测试都会认为订单金额计算没问题。二、再加一层UI自动化还是绿的我们继续用Playwright验证页面。from playwright.sync_api import expectdef 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 PASSDatabase PASSDOM PASS按传统自动化测试的逻辑这个Case基本可以结束了。但是实际页面可能长这样商品原价 ¥1000会员优惠券 -¥150运费 ¥10应付金额 ¥860¥1000[ 提交订单 ]问题来了。¥860下面又叠了一个¥1000。对于测试脚本来说pay-amount 860确实存在。所以PASS。但是对于用户来说他现在看到的是我到底要付860还是1000如果这是支付确认页这已经不是一个普通“样式不好看”的Bug。它可能直接影响用户是否敢点击支付。这就有可能升级成真正的高优先级问题。三、为什么DOM正确页面还能错这其实又是一道很适合测试开发面试的问题接口正确、DOM正确能不能证明页面一定正确答案当然是不能。但为什么因为页面最终呈现给用户的不是¥860而是浏览器经过HTMLCSS字体布局响应式规则组件状态浏览器渲染最终生成的视觉结果。所以数据正确≠DOM正确≠渲染正确≠用户理解正确这四层其实是不同的测试对象。而过去大量自动化测试主要覆盖的是前面两三层。最后这一层用户看到以后会怎么理解一直非常依赖人工测试。这恰恰是多模态模型真正有机会补上的地方。四、DeepSeek视觉模型真正应该看的不只是“有没有重叠”如果我们只是问页面有没有元素重叠其实还是把多模态模型当成一个高级图像识别器。更有价值的Prompt应该带上业务上下文。例如把结算页截图交给模型同时告诉它这是电商订单提交页面。业务规则商品原价1000元优惠金额150元运费10元最终应付金额860元。请从真实用户支付决策的角度检查截图。重点判断最终支付金额是否明确原价、优惠、实付价的视觉层级是否合理是否存在金额重复、遮挡或重叠是否可能导致用户误解实际付款金额“提交订单”按钮与支付金额之间是否存在歧义请输出风险等级及原因。模型如果识别到异常可以返回{“passed”: false,“severity”: “P1”,“issue_type”: “payment_amount_confusion”,“expected”: “¥860应为唯一突出展示的实付金额”,“actual”: “¥860下方同时出现¥1000”,“risk”: “用户可能误认为最终付款金额为1000元”}这里就出现了一个非常重要的变化。过去视觉测试问哪里变了现在开始问这个变化对业务意味着什么五、但AI说这是P1你就真的提P1吗还是不能。这一点特别重要。多模态模型可以成为“异常发现器”但不能天然成为最终裁判。因为模型也可能看错。所以真正企业级的AI视觉测试需要建立证据链。模型发现“页面存在两个可能的支付金额。”下一步不是自动创建P1 Bug。而是让测试系统继续调查。第一步确认后端金额到底是多少import requestsdef get_checkout(order_id):response requests.get( fhttps://test-api.example.com/orders/{order_id} ) response.raise_for_status() return response.json()order get_checkout(“ORDER_10086”)assert order[“pay_amount”] 860后端860PASS说明金额计算没有问题。第二步检查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:¥1000testid:legacy-original-priceposition:x1180y682而¥860x1178y670两个元素几乎叠在一起。到这里我们已经基本知道问题在哪了旧版价格组件没有正确隐藏。六、这才是“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视觉质量工程。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。