国内基于大模型的 GUI 与 UI 自动化测试实践

国内公开材料里，「AI 做 GUI 测试」并不是同一种系统。有的是根据用例描述生成 UI 脚本，有的是多模态模型看截图自己点，有的是用大模型补自动化代码，界面只是其中一种被测对象。## 企业分享里实际做了什么

沙丘社区 2024 年 11 月的跟踪，把四家机构放在同一篇里，正好看出差异。

蚂蚁集团的案例写的是支付宝小程序质量检测。传统监控难以识别跨行业场景里的业务异常，他们用自然语言处理和多模态模型做异常检测、链路测试，并提到智能动线预测。这更接近「用模型看业务路径是否异常」，不是替换一套选择器脚本。

中国邮储银行的金牛座自动化测试系统，把大模型和知识库、录制、报文解析、图像识别放在一起。单接口可以批量生成脚本；多接口业务流程走「录制、智能分析、辅助编写」；UI 侧则是根据简单用例描述生成测试脚本。公开介绍没有给出 UI 脚本的独立采纳率。

科大讯飞分了两条线。接口侧在新增或导入定义时调用智能用例生成，当时主要覆盖 HTTP。UI 侧是「用例文本生成脚本」。他们给出的业务验证口径是：用例编写规范时，UI 自动化脚本生成采纳率可以到 50% 以上。这个数字依赖用例写得规范，不能直接外推到探索式测试。

华为把突破口放在测试自动化代码生成，而不是先做一个全能 GUI Agent。路径是先做监督微调，用于老特性防护网补齐；再用检索增强，把新特性脚本压到分钟级；进一步希望少写样例、直接从自动化关键字生成。截至 2024 年 6 月底的公开口径：近 3000 人使用，覆盖 60 余个产品，生成代码 40 余万行。这是代码生成规模，不是 GUI 缺陷发现率。

同一时期还被反复点名、但细节多在闭门材料里的方向包括：百度 TestMate、优酷用例生成、字节测试设计生成、腾讯用例生成、360 智能测试。这些更偏用例与脚本，不宜和「模型自己操作界面」混成一个指标。

会议社区里的 GUI 专题

QECon 2025 北京站议程把界面测试单独抬出来了，和「大模型写用例」并列，而不是附在用例生成下面。和本主题直接相关的公开题目包括：

• 腾讯傅景良：基于 LLM 和数据驱动的 Web UI 自动化实践
• 华为虞清泉：AI 辅助 WebUI 自动化测试技术实践
• 华为李巍：界面测试智能化转型实践
• 字节跳动李鹤：基于自进化的 UI 自主测试智能体
• 腾讯陈佳：GUI Agent 驱动的全端 App 合规判定

从题目就能看出 2025 年的社区关注点已经从「生成一段 UI 代码」走到「智能体自己测」和「用 GUI Agent 做合规判定」。议程本身不是论文，落地数据要以演讲方后续公开稿为准。

学术与开源模型

《铁路计算机应用》2025 年第 8 期发表了王心雨、戴琳琳、李博、景辉、高志强的《基于大模型与多智能体交互的铁路客运软件智能化 UI 测试方法》（DOI：10.3969/j.issn.1005-8451.2025.08.06）。问题定义很具体：铁路客运场景多、规则脚本覆盖不住，业务迭代又快。方法是让测试人员用自然语言提需求，由视觉语言模型理解界面，再由多个智能体协作，结合检索增强生成脚本并执行。论文把美团 AUITestAgent（自然语言用例驱动终端测试）、Functionize、Testin 列为对照，说明当时产业界已经有「用例转脚本」产品，作者要补的是行业知识加上多智能体协作。

字节跳动的 UI-TARS 则是模型层，不是某个业务的测试平台。阿里云开发者社区 2025 年 1 月前后的介绍把它概括为：面向桌面、移动和网页的原生 GUI 代理模型，用自然语言驱动，具备感知、推理、行动和记忆，并能跨平台给出动作。它经常被后续测试框架当作视觉定位模型来调用，本身不等于一套完整的测试管理系统。

对照之后能得出的判断

试点时建议先选一层，不要同时承诺「自动写用例、自动点、自动判缺陷」。脚本生成看采纳率和维护成本；视觉执行看可复盘的步骤日志；缺陷判定必须有独立预期，不能让同一个模型既操作又给自己打分。