做移动端自动化测试这些年我最大的感受是维护成本永远比你预估的高。脚本写出来只是开始后面每一次页面改版、每一次弹窗调整都会让一批定位器失效然后你就要花大量时间去排查到底是产品改了还是脚本老了。这还不是最痛的最痛的是跨端场景下同一套业务逻辑在Android和iOS要各自维护一套脚本工作量直接翻倍。我们团队从去年开始尝试把大语言模型引入移动端自动化测试流程内部代号就叫 ARTEMIS。它不是传统意义上多了一个智能断言工具而是从运行机制上把测试的组织方式改了从写脚本变成定意图。这里最重要、也最值得展开聊的设计就是它的双模式架构。这篇文章把双模式的拆分逻辑、每个模式的运行机制、以及两者之间怎么衔接讲透希望对正在探索 LLM 自动化测试的同行有参考价值。1. 移动端自动化测试的困境ARTEMIS 想改变什么在拆架构之前先得说清楚一个问题现有的移动端自动化测试到底难在哪。如果没说清楚痛点任何架构设计看起来都像是炫技。1.1 脚本维护的隐性成本一个按钮变化牵动多少用例UI测试本质上是在和变化作斗争。传统做法里我们靠的是元素定位器比如id、xpath、content-desc这些。问题在于移动端的UI变更频率远高于后端接口产品同学经常为了一个按钮的文案、位置、颜色进行调整而这些调整很可能让定位器失效。举一个真实场景某个模拟项目里底部Tab栏的我的入口从第二个位置挪到第四个位置同时图标资源名也改了。这个变动大约导致 27 条用例失败其中真正因为业务逻辑变化的只有 3 条其余 24 条都是定位器失配。而修复这 24 条用例平均每条要花 5 到 10 分钟包括定位、验证、跑回归。一个月算下来光定位器修复就吃掉了一个人不少工时。跨端场景更麻烦。同一功能在 Android 和 iOS 上元素树结构完全不同自动化脚本得各写一套。如果业务逻辑调整了两边都要同步改改完还要各自验证。这就是很多团队自动化测试规模越大、负担越重的根本原因——测试资产是死的它不理解页面语义。1.2 LLM 带来的三个能力杠杆视觉理解、语义推理、自然语言接口LLM 给移动端自动化带来的不是新的定位方法而是三个更底层的能力杠杆第一个是视觉理解。多模态模型能直接看截屏理解页面布局、按钮位置、文案关系。这意味着什么意味着即使元素树缺失比如某些自绘控件、WebView 内嵌页面测试系统仍然能靠视觉理解页面内容定位到目标控件。第二个是语义推理。模型能从用户想做什么推导出应该执行哪些操作序列。比如把推送关掉传统脚本你得先知道入口在设置页、开关的 id 是什么、可能还要处理一个确认弹窗。而语义推理可以直接规划出动作序列进入设置页找到推送开关关闭处理弹窗。第三个是自然语言接口。这个听起来最不起眼实际价值最大。它把测试用例的编写门槛从会写代码降低到会说清楚需求。业务同学可以描述场景测试同学来审核和兜底自动化系统负责翻译成可执行动作。有了这三个杠杆我们完全可以重新设计一套移动端测试系统的运行架构。1.3 ARTEMIS 的定位意图驱动的移动端测试执行引擎ARTEMIS 不是要替代 Appium 或 XCUITest 这些成熟框架而是把 LLM 作为一个意图理解层叠加在传统框架之上。底层还是需要设备桥接、驱动管理、截图采集这些能力但上层的行为决策不再依赖固定脚本而是依赖模型对当前页面状态和任务意图的理解。它和传统框架的关系很像导航软件和汽车的关系。汽车负责执行设备控制、动作模拟、状态采集导航软件负责规划理解用户意图、选择路径、动态调整。ARTEMIS 在导航这个层面做文章。而导航软件需要两种工作模式一种是没有目的地时你让它随便开把城市路网摸清楚——这是探索另一种是你明确告诉它要去哪个地址它规划最优路线并逐段导航——这是执行。这就是双模式的由来。2. 双模式架构总览一个引擎两种运行形态很多团队做 LLM 测试系统时容易犯一个错误想做一个万能 Agent既要能自主探索又要能精确执行。实际做下来你会发现这两个目标的评价指标是冲突的。2.1 模式划分的底层逻辑探索要广度执行要精度自主探索的考核指标是覆盖率在有限时间内尽可能多地经过不同的页面状态、触发不同的行为分支。它要求模型敢试遇到不确定的控件也愿意点一下看看反应。执行模式的考核指标是准确率严格执行用户的意图、不越界操作、断言可靠。它要求模型克制只有高置信度时才动手拿不准就要停下来问。这两种行为倾向放在同一个 Agent 里会出现一个尴尬局面探索时太保守覆盖率上不去执行时太激进容易自作主张。所以 ARTEMIS 从一开始就把它们拆成了两个运行模式共用底层能力但决策策略、护栏机制、评价逻辑完全不同。2.2 整体组件分层交互层、理解层、决策层、执行层ARTEMIS 的逻辑结构可以分成四层双模式在这四层上的表现各有侧重层次核心职责自主探索模式的表现引导执行模式的表现交互层设备桥接、数据采集高频截图、层级树抓取、状态哈希计算低频采集按动作节点触发理解层页面语义解析、指令拆解页面分类、可交互元素识别、行为空间估计自然语言指令到结构化意图的映射决策层动作选择、路径规划探索策略广度优先/深度优先、去重控制动作序列校验、置信度判断、人工确认触发执行层动作翻译、结果收集随机但受控的动作执行严格受控的动作执行与断言验证交互层和执行层其实是共用的都是连设备、跑命令、拿状态。真正的差异在理解层和决策层。2.3 为什么保留传统测试框架作为底座有人会问既然 LLM 能理解页面为什么不干脆让模型直接操控手机还要 Appium 干嘛这一点实践之后体会特别深设备控制在稳定性上要求近乎苛刻连接断开要能重试、截图要保证完整、滑动手势要模拟得像真人。这些能力传统框架已经打磨了很多年没必要重新造轮子。ARTEMIS 的做法是把传统框架当作操作系统LLM 只负责在大脑层面做决策手脚还是交给成熟框架。一旦底层执行出现超时或异常不会让模型去猜为什么而是由框架层先做自动重连、重试、日志采集。这种分层设计让整体稳定性高了很多调试时也能快速定位是决策错了还是执行错了。3. 自主探索模式让测试 Agent 学会当一个有好奇心的用户自主探索模式的设计目标很简单在没有预设脚本的情况下让 Agent 自己逛App摸清哪些页面能到达、哪些控件能交互、哪些状态会触发异常。这本质上是一个强化学习里的探索问题只是策略函数换成了 LLM。3.1 感知通道融合视觉截图 UI 层级树 状态哈希纯视觉方案有个问题模型看截图能理解个大概但对控件边界、可点击区域这些细节判断不准容易点了按钮旁边 10 像素的地方触发不了任何事件。纯层级树方案呢遇到 WebView 和自定义绘制控件又是两眼一抹黑。所以 ARTEMIS 用的是双通道融合。截屏给视觉模型做页面布局理解这个页面上有哪些区域、每个区域大概是什么功能。层级树给结构化信息控件的具体边界坐标、类型、可见性、可点击性。两个通道配对后当视觉判断这是个登录按钮、层级树也确认这里有个可点击的 Button 控件时置信度就足够高可以执行点击。还需要一个状态哈希机制。同一个页面每次渲染可能都有细微差异比如网络头像加载完毕、滚动位置变化这些不能算页面变化。ARTEMIS 会对页面截图和简化后的层级树做归一化处理生成一个状态指纹。只有指纹变化超过阈值才认为进入了新的页面状态才会触发后续的动作决策。这个机制有效避免了模型在同一页面反复打转。3.2 决策循环观察、推理、行动、记忆探索模式的每次循环包含四个步骤。第一步观察采集当前截图、层级树、状态哈希形成当前状态的完整描述。第二步推理让 LLM 总结当前页面是什么、有哪些关键可交互元素、之前是否已经访问过类似状态。这一步有两个输出可选动作列表和倾向建议。动作列表来自层级树中的可交互控件加上系统级动作返回、滑动、截屏。第三步行动从动作列表中选择一个执行。选哪个由探索策略决定。ARTEMIS 默认采用混合策略维护一个未访问控件队列和未到达状态集合倾向于优先点击从未访问过的控件区域如果连续 N 步都没有产生新状态则随机跳转到一个历史页面重新开始。第四步记忆执行动作后把结果状态、动作效果记录到探索日志里。这个日志是后续沉淀知识资产的基础。3.3 动态状态处理等待网络、弹窗消解、加载态识别移动端探索最容易翻车的不是找不到控件而是异步状态。点了一个按钮页面进入 loading某些树节点是空的此时 LLM 很容易误判页面没反应或者操作失败。ARTEMIS 有一个专门的加载态识别器在决策前先判断当前页面是否处于稳定状态。逻辑不复杂如果检测到加载指示器进度条、loading 控件、骨架屏就等待并轮询最多等若干秒超时后如果还在加载记录一条状态异常然后选择其他动作路径。弹窗消解也至关重要。App 在探索过程中经常会弹出隐私授权、版本更新、活动推广等弹窗如果 Agent 不处理后续所有动作都可能被弹窗挡住。但也不能见弹窗就关有些弹窗很重要比如注销类确认框。ARTEMIS 对弹窗做了分级处理系统权限弹窗按既定规则处理业务推广弹窗优先关闭阻断性很强的确认弹窗会先截图记录并挂起等人工介入确认。3.4 探索结果的沉淀行为轨迹、控件地图与候选用例探索本身不是目的沉淀才是。探索结束后系统会把整个探索过程整理成三份产物第一份是行为轨迹。记录从启动页到每个终态页面的完整路径格式是页面状态 A → 控件 B 点击 → 页面状态 C。这份轨迹可以直接转成可回放的用例骨架测试人员可以把它当作初稿来修改而不是从零开始写。第二份是控件地图。把所有探索过程中识别过、操作过的控件聚合成一个语义控件库记录它的文案、类型、相对位置、所在页面。这个库在引导执行模式里特别有用相当于一个定位器知识库让后续执行时不需要每次都去重新解析页面。第三份是候选异常列表。探索中遇到的崩溃、无响应、异常弹窗、加载超时都会被标记出来附上现场截图和操作路径。这些是测试报告里最有价值的信息因为很多普通回归根本覆盖不到那些路径。4. 引导执行模式把帮我测一下登录翻译成可控的测试过程如果说探索模式是广撒网那引导执行模式就是精准打击。它的输入是用户的自然语言指令输出是一段被严格校验过的可执行动作序列。这个模式解决的是日常回归测试中最常见的诉求我想验证一个具体场景但我不想写脚本。4.1 指令解析与意图补全LLM 不只是翻译还要补上下文自然语言指令在实操中往往是不完整的。用户说测一下登录流程但登录流程有几个前置条件账号从哪来需要先注册吗登录失败场景要不要覆盖页面入口是从启动页进还是从设置页进这些信息用户大概率不会说全。ARTEMIS 的做法是意图补全。模型先把指令解析成一个结构化测试任务入口页面、动作序列、预期结果。然后针对缺失的参数发起澄清或者基于控件地图里已有的知识自动补齐。举个例子指令是从首页进到设置把推送通知关掉然后回首页确认图标变化。经过意图补全后变成这样启动 App确保首页加载完成找到设置入口可能是首页右上角图标并点击在设置页找到推送通知开关控件点击开关使其状态变为关返回首页检查是否有图标或角标变化断言开关状态为关且首页对应视觉元素发生变化每一次补全都有对应的可靠性标注有些步骤来自显式意图置信度高有些步骤来自推测置信度低执行到那里时系统会停下来请求确认。4.2 动作空间约束与安全兜底不能让它随心所欲LLM 生成动作序列这件事最让人担心的不是做不了而是乱做。模型可能设计出一个看起来合理但越界的动作比如直接调系统设置修改应用权限。这在自动化测试里很危险会污染环境、影响后续回归。ARTEMIS 在理解层和决策层之间加了一道动作空间过滤器。过滤器维护一个允许动作白名单点击、长按、滑动、输入、返回、等待、断言、截屏。超出白名单的动作比如修改设备系统设置、跨进程通信等直接拦截不进入执行层。拦截的时候不只是报错还会触发一个替代逻辑模型重新规划一条合规路径。比如想直接修改系统推送权限许可合规路径是进入应用内设置页 → 找到权限管理入口 → 逐个开关检查。这样既保证了测试目标能达成又限制了动作范围。此外还有控件级校验。执行点击之前执行层会再次确认目标控件在当前时刻仍然可见、可点击且坐标没有漂移。这个校验虽然引入了一点额外耗时但把大量因页面变化导致的误操作挡在了执行之前。4.3 断言与结果归因怎么判断测试通过不是说了算LLM 测试系统里的断言问题比传统框架复杂得多。传统断言很明确某个控件是否存在、文案是否匹配、某个接口返回值是否符合预期。LLM 场景下用户的预期往往是模糊的比如确认图标变化——什么样的变化算通过了ARTEMIS 把断言拆成显式和隐式两类。显式断言来自指令中的明确表述开关关闭、图标出现、消息发送成功。这类断言直接映射到控件状态检查。隐式断言来自系统对正常状态的理解没有崩溃日志、没有出现异常错误弹窗、网络请求没有大量失败、页面没有停留在 loading 超过正常时长。隐式断言不属于用户指令的一部分但它其实是很多回归测试真正想验证的内容。当测试失败时系统会做结果归因先回放动作序列判断是否存在执行偏差比如点击了错误的控件、等待超时如果执行没有问题再判断是不是应用本身的缺陷。这个归因过程会生成一段解释性文本告诉测试人员失败原因是动作 A 之后预期出现状态 B但实际出现状态 C执行链路完整疑似应用问题。这比传统框架一句干巴巴的断言失败有价值得多。4.4 人工协作与断点机制人在回路的必要性实践中我们逐渐意识到引导执行模式不能设计成全自动黑盒。模型在特定场景下的置信度就是不够高比如自定义绘制控件、有些视觉状态无法用文本描述清楚这时候强行自动执行失败率和误判率都会上升。ARTEMIS 设计了三级人工介入点第一级是执行前确认。意图补全后如果系统认为关键动作的置信度低于阈值会把待执行序列展示给用户等高亮标注的动作被确认后才执行。第二级是执行中断点。用户可以随时暂停执行查看当前页面截图和模型推理理由可以跳过某一个动作、也可以手动修正控件坐标后继续。第三级是执行后复盘。执行完成后测试人员会收到一份包含动作日志、截图、断言结果、归因分析的报告。测试人员可以在报告上标注这条路径以后可以固定下来标注过的路径会进入回归用例库下次不需要再经过 LLM 生成。5. 双模式的数据流与状态衔接探索得到的情报如何反哺执行双模式不能做成两个孤岛。探索模式产生的知识需要被执行模式消费执行模式产生的新发现也要回流到探索知识库。这条数据流才是 ARTEMIS 真正值钱的地方。5.1 探索模式留下的地图正是执行模式需要的导航如果没有探索模式引导执行模式每次执行都要从零开始解析页面截图、抽层级树、调模型推理、生成动作。这个过程慢且昂贵一次简单任务可能要调用几十次模型接口。有了探索模式沉淀的知识库执行模式就有了捷径。当用户说从首页进到设置页时系统先在控件地图里查设置入口在首页的具体位置如果命中直接跳过高代价的页面解析用已知控件坐标执行点击。如果控件地图没命中页面改版了执行模式会动态降级回完整解析流程并在执行结束后把新发现更新回控件地图。这套机制让系统越用越熟同一个App跑得越多后续执行越快越准。5.2 切换瞬间的状态同步App 状态、上下文、动作历史探索模式和执行模式切换时最容易出问题的是状态不同步。比如探索模式跑着跑着停在了一个登录中间页此时切换到执行模式去执行查看订单任务App 还停在登录页任务自然执行不了。ARTEMIS 在切换时做三件事一是重置 App 到初始状态。如果目标是验证一个独立功能链路一般会冷启动 App清掉中间页面的影响。二是跨模式的会话上下文延续。探索模式记录的哪些页面已访问、哪些控件已标注会作为执行模式的先验信息帮助模型避免重复推断。三是对齐动作历史。探索模式产生的一些高风险动作结论比如某个手势会导致崩溃会以警告标记的形式传递给执行模式执行阶段的路径规划会尽量避开这些坑。5.3 一条典型的双模式联动工作流先探索、再补测、后回归实际使用中我们最常用的一套流程长这样新版本提测后先跑一轮探索模式让它逛30 到 60 分钟看覆盖了多少页面状态、发现哪些异常。这时候得到的是整包的质量快照。然后 QA 根据探索报告挑出风险最高的几个场景用自然语言下达指令给引导执行模式做针对性验证。比如重点检查登录页面在弱网环境下的表现或者验证支付流程在取消后余额不变。最后把验证通过的场景固化成回归用例合并进常规回归流程。这个流程的好处很明显探索模式保证了没有遗漏大的功能块执行模式保证了关键路径的精确验证而固化用例保证了已确认的行为不会回退。6. 实测中的踩坑记录与优化调优从原型到真正能用的过程踩的坑比想象中多。挑几个有代表性的记录在这里给打算自己实现类似系统的同行一点参考。6.1 视觉理解与层级树不一致时以谁为准第一类高频问题是视觉模型和层级树信息冲突。典型场景页面上一张卡片视觉模型认为点击卡片区域可以跳转详情但层级树显示卡片本身不可点击可点击的是卡片下方一个透明按钮。如果不做仲裁模型会傻乎乎点击一个不可点击区域等待无反馈后误判页面无响应。我们的解决思路是双重确认视觉推理只负责候选区域生成和语义理解真正进入动作队列前必须由层级树确认该坐标存在可交互控件。如果视觉候选区域和层级树冲突优先以层级树为准同时记录冲突样本回流给模型做提示词修正。这套策略让探索模式的无效点击率下降了大概三四成。6.2 大模型的幻觉如何拦截动作校验与二次确认LLM 幻觉在测试场景里的表现比内容生成场景更有迷惑性。它不会直接说我编了一个控件而是会在推理过程中理所当然地认为页面上存在某个元素然后规划出依赖该元素的操作序列。我们遇到过一个印象很深的例子模型声称页面右下角有一个返回顶部悬浮球规划了点击它的动作。实际上那个悬浮球是另一条业务分支里才会出现的当前页面根本没有。如果系统照单全收这个动作必失败。现在的拦截手段是执行前校验动作规划完成后不只是检查动作类型还会把动作依赖的每个控件与当前页面层级树做一次匹配检查。匹配失败的动作用红色标记标注低置信度场景直接停下来询问用户不强行往下走。这一步让引导执行模式的动作成功率提升很明显也直接减少了很多误导性的假失败。6.3 稳定性与性能调优探索预算、超时、重试策略探索模式的资源消耗非常大如果不管控一次探索可能跑几个小时还停不下来。我们加了三个预算指标动作预算单个会话最多执行多少步动作默认 800 步左右状态预算允许访问多少个不同的页面状态默认 300 个时间预算单次探索总时长硬上限三个预算任何一个达成就进入收尾阶段模型会尝试从当前位置返回已发现的关键页面整理日志输出报告。超时处理的经验是加载等待不能用一个固定值。列表页由于内容长度不同加载时间差异很大。现在 ARTEMIS 按页面类型动态调整等待时长比如表单页等待短、带远程数据的列表页等待长。这个调整看似不起眼但对探索效率影响巨大等待时间过长会浪费大量预算。重试策略同样要分错误类型。设备连接失败值得重试三次因为可能只是瞬时抖动断言失败、控件未找到这种错误重试意义不大应该直接记录并标记为可疑点。6.4 提示词策略与上下文精简控制 Token 消耗的实用技巧LLM 测试系统的调用成本主要花在一次又一次的页面状态理解上。如果你把整个截图感知状态都塞给模型再让它推理很快 token 预算就爆了。我们做了两个优化。一个是截屏压缩输入不把原始截图直接喂给模型而是先经过一个轻量级图像理解模型提取页面布局信息、控件坐标、文案内容再压缩成结构化文本输入大模型。这个过程虽然多了一层模型调用但节省的主模型 token 成本大得多。另一个是动作上下文滚动窗口LLM 决策时不需要看完整条探索历史只需要看最近几步的动作和当前页面。更早期的高层摘要比如已访问设置页、已关闭推送开关会被压缩进一个短记忆槽。只有当模型判断需要追溯更多细节时才临时扩充上下文。这两个优化让单次探索的 token 消耗降到原来的约四分之一同时探索覆盖率没有明显下降。从我们的测试数据看ARTEMIS 跑在一个中等规模的模拟电商应用上探索模式 40 分钟能覆盖大概七成以上的页面状态引导执行模式的指令成功率初始生成一次就正确执行的比例在八成上下。如果加上人工确认和自动补全最终成功率能到九成以上。这个水平距离完美还很远但作为从意图到动作的辅助系统已经能实打实省下很多维护和编写脚本的时间。最后分享一个自己的体会如果要在真实项目里落地这套思路别一开始就追求把探索和执行双模式都做完整。先实现引导执行模式把它当成一个自然语言转脚本辅助工具用起来在真实用例中积累控件地图和上下文数据。等知识库有一定规模了再上探索模式那种系统明显越用越聪明的感觉会很不一样。这条路没有捷径但每一步踩下去都是实实在在的经验。 
长河君 · 2026/10/22 11:36:36 · 阅读 1.2k LLM驱动移动端自动化测试：双模式架构解析
做移动端自动化测试这些年我最大的感受是维护成本永远比你预估的高。脚本写出来只是开始后面每一次页面改版、每一次弹窗调整都会让一批定位器失效然后你就要花大量时间去排查到底是产品改了还是脚本老了。这还不是最痛的最痛的是跨端场景下同一套业务逻辑在Android和iOS要各自维护一套脚本工作量直接翻倍。我们团队从去年开始尝试把大语言模型引入移动端自动化测试流程内部代号就叫 ARTEMIS。它不是传统意义上多了一个智能断言工具而是从运行机制上把测试的组织方式改了从写脚本变成定意图。这里最重要、也最值得展开聊的设计就是它的双模式架构。这篇文章把双模式的拆分逻辑、每个模式的运行机制、以及两者之间怎么衔接讲透希望对正在探索 LLM 自动化测试的同行有参考价值。1. 移动端自动化测试的困境ARTEMIS 想改变什么在拆架构之前先得说清楚一个问题现有的移动端自动化测试到底难在哪。如果没说清楚痛点任何架构设计看起来都像是炫技。1.1 脚本维护的隐性成本一个按钮变化牵动多少用例UI测试本质上是在和变化作斗争。传统做法里我们靠的是元素定位器比如id、xpath、content-desc这些。问题在于移动端的UI变更频率远高于后端接口产品同学经常为了一个按钮的文案、位置、颜色进行调整而这些调整很可能让定位器失效。举一个真实场景某个模拟项目里底部Tab栏的我的入口从第二个位置挪到第四个位置同时图标资源名也改了。这个变动大约导致 27 条用例失败其中真正因为业务逻辑变化的只有 3 条其余 24 条都是定位器失配。而修复这 24 条用例平均每条要花 5 到 10 分钟包括定位、验证、跑回归。一个月算下来光定位器修复就吃掉了一个人不少工时。跨端场景更麻烦。同一功能在 Android 和 iOS 上元素树结构完全不同自动化脚本得各写一套。如果业务逻辑调整了两边都要同步改改完还要各自验证。这就是很多团队自动化测试规模越大、负担越重的根本原因——测试资产是死的它不理解页面语义。1.2 LLM 带来的三个能力杠杆视觉理解、语义推理、自然语言接口LLM 给移动端自动化带来的不是新的定位方法而是三个更底层的能力杠杆第一个是视觉理解。多模态模型能直接看截屏理解页面布局、按钮位置、文案关系。这意味着什么意味着即使元素树缺失比如某些自绘控件、WebView 内嵌页面测试系统仍然能靠视觉理解页面内容定位到目标控件。第二个是语义推理。模型能从用户想做什么推导出应该执行哪些操作序列。比如把推送关掉传统脚本你得先知道入口在设置页、开关的 id 是什么、可能还要处理一个确认弹窗。而语义推理可以直接规划出动作序列进入设置页找到推送开关关闭处理弹窗。第三个是自然语言接口。这个听起来最不起眼实际价值最大。它把测试用例的编写门槛从会写代码降低到会说清楚需求。业务同学可以描述场景测试同学来审核和兜底自动化系统负责翻译成可执行动作。有了这三个杠杆我们完全可以重新设计一套移动端测试系统的运行架构。1.3 ARTEMIS 的定位意图驱动的移动端测试执行引擎ARTEMIS 不是要替代 Appium 或 XCUITest 这些成熟框架而是把 LLM 作为一个意图理解层叠加在传统框架之上。底层还是需要设备桥接、驱动管理、截图采集这些能力但上层的行为决策不再依赖固定脚本而是依赖模型对当前页面状态和任务意图的理解。它和传统框架的关系很像导航软件和汽车的关系。汽车负责执行设备控制、动作模拟、状态采集导航软件负责规划理解用户意图、选择路径、动态调整。ARTEMIS 在导航这个层面做文章。而导航软件需要两种工作模式一种是没有目的地时你让它随便开把城市路网摸清楚——这是探索另一种是你明确告诉它要去哪个地址它规划最优路线并逐段导航——这是执行。这就是双模式的由来。2. 双模式架构总览一个引擎两种运行形态很多团队做 LLM 测试系统时容易犯一个错误想做一个万能 Agent既要能自主探索又要能精确执行。实际做下来你会发现这两个目标的评价指标是冲突的。2.1 模式划分的底层逻辑探索要广度执行要精度自主探索的考核指标是覆盖率在有限时间内尽可能多地经过不同的页面状态、触发不同的行为分支。它要求模型敢试遇到不确定的控件也愿意点一下看看反应。执行模式的考核指标是准确率严格执行用户的意图、不越界操作、断言可靠。它要求模型克制只有高置信度时才动手拿不准就要停下来问。这两种行为倾向放在同一个 Agent 里会出现一个尴尬局面探索时太保守覆盖率上不去执行时太激进容易自作主张。所以 ARTEMIS 从一开始就把它们拆成了两个运行模式共用底层能力但决策策略、护栏机制、评价逻辑完全不同。2.2 整体组件分层交互层、理解层、决策层、执行层ARTEMIS 的逻辑结构可以分成四层双模式在这四层上的表现各有侧重层次核心职责自主探索模式的表现引导执行模式的表现交互层设备桥接、数据采集高频截图、层级树抓取、状态哈希计算低频采集按动作节点触发理解层页面语义解析、指令拆解页面分类、可交互元素识别、行为空间估计自然语言指令到结构化意图的映射决策层动作选择、路径规划探索策略广度优先/深度优先、去重控制动作序列校验、置信度判断、人工确认触发执行层动作翻译、结果收集随机但受控的动作执行严格受控的动作执行与断言验证交互层和执行层其实是共用的都是连设备、跑命令、拿状态。真正的差异在理解层和决策层。2.3 为什么保留传统测试框架作为底座有人会问既然 LLM 能理解页面为什么不干脆让模型直接操控手机还要 Appium 干嘛这一点实践之后体会特别深设备控制在稳定性上要求近乎苛刻连接断开要能重试、截图要保证完整、滑动手势要模拟得像真人。这些能力传统框架已经打磨了很多年没必要重新造轮子。ARTEMIS 的做法是把传统框架当作操作系统LLM 只负责在大脑层面做决策手脚还是交给成熟框架。一旦底层执行出现超时或异常不会让模型去猜为什么而是由框架层先做自动重连、重试、日志采集。这种分层设计让整体稳定性高了很多调试时也能快速定位是决策错了还是执行错了。3. 自主探索模式让测试 Agent 学会当一个有好奇心的用户自主探索模式的设计目标很简单在没有预设脚本的情况下让 Agent 自己逛App摸清哪些页面能到达、哪些控件能交互、哪些状态会触发异常。这本质上是一个强化学习里的探索问题只是策略函数换成了 LLM。3.1 感知通道融合视觉截图 UI 层级树 状态哈希纯视觉方案有个问题模型看截图能理解个大概但对控件边界、可点击区域这些细节判断不准容易点了按钮旁边 10 像素的地方触发不了任何事件。纯层级树方案呢遇到 WebView 和自定义绘制控件又是两眼一抹黑。所以 ARTEMIS 用的是双通道融合。截屏给视觉模型做页面布局理解这个页面上有哪些区域、每个区域大概是什么功能。层级树给结构化信息控件的具体边界坐标、类型、可见性、可点击性。两个通道配对后当视觉判断这是个登录按钮、层级树也确认这里有个可点击的 Button 控件时置信度就足够高可以执行点击。还需要一个状态哈希机制。同一个页面每次渲染可能都有细微差异比如网络头像加载完毕、滚动位置变化这些不能算页面变化。ARTEMIS 会对页面截图和简化后的层级树做归一化处理生成一个状态指纹。只有指纹变化超过阈值才认为进入了新的页面状态才会触发后续的动作决策。这个机制有效避免了模型在同一页面反复打转。3.2 决策循环观察、推理、行动、记忆探索模式的每次循环包含四个步骤。第一步观察采集当前截图、层级树、状态哈希形成当前状态的完整描述。第二步推理让 LLM 总结当前页面是什么、有哪些关键可交互元素、之前是否已经访问过类似状态。这一步有两个输出可选动作列表和倾向建议。动作列表来自层级树中的可交互控件加上系统级动作返回、滑动、截屏。第三步行动从动作列表中选择一个执行。选哪个由探索策略决定。ARTEMIS 默认采用混合策略维护一个未访问控件队列和未到达状态集合倾向于优先点击从未访问过的控件区域如果连续 N 步都没有产生新状态则随机跳转到一个历史页面重新开始。第四步记忆执行动作后把结果状态、动作效果记录到探索日志里。这个日志是后续沉淀知识资产的基础。3.3 动态状态处理等待网络、弹窗消解、加载态识别移动端探索最容易翻车的不是找不到控件而是异步状态。点了一个按钮页面进入 loading某些树节点是空的此时 LLM 很容易误判页面没反应或者操作失败。ARTEMIS 有一个专门的加载态识别器在决策前先判断当前页面是否处于稳定状态。逻辑不复杂如果检测到加载指示器进度条、loading 控件、骨架屏就等待并轮询最多等若干秒超时后如果还在加载记录一条状态异常然后选择其他动作路径。弹窗消解也至关重要。App 在探索过程中经常会弹出隐私授权、版本更新、活动推广等弹窗如果 Agent 不处理后续所有动作都可能被弹窗挡住。但也不能见弹窗就关有些弹窗很重要比如注销类确认框。ARTEMIS 对弹窗做了分级处理系统权限弹窗按既定规则处理业务推广弹窗优先关闭阻断性很强的确认弹窗会先截图记录并挂起等人工介入确认。3.4 探索结果的沉淀行为轨迹、控件地图与候选用例探索本身不是目的沉淀才是。探索结束后系统会把整个探索过程整理成三份产物第一份是行为轨迹。记录从启动页到每个终态页面的完整路径格式是页面状态 A → 控件 B 点击 → 页面状态 C。这份轨迹可以直接转成可回放的用例骨架测试人员可以把它当作初稿来修改而不是从零开始写。第二份是控件地图。把所有探索过程中识别过、操作过的控件聚合成一个语义控件库记录它的文案、类型、相对位置、所在页面。这个库在引导执行模式里特别有用相当于一个定位器知识库让后续执行时不需要每次都去重新解析页面。第三份是候选异常列表。探索中遇到的崩溃、无响应、异常弹窗、加载超时都会被标记出来附上现场截图和操作路径。这些是测试报告里最有价值的信息因为很多普通回归根本覆盖不到那些路径。4. 引导执行模式把帮我测一下登录翻译成可控的测试过程如果说探索模式是广撒网那引导执行模式就是精准打击。它的输入是用户的自然语言指令输出是一段被严格校验过的可执行动作序列。这个模式解决的是日常回归测试中最常见的诉求我想验证一个具体场景但我不想写脚本。4.1 指令解析与意图补全LLM 不只是翻译还要补上下文自然语言指令在实操中往往是不完整的。用户说测一下登录流程但登录流程有几个前置条件账号从哪来需要先注册吗登录失败场景要不要覆盖页面入口是从启动页进还是从设置页进这些信息用户大概率不会说全。ARTEMIS 的做法是意图补全。模型先把指令解析成一个结构化测试任务入口页面、动作序列、预期结果。然后针对缺失的参数发起澄清或者基于控件地图里已有的知识自动补齐。举个例子指令是从首页进到设置把推送通知关掉然后回首页确认图标变化。经过意图补全后变成这样启动 App确保首页加载完成找到设置入口可能是首页右上角图标并点击在设置页找到推送通知开关控件点击开关使其状态变为关返回首页检查是否有图标或角标变化断言开关状态为关且首页对应视觉元素发生变化每一次补全都有对应的可靠性标注有些步骤来自显式意图置信度高有些步骤来自推测置信度低执行到那里时系统会停下来请求确认。4.2 动作空间约束与安全兜底不能让它随心所欲LLM 生成动作序列这件事最让人担心的不是做不了而是乱做。模型可能设计出一个看起来合理但越界的动作比如直接调系统设置修改应用权限。这在自动化测试里很危险会污染环境、影响后续回归。ARTEMIS 在理解层和决策层之间加了一道动作空间过滤器。过滤器维护一个允许动作白名单点击、长按、滑动、输入、返回、等待、断言、截屏。超出白名单的动作比如修改设备系统设置、跨进程通信等直接拦截不进入执行层。拦截的时候不只是报错还会触发一个替代逻辑模型重新规划一条合规路径。比如想直接修改系统推送权限许可合规路径是进入应用内设置页 → 找到权限管理入口 → 逐个开关检查。这样既保证了测试目标能达成又限制了动作范围。此外还有控件级校验。执行点击之前执行层会再次确认目标控件在当前时刻仍然可见、可点击且坐标没有漂移。这个校验虽然引入了一点额外耗时但把大量因页面变化导致的误操作挡在了执行之前。4.3 断言与结果归因怎么判断测试通过不是说了算LLM 测试系统里的断言问题比传统框架复杂得多。传统断言很明确某个控件是否存在、文案是否匹配、某个接口返回值是否符合预期。LLM 场景下用户的预期往往是模糊的比如确认图标变化——什么样的变化算通过了ARTEMIS 把断言拆成显式和隐式两类。显式断言来自指令中的明确表述开关关闭、图标出现、消息发送成功。这类断言直接映射到控件状态检查。隐式断言来自系统对正常状态的理解没有崩溃日志、没有出现异常错误弹窗、网络请求没有大量失败、页面没有停留在 loading 超过正常时长。隐式断言不属于用户指令的一部分但它其实是很多回归测试真正想验证的内容。当测试失败时系统会做结果归因先回放动作序列判断是否存在执行偏差比如点击了错误的控件、等待超时如果执行没有问题再判断是不是应用本身的缺陷。这个归因过程会生成一段解释性文本告诉测试人员失败原因是动作 A 之后预期出现状态 B但实际出现状态 C执行链路完整疑似应用问题。这比传统框架一句干巴巴的断言失败有价值得多。4.4 人工协作与断点机制人在回路的必要性实践中我们逐渐意识到引导执行模式不能设计成全自动黑盒。模型在特定场景下的置信度就是不够高比如自定义绘制控件、有些视觉状态无法用文本描述清楚这时候强行自动执行失败率和误判率都会上升。ARTEMIS 设计了三级人工介入点第一级是执行前确认。意图补全后如果系统认为关键动作的置信度低于阈值会把待执行序列展示给用户等高亮标注的动作被确认后才执行。第二级是执行中断点。用户可以随时暂停执行查看当前页面截图和模型推理理由可以跳过某一个动作、也可以手动修正控件坐标后继续。第三级是执行后复盘。执行完成后测试人员会收到一份包含动作日志、截图、断言结果、归因分析的报告。测试人员可以在报告上标注这条路径以后可以固定下来标注过的路径会进入回归用例库下次不需要再经过 LLM 生成。5. 双模式的数据流与状态衔接探索得到的情报如何反哺执行双模式不能做成两个孤岛。探索模式产生的知识需要被执行模式消费执行模式产生的新发现也要回流到探索知识库。这条数据流才是 ARTEMIS 真正值钱的地方。5.1 探索模式留下的地图正是执行模式需要的导航如果没有探索模式引导执行模式每次执行都要从零开始解析页面截图、抽层级树、调模型推理、生成动作。这个过程慢且昂贵一次简单任务可能要调用几十次模型接口。有了探索模式沉淀的知识库执行模式就有了捷径。当用户说从首页进到设置页时系统先在控件地图里查设置入口在首页的具体位置如果命中直接跳过高代价的页面解析用已知控件坐标执行点击。如果控件地图没命中页面改版了执行模式会动态降级回完整解析流程并在执行结束后把新发现更新回控件地图。这套机制让系统越用越熟同一个App跑得越多后续执行越快越准。5.2 切换瞬间的状态同步App 状态、上下文、动作历史探索模式和执行模式切换时最容易出问题的是状态不同步。比如探索模式跑着跑着停在了一个登录中间页此时切换到执行模式去执行查看订单任务App 还停在登录页任务自然执行不了。ARTEMIS 在切换时做三件事一是重置 App 到初始状态。如果目标是验证一个独立功能链路一般会冷启动 App清掉中间页面的影响。二是跨模式的会话上下文延续。探索模式记录的哪些页面已访问、哪些控件已标注会作为执行模式的先验信息帮助模型避免重复推断。三是对齐动作历史。探索模式产生的一些高风险动作结论比如某个手势会导致崩溃会以警告标记的形式传递给执行模式执行阶段的路径规划会尽量避开这些坑。5.3 一条典型的双模式联动工作流先探索、再补测、后回归实际使用中我们最常用的一套流程长这样新版本提测后先跑一轮探索模式让它逛30 到 60 分钟看覆盖了多少页面状态、发现哪些异常。这时候得到的是整包的质量快照。然后 QA 根据探索报告挑出风险最高的几个场景用自然语言下达指令给引导执行模式做针对性验证。比如重点检查登录页面在弱网环境下的表现或者验证支付流程在取消后余额不变。最后把验证通过的场景固化成回归用例合并进常规回归流程。这个流程的好处很明显探索模式保证了没有遗漏大的功能块执行模式保证了关键路径的精确验证而固化用例保证了已确认的行为不会回退。6. 实测中的踩坑记录与优化调优从原型到真正能用的过程踩的坑比想象中多。挑几个有代表性的记录在这里给打算自己实现类似系统的同行一点参考。6.1 视觉理解与层级树不一致时以谁为准第一类高频问题是视觉模型和层级树信息冲突。典型场景页面上一张卡片视觉模型认为点击卡片区域可以跳转详情但层级树显示卡片本身不可点击可点击的是卡片下方一个透明按钮。如果不做仲裁模型会傻乎乎点击一个不可点击区域等待无反馈后误判页面无响应。我们的解决思路是双重确认视觉推理只负责候选区域生成和语义理解真正进入动作队列前必须由层级树确认该坐标存在可交互控件。如果视觉候选区域和层级树冲突优先以层级树为准同时记录冲突样本回流给模型做提示词修正。这套策略让探索模式的无效点击率下降了大概三四成。6.2 大模型的幻觉如何拦截动作校验与二次确认LLM 幻觉在测试场景里的表现比内容生成场景更有迷惑性。它不会直接说我编了一个控件而是会在推理过程中理所当然地认为页面上存在某个元素然后规划出依赖该元素的操作序列。我们遇到过一个印象很深的例子模型声称页面右下角有一个返回顶部悬浮球规划了点击它的动作。实际上那个悬浮球是另一条业务分支里才会出现的当前页面根本没有。如果系统照单全收这个动作必失败。现在的拦截手段是执行前校验动作规划完成后不只是检查动作类型还会把动作依赖的每个控件与当前页面层级树做一次匹配检查。匹配失败的动作用红色标记标注低置信度场景直接停下来询问用户不强行往下走。这一步让引导执行模式的动作成功率提升很明显也直接减少了很多误导性的假失败。6.3 稳定性与性能调优探索预算、超时、重试策略探索模式的资源消耗非常大如果不管控一次探索可能跑几个小时还停不下来。我们加了三个预算指标动作预算单个会话最多执行多少步动作默认 800 步左右状态预算允许访问多少个不同的页面状态默认 300 个时间预算单次探索总时长硬上限三个预算任何一个达成就进入收尾阶段模型会尝试从当前位置返回已发现的关键页面整理日志输出报告。超时处理的经验是加载等待不能用一个固定值。列表页由于内容长度不同加载时间差异很大。现在 ARTEMIS 按页面类型动态调整等待时长比如表单页等待短、带远程数据的列表页等待长。这个调整看似不起眼但对探索效率影响巨大等待时间过长会浪费大量预算。重试策略同样要分错误类型。设备连接失败值得重试三次因为可能只是瞬时抖动断言失败、控件未找到这种错误重试意义不大应该直接记录并标记为可疑点。6.4 提示词策略与上下文精简控制 Token 消耗的实用技巧LLM 测试系统的调用成本主要花在一次又一次的页面状态理解上。如果你把整个截图感知状态都塞给模型再让它推理很快 token 预算就爆了。我们做了两个优化。一个是截屏压缩输入不把原始截图直接喂给模型而是先经过一个轻量级图像理解模型提取页面布局信息、控件坐标、文案内容再压缩成结构化文本输入大模型。这个过程虽然多了一层模型调用但节省的主模型 token 成本大得多。另一个是动作上下文滚动窗口LLM 决策时不需要看完整条探索历史只需要看最近几步的动作和当前页面。更早期的高层摘要比如已访问设置页、已关闭推送开关会被压缩进一个短记忆槽。只有当模型判断需要追溯更多细节时才临时扩充上下文。这两个优化让单次探索的 token 消耗降到原来的约四分之一同时探索覆盖率没有明显下降。从我们的测试数据看ARTEMIS 跑在一个中等规模的模拟电商应用上探索模式 40 分钟能覆盖大概七成以上的页面状态引导执行模式的指令成功率初始生成一次就正确执行的比例在八成上下。如果加上人工确认和自动补全最终成功率能到九成以上。这个水平距离完美还很远但作为从意图到动作的辅助系统已经能实打实省下很多维护和编写脚本的时间。最后分享一个自己的体会如果要在真实项目里落地这套思路别一开始就追求把探索和执行双模式都做完整。先实现引导执行模式把它当成一个自然语言转脚本辅助工具用起来在真实用例中积累控件地图和上下文数据。等知识库有一定规模了再上探索模式那种系统明显越用越聪明的感觉会很不一样。这条路没有捷径但每一步踩下去都是实实在在的经验。