1 背景
近来，随着 App 的功能愈发复杂，UI（用户界面）的交互逻辑也随之多样化。为了保障用户体验，针对 UI 的功能测试一直是质量保障中的重要环节。传统的 UI 功能测试往往依赖于人工编写的测试脚本或规则体系：通过手动编写校验逻辑来验证交互是否正确。这种方式虽然精确，但成本高昂，维护困难。
对美团而言， 一个 App 就有可能包含上千种 UI 界面、数万个交互操作。随着业务快速迭代、界面频繁调整、底层平台（如 Android、iOS、HarmonyOS NEXT）的更新，基于规则的测试脚本常常失效。每当脚本失效，测试工程师都需要花费大量时间重新绑定元素、修复规则脚本，极大地提升了测试自动化的开销。此外，当下的 UI 功能缺陷通常并不表现为崩溃，而是更复杂的响应逻辑异常：例如图 1 中点击“全部已读”却清空了消息列表等。这类问题严重影响用户体验，但难以通过简单规则概括，限制了传统 UI 测试自动化的覆盖率与效率。
考虑到 UI 功能缺陷虽表现各异，但共性是 App 的响应偏离用户预期。因此，若能实现对用户预期的模拟，就能以此作为测试准则（Oracle）、自动化的检测 UI 功能性异常。即无需人工逐页面编写规则，从而大幅提升自动化的程度与测试覆盖率。由于大语言模型（LLM）经过海量通用知识训练，具备一定的模拟人类常识与预期的能力，恰好契合模拟用户预期的需求，且无需针对特定应用 / 功能单独适配，天然具备泛化性。因此，通过分析 UI 功能缺陷的共性，我们提出了一个全新的思路：能否基于大模型理解“人类对 UI 交互的常识预期”，并以此自动判断交互是否正确？
基于这一理念，我们与复旦大学计算与智能创新学院 周扬帆教授团队 展开联合研究，设计并实现了 KuiTest —— 一套基于 大众通识 的 无规则（Rule-free）UI 功能测试系统。KuiTest 能够像人一样，理解按钮、图标等交互组件的含义，预测点击后的合理结果，并据此自动校验实际界面反馈是否符合预期，从而在无需手工脚本的情况下完成功能测试。该工作已在美团 App 的多个业务中落地应用，并产出论文《KuiTest: Leveraging Knowledge in the Wild as GUI Testing Oracle for Mobile Apps》，已被国际顶级软件工程会议 ICSE 2025（CCF-A 类会议）的 Software In Practice Track（软件工程应用实践）收录。
2. 设计思路与实现过程
2.1 总体流程
KuiTest 的核心是检查 UI 交互后的响应是否符合一般用户的 常识性预期，其中：识别交互组件的功能和常识性预期生成是需要两项关键能力。考虑到通用大模型具备图文理解能力且从海量的训练数据中习得了常识性推理能力，因此天然地适合模拟大众的认知和交互预期。至此，KuiTest 的核心挑战是提升大模型在执行 UI 功能测试的 性能和可靠性。考虑到通用大模型通常并未接受过 UI 测试领域数据的训练，因此缺少 UI 认知与测试的经验，直接让它识别 UI 功能和缺陷是十分困难的。所以我们借鉴人工测试的操作流程，将测试流程拆分以降低 LLM 的任务难度：
- 可交互组件功能识别：理解每个可交互组件（如按钮、图标）的功能含义、预测交互后的响应。
- 交互响应验证：在执行交互后，验证界面响应是否符合预期。
具体来说，如上图 2 所示，在测试开始时，首先选择需要交互的组件，KuiTest 会基于 GUI 截图分析和组件库匹配获取该组件的功能，并预测与之交互后的 UI 响应；随后执行交互，根据组件的预期功能以及交互后的页面信息判断实际响应是否符合预期。
2.2 UI 组件功能识别
为了提升大模型预测 UI 组件功能的可靠性，KuiTest 整合了多种 UI 页面相关信息输入：首先，我们获取结构化组件树并结合 Vision-UI 模型[1]从截图中识别所有可交互组件，再用 SoM（Set-of-Mark）策略[2]为每个组件添加 bounding box 标记并分配唯一 ID，形成带标记的 UI 截图，让大模型能快速分辨图中存在的 UI 组件。接着，针对有文本的组件，通过 OCR 提取文字内容并按“组件 ID - 文本”结构化整理；针对无文本的图标类组件，则利用 CLIP（Contrastive Language–Image Pre-training）模型[3]从积累的图标库（含历史识别失败图标及人工标注的功能描述）中检索相似图标，如果存在相似图标，则将库中图标的功能信息补充至输入来辅助大模型理解组件。最后，将上述所有信息整合进 Prompt，让大模型识别指定组件的功能，并预测交互后 UI 界面的响应。这一过程有效缓解了通用多模态大模型 UI 视觉信息理解薄弱的瓶颈，并为后续交互验证提供 Oracle。
2.3 交互响应验证
交互后响应验证是 KuiTest 判断 UI 功能是否存在 Bug 的核心环节，流程分为状态比对和 LLM 决策两步：KuiTest 在模拟用户交互后，先通过像素对比判断交互前后 UI 是否有视觉变化，若无变化则直接标记为 “UI 交互无响应”；若有变化，则让多模态模型判断实际 UI 响应是否符合前述预测。至此，KuiTest 完成了从 UI 功能语义测试到通用推理能力任务的转换，既规避了传统基于规则测试繁杂的开发和维护成本，也提升了大模型在 UI 测试领域的决策的可靠性，降低误报率。
3. 实验测试
KuiTest 的实验设计以验证其对解决工业级 UI 功能的测试能力为核心，在美团实际场景中筛选真实数据构造数据集，并且设计针对性基线对比方案。在验证技术有效性的同时为业务落地提供数据支撑，下文将继续介绍实验设计、设置以及结果分析。
3.1 实验设计
实验围绕三个关键问题（RQ）进行，目标是验证 KuiTest 设计的有效性与合理性，以及是否满足工业落地要求。针对 LLM 在 UI 理解领域能力不足的问题，设置 RQ1 从误报率和成本的角度验证任务分解（拆分为 “组件功能识别 + 交互后响应验证”）的综合性能。此外，设置 RQ2 评估多模态输入 + 图标库的方案是否能提高 LLM 的组件识别能力。最后，针对工业场景对 “高召回、低误报” 的刚需，设置 RQ3 验证 KuiTest 在美团 App 中的落地能力，重点评估决定缺陷覆盖度的召回率以及直接影响人工排查成本的误报率。
3.2 实验数据与对照方法
实验使用的基准数据集自美团的核心业务线（外卖、酒店、旅行等），这些业务线的 UI 风格、交互规则均有差异，因此具备对真实的工业测试场景的代表性。具体而言，RQ1 数据集含 150 个 UI 交互操作（25 个历史 Bug+125 个正常用例），bug 比例 16.7%，对应新功能测试场景；RQ2 数据集涵盖 250 个可交互 UI 组件（含文本与无文本类型），确保组件多样性；RQ3 数据集含 100 个真实 UI 页面（4664 个组件、150 个注入 Bug），Bug 占比仅 3.2%，与工业场景 Bug 稀疏的实际情况一致。
我们为各实验设置了基线方法作为对照：RQ1 设无分解（直接让大模型判断）与三步分解（单独提取交互后页面语义）对照，前者验证是否需要分解，后者验证分解步数合理性；RQ2 设纯 LLM（仅截图）、图片 + 文本（无图标库）、SoM + 文本（无图标库）对照，分别验证文本信息、组件标记以及图标库的价值，排除单一变量干扰；RQ3 虽无外部工具对照，但通过覆盖美团内 10 种业务线，以验证 KuiTest 的现实泛化性。
3.3 实验结果
RQ1：任务分解的合理性
任务分解对比结果显示，有分解的方案比无分解的方案在准确率和召回率上都有明显提高，并且 KuiTest 的两步分解方案（组件识别 + 响应验证）表现最优：平均准确率 86%、召回率 85%。
这一结果印证了任务分解合理性。对于三步分解的方案效果会略差于两步分解的结果，我们分析发现三步分解额外语义提取步骤，虽能提升页面类型理解，但会让 LLM 忽略图标颜色变化等细节，导致非跳转类 UI 功能 Bug 漏检（如点击收藏按钮后按钮应该从空心变为实心），且增加计算成本。这说明分解并非步骤越多越好，需贴合大模型能力边界，找到可靠性和效率平衡点，而两步分解恰好成为实现这一目标的最优解。
RQ2：组件功能识别的有效性
组件功能识别结果显示，KuiTest 方案的平均识别准确率达 95.5%，其中文本组件准确率 96%，无文本图标准确率 95%；而对照方案中，纯 LLM 的无文本图标准确率仅 13%，图片 + 文本和 SoM + 文本的方案准确率也未突破 20%。
这一数据表明对 UI 图像进行标记以及对 UI 组件语义信息的额外补充，能够显著提高 LLM 的 UI 组件功能识别能力。LLM 视觉理解能力薄弱，纯截图输入无法识别无文本图标，而 OCR 文本 + 组件标记能补充组件的文本语义，提升文本组件识别准确率。借助图标库为无文本组件补充功能描述，直接将其识别准确率从 13% 提升至 95%。并且这一图标库并不是全量的，说明仅通过业务线常用图标即可覆盖大部分场景，兼顾准确性与成本。
RQ3：对于真实 UI 功能异常识别的有效性
在美团 10 大业务线的真实场景测试中，KuiTest 整体召回率 86%、精确率 71%、误报率 1.2%，且各业务线表现稳定。这些实验结果表明 KuiTest 具备实际落地能力。86% 的召回率意味着能覆盖绝大多数真实 UI 功能 bug，避免漏检关键缺陷。1.2% 的误报率有效避免导致测试工程师进行无效排查，大幅降低人工成本。71% 的精确率虽看似不高，但因实验中 Bug 占比仅 3.2%（与真实场景一致），在 Bug 稀疏环境下已属优秀。实验结果证明了 KuiTest 在真实测试场景中能平衡覆盖度与准确性。
4. 应用效果
目前，KuiTest 已在美团的多类业务场景中落地应用，过去 6 个月有 20 个业务方向使用，总执行 21 万+Cases、8000 多个 Jobs，近期周均触发 5000 多个 Cases；在多个实测项目如鸿蒙适配、神会员地理传参巡检、酒店商家多语言适配等，KuiTest 发现了百余例有效的 UI 功能缺陷。
4.1 HarmonyOS NEXT 平台遍历
传统的 GUI 测试脚本的设计依赖于 App 的 UI 逻辑，但是不同操作系统上同一 App 的有所差异，这种差异会导致在一个系统上设计的脚本在另一个系统上失效，因此使得跨平台的测试十分困难，需要测试人员手动调整甚至重新设计测试脚本，适配成本较大。
美团 App 在 Android/iOS 平台的测试脚本较为完善，但是在 HarmonyOS NEXT 平台的测试脚本仍在完善之中，大量页面仍处于未测试状态。因此，KuiTest 被率先部署于该平台的稳定性巡检中，根据指定业务起始页面，自动地进行跨页面遍历，识别并验证崩溃、报错、功能不符合预期的情况，以减少重新设计测试脚本的成本。
项目中覆盖首批适配的 3 项业务，项目交付周期总体累计运行 1230 小时、共 4 万+个自动化测试用例，发现 34 个有效异常。
4.2 大前端回归巡检
由于美团 App 的更新速度十分快速，因此每周都需要进行回归巡检。传统的测试脚本的方法由于人力消耗过大，往往只能覆盖 App 中的核心业务区域，但是其他区域的 Bug 实际也会影响用户体验。而 KuiTest 能够测试一张页面的所有可交互组件，以一种低成本的方式提高测试覆盖率。因此，我们将 KuiTest 运用在美团的大前端回归巡检当中：截至目前，KuiTest 已经超一年稳定运行，累计检测出了 140+有效异常。
5. 认知与展望
KuiTest 作为无规则的移动应用 GUI 功能测试工具，标志着软件测试领域向智能化、自动化方向迈出的探索一步。该工具通过合理的任务拆解与多模态 UI 组件功能识别将大模型通识作为测试预言，利用其广泛的知识模拟用户期望，成功突破了传统基于规则测试方法的局限性，切实提升了 LLM 在 GUI 测试场景中的可靠性和实用性。
当前 KuiTest 主要聚焦于单步交互的功能验证，这是出于对测试可靠性和效率的权衡考虑。然而，向多步交互场景扩展是一个自然且必要的发展趋势，真实用户场景中存在大量需要多步操作才能触发的复杂功能 bug，例如，在执行操作序列“查看订单列表 → 点击 “待付款” 订单 → 选择退款 → 确认退款原因”时发现点击“待付款”后，页面却显示“退款订单”。
未来研究应当探索如何将测试能力扩展到长链路交互场景。针对长链路 Bug 分析，需要建立状态追踪机制来记录每一步交互后的 UI 状态变化，通过对比预期状态与实际状态的差异来识别异常节点，同时利用 LLM 的推理能力建立操作步骤之间的因果关系链，当检测到功能异常时能够回溯定位是哪一步操作导致了错误，这种因果推断能力对于复杂交互序列中的 Bug 定位至关重要。同时，可以引入基于历史 Bug 数据的学习机制, 分析过往发现的长链路 Bug 模式，自动生成类似的高风险测试路径，优先探索容易出现问题的操作序列组合。这种智能化的路径生成不仅能提高测试效率，还能显著提升对复杂功能 Bug 的检测能力。
6. 合作方简介
复旦大学周扬帆教授团队致力于新型软件系统的性能优化与故障排查研究，近年团队在软件系统领域的重要会议如 OSDI、SOSP、ICSE、FSE 等发表了多篇高影响力论文。最近，该团队以解决 UI 自动化测试中的复杂问题为核心，将大模型应用于 UI 功能认知与 UI 交互规划，以一系列创新方法显著提高了解决方案的适应性和稳定性。团队注重科研成果的实际应用，积极与企业及相关机构合作，共建实用工具和系统，推动研究成果的落地，助力合作伙伴提升技术能力并实现业务价值。
注释
- [1] vision-ui 模型：美团视觉 UI 分析工具
- [2] SoM（Set-of-Mark）策略：Yang J, Zhang H, Li F, et al. Set-of-mark prompting unleashes extraordinary visual grounding in gpt-4v [J]. arXiv preprint arXiv: 2310.11441, 2023.
- [3] CLIP（Contrastive Language–Image Pre-training）模型：Radford A, Kim J W, Hallacy C, et al. Learning transferable visual models from natural language supervision [C]//International conference on machine learning. PMLR, 2021: 8748-8763.
