导读：多模态大模型(MM-LLMs，全称Multimodal Large Language Models)的迅猛发展与提示工程(Prompt Engineering)的深度融合，正在为软件测开领域注入颠覆性创新。在雪球前端回归测试这一关键环节中，传统用例编写高度依赖脚本化代码，维护成本高昂且难以应对动态变化的UI和复杂交互场景。**我们设想：能否用一句简单的自然语言描述，直接完成前端自动化测试的全流程？即："NL2Test"（Natural Language to Test)。**为了解决这个挑战，雪球QA团队探索出一种基于自然语言交互与多模态感知的测试新思路：通过MM-LLMs的语义理解与图像解析能力，结合分层式提示词设计，将自然语言测试用例转化为可执行脚本，并实现视觉元素的动态适配验证。这一方法不仅能降低自动化测试的技术门槛，更能通过"所见即所测"的闭环反馈机制，显著提升测试覆盖率和场景适应能力。经过雪球、雪基、雪盈三条业务线多类回归场景的试用和分析跟踪，目前在自然语义理解、动线思考、UI验证方面表现出良好的智能化分析能力和脚本自愈能力。 本文从系统设计、业务实践和未来规划的角度，分享一下QA团队在结合AI大模型上的效能升级。
一、背景
回归测试(Regression Testing)是软件质量保障体系中的核心环节，也是雪球体系下各app发版前的重要步骤。在大前端领域，回归测试的重要性尤为突出。过去十年间雪球三大app上线了海量的需求，这些持续迭代的功能日益累加形成了庞大的功能回归集，现代前端工程普遍采用组件化、模块化架构，且需适配多终端、多分辨率场景，任何UI交互逻辑、视觉样式的调整、编译器的升级操作等变动都可能引发跨模块的功能和兼容性问题，从而影响产品质量和我们用户的最终体验。
尽管前端回归测试不可或缺，其实践路径却长期受限于技术工具与协作模式的滞后性，逐步形成以下两大阶段的典型"困境"：「低效率的人工回归测试」与「高维护成本的硬编码UI自动化测试」。在自动化工具普及前，回归测试高度依赖人工操作，容易导致"经验孤岛化"。为解决人工测试的局限性，Selenium、Cypress等自动化框架逐渐成为行业标配，但其"脚本化"实现方式也带来了新的技术债：
| 问题分类 | 具体问题 | 示例 |
|---|---|---|
| 静态定位符的脆弱性 | 元素定位失效：前端 UI 迭代常导致定位符失效 | 基金详情页购买按钮的className改变后，需人工修正所有关联脚本 |
| 动态内容无解：硬编码规则无法自适应内容变化 | 列表页动态分页逻辑调整，导致 10%的列表翻页用例失效 | |
| 验证逻辑的精细化陷阱 | 视觉校验缺失：无法遍历精细检测细微元素渲染异常 | 雪球账户设置列表页展开按钮方向渲染错误，校验脚本忽略该异常 |
| 状态机盲区：复杂交互链路的中间状态需要通过脚本精准遍历断言覆盖 | 投顾交易过程中支付方式或支付渠道可能触发渠道校验弹窗，需要遍历类型精细化处理 | |
| 与架构演进的强耦合 | 技术栈绑定：测试脚本深度依赖前端框架的实现细节 | 项目从Native迁移至RN时，可能会导致一定比例的用例重构 |
| 环境依赖僵化：本地与 CI/CD 环境的差异常导致"伪失败" | 某团队统计显示 15%的构建因环境问题误报失败 |
上述问题共同指向一个本质矛盾------传统回归测试的静态规则与端智能化的演进趋势脱节。当行业迈入大模型时代，通过多模态语义理解与自然语言交互重构测试范式，已成为突破"人肉脚本"困境的新型选择。这一转型的实现需同步推进雪球QA团队测试工具的智能化升级与协作流程的有序适配。
二、多模态大模型的端自动化架构升级
1. 多模态大模型的"本领"
在把多模态大模型(MM-LLMs)正式引入到自动化框架之前，让我们先来认识一下MM-LLMs，看看它有怎样的特性，这些能力如何跟我们的需求进行有效结合。
MM-LLMs（MultiModal Large Language Models，多模态大语言模型） 是一种结合了大语言模型（LLMs）和多模态处理能力的先进人工智能系统。它不仅能够理解和生成自然语言文本，还可以处理多种模态的数据（如图像、音频、视频等），并在不同模态之间建立关联，从而实现更全面、更智能的任务处理。
MM-LLMs模型架构
2. 多模态大模型在前端自动化中的核心作用
如果把自动化测试做简单暴力的抽象，大多数时候它在描述这两个场景：「用户去往哪里」以及「那里有什么问题」。 在了解了MM-LLMs的能力之后，我们关注到与前端自动化测试强相关的两个重要的特性：基于自然语义的动线识别与图像分析对比。这尝试解决了自动化测试的两个关键问题，让我们分别来看看这两个问题以及对应的解题过程：
问题1：如何去往目的地？
首先我们来看第一个问题------怎么定位到目标页面，如何设计和编排用户动线？我们拿「进入到雪球基金详情页」的场景来举例：
可以看到，在传统的"硬编码"式分析中，为了能够进入到基金详情页，我们需要分析每一步用户动线中历经的页面DOM(文档对象模型)，找到页面中的关键元素，对其定位方式和操作方式进行代码转义和执行。显然这里引入了繁琐的分析步骤和巨大的维护成本，在大模型的背景下，我们如何能够用一句话来复刻这样的过程呢？这里，我们将要引入本文第一类大模型：拥有Agent能力的多模态大模型。
我们以目前调研和试用表现稳定的Qwen2.5 VL来举例， **Qwen2.5 VL和Mobile Agent: **Locate and think for mobile phone control(github.com/QwenLM/Qwen...).
这里从其github和官网的介绍中抽取了Qwen2.5 VL模型与自动化关联最为紧密的3个核心能力：
既然大模型在移动设备控制上有以上这么优秀的能力，我们又是怎么使用的呢。此处仍然以进入个基页为例，我们来看一下从"进入到雪球app"之后，再到"进入到基金详情页"之间，设备、用户、大模型如何进行交互：
进入到基金详情页的自动化全流程
以上是基于多模态大模型体系下「进入基金详情页」的全流程自动化交互过程，可以看到我们仅使用一句简单的Prompt**"进入「广发上海金ETF联接A」的基金详情页"**，就成功了触发了大模型一连串的思考和执行，最终成功到目标页面。整个过程中，**我们没有指明固定的路径、关键的元素和具体的操作，**整个用户动线由AI来自动分析和判断，并把需要进行的操作进行一系列拆解后给到我们，我们仅完成最后的底层操作即可。我们拿第一步触发搜索来具体分析一下：
思考进入到搜索页的交互过程
可以看到模型的识别经历了几个步骤：它首先尝试从现有的基金列表中寻找目标基金，当我们故意把目标基金设为列表中存在的基金时，AI可以跳过后续的搜索步骤。现在的场景里由于列表中无法匹配到目标基金，AI开始寻找可能的进入路径，当它识别到搜索icon后，返回了对应的元素和操作并继续上述的思考和反馈过程，继续触发了后续一系列搜索点击、输入和筛选的过程，从而完成了最初给到的任务。
通过上图的分析，我们可以自然地引出基于Mobile Agent的脚本动线过程改造。其核心思路是：给模型以引导性的描述，这类描述尽量不与具体页面元素和动线强耦合，以提升后续的兼容性，从而降低动线的维护成本。下面回到最初的登录页面，开始我们全新的改造吧：
-
改造①：动线描述------自然语言描述动线代替硬编码元素定位：
自然语义完成雪球基金app登录
-
改造②：Prompt拼接------在模型交互前，将自然语言转换为结构化Prompt（本节不展开讲述内部的组装机制，下一节在讲述Prompt工程时我们再详细探讨）：
围绕自然语义的Prompt拼装结构
-
改造③：代理回调------响应解析，实现底层各端原子操作：
通过以上3步改造，基于大模型的引入我们可以把动线分析过程和回调过程进行有序解耦和分层拆解，把繁杂的元素识别判断通过自然语义的描述交付给大模型去理解和分析，再把转化后的执行过程对应到每个移动端单独处理，最终实现了自动化过程中"如何去"的目的。
问题2：目的地是否正确？
上一节我们利用动线模型解决了如何去的问题，本节我们来处理第二个问题：去的地方是否正确，其页面元素展示以及体现出的功能、设计等元素是否符合预期。
在思考如何用大模型处理这个问题之前，让我们再次回到基金详情页的场景，当一名QA同学尝试去判断基金详情页是否正确，可能会采用以下的两种大类型方案：1.基于设计规则、业务认知对详情页做基本判断；2.根据需求文档、设计稿做分析对比。我们不妨把这两大类进行简单抽象，即：单场景分析和多图对比。这里，我们将要引入本文第二类大模型：拥有专业视觉理解能力的多模态大模型。
我们以目前调研和试用表现稳定的Doubao-1.5-vision-pro来举例， **Doubao-1.5-vision-pro：专注于多模态数据处理与深度视觉解析。**这里我们抽取了数据分析模型与自动化关联最为紧密的3个核心能力： 接下来让我们带入到具体的测试场景中，看看视觉模型如何进行单场景分析和多图对比。
-
基础校验：单图片场景分析
基于设计规范的分析识别
-
进阶校验：多图对比分析
基于基准对比图像的diff分析
-
多模型验证
另外，在针对基金详情页不同日期时间跨度的两张图片比对结果中，我们也针对其他大模型做了校验结果可行性验证。以下大模型均能够识别出两张图片内容的相同点，以及由于时间跨度的不同从而造成业绩数值和曲线的不同走势。
不同时间间隔的基金详情页收益曲线对比
录入同一条prompt（比较两张图片的区别，如果忽略时间跨度导致的不同点，可以认为两张图片的内容是相同的吗），在进一步忽略时间跨度问题导致的不同点后能够总结回答正确：
| 厂商 | deepseek | 通义千问 | kimi | 豆包 |
|---|---|---|---|---|
| 模型 | R1 | qvq-72b-preview | k1 视觉思考模型 | Doubao-1.5-vision-pro |
| 备注 | 非视觉推理模型，仅支持识别图片中的文字进行分析 | 视觉推理模型，preview 版本 | 独立的视觉思考模型，比通用模型针对图片分析思考更全面 | 支持任意分辨率和极端长宽比图像识别，增强视觉推理 |
| 耗时 | 23秒 | 26.88秒 | 2秒 首token | 2.8秒 首token |
| 是否满足比对需求 | 是 | 是 | 是 | 是 |
可以看到，通过将验证行为拆解为单场景分析以及与基准图进行对比的方式，结合层级设计的引导提示词，可以有效的引导大模型分析出页面的展示元素、交互方式和功能实现是否符合预期，从而达到解决"去的地方对不对"的目的。同时我们也发现，擅长此类分析的视觉模型相较于Agent模型规模更大、识别稳定度更好。
3. 前端自动化系统层架构总览
基于以上的分析和设计，我们完成了一次前端自动化框架智能化升级，将具备视觉定位和页面分析的多模态大模型引入到自动化体系中，整体形成如下的架构：
基于上述的架构，我们的自动化测试流程也相应做出更智能的调整：
自此，我们阶段性的完成了基于MM-LLMs的端自动化测试架构升级，通过动线模型和分析模型的结合，把自动化交互和验证过程进行了AI化改造，重新解决了"如何去"和"去的地方对不对"这两个问题。
三、Prompt工程的"规则炼金术"初探
上一章节我们重点介绍了自动化的两个问题如何跟大模型进行结合，但AI真的智能到能完全自主决策吗？其实不然，我们已经看到，在跟大模型交互之前，我们准备了一套完善的结构化Prompt，虽然当前AI具备强大的语义理解能力，但若缺少结构化Prompt作为"方向盘"，模型极易陷入发散式输出，产生"一本正经地胡说八道"的技术风险。本章我们来重点介绍一下具备定向引导性的结构化Prompt是如何生成的？ （把Prompt Engineering带入到QA工程中是个庞大的系统建设过程，这里我们限于篇幅和重点，仅对其在前端回归中的设计和应用进行展开，后续我们会再跟大家分享其在AI测试全流程中的支撑作用。）
1. 结构化Prompt演进
结构化Prompt的本质是通过预置规则对模型能力进行定向激活，其生成过程包含场景识别、要素拆解、模块组装三个关键环节：系统会先解析用户意图所处的业务场景（如动线操作/图片分析），然后自动抽取该场景所需的角色定义、操作指令、格式规范等要素，最终组合成可执行的交互框架。所谓Prompt工程，正是对Prompt进行系统性优化的技术体系，包含提示词封装、要素标准化、上下文控制等方法。从技术视角看，现代Prompt不仅是问题描述，更承担着人机交互语义对齐的核心功能------通过角色扮演建立认知框架，通过规则描述划定能力边界，通过输出示例明确结果范式。例如在生成测试用例场景中，一段优秀的Prompt会同时包含角色设定、调用指令、期望结果、具体内容等多层控制逻辑，使AI的回复既专业又可控。
支撑这些演进的核心逻辑在于双重控制机制：1.闭合式Prompt通过模板化输入建立标准路径，比如要求"检查登录功能"必须包含用户名输入、密码加密、错误提示等检查项；2.组合式设计则借鉴目录管理思维，让基础规则与业务规则形成继承关系。这种结构化思维直接带来测试效能的跃升------明确的断言条件消灭了"似是而非"的通过结果，多规则组合能捕捉UI错位与接口数据不同步的复合缺陷，而自然语言编写的规则库更让业务人员可直接调整核心逻辑，这种技术演进的价值在回归测试中尤为凸显。
2. 回归测试的提示词设计三步走
介绍完结构化Prompt，让我们再回到具体的测试场景，看看Prompt工程的设计过程。这里还是以基金详情页为例来贯穿分析，当测试人员尝试对基金详情页进行验证时，实际上在进行哪些操作？这些操作又如何被我们抽象提取，最终形成了前端回归测试的Prompt工程。
步骤1，从人工校验到规则抽象。
①**人工校验流程拆解：**把人工校验流程进行拆解，以基金详情页为例，当测试人员看到基金详情页的展现时，需要完成下图左侧的所有校验步骤；
②规则抽象， 将人工校验流程抽象为三级可编程规则体系：元素级校验→组件级断言→业务流验证。
步骤2，规则目录同步分层。
按照自定义目录结构，将规则层级按照父子关系进行拆分，相同的规则合并向上递归，保证规则的原子性。
步骤3，验证内容的抽取与封装。
选择不同的规则类型，选择特定的规则进行校验；
选择不同的目录结构，递归到最上层，逐层进行内容拼接。
Prompt例子：校验"南方天天利货币B"个基页数据
思考：南方天天利货币B属于货币基金，目录需要选择"货币基金"，同样需要递归"公募-单品基金"、"基金品类"、"雪球基金"、"根目录"这几个目录内容。由于没有规定规则，则需要校验所有规则，因此生成Prompt的方式如下：
层级结构化封装Prompt
通过这三个步骤，我们把角色行为、业务属性、通用规则、定向校验内容等关联Prompt进行分层封装，在校验时再进行结构化组装，从而达到组合式、闭合式的多层级Prompt维护和使用的目的。
3. 面向NL2Test的雪峰后台规划
基于以上对于测试行为和关键验证节点的Prompt分层设计思路，我们也把雪峰后台的Prompt管理系统进行了梳理和拆解，形成全新的架构方式：
在这样的设计体系下，它能够更好的服务于后续的AI自动化测试，包括正在同步实施的后端MR/全项目分析、规划中的需求与业务规则风险预判以及通过测试结果反哺规则库的「知识库自进化」，我们会在未来的文章中与大家继续进行基于这些角度的Prompt工程演进探讨。
四、小结
经过Q1的工程实践，QA团队验证了多模态大模型在前端自动化测试中的可行性，但同时也认识到，AI技术落地的过程是系统工程能力与技术敏感度的双重加持，最后有几条接地气的经验也想分享一下。
-
多模型协同的必要性，打造模型间的"资产配置"
在初期技术验证中，单一模型方案暴露了显著的能力短板：视觉大模型虽能精准定位控件坐标，却对业务语义理解度表现一般；语言模型可解析测试需求，但缺乏界面元素感知能力，这些问题最终引导我们构建了分层式模型调度框架，这有点类似AI的"资产配置理念"，通过一揽子模型来应对现阶段测试场景需要的多维能力，降低单一模型的"风险"。
-
"套壳"不是一件简单的事，本地化适配工程需要同步助力
AI项目的落地无法通过简单的套壳完成，无论是通过雪峰后台的Prompt工程降低大模型的"幻觉"，还是采用前端AI测试系统的设备集群提升AI并发效率，这些本地化工程的建设和迭代都在尝试优化弥补当前大模型识别不准确、响应速度慢的问题。未来通过结合雪球业务的向量库系统建设，相信会把更多项目的自动化效率提升到更精准的智能化程度。
-
把AI的"幻觉"逐步调试收敛为确定性
与AI的交互和调试也是一项充满想象力的过程，借鉴传统调试方法的确定性分析思维（如断点调试、日志追踪），我们发现在提示词中添加约束条件可显著提升执行稳定性。例如，提示词中添加一句"停止思考"可以引导大模型跳出在某一批页面中陷入死循环问题，比如一句"请用英文思考回答"可以引导大模型转换中文判断后不执行的场景，这些调试过程和解决方式跟确定型分析相比，可能更需要思维的拓展。
前端AI自动化测试是雪球QA团队25年度实施NL2Test计划的首批项目。当前已完成三大核心业务线的技术验证，但在长尾场景覆盖和细粒度断言生成方面仍需持续优化。值得期待的是，随着多模态大模型技术迭代，面向测试领域的专用AI agent（兼具视觉解析、逻辑推理、脚本自愈等能力的综合智能体）正在加速演进。团队将持续评估国内外前沿模型，通过本地化工程改造（如提示工程优化、私有化部署、内部向量库等）构建AI测试增强框架，助力业务坐上"加速器"快速验证目标。