移动端自动化测试双模式架构：LLM与传统脚本引擎的协同实践

1. 移动端自动化测试的现状与ARTEMIS的切入点

移动端自动化测试这件事，做过的人都懂——写脚本的时间可能还没调脚本的时间长。尤其是这两年大模型能力往上走，很多团队开始琢磨用LLM来驱动测试用例生成、元素定位甚至异常恢复，但真正落地的时候会发现一个尴尬的现实：纯靠LLM做端到端自动化，稳定性堪忧；纯靠传统UI自动化框架，维护成本又高得离谱。

ARTEMIS这个项目就是在这个夹缝里长出来的。它的核心思路不是用LLM替代传统自动化框架，而是做了一层“双模式架构”，让LLM和传统脚本引擎各管各的、互相补位。这个思路听起来简单，但拆开来看，里面有不少值得细说的设计取舍。

我第一次接触这个架构的时候，最直观的感受是：它把“什么时候该用LLM”和“什么时候该用确定性脚本”这件事想得很清楚。很多团队做LLM自动化测试，上来就是全链路LLM驱动，结果跑十个用例挂八个，最后得出结论“LLM不靠谱”。ARTEMIS的做法恰恰相反——它把LLM放在它最擅长的地方，把确定性逻辑交给传统引擎，两者通过一套调度层衔接。

这篇文章我会从架构设计、核心模块拆解、实操配置、常见问题几个角度，把这个双模式架构讲透。适合正在做移动端自动化测试、或者想把LLM引入测试流程的工程师参考。不管你是刚接触移动端自动化，还是已经在用Appium、UiAutomator这类工具，应该都能从中找到一些可以直接抄作业的东西。

2. 双模式架构的整体设计与选型逻辑

2.1 为什么不是“纯LLM驱动”

先说一个我踩过的坑。之前有个项目，团队想用LLM直接根据自然语言描述生成Appium脚本，然后直接执行。想法很美好——产品经理写一句“打开首页，点击搜索框，输入关键词，检查结果列表非空”，LLM生成对应的Python代码，跑就完了。

实际跑下来，问题出在几个地方：

第一，LLM生成的元素定位策略不稳定。同一个按钮，这次用resource-id定位，下次用xpath，再下次用text。App一改版，全挂。第二，LLM对时序的理解很弱。移动端操作有大量隐式等待、动画过渡、网络延迟，LLM生成的脚本往往缺少合理的等待逻辑。第三，异常恢复几乎没法做。脚本跑挂了，LLM不知道当前页面处于什么状态，更不知道怎么回到主流程。

这三个问题加起来，导致纯LLM驱动的方案在真实项目里几乎不可维护。ARTEMIS的设计者显然也意识到了这一点，所以它的双模式架构本质上是一个“分工协议”：LLM负责它擅长的语义理解、动态决策、异常恢复；传统引擎负责它擅长的确定性操作、元素定位、断言校验。

2.2 双模式的具体分工

ARTEMIS把整个测试执行过程拆成两种模式：

脚本模式（Script Mode）：这是基础模式，走的是传统的自动化测试路径。测试用例被预先定义成结构化的步骤序列，每一步包含操作类型（点击、输入、滑动等）、定位策略（resource-id、accessibility-id、xpath等）、预期结果。执行引擎按顺序执行，遇到断言失败就标记用例失败。这个模式的特点是确定性高、执行速度快、结果可复现。

智能模式（Smart Mode）：这是LLM介入的模式。当脚本模式遇到无法处理的情况——比如元素定位失败、页面结构变化、需要动态决策下一步操作——控制权会交给智能模式。LLM根据当前页面截图、UI树结构、历史操作上下文，推理出下一步应该做什么，然后生成一个临时操作指令，交给执行引擎去执行。

这两种模式不是互斥的，而是可以嵌套的。一个测试用例可以大部分步骤走脚本模式，在特定环节切换到智能模式，处理完再切回来。这种设计的好处是：大部分确定性操作不消耗LLM调用，成本和延迟都可控；只在真正需要语义理解的地方才动用LLM。

2.3 调度层的核心作用

双模式架构能跑起来，关键在于中间那层调度器。ARTEMIS的调度层做了几件事：

• 模式切换决策：根据当前步骤的执行结果，判断是否需要从脚本模式切到智能模式。比如元素定位失败超过阈值、页面结构与预期不符、断言失败但不确定是bug还是脚本问题。
• 上下文管理：维护当前测试用例的执行历史、页面状态快照、已尝试过的操作序列。这些上下文在切换到智能模式时传给LLM，帮助它做出更准确的决策。
• 结果回写：智能模式产生的操作指令执行后，结果会回写到脚本模式的执行记录里，保证整个用例的执行轨迹是完整的。
• 降级策略：如果智能模式也无法解决问题，调度层会触发降级——标记用例为“需人工介入”，保存现场快照，继续执行下一个用例，而不是整个测试套件挂掉。

这个调度层的设计思路，我觉得是ARTEMIS最值得借鉴的地方。它没有试图让LLM做所有事，而是把LLM当成一个“高级异常处理器”来用。这个定位非常务实。

2.4 与传统PO模式的对比

如果你用过Page Object模式，可能会觉得ARTEMIS的脚本模式跟PO很像。确实有相似之处，但区别在于：PO模式把页面元素和操作封装成类，测试用例调用这些类的方法；ARTEMIS的脚本模式更轻量，它把步骤定义成数据（JSON或YAML），执行引擎根据数据驱动操作。

这样做的好处是，步骤定义可以被LLM直接理解和生成。LLM不需要理解复杂的类继承关系，只需要根据页面结构和任务描述，生成一个步骤列表就行。这降低了LLM介入的门槛。

另一个区别是，PO模式下面临页面变化时，需要人工修改Page类；ARTEMIS的智能模式可以在页面变化时自动尝试修复定位策略，把修复结果反馈给脚本模式，实现一定程度的自愈。

3. 核心模块拆解与关键细节

3.1 脚本引擎的执行流程

脚本引擎是ARTEMIS的基础设施，它的执行流程大致是这样的：

1. 加载测试用例文件，解析成步骤列表。
2. 初始化移动端驱动（基于Appium或类似协议）。
3. 逐步执行每个步骤：
   • 解析定位策略，查找元素。
   • 执行操作（点击、输入、滑动等）。
   • 执行断言（元素存在、文本匹配、属性校验等）。
   • 记录执行结果和页面快照。
4. 如果某一步失败，根据失败类型决定是否触发智能模式。
5. 所有步骤执行完毕，生成测试报告。

这里面有几个细节值得注意。首先是定位策略的优先级。ARTEMIS默认的定位优先级是：accessibility-id > resource-id > text > xpath。这个顺序是有讲究的——accessibility-id和resource-id通常最稳定，text容易受多语言影响，xpath最脆弱但通用性最强。

其次是等待策略。移动端操作不能硬等，也不能完全不等待。ARTEMIS的做法是组合使用隐式等待和显式等待：驱动层设置一个全局隐式等待（通常5-10秒），每个步骤可以覆盖这个设置，指定特定的等待条件（如元素可见、元素可点击、页面标题变化等）。

实操心得：隐式等待不要设太长，否则失败用例的反馈时间会很难受。我一般设5秒，然后在关键步骤上加显式等待。另外，动画过渡多的页面，可以在步骤里加一个短暂的固定等待（500ms左右），比纯靠条件等待更稳。

3.2 智能模式的触发条件与决策逻辑

智能模式不是随便触发的。ARTEMIS定义了几种触发场景：

触发智能模式后，ARTEMIS会把当前页面的截图、UI树结构、最近几步的操作历史、当前测试用例的目标描述，一起打包发给LLM。LLM返回一个结构化的操作指令，包含操作类型、目标元素描述、预期结果。

这里有个关键设计：LLM返回的不是代码，而是结构化的操作描述。比如它不会返回driver.find_element(By.ID, "com.example:id/btn").click()，而是返回{"action": "click", "target": "搜索按钮", "locator_hint": "resource-id包含search"}。执行引擎拿到这个描述后，再根据当前页面结构去解析和执行。

这样做的好处是，LLM的输出可以被校验和缓存。如果同一个操作在多个用例中重复出现，执行引擎可以复用之前的定位结果，减少LLM调用次数。

3.3 上下文管理与状态快照

智能模式能不能做对决策，很大程度上取决于上下文给得够不够。ARTEMIS的上下文管理模块负责收集和整理这些信息：

• 页面快照：当前页面的截图（压缩后）、UI树结构（裁剪掉无关节点）、关键元素的属性。
• 操作历史：当前用例最近N步的操作记录，包括操作类型、目标元素、执行结果。
• 用例目标：当前测试用例的自然语言描述，帮助LLM理解“现在要做什么”。
• 全局状态：当前登录用户、网络状态、App版本等环境信息。

这些信息会被组织成一个结构化的prompt，发给LLM。prompt的设计很关键——太长了浪费token，太短了LLM理解不够。ARTEMIS的做法是分层传递：页面快照只传关键区域，UI树只传可见节点，操作历史只传最近5步。

注意事项：UI树裁剪是个技术活。裁得太狠，LLM找不到目标元素；裁得太松，token消耗爆炸。我的经验是保留所有可交互节点和文本节点，去掉纯布局容器。另外，截图分辨率不要太高，720p足够LLM识别元素了。

3.4 结果回写与自愈机制

智能模式执行完操作后，结果会回写到脚本模式的执行记录里。如果智能模式成功修复了一个定位问题，ARTEMIS会把这个修复记录下来，下次遇到同样的定位失败时，直接使用修复后的策略，不再调用LLM。

这个自愈机制是ARTEMIS比较有意思的地方。它本质上是一个“LLM辅助的定位策略缓存”：LLM第一次解决某个元素的定位问题后，解决方案被缓存；后续遇到相同元素，直接查缓存。缓存有有效期，App版本更新后失效。

自愈机制的实现依赖一个定位策略库，里面存储了元素描述到定位策略的映射。这个库可以是本地的JSON文件，也可以是远程的配置中心。ARTEMIS默认用本地文件，方便调试和版本管理。

4. 实操配置与核心环节实现

4.1 环境准备与依赖安装

ARTEMIS本身是一个测试框架，它的运行依赖几个东西：

• 移动端驱动：底层还是走Appium或类似的WebDriver协议。你需要先搭好Appium环境，确保能连上真机或模拟器。
• LLM接口：ARTEMIS需要调用LLM服务。它支持多种接口格式，包括OpenAI兼容接口、本地模型接口等。你需要准备一个可用的API端点和密钥。
• Python环境：ARTEMIS的核心是Python写的，建议用3.9以上版本。依赖管理用pip或poetry都行。

安装步骤大致如下：

# 创建虚拟环境 python -m venv artemis-env source artemis-env/bin/activate # Windows下用 artemis-env\Scripts\activate # 安装ARTEMIS核心包 pip install artemis-test # 安装移动端驱动依赖 pip install Appium-Python-Client # 如果需要截图处理，安装图像库 pip install pillow opencv-python

配置方面，ARTEMIS需要一个配置文件，通常叫artemis.config.yaml，里面定义驱动地址、LLM接口、超时参数等。下面是一个最小配置示例：

driver: hub_url: "http://127.0.0.1:4723" platform: "android" device_name: "emulator-5554" app_package: "com.example.app" app_activity: ".MainActivity" llm: provider: "openai-compatible" base_url: "http://127.0.0.1:8000/v1" api_key: "your-key-here" model: "gpt-4o-mini" max_tokens: 1024 temperature: 0.1 execution: implicit_wait: 5 explicit_wait: 10 smart_mode_threshold: 2 snapshot_quality: 70

实操心得：temperature一定要设低，0.1甚至0都行。智能模式需要的是确定性推理，不是创意写作。另外，max_tokens不要设太大，1024足够返回一个操作指令了，设大了反而容易让LLM输出一堆废话。

4.2 测试用例的编写格式

ARTEMIS的测试用例支持YAML和JSON两种格式。YAML更易读，推荐用YAML。一个典型的用例长这样：

name: "搜索功能验证" description: "打开首页，点击搜索框，输入关键词，验证结果列表非空" steps: - action: "launch_app" params: package: "com.example.app" activity: ".MainActivity" - action: "click" target: "搜索入口" locator: strategy: "accessibility-id" value: "search_button" wait: condition: "element_visible" timeout: 10 - action: "input" target: "搜索输入框" locator: strategy: "resource-id" value: "com.example.app:id/search_input" text: "自动化测试" wait: condition: "element_clickable" timeout: 5 - action: "click" target: "搜索按钮" locator: strategy: "text" value: "搜索" smart_mode: true # 标记为智能步骤 - action: "assert" target: "结果列表" condition: "element_exists" locator: strategy: "resource-id" value: "com.example.app:id/result_list" timeout: 15

这个用例里，大部分步骤是脚本模式，只有“点击搜索按钮”这一步标记了smart_mode: true。这意味着如果这一步的定位失败，会触发智能模式。

4.3 智能模式的调用与参数配置

智能模式的调用不是自动的，需要在用例里显式标记，或者在配置里设置全局触发条件。ARTEMIS支持两种触发方式：

显式触发：在步骤里加smart_mode: true，表示这一步如果失败，走智能模式。

隐式触发：在配置里设置smart_mode_threshold，表示连续N步失败后自动触发智能模式。这个阈值默认是2，意思是连续两步失败就触发。

智能模式调用时，ARTEMIS会构造一个prompt发给LLM。prompt的结构大致如下：

你是一个移动端自动化测试助手。当前页面信息如下： 页面截图：[图片] UI树结构：[裁剪后的XML] 最近操作：[最近5步的操作记录] 当前目标：[当前用例的描述] 请根据以上信息，判断下一步应该执行什么操作。返回JSON格式： { "action": "click|input|swipe|assert|wait", "target": "目标元素描述", "locator_hint": "定位提示", "params": {}, "reason": "决策理由" }

LLM返回的JSON会被解析成操作指令，交给执行引擎执行。如果LLM返回的格式不对，ARTEMIS会重试一次，重试失败则标记用例为“智能模式失败”。

4.4 执行与报告生成

执行测试用例的命令很简单：

artemis run --config artemis.config.yaml --suite tests/search_suite.yaml

执行过程中，ARTEMIS会实时输出每一步的执行状态。如果触发了智能模式，会额外输出LLM的决策理由。执行完毕后，生成HTML报告，包含：

• 用例通过率
• 每步的执行耗时
• 智能模式触发次数和成功率
• 失败步骤的截图和UI树快照
• LLM决策记录

报告里最有价值的是智能模式触发记录。你可以看到哪些步骤经常触发智能模式，哪些定位策略不稳定，哪些页面变化频繁。这些信息对优化测试用例很有帮助。

实操心得：建议把智能模式的触发记录单独导出成CSV，定期分析。如果某个步骤频繁触发智能模式，说明这个步骤的脚本模式定义有问题，应该优化定位策略或者调整等待条件，而不是依赖LLM去修。

5. 常见问题与排查技巧实录

5.1 智能模式频繁触发怎么办

这是最常见的问题。智能模式触发太频繁，会导致测试执行变慢、LLM成本上升。排查思路如下：

我的经验是，智能模式触发率控制在10%以内比较健康。超过20%就说明脚本模式的定义质量有问题，需要回头优化用例。

5.2 LLM返回格式错误怎么处理

LLM有时候会返回不符合JSON格式的内容，或者返回了JSON但字段不对。ARTEMIS的处理策略是：

1. 第一次解析失败，重试一次，在prompt里强调“只返回JSON，不要有其他内容”。
2. 第二次解析失败，尝试用正则提取JSON部分。
3. 第三次失败，标记该步骤为“智能模式失败”，降级到人工介入。

为了减少格式错误，可以在prompt里加一个few-shot示例，给LLM展示正确的返回格式。另外，temperature设低也能减少格式错误。

5.3 截图和UI树传输的优化

截图和UI树是智能模式的主要输入，也是token消耗的大头。优化策略包括：

• 截图压缩：用JPEG格式，质量设70左右，分辨率降到720p。
• UI树裁剪：只保留可交互节点和文本节点，去掉纯布局容器。
• 按需传输：如果当前步骤只需要定位一个元素，可以只传页面局部截图和UI树片段。

注意事项：UI树裁剪时要注意保留节点的层级关系，否则LLM无法理解元素之间的包含关系。另外，截图和UI树的坐标系要一致，否则LLM定位会出错。

5.4 多设备并行执行的支持

ARTEMIS支持多设备并行执行，但智能模式在并行环境下需要额外注意：

• 每个设备需要独立的LLM会话上下文，避免上下文串扰。
• 截图和UI树的采集要加设备标识，方便排查问题。
• LLM调用需要做限流，避免并发过高导致接口超时。

并行执行的配置在artemis.config.yaml里设置：

execution: parallel: true max_workers: 4 device_pool: - "emulator-5554" - "emulator-5556" - "emulator-5558" - "emulator-5560"

5.5 智能模式的自愈缓存管理

自愈缓存是ARTEMIS的一个亮点，但缓存管理不好也会出问题。常见问题包括：

• 缓存过期不清理：App更新后，旧的定位策略失效，但缓存还在用。
• 缓存冲突：不同页面有相同描述的元素，缓存串了。
• 缓存膨胀：缓存文件越来越大，加载变慢。

解决方法：

• 缓存加版本号，App版本更新时自动失效。
• 缓存key加上页面标识，避免跨页面冲突。
• 定期清理缓存，只保留最近N条记录。

# 缓存清理示例 from artemis.cache import LocatorCache cache = LocatorCache("locator_cache.json") cache.cleanup(max_entries=500, max_age_days=7) cache.save()

这个清理脚本可以放在测试套件执行前跑一次，保证缓存不会无限膨胀。

5.6 智能模式与人工介入的边界

最后说一个设计上的问题：智能模式不是万能的，有些情况必须人工介入。ARTEMIS定义了几个必须人工介入的场景：

• 智能模式连续失败超过3次。
• LLM返回的操作指令涉及敏感操作（如删除数据、支付）。
• 页面出现验证码、人脸识别等无法自动处理的环节。
• 断言失败但LLM无法判断是bug还是脚本问题。

这些场景下，ARTEMIS会保存现场快照，标记用例为“需人工介入”，然后继续执行下一个用例。人工介入后，可以手动修复用例，或者更新自愈缓存。

我个人在实际操作中的体会是，智能模式最适合处理的是“页面结构变化导致的定位失败”和“预期外的弹窗干扰”。这两类问题占移动端自动化测试失败原因的大部分，用LLM处理性价比最高。至于复杂的业务流程决策，还是老老实实写脚本更靠谱。ARTEMIS的双模式架构给了我们一个很好的思路：不是让LLM替代一切，而是让LLM在它最擅长的地方发挥作用，其余的交给我们已经验证过的确定性方案。这个思路，我觉得比具体的技术实现更有价值。