摘要：针对移动应用自动化测试中脚本维护成本高、跨设备适配困难等问题，本文提出了一种基于多模态大模型的跨设备协同测试框架。该框架采用视觉理解与自然语言处理相结合的技术路线，破除了传统基于文档对象模型定位方法对页面结构的强依赖性，建立“视觉感知—语义理解—操作映射—执行验证”的四阶段测试理论模型。框架设计了PC-Mobile双端协同工作流，通过配置化的规则引擎实现从自然语言测试指令到可执行操作的自动映射，并依托通义千问多模态大模型进行用户界面元素智能定位与识别。在实时文本测试场景的实验评估中，该框架的测试成功率达100%，测试用例开发效率较传统自动化测试方法提升约60%，且在用户界面变更后无需修改测试配置，展现出较强的鲁棒性。研究结果表明，基于多模态大模型的视觉AI驱动测试方法能够有效降低移动应用自动化测试的维护成本，提升跨设备适配能力，为智能化测试技术的发展提供新的方法论与实践范式。
关键词：实时文本测试；多模态大模型；自动化测试；跨设备协同
随着移动互联网的深入发展，移动应用已成为数字经济的重要载体和人们日常生活的必需品。中国互联网络信息中心发布的第57次《中国互联网络发展状况统计报告》显示，截至2025年12月，我国网民规模达11.25亿[1]。在激烈的市场竞争中，应用质量已成为决定产品成败的核心要素之一。
在移动应用开发过程中，敏捷开发逐渐成为主流模式。该模式强调以较短周期进行需求响应、功能迭代和版本发布，以提升软件开发效率和市场响应速度。然而，快速迭代也使用户界面变更愈加频繁，给软件质量保障带来严峻挑战：一方面，传统的手工测试存在效率低、成本高、易出错等固有缺陷，难以满足快速交付的需求；另一方面，虽然自动化测试能够显著提升测试效率，但却面临维护工作繁重的难题。现有研究表明，移动应用自动化测试技术仍面临诸多瓶颈[2]。以Appium、Selenium等为代表的主流测试工具高度依赖于应用的内部实现细节，如控件标识符、XPath定位符等，一旦用户界面布局发生变化，测试脚本即失效，维护成本将居高不下。
近年来，人工智能技术快速发展，特别是大语言模型（large language model，LLM）和多模态大模型（large multimodal model，LMM）的突破性进展，为解决上述问题带来了新的契机[3]。这些模型展现出强大的视觉理解、自然语言处理和少样本学习能力，为构建高鲁棒性、智能化的自动化测试框架奠定了技术基础。
1 相关工作
使用基于脚本的测试工具是当前移动应用测试领域的主流方案。Appium、Selenium、UI Automator等工具通过控件定位符提供了精确的元素操作能力，适用于界面相对稳定的回归测试场景。然而，这类工具对文档对象模型（document object model，DOM）结构存在强依赖性。研究表明，当开发人员修改控件标识符、层级结构或属性时，约80%的测试脚本需要相应调整[4]。这种脆弱性导致测试维护成本与用户界面变更频率呈正相关，严重制约了敏捷开发环境下的测试效率。
为突破DOM依赖性限制，Sikuli等工具引入了基于图像匹配的元素定位技术[5]。该方法通过模板匹配或特征点检测在屏幕截图中搜索目标元素，实现了与源代码的解耦。然而，传统计算机视觉算法主要依赖低层视觉特征，对分辨率、光照条件、渲染差异等因素高度敏感，在跨设备测试场景中泛化能力不足。此外，基于光学字符识别（optical character recognition，OCR）的辅助定位技术虽能识别文本元素，但难以理解图标、布局等视觉语义信息，适用范围受限。
为消除传统脚本化测试对DOM结构的依赖，以及突破图像匹配和OCR方法在跨设备鲁棒性、界面理解能力方面的局限，近年来深度学习与大模型技术被引入图形用户界面测试领域。相关研究尝试融合界面图像、自然语言任务描述和交互行为信息，实现更高层次的界面理解与自动化测试。王媛等提出了基于提示词工程的软件测试用例生成方法，将大模型应用到软件测试领域中[6]；Wen等人把自然语言任务、用户界面表征、动态分析和Android自动执行结合起来，是LLM驱动移动端自动化任务的代表作[7]。然而，现有工作多聚焦测试用例生成或单一模态的元素识别，如何系统性地利用多模态大模型构建移动应用测试框架，仍是一个值得深入探索的前沿课题。
针对上述研究目的，本文提出了一种基于多模态大模型的跨设备协同测试框架，并选取实时文本交互（real-time text, RTT）作为典型验证场景，对该框架的有效性开展系统的实验评估[8-10]。由于本文方法并不依赖特定应用的控件结构和业务规则，而是基于视觉感知、语义理解与通用操作映射实现自动化测试，因此具备向其他移动应用场景扩展的通用性。通过对比实验，验证了所提方法在准确性、效率和鲁棒性方面具有优势，针对现有移动应用自动化测试方法的局限性，作出了如下贡献。首先，提出了视觉-语义协同的测试方法论框架，建立了“视觉感知—语义理解—操作映射—执行验证”的四阶段测试理论模型，利用多模态大模型实现跨模态信息融合，从根本上摆脱了对底层文档结构及其元素定位机制的依赖。其次，设计了PC（personal computer，个人计算机）-Mobile跨设备协同测试架构，提出了双端协同工作流与事件驱动的松耦合通信机制，实现了从PC端（即测试控制端）测试指令提取到移动端（即被测移动终端）智能执行的流程闭环，支持RTT业务场景的全流程（通话发起—RTT升级—消息收发—RTT降级—挂断）自动化测试。最后，建立了可配置的自然语言指令映射机制，设计了规则驱动的指令转换引擎，结合结构化提示词工程技术，实现了从自然语言测试描述到可执行操作序列的自动转换，降低了测试用例编写与维护的技术门槛。
2 系统设计与关键技术
针对用户界面定位符失效频繁、移动设备碎片化严重、技术实现与业务逻辑脱节三大痛点，本文提出了一种新型自动化测试框架。该框架旨在通过多维度策略解决传统测试问题：首先，引入鲁棒的智能定位机制，有效应对高频用户界面变更导致的脚本脆化问题，大幅降低维护成本；其次，构建跨设备自适应适配层，消除屏幕分辨率与系统差异，使同一套测试指令和规则配置可在参与测试的多款终端上复用；最后，采用业务驱动的抽象层设计，消除底层代码与业务需求之间的实现偏差。本框架在满足各项功能性与非功能性需求的同时，将显著提升测试脚本的稳定性与持续集成/持续交付流程的效率。
系统采用经典的分层架构设计模式，实现了关注点分离（separation of concerns，SOC）与模块解耦，如图1所示。
图1 基于多模态大模型的跨设备协同测试框架
该架构自上而下包含四个层次。
用户配置层：提供声明式的配置接口，包括区域裁剪配置文件和指令映射规则文件，测试人员无需修改代码即可适配不同应用场景。
工作流编排层：负责整体测试流程的协调与控制，实现PC端与移动端的消息传递、状态同步及异常处理，确保测试执行的原子性与一致性。
双端处理层：包括PC端指令提取模块与移动端智能执行模块。前者负责截图监控、感兴趣区域（region of interest，ROI）裁剪与指令解析，后者负责基于视觉信息的元素定位、操作执行及结果验证。
多模态AI服务层：封装通义千问视觉语言模型Qwen3-VL-Flash用于指令理解，Qwen-VL-OCR用于高精度文本识别，为上层模块提供统一的AI能力接口。
3 框架实现与核心模块
本文所提框架严格遵循“视觉感知—语义理解—操作映射—执行验证”的四阶段测试理论模型，各阶段依次衔接，构成从指令解析到结果验证的自动化测试闭环。
3.1 视觉感知
在实际测试场景中，PC端截图往往包含大量与测试指令无关的界面元素，如菜单栏、状态栏、广告区域等，这些冗余信息可能降低有效信息在输入图像中的占比，从而影响模型的指令识别效果。对此，本文设计了基于配置的感兴趣区域裁剪机制。
为防止框选区域超出原图范围，将转换后的横、纵坐标分别限制在和内，并对两个端点的横、纵坐标分别排序，使较小值对应裁剪区域的左上角、较大值对应右下角，从而消除用户框选方向的影响。系统将所得裁剪坐标以JSON格式持久化存储。测试执行时，框架加载该配置并裁剪PC端截图，仅将目标区域传递给多模态大模型进行指令识别，以减少无关界面信息的干扰。
为验证该机制的有效性，本文在框架开发阶段开展了预实验，以常见交互界面（含通话界面、文本输入界面、设置菜单等）的40条典型测试指令为样本，每条指令独立执行3次（共计120次执行），对比启用ROI裁剪前后的指令识别效果。未启用裁剪时，由于截图包含状态栏、导航栏等冗余信息，120次执行中正确识别108次，准确率为90.0%（108/120）；启用裁剪后，有效区域内的信息密度提升，120次执行中正确识别114~117次，准确率为95.0%~97.5%，提升幅度为5.0~7.5个百分点。测试条件是：PC端截图分辨率1920×1080，ROI区域平均面积占原图的25%~35%，测试设备为工程样机。
3.2 语义理解
提示词设计质量直接影响多模态大模型对界面内容的理解能力以及操作指令生成的准确性。为提高模型在自动化测试场景中的稳定性与可控性，本文构建了三段式结构化提示词框架，将业务层测试意图统一映射为可执行的标准化指令。
本文采用由任务描述、规则注入、输出约束组成的三段式结构化提示词模板。其中，任务描述段用于明确模型需要完成的核心任务，即从用户界面图像中提取关键信息并将其转换为测试操作指令，同时结合少量示例对模型进行引导，以增强其对任务语义的理解。规则注入段用于动态注入业务领域中的指令映射规则，使模型能够根据特定业务术语、页面语义和操作上下文，生成符合测试需求的操作指令。输出约束段则强制模型采用统一的JSON格式输出，包含content、instruction和type三个字段，分别对应原始文本内容、转换后的操作指令及指令类型，以便于后续模块进行自动解析与执行。
3.3 操作映射
依托多模态大模型的语义解析结果，本文进一步设计了基于规则的指令映射引擎，用于降低测试用例编写门槛并增强框架的领域适应能力。该引擎采用声明式可配置规则设计，将业务层自然语言测试意图映射为技术层可执行操作序列。规则文件支持关键词匹配、模糊匹配等多种模式，能够在运行时动态加载规则库，并结合大模型的语义理解能力完成意图识别与规则匹配。相较于传统项目硬编码分支判断方式实现的测试逻辑，本文设计的可配置规则引擎在可维护性、扩展性方面更具优势：业务人员可通过编辑规则配置文件完成测试逻辑调整，无需改动框架底层代码；规则支持热更新、版本管理和复用积累，有利于形成面向特定业务场景的测试知识库。实验表明，该语义理解与规则引擎协同机制能够有效提升测试用例的业务可读性与框架的实际落地能力。
3.4 执行验证
大模型返回的坐标信息通过正则表达式进行解析，支持{[x,y]}和{[x,y,width,height]}两种格式。
为防止误操作导致的测试失效或系统异常，方案设计了多层验证机制。首先，进行边界验证，确保坐标(x,y)满足0＜x＜Wscreen且0＜y＜Hscreen；其次，进行禁区检测，排除系统保留区域（状态栏、导航栏、虚拟按键区）；最后，进行可达性检查，验证目标坐标是否位于当前可见视口内，避免点击屏幕外元素。验证失败时，系统触发重试机制或降级处理，确保测试流程的健壮性。
4 实验设计与评估
4.1 RTT测试场景选择依据
RTT是一种基于IP网络的双向通信技术，它允许用户在语音通话过程中，通过键盘输入文本，并实现字符级别的即时传输。在移动应用中，RTT作为典型的“富媒体通信应用”，具备高度动态的用户界面交互（通话界面与文本框共存）、多线程的数据处理（音频流与文本流并行）以及严格的网络协议依赖（IP多媒体子系统核心网）等特征。
本文选择RTT测试场景作为检验框架有效性的典型场景，主要基于其在移动应用自动化测试中具备突出的行业典型性；同时兼顾实验环境条件与业务可落地性，适合作为标杆测试场景开展对照验证。RTT场景拥有界面动态变化、多流程强交互、跨设备界面布局存在差异等特征，能够充分暴露传统移动应用自动化测试方法的固有短板，适用于检验本文测试框架的综合性能与适配能力。
用户界面变更的高频性：RTT功能中的聊天界面（包括输入框、状态提示、气泡样式）是应用中变更较为频繁的区域，能够有效检验框架对界面变化的适应能力。
多模态交互的复杂性：如今移动应用已不再局限于单一的图形界面操作，而是越来越多地融合了语音、视频、文本等多种模态。RTT场景要求测试框架必须同时处理界面交互和底层媒体流。
跨设备界面布局的差异性：不同型号移动终端RTT功能的界面布局、控件设计（升级键、降级键）存在差异，能够验证框架脱离DOM定位符、基于视觉自适应识别的跨设备兼容能力。
4.2 实验环境
为确保实验的可重复性与结果的可信度，本文构建了标准化的实验环境，硬件与软件配置如下。
硬件环境包括网络模拟器、PC端和移动测试设备三部分。网络模拟器采用安立公司Anritsu MD8475B综测仪，PC端配置为Intel Core i7-12700K处理器（12核20线程，主频3.6 GHz），移动测试设备选用三款不同品牌的工程测试样机。
为明确实验环境中各硬件单元的物理连接关系，测试连接如图2所示。PC端运行测试控制软件，通过USB数据线与待测移动端连接，负责界面监控、操作指令下发与测试日志采集；移动端通过射频线缆与MD8475B协议测试仪连接，接收测试仪表模拟的IMS/RTT网络信令；测试仪通过网络交换机接入控制端PC，完成网络侧状态配置与信令交互。整套连接满足RTT场景下控制端、仪表、终端三方的实时协同需求。
图2 RTT测试连接示意
软件环境方面，PC端操作系统为Windows 10 Pro；开发语言采用Python 3.10.12，多模态模型调用Qwen3-VL-Flash。
为在实验环境中支撑RTT场景的全流程自动化测试，本文基于所提框架构建了如图3所示的测试架构，该架构由云端决策层与本地处理层组成。本地处理层以PC端为中心，通过测试仪表完成网络侧状态模拟，并借助安卓调试桥（Android debug bridge，ADB）完成终端界面捕获、操作执行与结果验证；区域裁剪配置与指令映射规则作为用户配置层的前置输入，对本地采集的界面信息进行预处理。云端决策层通过PC端处理模块与移动端执行模块接收双端数据，调用Qwen3-VL-Flash完成指令理解与视觉推理，调用Qwen-VL-OCR完成界面文本的高精度识别。在实验过程中，本地处理层持续将仪表界面与终端界面回传至云端决策层，云端决策层基于多模态理解结果下发操作指令，由本地处理层执行弹窗确认、终端操作与结果验证，从而实现PC、仪表与移动端的跨设备协同。
图3 基于多模态大模型的RTT测试架构
4.3 实验结果
为测试框架在跨设备协同测试场景中的实际表现，本文选取语音通话发起、RTT升级、升级结果验证、RTT消息发送、消息发送验证、消息接收验证、RTT降级、降级结果验证以及挂断通话等9类典型测试场景，在不同测试终端上开展RTT全流程测试。评价指标主要包括测试执行时长、各类操作调用次数以及场景通过情况。图4为不同终端在测试时长和应用程序接口（application program interface，API）调用次数上的对比结果，图5进一步展示了测试过程中API调用、PC处理、ADB操作、点击操作和验证次数等细粒度操作分布。由此可以看出测试框架并非仅在测试开始阶段调用一次模型完成静态识别，而是在测试执行过程中持续依托多模态大模型，完成界面理解、操作目标定位、状态判断及结果验证，使AI能力深度嵌入测试全流程。相比传统自动化测试主要依赖脚本逻辑和控件定位符的执行方式，本文方案将测试决策过程更多地交由视觉语义理解模块，从而提升了跨设备场景下对界面差异和动态状态变化的适应能力。
图4 不同终端测试时长、API调用次数对比
图5 不同终端操作执行分布
从图4可以看出，不同终端在测试执行效率方面存在一定差异。其中，手机终端2整体执行效率最高，10轮重复测试的平均测试时长为5.9 min（单轮测试时长在5.5~6.3 min之间波动），API调用次数为95次；手机终端3次之，平均测试时长为7.6 min（单轮测试时长在7.1~8.1 min之间波动），API调用次数为100次；手机终端1耗时最长，平均测试时长为8.5 min（单轮测试时长在7.9~9.1 min之间波动），API调用次数达到117次。各终端在10轮测试中，单轮测试时长的波动幅度均不超过均值的10%，表明框架在不同终端上的执行时间具有较好的一致性。总体来看，三类终端均能在10 min以内完成全部测试任务，说明该框架在跨设备场景下具有较好的执行效率，整体开销处于可接受范围内。进一步结合柱状分布可以发现，测试时长与API调用次数呈现较为一致的变化趋势，即API调用次数越多，整体执行耗时越长。这表明系统总体时间开销主要受多模态模型推理与交互轮次影响，同时也说明不同终端在界面加载速度、页面响应时间以及状态稳定时间等方面的差异，会进一步放大测试时间上的差别。
本文方案在保证高准确率的同时，在执行效率与工程可用性方面达到实用要求。一方面，基于视觉语义理解的元素定位方式，有效降低了对控件标识符、XPath等传统定位符的依赖，增强了框架面对用户界面变化时的鲁棒性；另一方面，PC-Mobile双端协同机制与规则驱动的指令映射方法，使自然语言测试意图能够稳定转换为可执行操作序列，从而提升了复杂业务场景下自动化测试的可落地性。
5 结论与展望
针对移动应用自动化测试中脚本维护成本高、跨设备适配难度大等痛点，本文提出了一种基于多模态大模型的跨设备协同测试框架。该框架建立了视觉-语义协同的四阶段测试理论模型，从根本上摆脱了对DOM结构及控件定位符的依赖；设计了PC-Mobile双端协同架构与事件驱动的松耦合通信机制，实现了从PC端测试指令提取到移动端智能执行的自动化闭环；建立了可配置的自然语言指令映射机制，结合规则驱动的指令转换引擎与结构化提示词工程，将自然语言测试意图自动转换为可执行操作序列，降低了测试用例编写与维护的技术门槛。
实验结果表明，该框架在9类典型RTT测试场景中全部验证通过，测试成功率达100%；测试用例集平均开发工时由传统方法的15人时降至6人时，开发效率提升约60%；且用户界面变更后无需修改测试配置，展现出较强的鲁棒性与跨设备适配能力。
下一阶段工作将围绕5个方向展开：第一，扩展测试终端覆盖范围，纳入更多品牌设备，验证框架的广泛适用性；第二，探索动态页面与实时交互业务场景，提升时序同步能力；第三，研究多任务并发测试机制，进一步提升测试吞吐量；第四，结合知识蒸馏或模型压缩技术降低推理延迟，探索边缘端部署方案，减少对云端API的依赖；第五，将本方法推广至网页应用和桌面应用的自动化测试场景，进一步拓展方案的适用场景与应用边界。
参考文献
[1] 中国互联网络信息中心. 第57次中国互联网络发展状况统计报告[R]. 北京: 中国互联网络信息中心, 2026.
[2] 王军. 人工智能自动化测试技术在移动互联网领域的应用研究[J]. 软件工程与应用, 2024, 13(4): 510-515.
[3] 赵东升, 孟伟, 徐锋, 等. LLM在软件测试用例智能生成中的应用研究[J]. 计算机科学与应用, 2025, 15(12): 222-227.
[4] LEOTTA M, CLERISSI D, RICCA F, et al. Capture-replay vs. programmable web testing: An empirical assessment during test case evolution[C]//2013 20th Working Conference on Reverse Engineering (WCRE). IEEE, 2013: 272-281.
[5] YEH T, CHANG T H, MILLER R C. Sikuli: using GUI screenshots for search and automation[C]//Proceedings of the 22nd Annual ACM Symposium on User Interface Software and Technology. New York: ACM, 2009: 183-192.
[6] 王媛, 韩启, 张絮, 等. 基于提示工程的软件测试用例生成方法研究[J]. 嵌入式技术与智能系统, 2025, 2(5): 330-336.
[7] WEN H, LI Y, LIU G, et al. Autodroid: LLM-powered task automation in Android[C]//Proceedings of the 30th annual international conference on Mobile computing and networking. 2024: 543-557.
[8] 3GPP. TS 26.114: Multimedia Telephony over IP Multimedia Subsystem (MTSI)[S]. v17.0.0. Sophia Antipolis: 3GPP, 2022.
[9] HELLSTROM G, JONES P. RFC 4103: RTP Payload for Text Conversation[S]. IETF, 2005.
[10] Federal Communications Commission. Transition from TTY to Real-Time Text Technology[S]. 47 CFR §67.1, 2016.
热门跟贴