★ FEATURED ARTICLE 移动端自动化测试这个领域但凡做过一段时间的人心里都有一本账脚本又崩了、定位符失效了、断言写得太脆、回归用例维护成本高到离谱。这个系列写到第 05 篇我想认真聊一个偏底层的设计问题——当我们把 LLM 引入移动端自动化流程时到底应该用什么样的架构来组织它的工作方式。以我之前一直在搭的 ARTEMIS 为例它默认采用的就是一套“双模式架构”在线执行的智能体模式加上离线生成脚本的回放模式。这篇把设计思路、核心细节和踩坑记录完整拆开不是为了炫技而是想给同样在探索 LLM 测试方向的人省点弯路。适合看这篇的人很明确已经在做移动端自动化、但对 LLM 接入方式还有困惑的测试开发以及刚想尝试用大模型改造测试流程、却不知道如何下手的技术负责人。后面会涉及不少代码和配置但核心逻辑我会尽量讲得通俗保证跟得上。1. 传统移动端自动化的痛点为什么需要 LLM 来“换引擎”1.1 脚本为什么总在改版之后翻车做过移动端自动化的人应该都有这种体验一套用例写的时候好好的跑起来也绿油油但只要 App 一改版第一个崩的永远是定位符。不是按钮被换了个位置就是文案从“购物车”变成了“我的购物车”content-desc 一变原先写死的 xpath 直接失效。如果只是偶尔改一次还能忍但移动端产品迭代节奏普遍快两周一个版本是常态每个版本都来一轮这种修脚本的消耗战测试人力几乎全被吞进去了。更深一层的问题是断言太脆弱。传统自动化里断言一般写“某个文本存在”“某个元素可见”可产品改版时最常动的恰恰是文案和布局。你断言“立即购买”这个按钮出现结果产品把按钮改成“马上购买”断言就挂了。这类问题不是脚本写得不好而是基于具体元素属性的测试天然就耦合了页面实现UI 一变测试就得跟着改。再加上移动端的操作习惯和 PC 不同需要处理弹窗、Toast、下拉刷新、横竖屏切换、权限请求这类五花八门的干扰传统脚本遇到这些情况基本只能靠预埋各种分支去硬扛写多了代码就成了一团乱麻。这也是为什么很多团队的移动端自动化项目最后都慢慢烂尾维护成本实在太高了。1.2 LLM 到底带来了哪些“新能力”LLM 出现以后测试圈开始有人尝试把它塞进自动化流程里。最开始大家做的事情比较简单让大模型写测试代码、帮忙修 xpath、生成测试数据。这些都属于“辅助生成”本质上还是人写框架模型打下手。但后来有人往前走了一步既然大模型能看懂图文信息、能理解自然语言指令、能做推理那能不能让它直接驱动 App也就是把测试任务以自然语言的方式交给模型模型自己看屏幕、自己决定点哪里、自己验证结果。这个设想很有意思它实际上把“写测试用例”这件事从编码层面提升到了意图层面——你不再需要告诉程序“点击坐标 (100, 200) 的按钮”而是告诉它“登录后检查首页的搜索框能不能正常输入”剩下的步骤由模型自己规划。这个变化的核心价值在于元素定位从固定选择器变成了语义理解。按钮的 content-desc 改了没关系只要模型还能看懂屏幕上有“一个用于登录的按钮”它就可以执行操作。UI 改版对测试的冲击力一下子小了很多这就是 LLM 给移动端自动化带来的最本质的能力升级。1.3 但直接让 LLM 全程在线跑并不现实三个翻车现场不过如果只想着“让大模型全程在线操作手机”那会死得很难看。我一开始也走过这个极端让模型每一步都去看截图、做决策结果核心踩了三个坑。第一个坑是稳定性差。LLM 是概率模型同样的界面、同样的任务不同次运行给出的操作路径可能完全不同。有时候它会莫名其妙点了一个无关的按钮有时候明明该点击输入框它却直接发了一个回车指令。这种不确定性放在测试场景里是非常致命的因为你无法判断测试失败是因为产品有 bug还是因为模型自己跑偏了。第二个坑是上下文失控。移动端操作是长序列任务跑一个 20 步的流程每一步都要把截图、控件树、操作结果塞给模型很快就超过上下文窗口。截到一半模型忘了最初要干什么了开始自由发挥。你可以限制步数、截断上下文但截断之后模型又可能丢失关键状态进退两难。第三个坑是成本。在线跑一个场景每步都要调一次大模型接口图片加控件树加起来 token 消耗大得惊人。如果每天回归几百条用例光 API 费用就能把团队的测试预算吃光。自动化追求的是高频回归成本不上限、稳定性不到位那这套方案就没法落地。这三个问题逼得我去重新想架构LLM 的能力要用但不能让它每一步都不可控地在线上自由发挥。也就是从那时起我确定了“双模式”的基本思路——在线执行和离线生成两条腿走路。2. ARTEMIS 双模式架构总览在线执行 离线生成两条腿走路2.1 双模式的定位差异一个求快一个求稳ARTEMIS 的双模式英文叫 Agent Mode 和 Script Mode一个是在线实时执行一个是离线生成脚本后回放。两者不是简单的功能取舍而是针对完全不同的使用场景设计的。Agent 模式解决的是“探索验证”和“智能应对变化”的问题。它适合新功能验收、UI 变动频繁的版本初期、以及临时性探索测试。这种模式下测试人员用自然语言描述任务模型实时读取屏幕语义、自主决策并执行操作。它的优点是灵活面对突发弹窗、未知控件也能随机应变适合前期的功能验证。Script 模式解决的是“回归稳定”和“控制成本”的问题。它由模型离线分析任务先生成一份结构化的操作脚本固定的选择器策略和断言逻辑再通过执行器回放。回放阶段完全不需要调用大模型跑得快、成本低、结果可重复适合 CI 里每天跑的回归套件。一个形象的比喻Agent 模式像一个经验丰富的店长巡店看到什么问题就现场处理Script 模式则像把巡店经验写成标准作业流程手册让普通店员照着执行。店里平时按手册走只有遇到手册没写的情况再让店长出马。2.2 两种模式的完整调用链对比两种模式虽然定位不同但底层的感知层和执行层是复用的。我把整个调用链拆成四层设备连接层、语义感知层、任务决策层、执行回放层。设备连接层负责跟手机打交道底层适配了 Android 的 UIAutomator2 和 iOS 的 XCUITest对外暴露统一的接口。语义感知层负责把屏幕上的原始控件树和截图转化成 LLM 能看懂的“语义树”两种模式共用。任务决策层在 Agent 模式里是大模型的在线推理在 Script 模式里是离线生成时的规划过程。执行回放层则统一消费“原子操作序列”Agent 模式直接把序列交给系统执行Script 模式把序列落盘成脚本后由回放器执行。用表格对比会更清楚对比维度Agent 模式在线Script 模式离线生成决策时机运行时逐步决策提前规划并固化大模型调用每步都要调用仅在生成阶段调用执行速度较慢单步有延迟快接近原生自动化稳定性中等受模型波动影响高可重复执行适用场景新功能验证、探索测试日常回归、CI 集成成本高生成后几乎为 0变更响应自适应强需要重新生成这套架构里最关键的洞察是在线跑通一次成功的任务后它的成果不应该浪费。如果每次探索完都要重新生成脚本那 Agent 模式的价值就只局限在找 bug 上。ARTEMIS 的设计目标是让 Agent 模式跑通的任务能够自动沉淀为 Script 模式能直接消费的脚本这也是后面要讲的轨迹脱水机制。2.3 共用的“中间层”UI 语义树与工具集两套模式能共用一套底层靠的是一个中间表示层我把它叫 USTUI Semantics Tree界面语义树。它把千奇百怪的页面元素统一成一个稳定的、面向语义的 JSON 结构LLM 不需要去理解 Android 的 View 层级或者 iOS 的 Accessibility 树只需要看这个 JSON 就能知道当前屏幕上大概有什么、元素之间的相对关系是什么。语义树不是简单的控件树拷贝而是要经过清洗和抽象。原始控件树里充满了无用节点不可见的、零尺寸的、纯布局容器的这些直接丢给大模型既浪费 token 又干扰判断。ARTEMIS 在构建语义树时会做三级处理剔除不可见节点、合并同类列表项、对关键节点补充 OCR 识别结果。工具集的设计也很克制。很多人在做 LLM Agent 时喜欢给模型一大堆工具但其实工具越多越容易让模型用错。ARTEMIS 只暴露九个原子操作tap、long_press、input_text、clear_text、swipe、scroll、back、wait、assert。每个操作都有严格的 JSON Schema 定义和参数约束模型没有自由发挥的空间。2.4 模式切换与降级策略双模式不是割裂的运行过程中可以根据实际情况互相切换。ARTEMIS 内置了一个简单的状态判断器Script 模式回放时如果连续两步断言失败或定位失败会自动把现场打包后切到 Agent 模式接管让大模型实时分析发生了什么、是否能绕过障碍。反过来Agent 模式跑通一条任务后也会自动把操作轨迹脱水成脚本转给 Script 模式用于后续回归。这样两种模式形成了一个闭环Agent 负责探索和解决疑难杂症Script 负责大规模回归和稳定保障。探索出来的成果回流成脚本资产脚本跑不动的时候再由 Agent 兜底。这套降级策略在实际使用中非常重要。很多时候脚本失败并不是产品 bug而是设备状态异常、网络延迟、或者某个弹窗突然出现。如果脚本模式直接报红测试人员还得花时间排查浪费人力。有了模式切换机制这类非产品问题会被 Agent 自动消化掉只有 Agent 也处理不了的情况才会最终标记为失败并保留完整现场。3. 核心细节语义树、工具集与 Prompt缺一不可3.1 如何把一屏界面“翻译”成 LLM 能看懂的语义树语义树是 ARTEMIS 的基石这一步做不好后面全崩。构建流程大致分四步走。第一步原始数据采集。Android 端通过 UiAutomator2 dump 出 View 层级iOS 端通过 XCTest 的 Accessibility 接口获取 AX 树。同时截一张当前屏幕的截图。这里有个细节dump 出来的层级里可能包含大量折叠的 RecyclerView 节点直接把整个列表展开的话节点数量会爆炸所以采集层需要做一次预裁剪只保留当前屏幕可见范围内的节点。第二步节点清洗。筛选出 isVisibletrue 且尺寸不为零的节点过滤掉占位布局。很多 App 会有一个不可见的全屏遮罩用来拦截点击这类节点如果不过滤模型会被误导以为全屏都是可点击区域。清洗之后要做“容器折叠”也就是当一个父节点下面只有一个有效子节点时直接把父节点合并进子节点描述里减少层级深度。第三步语义增强。这一步会结合 OCR 和视图分析对关键节点补充识别出的文本内容尤其是图片型按钮比如一张写着“确认”的图片。另外还会用图标识别模型辅助判断按钮意图——如果发现一个 ImageButton 的 content-desc 为空但截图目标区域有一个购物车图标就会自动补一个icon_hint: cart字段。第四步JSON 序列化。每个节点只保留四个核心字段node_id、type、content、position。type 包括 button、input、text、list、image 等position 用归一化坐标表示。position 不是用来精确定位的而是给模型一个空间关系参考——比如判断“取消按钮在确认按钮左边”这种相对位置。最终一屏大概会输出 10 到 30 个有效节点这个量级丢给大模型看既丰富又不至于爆上下文。3.2 工具集设计宁可少给能力也要给得准我见过不少 LLM Agent 项目工具是越多越好点击、滑动、输入、截图、取坐标、查 API、拉日志恨不得把所有能力都塞给模型。实测下来工具数量一旦超过十五个模型选错工具的概率就明显上升。ARTEMIS 只保留九个原子操作是刻意做的减法。每个工具在向模型展示时都带一份完整的 JSON Schema包含参数说明、取值范围、示例。比如 tap 操作的 target_id 参数会指向语义树里的 node_id这样模型不需要关心具体坐标只需要从语义树里挑一个目标节点。坐标由执行器在运行时从语义树里查出来这样即使页面位置发生了变化只要语义没变操作依然能命中。input_text 操作稍微特殊一点它需要传入文本内容以及目标输入框的 node_id。同时还要支持一个clear_first布尔参数决定输入前要不要清空已有内容。这个参数很实用因为很多测试场景需要反复输入不同内容不清空会造成字符叠加。assert 操作是这套工具里最能体现测试思维的一个。传统 Agent 框架里几乎没有“断言”这个概念模型看到什么就是什么不会主动验证。ARTEMIS 把 assert 作为一等公民工具支持assert_text_visible、assert_element_exists、assert_text_not_exists三种断言类型。Agent 在执行关键步骤后需要主动调用 assert 来确认结果这个设计直接影响了生成脚本的质量——如果 Agent 在某些步骤后调用了 assert脱水出的脚本就会自动带上检查点而不是只有操作没有验证。3.3 Prompt 设计任务级规划与原子操作分开在跑 Agent 模式时Prompt 的组织方式直接决定推理质量。ARTEMIS 的做法是“任务级规划与原子操作分开”让模型先想做什么再想具体怎么做。具体来说每次请求的结构是三层系统提示词System Prompt、任务上下文Task Context、当前屏幕状态Screen State。系统提示词里固定写清楚三件事模型扮演什么角色一个移动端测试执行助手、有哪些可用工具及各自约束、总的安全边界不执行卸载、不改系统设置、不输入敏感信息。任务上下文里放的是当前这一步正在执行的子任务描述以及已经完成的操作摘要。这里有个经验千万不要把用户的整段原始任务一直原封不动地塞在上下文里。移动端长流程跑下来原始任务指令早就被大量历史信息淹没了模型容易丢失目标。ARTEMIS 每完成几个步骤就会让模型重写一次任务摘要把“已完成”和“待完成”压缩成两三句话始终保持上下文里有一个最新的、精简的任务状态。当前屏幕状态则包括语义树 JSON、上一操作的结果反馈成功/失败/超时、以及可选的截图尺寸信息。这里我尝试过是否把截图发给多模态模型一起分析视觉能力确实能补充语义树遗漏的信息但代价是 token 消耗明显变大、响应延迟从秒级变成十秒级。最终方案是默认不传截图只有当语义树中出现大量未知节点时才开启视觉兜底。3.4 从在线轨迹到离线脚本的“脱水”过程双模式闭环的关键在于轨迹脱水。Agent 模式跑通一次任务后系统里会留下一份完整的操作日志包含每一步的决策理由、选用的工具、传入的参数、执行结果、以及是否调用了断言。脱水过程就是把这份日志转成 Script 模式能直接执行的 YAML 脚本。脱水不是简单的日志重放需要做几层抽象。第一层是选择器抽象把日志里的 node_id 对应到执行时的语义特征转成语义选择器。比如某个 node_id 当时的 content 是“登录”type 是 button脱水时会记录成button[name登录]而不是坐标。这样下次执行时即使登录按钮位置变了只要语义还在就能命中。第二层是断言提取。Agent 日志里调用过的 assert 操作会被原样保留成脚本里的断言语句。如果 Agent 全程没调用过 assert这种情况很常见因为模型默认喜欢点完就算完脱水模块会自动做一次检查标记出“极可能需要断言”的步骤供人工补充。这个自动标记功能非常省心它会把执行完点击后屏幕状态发生显著变化的位置找出来推荐在那里加断言。第三层是参数固定。日志里输入过的文本内容会被保留但之前从动态数据源读取的内容会替换成变量占位符比如手机号字段会变成$phone。这样生成的脚本可以套用到不同测试数据上不至于写死。脱水完成后输出一份 YAML 文件人可以直接查看和修改。这个设计很关键——完全自动生成的脚本我还是不太放心但人工从零写脚本成本又高折中方案就是生成一个可读可改的中间产物。4. 实操记录用 ARTEMIS 跑通一个移动端验收场景4.1 环境准备与基础配置实际操作层面ARTEMIS 的环境准备比想象中轻。因为它底层对接的是已有的移动端自动化框架所以项目依赖不重。Android 端需要在设备上安装 Appium 的 UiAutomator2 驱动iOS 端需要 XCUITest 环境这些是常规操作不做赘述。ARTEMIS 的核心依赖是一个配置文件用来描述被测 App 的基本信息和模式开关。配置文件里会指定 App 的包名/Activity、启动等待时间、底层驱动类型、以及默认的 LLM 服务地址。首次接一个新 App 时只需要改配置里的应用描述以及一条启动指令剩下的语义树构建和工具集挂在系统上就能跑。有一点要提醒ARTEMIS 不会帮你处理签名安装这种基础问题。App 得先能正常安装到设备上并且允许被自动化驱动。权限弹窗、系统级弹窗如果不想让模型的决策逻辑处理建议在设备层面先做好权限预授权。否则每次启动都跑一遍授权流程既浪费执行时间也容易让模型在弹窗里反复横跳。4.2 场景定义登录 - 搜索 - 结果校验我用一个典型的电商验收场景来演示启动 App 后登录账号在首页搜索框输入“无线耳机”点击搜索结果里的第一个商品进入详情页后校验“加入购物车”按钮可见。这个场景横跨了输入、搜索、列表选择、页面跳转、断言校验五个操作类型覆盖了大部分基础原子操作。换成自然语言任务的写法就是一句话登录账号 138xxxx搜索“无线耳机”打开第一个搜索结果确认能看到“加入购物车”按钮。这个任务交给 Agent 模式执行时模型需要自己拆解成多个子步骤先找登录入口、处理登录页输入、回首页、找搜索框、输入关键词、点击搜索、识别结果列表、点击第一个条目、等待详情页渲染、执行断言。实际执行前最好先在配置里把核心超时参数设好页面加载超时默认 10 秒、单步操作重试两次、整个任务的最大步数设为 30。这些参数不是拍脑袋定的页面加载超时短了容易误判失败长了又拖慢整个流程。4.3 模式 A 实操自然语言任务Agent 在线执行启动 Agent 模式时ARTEMIS 会先拉一次屏幕语义树然后把用户的任务指令和当前屏幕状态一起发给大模型。模型先输出一个规划摘要说明准备分几步走然后开始逐步操作。这里分享一个观察到的具体案例。任务开始后模型在登录页卡住了大约 15 秒原因是登录页同时存在“手机号登录”和“验证码登录”两个 tab模型第一次尝试选择了验证码登录之后发现无法获取验证码又切换回手机号登录。它不是一次就找对路径但这恰好体现了 Agent 模式的价值——传统的固定脚本遇到这种分支时早就报错了Agent 模式却能在现场自我纠正。过程中模型执行了七次原子操作点击手机号输入框、输入手机号、点击获取验证码、等待 2 秒、输入验证码、点击登录、等待首页加载。每一步操作后 ARTEMIS 都会刷新语义树并反馈操作结果。当模型点击“获取验证码”按钮后界面弹了一个 Toast 提示虽然语义树里没有关于 Toast 内容的节点但 OCR 增强模块识别到了“验证码已发送”文本并将它补充到下一轮的语义树中模型据此判断操作成功继续下一步。整个任务从开始到断言完成总共耗时约 1 分 20 秒。模型在最后一步执行了 assert 操作确认“加入购物车”按钮可见。这个用时比传统脚本慢不少——传统脚本纯执行可能 30 秒内就跑完但考虑这是在线推理驱动的而且不需要写任何代码这个效率其实是可接受的。4.4 模式 B 实操自动沉淀脚本并回放Agent 模式跑完任务后ARTEMIS 自动生成了脱水脚本。我打开脚本查看发现比预想中干净很多。脚本已经把登录手机号参数化成了变量断言也保留在了最后一步。唯一需要人工补的是中间某一步搜索完成后模型没有立刻断言搜索结果列表只直接点击了第一个商品。我手动在脚本里加了一行断言“搜索结果显示‘无线耳机’相关商品”然后保存脚本切到 Script 模式执行。回放过程完全不依赖大模型纯本地执行跑了三遍第一遍和第二遍都稳定通过。第三遍我人为把首页搜索框的位置在 UI 上挪动了位置模拟 UI 布局变更脚本依然通过因为语义选择器命中靠的是文本特征而不是坐标。这个体验很有说服力脚本模式下一次在线跑通的任务后续成本几乎为零而且对 UI 微调具备天然的鲁棒性。理论上讲任何 UI 调整只要没有改变元素的语义含义脚本就不会挂。这让移动端回归测试的维护成本和传统方案形成了鲜明对比。4.5 关键参数与调优心得跑了几十个场景后我沉淀了几个参数调优的心得都记在这里。首先是最大步数 max_steps。默认 30 基本够用但遇到注册、下单这类超长流程时建议提到 50。超过 50 步的任务基本不太可能在线一次性跑成功因为上下文已经非常长了中途状态容易混乱更靠谱的做法是把长流程拆成两三个短任务分步跑。其次是单步重试次数 retry_limit。设置 2 次是基于平衡单步操作偶发失败大概率是时序问题等 1.5 秒重试通常能解决重试超过 2 次还失败就不是等一等能解决的了需要切换模式或让模型重新看屏幕。设了 3 次以上会导致单步卡死时间过长体验很拖沓。最后是温度 temperature。Agent 模式我建议设 0.2 左右别太高。有些探索性测试可以调到 0.4 增强随机性但回归性质的任务必须低温度确保操作路径稳定可复现。Script 模式生成阶段温度可以稍微高一点但生成之后回放阶段不受温度影响。5. 踩坑实录四个高频问题与排查技巧5.1 元素定位漂移语义树前后不一致跑了一段时间后遇到的第一个哭笑不得的问题是语义树输出不稳定。同一个页面两次启动 App 后构建出来的语义树差别很大有时一个按钮被识别成两个独立节点有时两个相邻文本被合并成一个节点。原因是 OCR 增强模块对图片型按钮的识别存在波动以及 View 树复用带来的节点顺序变化。排查时发现语义树不稳定会导致 Agent 在执行过程中反复找不到目标节点。比如第一次识别出“搜索”按钮第二次同一个按钮的 content 变成了“搜索按钮”如果模型严格按文本匹配去定位就会失败。我的解决办法是在语义树节点生成时加一个“稳定 ID 映射”根据节点在当前屏幕中的位置和类型生成一个持久指纹比如buttonhome_search这种形式。这个指纹由 ARTEMIS 在每次构建语义树时尽量保持稳定只有节点真实变化时才更新。这样 Agent 在多次请求间引用同一个 target_id 时就不会因为细粒度文本差异而漂移。5.2 上下文太长模型忘了任务目标上下文失控是老生常谈实际跑下来比预想中更隐蔽。嵌入式遇到的情况不是上下文一下子超出窗口而是在第五六步之后模型开始出现“近期偏置”——它越来越关注最近一两步的屏幕状态而对最初的任务目标记忆模糊。表现是本来任务是“打开第一个搜索结果”模型却在详情页里开始反复滑动似乎忘记了自己要验证的目标是什么。我一度以为是模型能力不足后来加了任务摘要重写机制后这个问题得到明显改善。具体做法是在每完成三步操作后插入一次“状态压缩”请求让模型根据历史操作输出一个当前任务摘要包含已完成步骤和下一步计划。下一轮请求用这个摘要替换掉完整的历史上下文。代价是每三轮多一次请求但换来的是长任务完成率从不到一半提升到八成以上划算太多了。5.3 Toast、弹窗、模态误判移动端最烦人的是系统级弹窗和瞬时提示。权限申请弹窗、更新弹窗、评分引导弹窗、网络异常提示这些在传统自动化里都能通过预置处理逻辑解决但在 LLM 驱动的 Agent 模式里模型并不总能分清楚“这是必须处理的弹窗”还是“一个可以忽略的页面元素”。有一次执行任务时手机系统突然弹了一个“允许发送通知”的权限请求语义树里出现了“允许”和“不允许”两个按钮。模型误判为业务弹窗随手点了“允许”结果后续整个流程都被通知推送干扰了。排查时发现语义树本身没有提供足够的上下文区分系统弹窗和业务弹窗。解决办法是在语义树构建阶段加一个“弹窗来源标记”通过窗口类型和布局层级判断当前弹出的是系统级窗口带系统图标和特定文案还是应用内弹窗。系统弹窗会单独标注并在 Prompt 系统提示词里固定加入处理策略。另外在权限弹窗这类场景ARTEMIS 配置里默认建议先设好设备授权尽量避免在测试过程中触发系统弹窗。5.4 死循环与重试风暴步数上限与模式切换降级最头疼的问题是死循环。Agent 模式在某些场景下会陷入“点击 A 失败 - 刷新页面 - 又点击 A 失败”的循环由于每一步都会重新生成决策模型可能意识不到自己正在做重复操作。有一次任务陷入循环模型连续八次尝试点击同一个按钮每次失败后都以为页面发生了变化实际上根本没有。步数上限起到了最终兜底作用但默认的 30 步已经消耗了八步对最终任务完成影响很大。后续我加了一个循环检测器记录最近五步的操作签名当前屏幕关键节点哈希 操作名。如果发现同样的签名重复出现三次以上会自动把任务切到人工介入或模式切换流程而不是让模型继续尝试。另一个有效手段是当脚本回放连续失败时主动触发 Agent 接管Agent 会重新拉取语义树并给出一份完整分析通常能准确指出是因为页面元素确实不存在还是因为时序问题需要等待。5.5 生成脚本的断言盲区Script 模式刚上线时我发现大多数自动生成的脚本都缺少中途断言。Agent 在线执行时模型每一步都看着屏幕能隐式感知各种状态变化但脱水的脚本如果没有显式断言回放时就只能盲目执行到最后一步再去校验结果。一旦中途某步失败脚本仍然会继续往下跑最终报一个让人摸不着头脑的错误。这个问题我做了两方面改进。一方面在脱水时利用“屏幕状态变化分析”自动推荐断言插入点如果某次操作前后语义树发生了显著变化比如列表出现或消失、按钮文本切换、页面标题变化就会在这一步后自动插入一条候选断言。推荐的断言插件不一定准确但好歹给了人工一个参考方向。另一方面我在 Prompt 系统提示词里增加了引导要求 Agent 在每个关键状态变化后调用 assert 工具确认结果而不是默默继续下一步。一段时间后生成的脚本质量有明显提升中途断言覆盖率从三成提高到七成以上。对于剩下没有断言的部分人工在评审脚本时补齐。6. 双模式跑通之后我看到的三组变化与后续计划6.1 实际数据里最有价值的三个变化ARTEMIS 双模式跑通后我在一个小范围的移动端回归项目上做了前后对比。最有价值的变化有三个。第一是 UI 改版导致的脚本维护成本大幅下降。以往每次版本迭代至少要花半天到一天修脚本采用语义定位后绝大多数无实质功能变化的 UI 调整都不会破坏脚本维护时间降到两小时左右。第二是探索式测试的覆盖面明显扩大。以前人工探索测试依赖个人经验现在可以直接用自然语言下达测试意图Agent 模式会自动尝试多条路径。在执行过程中发现的问题比之前固定场景高出不少有些是边缘交互路径的老问题在自动化回归里从来没被发现过。第三是回归频次上去了。Script 模式回放速度快、稳定性高、零推理成本团队可以把原本每周一次的回归提升到每天执行。高频回归带来的是问题发现时间前移线上问题数量有可观察的下降。当然这里不全是 ARTEMIS 的功劳但自动化稳定性提升带来的正向循环是明确的。6.2 后面想继续做的几件事ARTEMIS 这个项目到现在为止还算顺手但我也清楚它离一个可产品化的测试平台还有距离。后面想重点投入的方向有三个一是把语义树构建从“页面级别”升级到“任务级别”让模型在跑长流程时能记住更多跨页面的状态信息二是探索让 Script 模式生成的脚本自动进行自我修复不用每次 UI 变化都切回 Agent 重新生成三是把多设备并行和结果聚合做起来让这套架构真正支撑起整套移动端回归流水线。以我个人的实际体会来说双模式架构最值得投入的地方不是那套在线执行能力而是“在线跑通后能自动沉淀为离线资产”的闭环设计。做 LLM 自动化测试最忌讳的就是把大模型当成每次都要在场的“神”真正靠谱的思路是让它当一个会总结经验的老师傅把经验变成可以反复使用的手册。ARTEMIS 的探索到这里最大的收获不是技术实现而是这个思路本身——工具会迭代但“灵活执行 稳定沉淀”这对组合会在很长一段时间里持续成立。
阅读完成 · 觉得有帮助？
