夜雨聆风一、传统 UI 自动化的天花板
UI 自动化测试一直是质量保障领域的老大难。十几年来，Selenium、Appium、Airtest 这类工具支撑了大量业务，但工程师们心里都清楚：传统方案的天花板肉眼可见。
最直观的痛点是脆弱性。一套基于 XPath 与 CSS Selector 的脚本，前端一次样式调整、一次组件重构，就可能让数十条用例大面积失败。得物技术团队在 2026 年处理过真实场景：交易后台从 Vue 迁移到 React，再迁移到全栈，两轮大改后，传统 E2E 用例的维护成本翻了三倍。一个电商 App 的核心下单链路，传统 XPath 方案在三个月内因为 UI 调整导致失效次数超过 20 次，每次都需要重新定位元素，工程师苦不堪言。
更深层的痛点在于覆盖面。传统方案依赖工程师手动编写脚本或录制操作，UI 一旦微调，就要重写定位表达式。一个页面可能只有 20% 的核心流程有自动化覆盖，剩下的 80% 长期处于"裸奔"状态。更有甚者，跨平台兼容性成了"双倍负担"——同一功能在 Android 和 iOS 上的元素属性完全不同，需要维护两套脚本。
更隐蔽的是动态内容处理能力缺失。弹窗、广告、浮层、权限请求这些"非预期但必然出现"的元素，传统方案要么硬编码坐标，要么提前枚举所有可能，遇到没见过的就卡死。
这正是 AI Native 测试范式诞生的背景：不再让脚本去死磕 DOM 结构，而是让 AI 像人一样"看懂"界面，再驱动执行。
二、什么是 AI Native 的 UI 测试
AI Native 并不是把 AI 当作辅助插件塞进传统流程，而是从用例生成到执行验证全链路都围绕 AI 重新设计。得物技术的 AI UITester 给出了清晰的定义：
AI Native UI 测试 = 多模态视觉理解 + 自然语言决策 + 确定性执行兜底
三个关键词缺一不可：
- • 多模态视觉理解：通过视觉大模型识别 UI 元素，不再依赖 DOM 结构
- • 自然语言决策：用例以人类可读的自然语言描述，AI 自行决定操作序列
- • 确定性执行兜底：在 AI 不确定的场景下，用 Playwright/Puppeteer 这类确定性工具接管
这种范式和传统 E2E 的根本差异在于：传统方案是"人告诉机器每一步怎么做"，AI Native 则是"人告诉机器目标是什么，机器自己想办法做到"。前者是脚本执行者，后者是目标完成者。
更深入一层，AI Native 还意味着测试资产的形式变化。传统方案的资产是"脚本"——一段段耦合了元素定位与业务逻辑的代码；AI Native 的资产是"用例"——一段段自然语言描述的目标。脚本会随 UI 变化而失效，用例则可以跨越 UI 迭代长期有效。
三、技术架构拆解
AI UITester 的技术栈可拆成四层，每一层都有明确的职责边界。
3.1 感知层：多模态大模型
核心是视觉大模型（VLM）。得物技术选用了 Qwen2.5-VL-72B 作为主力模型，配合 GPT-4V 等作为备选。VLM 能直接"看懂"截图，理解按钮位置、文字含义、控件状态。
# 多模态理解的最小化示例
from openai import OpenAI
client = OpenAI(
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="your-key"
)
def analyze_screenshot(image_base64, instruction):
response = client.chat.completions.create(
model="qwen2.5-vl-72b-instruct",
messages=[{
"role": "user",
"content": [
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{image_base64}"}},
{"type": "text",
"text": f"请分析截图，并按 JSON 格式输出：{instruction}"}
]
}]
)
return response.choices[0].message.content这一层的关键是响应速度和准确率的平衡。72B 模型在复杂场景下准确率高，但单次调用延迟可能达到 3-5 秒，成本约 0.05 元/次；轻量模型（如 7B）速度快、成本低（0.005 元/次），但面对长尾 UI 容易误判。工程上一般会分级路由，常见路径走小模型，关键路径调用大模型。
视觉大模型相比传统 OCR 与图像识别有质的飞跃：它能理解"促销标签"是促销标签、"价格计算正确"是什么意思，这是传统像素匹配和文字识别都做不到的语义理解。
3.2 决策层：ReAct 循环
AI 不会"一次性"做完所有事，而是采用 ReAct（Reasoning + Acting）循环：
观察(Observe) → 思考(Think) → 行动(Act) → 观察(Observe) → ...每一步执行后，AI 重新审视当前界面，再决定下一步动作。这种循环让 AI 具备真正的自主决策能力——遇到弹窗会处理，遇到错误会重试，遇到目标完成会终止。
# ReAct 循环的伪代码实现
def execute_with_react(instruction, max_steps=20):
history = []
for step in range(max_steps):
# 1. 观察当前界面
screenshot = device.screenshot()
# 2. 让 AI 思考下一步
action = vlm_decide(screenshot, instruction, history)
# 3. 执行动作
device.execute(action)
history.append(action)
# 4. 检查目标是否达成
if vlm_verify(screenshot, goal=instruction):
return "success", history
return "timeout", history这套循环模式的工程价值在于：AI 不再是单次调用，而是一个持续决策的智能体。它可以从错误中恢复，可以在不确定时探索多条路径，可以对结果进行二次确认。
ReAct 模式源自 AI Agent 研究领域。在 UI 测试场景落地时，需要做几个工程化改造：增加历史记忆压缩机制（避免上下文爆炸）、增加动作指令标准化（便于解析执行）、增加异常恢复路径（避免单点失败导致整个流程崩溃）。
3.3 执行层：确定性工具兜底
纯 AI 执行有两个致命问题：慢（每次决策都要调用大模型）和不稳定（同一个界面可能给出不同操作）。
AI UITester 的解决方案是分层执行：
- • AI 路径：视觉理解 + 语义决策，处理复杂、模糊场景
- • 确定性路径：Playwright/Puppeteer 直接操作 DOM，处理已知场景
- • 路由层：先用确定性工具尝试，失败或不在覆盖范围内时切换到 AI
class HybridExecutor:
def execute(self, instruction):
# 先尝试确定性路径
if self.has_dom_selector(instruction):
return self.playwright_execute(instruction)
# 确定性路径无法处理，交给 AI
return self.ai_execute(instruction)这套设计的精妙之处在于：让 AI 做 AI 擅长的事，让工具做工具擅长的事。确定的场景用确定的方式（毫秒级响应、100% 可复现），模糊的场景用模糊的方式（语义理解、灵活决策）。实测下来，这种混合模式比纯 AI 执行快 3-5 倍，稳定性提升一个数量级。
3.4 数据层：质量闭环
AI UITester 不只是"执行测试"，还要把执行结果转化为可运营的质量数据：
- • 每个页面的代码覆盖率
- • 每个用例的步骤执行成功率
- • 每步操作的截图与错误堆栈
- • 失败原因的可信度打标
这些数据回流到平台后，可以指导用例优先级排序、识别高风险页面、预测质量趋势。例如，得物技术的实践数据显示：高 PV 页面（PV > 10万/天）的用例失败率是低 PV 页面的 2.3 倍，这意味着资源应该优先铺在高 PV 页面。
四、方案选型的关键决策
AI UITester 的方案选型过程中，得物技术团队做过几次关键决策。
4.1 工具选型：Midscene vs browser-use
最终选用了 Midscene，主要考量：
- • 技术栈匹配：Midscene 基于 JavaScript，与前端工程无缝衔接，降低团队上手成本
- • 多模态能力：原生支持 DOM 分析和视觉分析双路径，可灵活切换
- • 工程化空间：与 Playwright/Puppeteer 深度集成，便于做兜底控制
browser-use 也是优秀选项，基于 Python + Playwright，能力面广，但团队技术栈以 JS 为主，切换成本较高。在企业级落地时，技术栈匹配度的优先级往往高于功能丰富度——团队熟悉才能持续迭代。
4.2 模型选型：开源 vs 商用
72B 级别的视觉大模型，自托管成本高（A100 单卡推理成本约 ¥3/小时）、推理慢；商用 API（如 GPT-4V）准确率高但数据合规有风险。
折中方案是多模型路由：
- • 高敏感数据场景：使用私有化部署的开源模型（如 Qwen-VL）
- • 通用场景：调用商用 API 平衡成本与效果
- • 关键回归路径：使用大模型确保准确率
这种"分级路由"思想借鉴了 CDN 的设计——不同请求走不同路径，整体成本可控、效果最优。
4.3 用例来源：人工编写 vs 自动生成
传统用例完全靠人工编写，覆盖率受限于工程师数量。AI UITester 引入了基于真实运营行为的用例自动生成：
线上运营操作日志 → AI 提取关键路径 → 生成自然语言用例 → 转化为可执行脚本这种"从真实行为反推用例"的思路，比"从需求文档编写用例"更贴近实际使用场景。线上运营每天的操作路径，就是最真实的测试用例库。某次实践中，基于一周的运营日志，AI 自动生成了 280 条用例，覆盖了原本手工编写的 47 条用例涵盖的所有核心路径，并发现了 12 条工程师遗漏的边界场景。
五、工程落地的真实挑战
把 AI 能力落地到生产环境，远比 Demo 复杂。AI UITester 在落地过程中踩过几个深坑。
5.1 稳定性问题
AI 的不确定性是工程化最大的敌人。同样一张截图，同一个 Prompt，模型可能给出不同操作。在 7 天连续运行测试中，纯 AI 模式的单步操作通过率约 92%，意味着每 100 步会有 8 次异常。
解决方案是多层次稳定性保障：
- • 图片哈希缓存：相同截图复用历史决策结果，缓存命中率达 35%
- • 结果校验：关键操作后必须由 VLM 二次确认
- • 超时熔断：单步操作超过阈值立即降级到确定性路径
- • 重试退避：失败后指数退避重试，最多 3 次
5.2 成本问题
视觉大模型的调用成本不容忽视。一条用例 20 步，每步调用一次大模型，单次成本可能高达 1 元。1000 条用例跑一轮就是 1000 元，企业级规模下月度成本可达数十万元。
优化手段：
- • 多级模型路由：常见路径用小模型，关键路径用大模型，整体成本降低 60%
- • 批量决策：连续相同操作合并为单次决策
- • 结果缓存：截图+Prompt 哈希作为缓存键
- • 智能跳过：连续 3 步无变化的场景直接复用结果
5.3 调试困难
AI 决策是个黑盒，失败时难以定位原因。AI UITester 引入了全链路可观测性：
- • 每步操作的截图、操作指令、AI 思考过程全部落库
- • 失败时自动关联错误堆栈与监控告警
- • 提供"AI 决策回放"能力，复现失败场景
可观测性是 AI Native 系统能否在生产环境长期运行的关键。缺乏观测能力的 AI 系统，失败时只能"靠猜"，工程师无法形成有效的运维经验。
六、AI Native 测试的核心收益
落地 AI UITester 后，几个核心指标有明显改善：
代码覆盖率：从传统方案的 20%-30% 提升到 60%+。AI 可以探索非预期路径，发现工程师遗漏的场景。
用例维护成本：从每周 3 人天降到 0.8 人天。UI 微调不再导致大面积用例失败，AI 自动适应变化。
测试效率：回归一轮从原来的 4 小时缩短到 1.5 小时。AI 并行执行 + 智能跳过稳定路径。
用例生成效率：一个包含 47 个接口的模块，从准备数据到生成完整用例，人工需要 2 天，AI 在 15 分钟内完成，人工审核后 92% 可直接使用。
这些数字背后，更深层的价值是测试角色的转变：测试工程师从"写脚本的执行者"变成"用例审核者 + 质量策略制定者"。AI 处理重复性的执行工作，人类专注于判断"什么值得测"和"什么算测好了"。
七、代码示例：一个最小可运行的 AI UITester
下面给出一个简化版的实现，演示核心思路：
import base64
from openai import OpenAI
from playwright.sync_api import sync_playwright
class AIUITester:
def __init__(self, model="qwen2.5-vl-72b-instruct"):
self.client = OpenAI(
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="your-key"
)
self.model = model
def screenshot_to_base64(self, page):
img_bytes = page.screenshot()
return base64.b64encode(img_bytes).decode()
def decide_action(self, page, instruction):
img_b64 = self.screenshot_to_base64(page)
prompt = f"""
目标：{instruction}
请分析当前界面，决定下一步动作。
输出 JSON 格式：
{{
"thought": "你的思考过程",
"action": "click/input/wait/finish",
"target": "操作目标描述",
"value": "输入内容（如有）"
}}
"""
response = self.client.chat.completions.create(
model=self.model,
messages=[{
"role": "user",
"content": [
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{img_b64}"}},
{"type": "text", "text": prompt}
]
}]
)
return response.choices[0].message.content
def run(self, url, instruction, max_steps=15):
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page()
page.goto(url)
for step in range(max_steps):
decision = self.decide_action(page, instruction)
# 解析决策并执行
# ...
if "finish" in decision:
break
browser.close()
# 使用示例
tester = AIUITester()
tester.run(
url="https://example.com/login",
instruction="使用 test_user / password123 登录，登录成功后停止"
)这个示例虽然简化，但展示了 AI UITester 的核心循环：截图 → 决策 → 执行 → 再截图。真实生产环境的实现会复杂得多，包括错误恢复、并发执行、结果缓存、报告生成等模块。
八、未来的演进方向
AI UITester 的下一步演进有几个清晰的方向：
从执行到预测：基于历史测试数据，AI 预测哪些模块可能出问题，提前介入。这需要把测试数据接入到代码仓库的变更流中，建立"代码改动 → 测试预测 → 精准执行"的链路。
从单模态到多模态：除视觉外，融入音频（如语音播报验证）、日志（如服务端报错关联）、性能数据（如响应时间监控）等多维度信息。多模态融合让 AI 拥有更全面的判断依据。
从工具到平台：让 AI 自主编排测试策略，工程师只定义质量目标。例如输入"保障交易链路的稳定性"，AI 自动规划用例、自动执行、自动报告。
Agent 化测试：单个 AI Agent 负责一个产品线，多个 Agent 协同完成端到端质量保障。这种模式类似 DevOps 中的 SRE 团队，但每个 Agent 都是一个高度自治的智能体。
这些方向背后，是测试自动化的根本转变——从"工程师设计测试"到"AI 自主测试"。工程师的角色从"设计者"逐渐变成"监督者"，负责定义质量标准、审核 AI 决策、处理异常情况。
九、给测试工程师的建议
AI Native 不是要取代测试工程师，而是重新定义这个角色。未来的测试工程师需要具备的能力：
- • AI 工程能力：能熟练使用视觉大模型、Agent 框架、Prompt 工程。理解模型的边界，知道何时该信任 AI、何时该人工介入。
- • 质量策略能力：从执行层面上升到策略层面，决定"测什么、不测什么"。在资源有限的情况下，质量策略比测试执行更重要。
- • 数据运营能力：通过测试数据反推业务风险，指导产品决策。AI UITester 沉淀的质量数据，是测试工程师最有价值的资产。
工具会变，但对质量的追求不会变。AI Native 是手段，不是目的。它解放了工程师从重复性劳动中的时间，让工程师能专注于真正需要人类判断的工作——理解业务、定义标准、识别风险。
UI 自动化测试走过 Selenium、Appium、Airtest 三个时代，正在进入第四个时代——AI Native 时代。这个时代不再让脚本去死磕 DOM，而是让 AI 像人一样理解界面、自主决策、持续学习。
得物技术的 AI UITester 给出了工程化范本：多模态感知 + ReAct 决策 + 确定性兜底 + 数据闭环。这套架构既保留了 AI 的智能，又兼顾了工程化的稳定性与可观测性。在真实的电商交易场景中验证下来，AI Native 范式能显著提升测试覆盖、降低维护成本、加速交付节奏。
AI Native 不是未来，它正在发生。
