先说一个我在移动端自动化测试上反复撞墙后的真实感受大多数团队从纯手工点按切换到自动化脚本之后省下的时间并没有想象中那么多反而多出一堆修脚本、调选择器、处理弹窗超时的活儿。这两年LLM的出现确实把不少顽疾松动了但真正落地的移动端自动化方案并不多能说清楚架构设计的更少。这篇文章想拆解的ARTEMIS就是一套围绕LLM设计的移动端自动化框架核心是它的双模式架构一个模式面向确定性的功能回归另一个模式面向探索性的异常发现。两者的设计逻辑、分工边界、以及在实际调试中踩过的坑我会在下面展开聊。1. 传统移动端自动化卡在哪三个绕不开的死穴移动端自动化测试不是没有工具相反工具非常多。但这么多年下来真正能用出效果的团队并不多。问题不总是工具不好用而是移动端QA在三个层面存在结构性缺陷。1.1 元素定位的“字面依赖”与页面改版灾难传统移动端自动化最核心的操作就是定位元素然后对元素做点击、输入、滑动。定位方式大致依赖资源ID、文本内容、坐标以及基于控件层级关系的表达式。这些定位方式本质上都是“字面依赖”必须精确知道页面上某个控件叫什么名字、或者在层级结构里的哪个位置。问题在于移动端页面改动太频繁了。改版、换字体、调布局、加一个外层容器都会让原先写好的定位路径直接失效。举个很普通的例子列表页某个按钮从idlogin_button改成了idlogin_btn_new整条用例就可能从第3步开始全挂。更麻烦的是很多定位表达式是层层嵌套的页面改一个节点牵一发动全身。我在实际项目里见过最夸张的情况是一次常规改版后一个原本稳定执行了半年的150条用例直接报废了60多条而且每条报废的定位错误都长得不一样。修完这一批下一批又因为另一个页面改造开始报警。这种循环消耗的时间比手工回归还要多。LLM能改善的恰恰是这一层定位从“精确匹配”转向“语义匹配”。只要页面截图和控件树能提供给模型模型就能理解“页面右上角那个登录按钮”这种自然语言描述并在新页面上找到对应控件。等于说脚本不再绑定某个特定UI实现而是绑定产品层面的语义。这样页面改版时只要功能没变自动化用例就不需要跟着改。1.2 断言与用例维护是人力黑洞传统移动端自动化的第二个死穴是断言。大多数用例的断言都很简单无非就是“等待某个文本出现”“判断某个控件是否可见”偶尔会有截图对比。这些断言本身写得再精细也只覆盖了业务结果的一部分而且断言策略完全依赖写用例的人凭感觉判断“这一步应该验证什么”。带来的后果就是要么断言过粗页面白屏了用例还是绿的要么断言过脆某个不影响功能的文案变化就会让用例失败。更隐蔽的问题是移动端业务往往有成百上千条用户路径每条路径都有多个分支和边界条件人工为每条路径设计合理断言工作量极大。大多数团队根本没有资源做到这个粒度最后只能回到“脚本就是代替手工点一点”的低水平状态。LLM在这一层能做的是把“人类精确断言”替换成“模型判断状态是否符合预期”。比如执行完“完成支付”这步之后模型综合截图、页面控件树、当前Activity信息和前文操作日志判断当前是否处于“支付结果页”并给出相应的业务语义验证结论。这一步把断言从“写死的代码”变成了“动态的理解”。1.3 跨端复用的低效妥协第三个痛点是最容易被人忽略的移动端不是一个平台而是安卓和iOS两个体系。很多团队为了省成本会把同样的用例在两端各写一遍或者在封装层做一层通用抽象但遇到平台特有弹窗、手势、权限对话框时抽象层的保护伞立刻失效。真正执行起来依然是两套代码、两套维护节奏。ARTEMIS在设计上没有试图解决“一套脚本跑两端”这个伪命题。它遵循一个更务实的思路两端共享的是任务描述和LLM决策层平台差异交给下层的驱动适配器去消化。这样既避免了重复发明轮子也不会为了强行统一而牺牲平台细节。2. 双模式架构的总体设计一套框架的两种工作姿态ARTEMIS并不是一个只有一个Agent跑到底的五花八门框架它对“测试任务”做了切分认为移动端测试本质上只有两类需求一类是明确的、可描述的路径回归另一类是模糊的、需要主动探索找问题的场景。这两类需求的工作方式完全不同硬塞进同一个执行循环里会出现不伦不类的结果。2.1 双模式的定义Plan-Act 与 Probe-Verify先说两种模式分别是什么。Plan-Act模式中文可以叫“规划-执行模式”。它接收的是一个高层次的用户目标比如“完成新用户注册流程并退出登录”。这个模式下LLM先基于任务目标和当前页面信息生成一份初步的操作计划然后逐步执行每一步都先观察当前页面再决定具体动作执行之后检查状态变化是否和预期一致不一致时做反馈修正。Probe-Verify模式可以叫“探索-验证模式”。它不需要人类提供明确任务而是让框架在一个页面图结构中进行遍历和变异操作比如随机输入、异常滑动、快速点击等然后通过比对状态差异来发现异常候选。发现可疑状态变化后LLM再介入判断这是正常业务行为还是潜在缺陷。这两种模式的差异本质上是“已知与未知”的差异。Plan-Act应对的是已知路径追求高确定性和高可解释性每一步都可以追溯到具体预期Probe-Verify应对的是未知缺陷追求覆盖面和异常召回率允许大量无效尝试。2.2 共享中间表示UI状态流与操作日志双模式虽然执行逻辑不同但它们底层共享同一套“中间表示”。这套表示是我认为ARTEMIS里最值得参考的设计它由两个核心数据对象构成。第一个是UI状态流。框架在每次操作前后都会采集当前页面的快照包括截图像素信息、空间信息、关键文本和可交互控件列表。这些信息不是简单堆叠而是被组织成一个结构化的状态节点并标明节点的父子关系和页面跳转方向。整条用例执行过程会形成一张“UI状态图”每一步操作都对应图里的一条边。第二个是操作日志。每执行一次操作框架都会记录动作类型、目标控件描述、屏幕坐标、操作耗时、前后状态哈希值以及LLM在决策时的输入输出摘要。操作日志的作用是让整个测试过程可以被精确回放和审计不管是排查框架自己的问题还是给开发同学复现Bug都极其有用。这两个数据对象串起了一条可逆的执行链路。Plan-Act模式依赖它做逐步验证Probe-Verify模式依赖它做状态差异分析。这也是为什么双模式可以共用同一套下层驱动和报告体系的原因。2.3 为什么不做成单模式的“万能Agent”很多人在设计这类框架时第一反应是做一个纯粹的“Agent测试员”给模型一个目标让它自己连续操作直到完成。这个思路不是不行但在移动端场景下效果往往很不理想。原因是移动端UI操作存在很强的状态依赖和反馈延迟中间任何一个误判都会让后续动作全部建立在错误的前提上。如果Agent一口气规划20步然后闷头执行中间只要错一步后续19步基本全废而且很难定位是哪一步错的。ARTEMIS把单Agent模式拆成双模式实际是做了一个分治有明确目标时采取小步快跑、逐步修正的Plan-Act没有明确目标时采用覆盖率优先、后置判断的Probe-Verify。这相当于把“让模型自由发挥”收敛成“在框架约束下让模型做局部决策”既保留LLM的语义理解能力又不至于让模型的无序性毁掉整个测试过程。3. Plan-Act 模式拆解从自然语言需求到可执行操作序列Plan-Act模式是这个框架里最常用到的工作姿势也是团队把日常回归用例迁移到LLM时最先接触的部分。下面按执行顺序拆开讲。3.1 任务意图解析与前置约束注入Plan-Act的输入不是一串步骤而是一段自然语言目标比如“验证游客状态下看不到个人中心的订单入口”。这个目标会被送入意图解析模块转换成机器可理解的任务描述和约束清单。约束清单是容易被忽略但非常关键的部分。因为LLM对业务规则是不知道的它可能会在测试过程中做出真实用户不会做的操作比如在登录页随意输入一串手机号、在支付环节选择不可能的优惠券组合。这些行为在UI层面不一定报错但会让测试结论失真。因此意图解析阶段需要允许维护者注入前置约束比如“不得使用已存在的真实手机号”“到达支付页后不要点击支付按钮”。约束会被存到本次任务的上下文里后续每步决策都会带着它走。解析输出的产物是一个初始计划草案包含若干候选动作步骤。但这个草案并不直接执行它只是给LLM一个起点。实际执行时每一步都要结合当前页面状态重新确认这也是Plan-Act稳定性的来源。3.2 LLM驱动的元素定位语义匹配、视觉锚点与坐标回退移动端自动化的地基是定位。ARTEMIS在Plan-Act模式中设计了三级联动的定位策略这是比传统框架多出来的核心机制。第一级是语义匹配。LLM结合当前页面截图和控件树理解“那个用于输入手机号的输入框”这类描述将其映射到具体控件。这一级依赖多模态能力截图提供视觉信息控件树提供精确边界。两者结合的优势是控件树可以拿到精确位置截图可以解决控件树信息不足的页面比如自定义绘制的控件。第二级是视觉锚点。当控件树无法提供有效候选时比如页面是一个重度自定义渲染的图表框架会退回到视觉层面在截图中根据语义描述寻找目标区域裁出候选图片块再让LLM确认哪个区域是操作目标。这一步本质上是把定位问题转成了目标检测问题虽然速度慢一些但扩展了可操作范围。第三级是坐标回退。前两级都失败时框架会直接基于语义描述生成屏幕坐标区域比如“右上角四分之一区域”执行一个修正性的点击。坐标回退的成功率不高但它保证了用例不会因为一次定位失败而直接中断而是尽可能试探继续执行。这三级的切换逻辑是语义匹配失败自动降到视觉锚点视觉锚点置信度不足再用坐标回退。每一级的结果都会写入操作日志方便后续复盘为什么定位失败。3.3 逐步执行与错误反馈修正Plan-Act模式每执行一步动作之后都会重新采集页面状态做一次“预期一致性校验”。这里的预期不是写死的断言而是LLM在动作之前生成的一段自然语言描述比如“执行点击后页面应切换到礼物选择面板并且底部购物车角标消失”。执行后框架把实际截图和控件树再喂给LLM让它判断结果是否与预期吻合。不一致时框架会组装一条反馈信息包含错误截图、当前页面控件概要、上一次动作描述和预期描述。LLM看到反馈后有四个可选动作重试当前动作、放弃当前动作改用其他等价操作、跳过当前步骤并调整后续计划、直接判定用例失败并给出原因分析。这个反馈闭环是Plan-Act模式下成功率显著提升的关键所在。值得说明的是LLM在反馈闭环中并不是无限重试的。ARTEMIS给每个动作设置了默认重试上限通常2到3次超过上限就整体失败退出。这个设计非常务实避免模型陷入“不停点击但页面毫无变化”的原地打转状态。3.4 防抖机制与“假成功”拦截我在真实调试中遇到最尴尬的情况不是用例失败而是用例一路绿灯但最后人工复盘发现页面其实卡在同一个界面重复执行了十几步。LLM会在每次执行后都生成了“看起来合理”的预期描述但实际情况是操作没有产生任何状态变化。ARTEMIS对这个问题做了两层拦截。第一层是状态哈希比对每次采集页面状态后框架会生成一个轻量级状态指纹如果连续N步操作后状态指纹没有变化就触发重复动作预警。第二层是操作本体比对如果当前动作和最近3步内的动作高度相似并且状态没有变化框架会主动终止当前步骤要求LLM重新审视页面和任务目标。这两层机制叠加起来基本堵住了“假成功”这个坑。也正因为如此回归测试的稳定性才有了底线。4. Probe-Verify 模式拆解遍历、变异与异常语义分类如果说Plan-Act解决的是“把已经知道的路径跑稳”那么Probe-Verify解决的则是“把不知道的角落翻出来”。这个模式更适合兼容性检测、新版本发布前的冒烟探索以及长期无人维护的历史模块巡检。4.1 UI图遍历与状态约束管理Probe-Verify的第一步是让框架自动遍历App内的UI状态图。它从启动页开始持续寻找可交互控件并执行点击进入新的页面后再重复这个过程。遍历策略可以配置为首选广度优先或按控件类型加权比如优先尝试列表项、Tab、菜单入口。移动端遍历有一个传统自动化容易忽略的问题状态约束。有些页面在没有登录态时和被系统弹窗遮挡时遍历结果会完全不同。比如首次启动会弹出多个权限请求弹窗如果框架不去处理这些弹窗后面的遍历基本在错误状态下进行。ARTEMIS在遍历引擎里内置了弹窗预处理策略每次发现系统弹窗先尝试关闭再进行页面节点采集。另一个约束是业务深度的限制。有些业务需要登录、需要特定账号等级、需要前置数据Probe-Verify模式不会尝试构造这些复杂前置条件而是记录“此处存在未探索分支”留给Plan-Act模式用明确任务去覆盖。这也再次体现了双模式各司其职的关系。4.2 变异操作与状态差异计算遍历只能发现“页面能进去”但发现不了“输入异常值时系统会不会崩”。所以Probe-Verify在遍历的基础上加入了变异操作引擎。它会对可输入控件注入异常类型的数据比如超长文本、特殊符号、空字符串、边界数值对可点击控件执行连点、快速滑动、双击等非常规操作。每执行一次变异操作框架都会对比操作前后的状态指纹、页面跳转关系、关键业务标记字段。如果状态没有发生变化说明这个变异被正常消化如果发生了变化框架就会产出一个“异动候选记录”并把操作前后的截图、控件树、日志片段一起打包供后续模型验证。这个阶段最重要的是“宁滥勿缺”。哪怕是状态变化非常微小比如某个隐藏控件突然变为可见也要先记录下来。因为很多严重的Bug在出现初期UI变化并不明显如果过早过滤候选就把真正的问题漏掉了。4.3 LLM异常语义分类与复现路径生成Probe-Verify收集到的异动候选记录数量通常很大一次深度遍历下来可能有几十上百条不可能让人类逐条去看。ARTEMIS把筛选任务交给LLM对每一条候选记录做四分类正常业务行为、需要人工确认的疑似异常、明确缺陷如崩溃、白屏、无响应、以及测试环境因素导致的伪异常。分类的时候LLM会结合页面截图、控件树、操作日志和业务上下文说明进行综合判断输出判断理由和置信度。对于标记为明确缺陷的记录框架会把对应的操作步骤自动转成一份复现路径格式上可以直接作为Bug单里的复现步骤。这一步极大减少了测试和开发之间的沟通成本。我自己体验最深的是过去写一个崩溃复现步骤要整理半天现在Probe-Verify跑完连截图和日志都已经按步整理好了开发拿到手就能开查。5. 双模式的协同策略与工程集成框架有了两种模式之后紧接着的问题是什么场景该用哪个模式两种模式怎么协同这在工程落地时是决定成败的细节。5.1 选择模式的决策规则我的经验是把选择规则做成一张简单的决策表而不是靠测试人员临时判断。场景特征建议模式有明确用户路径、有具体业务目标Plan-Act单个功能模块深度回归稳定重复执行Plan-Act版本更新后需要检查全局是否有异常Probe-Verify页面控件种类庞杂、缺少人工用例覆盖Probe-Verify新功能首次接入连预期行为都不清晰先用Probe-Verify摸底再转Plan-Act固化另外还有一个比较通用的策略一个版本周期内Plan-Act负责每天跑固定回归Probe-Verify在一个里程碑版本前做一次集中巡检。两者不互斥更像是“日常巡检”和“定期体检”的关系。5.2 与CI和设备矩阵的集成方式无论哪种模式最终都要包装成命令行工具才能接入现有测试基础设施。ARTEMIS对外的执行入口就是一个标准命令输入是任务描述或探索配置输出是统一格式的报告。报告格式走的是兼容路线直接输出成团队里常见测试报告工具能够识别的格式。这样就不需要推翻已有平台只需要把ARTEMIS的执行结果当作一种新的测试来源接入即可。设备矩阵方面两种模式可以并行分发到多台真机或模拟器上Probe-Verify对设备数量更饥渴因为它的成本大头在遍历广度而Plan-Act对单台设备的执行稳定性更敏感。5.3 可观测性设计日志、回放与回归评估LLM自动化测试和传统自动化有一个本质区别传统脚本出了问题看看代码和堆栈基本能定位LLM决策链路出了问题必须能看到模型当时看到了什么、想了什么、为什么这么操作。ARTEMIS在这块做得比较厚每一步都保留完整审计包括完整Prompt、模型返回、页面截图、操作结果。这也带来了存储成本压力实际部署时通常只对失败用例保留完整审计成功用例仅保留摘要信息。还有一个容易被忽略的指标是“回归评估”既然引入了LLM就必须定期评估这套框架自己的回归效果。ARTEMIS会沉淀一批历史样本每周用两种模式分别回放一次统计通过率、误报率、漏报率和平均耗时。这些指标如果出现明显波动说明框架配置、模型版本或页面结构可能发生了变化需要及时介入。这个机制我认为是LLM测试工具能否长期可信运行的生命线。6. 实测踩坑记录从框架可用到稳定运行的最后一公里最后这部分分享一些我在实际调试中的真实遭遇。任何一个LLM自动化框架从Demo跑通到稳定使用中间都有一条满是坑的路。6.1 LLM的“假成功”与重复点击问题前文提到框架层面做了状态哈希比对来防呆但这是事后补救。真正深挖会发现“假成功”的根源往往是Prompt设计里缺少“执行前普适性检查”这个环节。后来我在每个动作开始前都会强制让模型输出“当前页面关键特征”和“目标控件是否仍然存在的判断依据”这个看似多此一举的步骤把方向性错误堵掉了大半。处理重复点击还有一个心得不要只比对页面指纹还要比对当前操作和历史操作的相似度。没有这层操作本体比对时经常出现一套流程中某个步骤被重复执行了三四次每次都在不同页面上做了同样的点击动作页面指纹虽然变了但逻辑上已经乱了。6.2 长任务执行中的上下文漂移Plan-Act模式在处理超过15步的长流程时会出现一个典型问题模型越到后面越“忘记”最初的约束开始按照自己的理解做计划外操作。比如任务说的是“游客状态下查看”执行到后面它可能会自动进入登录流程。应对方式是把原始任务摘要和约束清单做成常驻上下文穿插在每一步的Prompt中单步决策用的上下文尽可能精简只保留最近3到5步的状态摘要。这比把全部历史都塞给模型要稳定得多交互成本也更低。6.3 Prompt工程与成本控制的小账本LLM测试框架的成本是绕不开的话题。一份20步的Plan-Act任务决策调用加上执行后验证可能要消耗几十次模型请求。做成本优化时我主要用了三招第一把页面截图的尺寸压缩到模型可理解的较小分辨率减少图片Token第二页面元素清单做摘要化只保留候选可交互控件的简要信息第三小模型先做粗糙判断大模型只处理定位冲突、异常分类等核心决策。按照这个思路优化之后一个常规回归任务的平均调用成本是可以压到团队可接受范围内的但如果完全不做控制成本确实会很快失控。建议任何新接手的团队先把这个账算清楚再上规模。6.4 落地建议先从哪条路径开始基于上面的体验我会建议刚接触这类框架的团队不要一上来就把全部用例迁到LLM上也不要同时启用两种模式。稳妥的做法是选择一条最核心的高频回归路径用Plan-Act模式跑通把定位策略、反馈闭环和审计日志都验证熟练之后再逐步扩容。Probe-Verify可以在一个测试版本发布之前做一次试点通过它发现几个真实缺陷之后团队对这套体系的信任度自然会建立起来。移动端LLM自动化当前的边界还很明显比如对于复杂的手势操作、动态页面无限加载、音视频场景都还不能做到完美覆盖。但双模式架构提供了一条务实的路径想在某个局部场景获得确定性的结果就用Plan-Act把路径钉死想全局摸清状态和异常就用Probe-Verify把触角铺开。这套思路不依赖某一家模型的能力爆发更多是把LLM嵌进一套有边界的工程体系里让它在该理解的地方理解在该收敛的地方收敛。