企业官网建设流程全解析

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

移动端自动化测试这件事，做过的人都懂，它跟Web端完全不是一个难度量级。Web端你至少有一个相对统一的DOM树可以抓，有稳定的选择器可以定位，浏览器DevTools一开，元素、网络、控制台全都摆在明面上。但移动端呢？原生控件体系碎片化、渲染管线不透明、不同系统版本行为差异巨大，再加上真机与模拟器的表现不一致，导致很多团队在移动端自动化上的投入产出比一直很难看。

我最早接触移动端自动化是在一个跨平台应用的项目里，当时用的是传统的UI测试框架，脚本写了几百条，维护成本高得离谱。每次应用改版，选择器大面积失效，测试脚本的修复时间甚至超过了手工回归的时间。后来大语言模型的能力上来了，我开始琢磨能不能用LLM来做移动端的自动化测试，让模型去理解界面、生成操作序列、甚至自主判断测试结果。这个方向探索了一段时间之后，我注意到一个叫ARTEMIS的方案，它提出的双模式架构让我眼前一亮。

ARTEMIS这个名字本身是“Automated Reasoning and Testing for Mobile Interface Systems”的缩写，从命名就能看出来，它是专门针对移动端界面系统的自动化推理与测试框架。它最核心的设计就是双模式架构——一套系统里同时支持两种截然不同的工作模式，分别应对移动端自动化测试中两类本质不同的任务场景。这个思路解决了我之前一直纠结的一个问题：到底应该让LLM做“理解型”的工作还是“执行型”的工作？ARTEMIS的答案是，两者都要，但要用不同的模式来承载。

这篇文章我会从架构设计的角度，把ARTEMIS的双模式拆开来讲清楚。包括它为什么这么设计、两种模式各自解决什么问题、底层是怎么实现的、实际跑起来效果如何、有哪些坑需要注意。如果你正在做移动端自动化测试，或者正在探索LLM在测试领域的落地，这篇内容应该能给你不少参考。

2. 双模式架构的整体设计思路

2.1 为什么单一模式走不通

在聊ARTEMIS的双模式之前，得先说说为什么单一模式在移动端自动化测试里走不通。我试过两种极端方案，都碰了壁。

第一种是纯脚本驱动模式。就是传统的做法，测试人员写好每一步操作，LLM只负责在脚本失败的时候帮忙分析一下日志。这种模式的问题在于，移动端界面的变化太频繁了，脚本的脆弱性极高。一个按钮从左上角挪到右下角，或者文案从“确认”改成“确定”，脚本就挂了。LLM在这里只是个事后诸葛亮，帮不上实质性的忙。

第二种是纯LLM自主模式。让LLM看着屏幕截图，自己决定下一步点什么。听起来很美好，但实际跑起来问题一大堆。首先是延迟，每次操作都要调一次模型推理，一个完整的测试用例跑下来要几分钟甚至十几分钟。其次是稳定性，LLM有时候会“幻觉”，点到一个不存在的控件上，或者陷入循环操作。最后是成本，高频调用大模型的费用不是每个团队都能承受的。

ARTEMIS的设计者显然也踩过这些坑，所以他们的双模式架构本质上是在确定性与灵活性之间找平衡。一种模式负责处理那些结构清晰、流程固定的测试场景，追求的是速度和稳定性；另一种模式负责处理那些需要理解、推理、探索的复杂场景，追求的是覆盖度和智能性。两种模式共享同一套底层能力，但在调度策略、推理深度、执行方式上做了明确的区分。

2.2 两种模式的分工逻辑

ARTEMIS把两种模式分别叫做Direct模式和Agentic模式。名字很直白，Direct就是直接执行，Agentic就是智能体式的自主执行。

Direct模式的核心思路是“预编译+轻量推理”。测试人员或者上游系统提供结构化的测试意图描述，ARTEMIS把它编译成一套可执行的操作序列，然后在执行过程中用轻量级的视觉匹配来定位控件。这里的LLM参与度很低，主要用在两个环节：一是把自然语言描述的测试意图转成结构化指令，二是在视觉匹配失败的时候做一次兜底判断。整个执行过程是确定性的，速度快，资源消耗低。

Agentic模式则是“感知-推理-行动”的闭环。LLM在这里是核心决策者，它看着当前屏幕的截图，结合测试目标，自主决定下一步该做什么操作。这个模式适合处理那些流程不固定、需要探索的测试场景，比如“遍历应用的所有设置项，检查是否有崩溃”这种任务。Agentic模式的单步延迟高，但它的优势在于能处理Direct模式搞不定的复杂情况。

这两种模式不是互斥的，而是互补的。ARTEMIS的调度层会根据测试任务的特征自动选择模式，也支持在同一个测试用例里混合使用。比如一个测试用例的前半段是固定的登录流程，用Direct模式快速跑完；后半段是探索性的功能验证，切换到Agentic模式。这种灵活性是ARTEMIS相比其他方案的一个明显优势。

2.3 共享底层能力的架构分层

虽然两种模式的工作方式差异很大，但ARTEMIS在架构上做了很好的抽象，让它们共享了大量的底层能力。整个系统大致分为四层：

这个分层设计的好处是，感知层和执行层的代码只需要维护一份，两种模式的差异被收敛在推理层和调度层。我在自己搭建类似系统的时候，一开始没有做这种抽象，结果两套逻辑各写各的，维护起来非常痛苦。ARTEMIS的这个设计值得借鉴。

感知层里有一个细节值得说，就是UI树的获取方式。Android端通过无障碍服务拿到的UI树信息最全，但有些应用会做反自动化处理，导致UI树不完整。iOS端的情况更复杂，XCUITest提供的元素信息有限。ARTEMIS的做法是UI树和截图双通道并行，UI树能拿到就用UI树做精确定位，拿不到就用视觉模型做兜底。这个双通道策略在实际项目里非常实用。

3. Direct模式的实现细节与实操要点

3.1 测试意图的结构化描述

Direct模式能不能跑得快、跑得稳，关键看测试意图描述得够不够结构化。ARTEMIS定义了一套DSL，用来描述测试步骤。这套DSL不复杂，核心就是几个要素：操作类型、目标控件、操作参数、预期结果。

举个例子，一个登录操作的DSL描述大概长这样：

step: login actions: - type: input target: text: "用户名输入框" locator_hint: "resource_id:username_field" value: "test_user" - type: input target: text: "密码输入框" locator_hint: "resource_id:password_field" value: "test_pass" - type: click target: text: "登录按钮" locator_hint: "text:登录" expect: - type: element_visible target: text: "首页"

这里有个设计细节值得注意：locator_hint字段。它不是强制性的精确定位符，而是一个提示。ARTEMIS在执行时会优先用这个提示去找控件，如果找不到，再启动视觉匹配。这种“提示+兜底”的设计比传统的硬编码选择器灵活得多。我在自己的项目里也采用了类似的做法，把resource_id、text、content_description都作为候选提示，命中率明显提升。

DSL的编写可以由人工完成，也可以由LLM从自然语言测试用例自动生成。ARTEMIS提供了一个转换工具，输入是自然语言描述的测试步骤，输出是DSL。这个转换过程用的就是LLM，但只做一次，生成的DSL可以复用。这比每次执行都调LLM要经济得多。

3.2 视觉匹配的轻量推理策略

Direct模式在执行时，如果locator_hint没能命中控件，就会启动视觉匹配。这里的视觉匹配不是让LLM直接看截图找控件，那样太慢。ARTEMIS用的是一个两阶段策略。

第一阶段是传统CV匹配。用模板匹配、特征点匹配这些经典方法，在截图里找和预期控件相似的区域。这一步很快，毫秒级。如果匹配度超过阈值，直接返回坐标。大部分情况下，这一步就能解决问题，因为移动端界面的控件外观变化通常不会太剧烈。

第二阶段才是LLM辅助判断。当传统CV匹配的置信度不够时，把截图和控件描述一起发给LLM，让LLM判断控件的位置。这里的提示词设计很关键，ARTEMIS用的是“网格定位法”：把截图划分成N×M的网格，让LLM输出控件所在的网格编号，而不是直接输出像素坐标。这样做的好处是降低了LLM的输出空间，提高了准确率。我实测下来，网格定位法比直接输出坐标的准确率高出不少，尤其是在控件较小或者界面较复杂的情况下。

实操心得：网格的粒度需要根据屏幕分辨率调整。1080P的屏幕用6×10的网格比较合适，太粗了定位不准，太细了LLM容易搞混。另外，在提示词里明确告诉LLM“只输出网格编号，不要输出其他内容”，能进一步降低解析失败的概率。

3.3 批量执行与异常恢复机制

Direct模式的一个核心优势是支持批量执行。因为操作序列是预编译好的，ARTEMIS可以一次性把多个操作下发给设备，而不是一步一步等。这在Android上通过UiAutomator的批量操作接口实现，在iOS上通过XCUITest的批量命令实现。批量执行能把测试速度提升30%到50%，具体取决于操作的类型。

但批量执行也带来了一个问题：异常恢复。如果批量操作中间某一步失败了，后面的操作可能全部错位。ARTEMIS的解决方案是在每个操作之间插入状态检查点。检查点不执行实际操作，只是快速验证当前界面是否符合预期。如果检查点失败，就中断批量执行，回退到单步模式，重新定位控件后再继续。

这个机制听起来简单，但实现起来有不少细节。比如检查点的验证逻辑要足够轻量，不能拖慢整体速度；检查点的频率要合理，太密了影响性能，太疏了异常发现不及时。ARTEMIS默认是每3到5个操作插入一个检查点，这个频率在实际项目里比较平衡。

异常恢复还有一个重要的策略是重试与降级。当某个操作失败时，ARTEMIS会先重试一次，重试时换一种定位方式（比如从resource_id换成text）。如果还失败，就降级到Agentic模式，让LLM来接管这一步。这种“Direct优先，Agentic兜底”的策略，既保证了大部分场景的速度，又保证了复杂场景的覆盖率。

4. Agentic模式的推理闭环与执行策略

4.1 感知信息的组织与提示词设计

Agentic模式的核心是让LLM根据当前屏幕状态自主决策。这里第一个要解决的问题是：给LLM看什么。只给截图？只给UI树？还是两者都给？

ARTEMIS的做法是截图为主，UI树为辅。截图提供视觉信息，UI树提供结构信息。但两者不能简单拼接，因为UI树的信息量可能非常大，全部塞进提示词会超出上下文窗口。ARTEMIS用了一个信息压缩的策略：从UI树里提取出可交互的控件列表，每个控件只保留类型、文本、位置、是否可点击这几个关键属性，然后以简洁的格式呈现给LLM。

提示词的结构大致是这样的：

当前屏幕截图：[图片] 可交互控件列表： 1. 按钮 "登录" 位置(500,1200) 可点击 2. 输入框 "用户名" 位置(300,800) 可输入 3. 文本 "忘记密码" 位置(700,1300) 可点击 ... 测试目标：完成登录流程 历史操作：已输入用户名，已输入密码 请决定下一步操作，输出格式：{"action": "click", "target": "登录"}

这个提示词设计有几个讲究。第一，控件列表用编号而不是坐标，让LLM输出编号，减少输出错误。第二，包含历史操作，避免LLM重复执行已经做过的操作。第三，输出格式固定为JSON，方便程序解析。第四，测试目标要明确，LLM需要知道它要达成什么，才能做出合理的决策。

注意事项：提示词里的控件列表顺序会影响LLM的决策。我试过按位置从上到下排序，也试过按重要性排序，实测下来按位置排序更符合LLM的“阅读习惯”，决策准确率略高。另外，控件列表不要超过20个，太多了LLM会“看花眼”，需要做截断或者分页。

4.2 行动空间的约束与安全边界

让LLM自主操作移动设备，听起来很酷，但风险也很大。如果LLM决策失误，可能会点到不该点的地方，比如删除数据、发送消息、产生费用。ARTEMIS在Agentic模式里设置了多层安全边界。

第一层是操作白名单。只有白名单里的操作类型才允许执行，比如click、input、swipe、back。像“卸载应用”“清除数据”这类危险操作默认被禁用。

第二层是控件黑名单。某些控件被标记为不可操作，比如“删除”“支付”“退出登录”这些。黑名单可以由测试人员配置，也可以由系统根据控件文本自动识别。

第三层是操作频率限制。同一个控件在短时间内被连续点击超过N次，就触发熔断，暂停Agentic模式，转人工确认。这个机制能有效防止LLM陷入循环。

第四层是敏感操作二次确认。对于输入密码、点击支付按钮这类操作，ARTEMIS会先截图存档，再执行操作，方便事后审计。

这些安全边界在实际项目里非常必要。我在早期实验里就遇到过LLM反复点击同一个按钮的情况，因为没有频率限制，白白浪费了好几分钟的推理时间。加上熔断机制之后，这类问题基本消失了。

4.3 多步推理与状态追踪

Agentic模式的另一个难点是多步推理。一个复杂的测试任务可能需要几十步操作，LLM需要记住之前做了什么、当前处于什么状态、下一步该做什么。ARTEMIS用了状态机+记忆摘要的方式来管理。

状态机定义了测试任务的关键状态节点，比如“未登录”“已登录”“在首页”“在设置页”。每次操作后，ARTEMIS会根据当前界面判断处于哪个状态，并更新状态机的状态。如果状态偏离了预期路径，就触发告警。

记忆摘要则是把历史操作压缩成简短的文本，塞进提示词里。比如“已输入用户名，已输入密码，已点击登录按钮，当前在首页”。这样LLM不需要看完整的历史记录，就能知道当前进展。摘要的生成也是用LLM做的，但用的是小模型，成本很低。

这个状态追踪机制还有一个好处是支持断点续测。如果测试中途因为网络问题或者设备问题中断了，ARTEMIS可以根据状态机的记录，从断点处继续执行，而不需要从头再来。这在跑长流程测试用例的时候非常实用。

5. 两种模式的调度与协同机制

5.1 模式选择的决策依据

ARTEMIS的调度层负责决定什么时候用Direct模式，什么时候用Agentic模式。这个决策不是随机的，而是基于几个明确的依据。

第一个依据是测试任务的确定性。如果测试步骤是预先定义好的、流程固定的，就用Direct模式。如果测试任务是探索性的、需要根据界面反馈动态调整的，就用Agentic模式。

第二个依据是界面的稳定性。如果目标应用的界面结构稳定、控件定位容易，Direct模式就够了。如果界面变化频繁、控件难以定位，Agentic模式的适应性更强。

第三个依据是性能要求。如果测试用例需要在短时间内跑完，比如CI流水线里的冒烟测试，优先用Direct模式。如果对时间不敏感，比如夜间的全量回归，可以用Agentic模式做更深入的探索。

第四个依据是历史执行数据。ARTEMIS会记录每个测试用例的历史执行情况，如果某个用例用Direct模式经常失败，调度层会自动切换到Agentic模式。这种基于数据的自适应调度，比人工配置要智能得多。

5.2 混合执行的实际案例

我拿一个电商应用的测试用例来举例，说明混合执行是怎么工作的。

这个测试用例的目标是“验证用户从搜索商品到下单的完整流程”。整个流程可以拆成几个阶段：

• 阶段一：登录。这是固定流程，用Direct模式。输入用户名密码，点击登录，验证首页出现。整个过程5秒内完成。
• 阶段二：搜索商品。搜索关键词是固定的，但搜索结果列表的排序可能变化。这里用Direct模式输入关键词，但点击哪个商品用Agentic模式决策，因为需要根据商品名称、价格、评分来选择。
• 阶段三：加入购物车。这是固定流程，用Direct模式。点击加入购物车按钮，验证购物车数量变化。
• 阶段四：结算下单。结算流程涉及地址选择、支付方式选择、优惠券选择，这些选项的状态可能因用户账号而异。这里用Agentic模式，让LLM根据当前页面状态自主决策。
• 阶段五：订单验证。验证订单是否创建成功，用Direct模式检查订单列表。

这个混合执行的方案，比全程用Direct模式覆盖率更高，比全程用Agentic模式速度快了将近一倍。ARTEMIS的调度层会自动做这种拆分，测试人员只需要描述测试目标，不需要手动指定每个阶段用什么模式。

5.3 模式切换的触发条件与开销

模式切换不是没有代价的。从Direct切到Agentic，需要重新初始化Agentic模式的上下文，包括加载提示词模板、建立状态机、采集当前屏幕信息。这个开销大概在1到2秒。从Agentic切回Direct，开销小一些，主要是保存Agentic的状态和清理上下文。

ARTEMIS在调度时会把切换开销考虑进去。如果预计Agentic模式只需要执行一两步就切回Direct，那可能不划算，不如全程用Direct加视觉兜底。调度层有一个简单的成本模型，估算两种模式的预期耗时，选择总耗时更低的方案。

实操心得：模式切换的频率不宜过高。我见过一个配置，每个操作都在两种模式之间切换，结果切换开销占了总时间的40%。后来把切换粒度调整为“按阶段切换”，性能明显改善。建议在测试用例设计阶段就规划好模式的使用，而不是完全依赖调度层的动态决策。

6. 实际部署中的常见问题与排查技巧

6.1 设备兼容性问题

移动端自动化测试绕不开设备兼容性。ARTEMIS虽然做了抽象，但不同设备、不同系统版本的表现还是有差异。我整理了几个常见问题和应对方法。

设备兼容性问题的排查，最有效的方法是保留现场。ARTEMIS在每次操作失败时都会自动保存截图、UI树、日志，方便事后分析。我建议把这些现场数据按测试用例和时间戳组织好，出问题的时候能快速定位。

6.2 LLM推理的稳定性问题

Agentic模式依赖LLM推理，而LLM的输出不是100%稳定的。同样的输入，可能这次输出正确，下次就输出错误。ARTEMIS用了几个策略来提升稳定性。

温度参数调低。Agentic模式的LLM调用温度设置为0.1到0.3，减少随机性。但温度也不能太低，太低了LLM会变得“死板”，遇到稍微不同的情况就不知道怎么办。

输出格式校验。LLM的输出必须符合预定义的JSON格式，不符合就重试。重试时会在提示词里加上“上次输出格式错误，请严格按照JSON格式输出”的提醒。

多候选投票。对于关键决策，ARTEMIS会调用LLM三次，取多数结果。这个策略能把决策准确率提升5到10个百分点，但成本也翻了三倍。一般只在关键步骤上用。

规则兜底。如果LLM连续多次输出无效结果，就降级到规则引擎，用预定义的启发式规则做决策。虽然不够智能，但至少能保证测试继续跑下去。

6.3 测试脚本的维护策略

不管是Direct模式还是Agentic模式，测试脚本的维护都是个长期工作。ARTEMIS在这方面提供了一些辅助功能，但工具只是辅助，关键还是要有好的维护策略。

我的经验是分层维护。把测试脚本分成三层：基础操作层、业务逻辑层、测试用例层。基础操作层封装点击、输入、滑动这些原子操作，这部分最稳定，很少改动。业务逻辑层封装登录、搜索、下单这些业务动作，应用改版时可能需要调整。测试用例层是具体的测试场景，变化最频繁。

ARTEMIS的DSL支持这种分层，可以在DSL里引用其他DSL片段。这样应用改版时，只需要修改业务逻辑层的DSL，测试用例层不用动。这个设计能大幅降低维护成本。

另外，定期回归很重要。我建议每周跑一次全量回归，及时发现因为应用更新导致的脚本失效。ARTEMIS的调度层会根据历史数据自动标记“脆弱”的测试用例，这些用例需要优先检查和修复。

7. 性能优化与成本控制的实战经验

7.1 截图与UI树采集的优化

截图和UI树采集是移动端自动化测试里最频繁的操作，优化这两项能显著提升整体性能。

截图的优化点主要有三个。第一是降低截图质量。Agentic模式用的截图不需要原图，压缩到70%质量、缩放50%大小，LLM照样能看懂，但传输和处理时间能减少一半以上。第二是增量截图。如果两次截图之间界面变化不大，只传输变化区域。这个需要设备端支持，Android的MediaProjection API可以实现。第三是截图缓存。同一个界面状态下的截图只采集一次，后续复用。

UI树的优化主要是裁剪。完整的UI树可能包含几百个节点，但真正有用的可交互控件可能只有十几个。ARTEMIS在采集UI树后，会做一次过滤，只保留可点击、可输入、可滚动的节点，以及它们的父节点。这样UI树的大小能减少80%以上。

7.2 LLM调用的成本控制

Agentic模式的成本主要来自LLM调用。控制成本有几个实用的方法。

用小模型做粗筛。不是所有决策都需要大模型。ARTEMIS先用一个小模型（比如7B参数级别的）做初步决策，如果小模型的置信度高于阈值，就直接采用；如果置信度低，再调用大模型。这个策略能在保证准确率的前提下，把大模型调用量减少60%以上。

缓存决策结果。相似的界面状态和测试目标，决策结果往往是一样的。ARTEMIS会把决策结果缓存起来，下次遇到相似情况直接复用。缓存的key是界面特征的哈希值，相似度匹配用向量检索。

批量推理。如果多个测试用例同时跑，可以把它们的LLM调用合并成一批，一次性发给模型。批量推理的吞吐量比单条调用高得多，成本也更低。

设置预算上限。每个测试用例设置一个LLM调用次数上限，超过了就降级到Direct模式或者直接失败。这个机制能防止某个用例因为LLM陷入循环而烧掉大量预算。

7.3 并行执行与资源调度

移动端自动化测试通常需要多台设备并行跑，才能满足CI的时间要求。ARTEMIS支持多设备并行，但并行也带来了资源调度的问题。

设备分配策略。ARTEMIS会根据测试用例的设备需求（比如需要Android还是iOS、需要什么系统版本）来分配设备。分配算法用的是贪心策略，优先把测试用例分配给最匹配的设备。

任务队列管理。所有待执行的测试用例进入一个队列，调度器从队列里取任务分配给空闲设备。队列支持优先级，冒烟测试的优先级高于全量回归。

资源隔离。每台设备上的测试进程相互隔离，一个进程崩溃不影响其他进程。ARTEMIS用容器化技术做隔离，每个测试任务跑在独立的容器里。

失败重试。测试用例失败后，会自动重新排队，分配给另一台设备重试。重试次数可配置，默认是2次。如果重试都失败，才标记为最终失败。

实操心得：并行执行时，设备发热和性能下降是常见问题。我建议在设备之间加散热风扇，并且每跑完一批测试就让设备休息几分钟。另外，并行度不要设得太高，一般每台控制机管理4到6台设备比较合适，太多了控制机本身会成为瓶颈。

8. 从ARTEMIS架构中能学到什么

ARTEMIS的双模式架构给我最大的启发是：不要试图用一种方案解决所有问题。移动端自动化测试的场景太复杂了，有的场景需要速度，有的场景需要智能，有的场景需要稳定性。把这些需求拆开，用不同的模式分别满足，比强行做一个“全能”的方案要务实得多。

Direct模式和Agentic模式的划分，本质上是在确定性和灵活性之间做权衡。Direct模式牺牲了一部分灵活性，换来了速度和稳定性；Agentic模式牺牲了一部分速度和稳定性，换来了对复杂场景的适应能力。两种模式共享底层能力，通过调度层协同工作，整体效果比单一模式好得多。

这个思路不仅适用于移动端自动化测试，也适用于其他LLM落地的场景。比如在客服系统里，简单问题用规则引擎快速回答，复杂问题转给LLM处理；在代码生成里，模板化的代码用代码片段库，需要推理的部分用LLM。这种“分层处理”的思路，是LLM工程化落地的一个通用模式。

我在自己的项目里借鉴ARTEMIS的架构，搭了一套类似的测试系统。Direct模式的部分用传统的UI测试框架做底座，Agentic模式的部分用LLM做决策，中间加了一个调度层做模式切换。跑下来的效果比之前纯脚本的方案好了不少，测试用例的通过率从70%多提升到了90%以上，维护成本也降下来了。

当然，ARTEMIS也不是银弹。它的Agentic模式在复杂界面上的决策准确率还有提升空间，双模式切换的开销在某些场景下也比较明显。但作为一个架构参考，它的设计思路是值得学习的。特别是对于那些正在探索LLM在测试领域落地的团队，ARTEMIS的双模式架构提供了一个很好的起点。

最后分享一个我在实践中总结的小技巧：先用Direct模式跑通全流程，再逐步引入Agentic模式。不要一上来就全用Agentic，那样调试成本太高。先把Direct模式的骨架搭好，确保基础流程能跑通，然后在那些Direct模式搞不定的环节上，有针对性地引入Agentic模式。这样渐进式的落地，风险可控，效果也更容易验证。