1. 移动端自动化测试的现状与ARTEMIS的切入点移动端自动化测试这件事做过的人都懂它跟Web端自动化完全是两个世界的玩法。Web端你有一套相对稳定的DOM结构可以依赖元素定位、状态判断、断言逻辑都有一套成熟的体系。但到了移动端尤其是Android生态碎片化程度高得离谱——不同厂商的ROM、不同的分辨率、不同的系统版本、不同的输入法行为甚至同一个应用在不同设备上的渲染结果都可能存在细微差异。这就导致一个很现实的问题你写好的测试脚本在A设备上跑得好好的换到B设备上可能就各种超时、找不到元素、点击偏移。传统方案是怎么应对的主流做法无非两种一种是基于UI控件树的定位方式比如通过无障碍节点或者控件ID来查找元素另一种是基于图像识别的方案截屏后在画面上做模板匹配或者特征点匹配。这两种方案各有各的痛点。控件树方案依赖应用的可访问性支持很多应用尤其是游戏或者自绘UI的应用控件树信息非常稀疏甚至完全不可用。图像识别方案则对分辨率、主题、动效、弹窗极其敏感维护成本随着用例数量增长呈指数级上升。ARTEMIS这个项目要解决的核心问题就是在移动端自动化测试中引入大语言模型的能力让测试脚本具备一定的“理解”和“自适应”能力而不是死板地依赖固定的定位器或者像素坐标。它的双模式架构本质上是在回答一个问题当LLM作为测试执行的核心决策者时如何平衡执行效率和决策准确性这个问题的答案直接决定了这套方案能不能在真实的生产环境中跑起来而不是停留在Demo阶段。我接触过不少团队在尝试LLM自动化的组合大多数都卡在两个地方一是LLM调用延迟太高一个简单的点击操作要等好几秒二是LLM的输出不稳定同样的界面描述两次调用可能给出不同的操作决策。ARTEMIS的双模式架构恰恰是在这两个痛点上做了针对性的设计。接下来我会从架构设计、模式切换逻辑、核心实现细节、实操踩坑经验几个维度把这套方案拆开来讲清楚。2. 双模式架构的整体设计与选型逻辑2.1 为什么需要两种模式先说说ARTEMIS为什么不是单一模式。如果只用LLM来做所有决策理论上最灵活但实际上根本跑不动。我做过一个粗略的测算在一个中等复杂度的移动应用上完成一次完整的业务流程测试比如登录→搜索→加购→下单→支付大概需要执行30到50个操作步骤。如果每个步骤都调用一次LLM来做界面理解和决策按照当前主流模型的响应速度单次调用平均2到4秒光LLM调用就要花掉60到200秒。再加上截图、图像预处理、结果解析的时间一个用例跑下来可能要三五分钟。这还没算上LLM输出不稳定导致的重复尝试。反过来如果完全不用LLM那就退回到了传统的控件树或者图像匹配方案失去了引入LLM的意义。所以ARTEMIS的设计思路是把操作分成两类一类是“确定性操作”一类是“不确定性操作”。确定性操作指的是那些目标明确、定位方式稳定的步骤比如“点击屏幕底部导航栏的首页按钮”“在搜索框中输入关键词”“滑动列表直到出现某个文本”。这些操作完全可以用传统方式高效完成不需要LLM介入。不确定性操作指的是那些需要理解界面语义、处理动态变化、或者应对异常情况的步骤比如“判断当前页面是否加载完成”“识别弹窗类型并决定是否关闭”“在控件树信息缺失的情况下找到目标元素”。这些才是LLM真正能发挥价值的地方。基于这个分类ARTEMIS设计了两种模式快速模式和智能模式。快速模式走传统自动化路径执行速度快、资源消耗低适合处理确定性操作。智能模式走LLM决策路径灵活性强、适应面广适合处理不确定性操作。两种模式共享同一套设备控制层和结果校验层区别只在于“决策引擎”不同。2.2 模式切换的触发条件模式切换不是随机的ARTEMIS定义了一套触发规则。我把它归纳为三类触发条件第一类是定位失败触发。当快速模式尝试用控件树定位元素失败或者图像匹配置信度低于阈值时自动升级到智能模式。这个逻辑很直观传统方式搞不定了让LLM来试试。第二类是语义判断触发。有些步骤本身就需要语义理解比如“确认当前页面显示的是商品详情页而非列表页”。这种判断用传统方式很难做因为页面结构可能千变万化但用LLM来看截图或者控件树摘要就能给出相对可靠的判断。这类步骤在用例编写时就会标记为“需要智能模式”。第三类是异常处理触发。当测试执行过程中出现预期外的弹窗、广告、权限请求、网络异常提示时快速模式的脚本通常没有预设处理逻辑这时候切换到智能模式让LLM根据当前界面内容决定如何处理。这个触发机制在实际跑用例时特别有用因为移动端应用的弹窗行为实在太不可控了。注意模式切换的触发条件需要根据具体应用的稳定程度来调整。如果一个应用的UI非常稳定控件树信息完整那么智能模式的触发频率可以调低以提升整体执行速度。反之如果应用UI变动频繁或者大量使用自绘控件那么智能模式的触发频率就需要调高。2.3 双模式架构的分层设计ARTEMIS的整体架构分为四层我从下往上依次说明设备控制层是最底层负责与移动设备进行通信。这一层封装了ADB命令、截图获取、触摸事件注入、文本输入等基础能力。不管是快速模式还是智能模式最终的操作执行都要落到这一层。这一层的设计要点是稳定性和响应速度因为它是所有操作的基础通道。感知层负责获取当前界面的状态信息。在快速模式下感知层主要提取控件树信息包括节点的类名、资源ID、文本内容、坐标范围、可点击属性等。在智能模式下感知层除了控件树信息还会获取屏幕截图并对截图进行必要的预处理比如缩放、压缩、格式转换以便传给LLM做视觉理解。感知层的设计难点在于信息取舍控件树信息太详细会消耗大量Token太简略又可能导致LLM判断失误。ARTEMIS的做法是提取一个“精简控件树”只保留可见的、可交互的、有文本内容的节点并且对节点属性做裁剪只保留对决策有用的字段。决策层是双模式架构的核心。快速模式的决策层是一个基于规则的执行引擎它按照预设的步骤序列依次执行定位、操作、校验。智能模式的决策层是一个LLM调用模块它把感知层获取的界面信息、当前测试目标、历史操作记录组装成Prompt发送给LLM解析LLM返回的操作指令然后交给设备控制层执行。决策层还需要处理两种模式之间的切换逻辑以及切换时的上下文传递。编排层是最上层负责测试用例的解析、步骤调度、结果记录、报告生成。编排层不关心具体用哪种模式执行它只负责按照用例定义驱动整个测试流程。这种分层设计的好处是模式切换对上层透明用例编写者不需要关心底层用的是哪种决策方式只需要定义好测试步骤和预期结果即可。3. 快速模式的实现细节与优化要点3.1 控件树定位的增强策略快速模式的核心是控件树定位但原生控件树定位有几个常见的坑一是元素属性不稳定比如某些应用每次启动时生成的资源ID会变化二是元素层级过深导致XPath表达式冗长且脆弱三是存在多个匹配元素无法确定应该操作哪一个。ARTEMIS在原生定位基础上做了几层增强。第一层是多属性联合定位不依赖单一属性而是组合使用文本内容、类名、坐标范围、兄弟节点关系等多个维度来定位元素。比如一个按钮如果它的资源ID不稳定但它的文本内容是固定的且它位于某个特定容器的右下角那么就可以用“文本内容相对位置”来定位。第二层是定位器优先级排序。对于同一个目标元素ARTEMIS会生成多个候选定位器并按照稳定性排序。资源ID最稳定优先级最高其次是文本内容再次是相对位置最后是绝对坐标。执行时从高优先级开始尝试失败则降级到下一个。这个策略在实际使用中效果很明显大部分元素都能在前两个优先级内定位成功。第三层是定位结果缓存。对于在多个用例中重复出现的元素比如底部导航栏的各个TabARTEMIS会缓存成功的定位器后续用例直接复用减少重复查找的开销。缓存会设置过期时间并且在连续失败时自动失效避免因为UI改版导致缓存污染。3.2 图像匹配的加速技巧快速模式中也会用到图像匹配主要用于处理那些控件树信息缺失的场景。但图像匹配的计算量不小尤其是在高分辨率屏幕上做全屏模板匹配单次耗时可能超过一秒。ARTEMIS用了几个技巧来加速第一个技巧是区域限定。不总是做全屏匹配而是根据业务逻辑限定搜索区域。比如要点击“确认”按钮通常它出现在屏幕底部或者弹窗的右下角那么就可以只在屏幕下半部分做匹配。区域限定可以把搜索空间缩小到原来的四分之一甚至更小匹配速度提升非常明显。第二个技巧是多尺度模板。移动端设备分辨率差异大同一个按钮在不同设备上的像素尺寸可能不同。ARTEMIS会预先对模板图片做多尺度缩放生成一组不同尺寸的模板匹配时并行使用这些模板取最高置信度的结果。这样就不需要针对每种分辨率单独准备模板图片。第三个技巧是特征点匹配兜底。当模板匹配置信度低于阈值时切换到特征点匹配比如ORB或者SIFT。特征点匹配对缩放、旋转、亮度变化更鲁棒但计算量更大。所以ARTEMIS把它作为兜底方案只在模板匹配失败时启用。3.3 快速模式的执行流程快速模式执行一个测试步骤的完整流程是这样的解析步骤定义提取目标元素描述和操作类型点击、输入、滑动等。从定位器缓存中查找是否有可用的定位器如果有则直接使用。如果没有缓存则生成候选定位器列表按优先级排序。依次尝试每个定位器直到成功定位到元素。如果所有定位器都失败尝试图像匹配。如果图像匹配也失败触发模式切换升级到智能模式。定位成功后执行对应的操作。操作完成后进行结果校验比如检查页面是否跳转、元素是否存在。如果校验通过记录成功并继续下一步如果校验失败根据失败类型决定是重试、切换模式还是标记用例失败。这个流程看起来步骤不少但实际执行时大部分步骤都能在毫秒级完成因为定位器缓存和优先级排序大大减少了查找时间。我实测下来一个稳定的点击操作从开始定位到操作完成平均耗时在200到500毫秒之间完全能满足大部分测试场景的效率要求。实操心得快速模式的定位器缓存一定要设置合理的失效策略。我遇到过一种情况应用更新后某个按钮的资源ID变了但缓存里还是旧ID导致连续多个用例失败。后来加了“连续失败三次自动清空缓存”的机制问题就解决了。另外缓存最好按应用版本号隔离应用更新后自动失效旧缓存。4. 智能模式的LLM集成与决策逻辑4.1 Prompt工程的核心设计智能模式的效果好坏很大程度上取决于Prompt的设计。ARTEMIS的Prompt结构包含四个部分角色定义部分告诉LLM它扮演的是什么角色比如“你是一个移动端自动化测试执行引擎负责根据当前界面状态决定下一步操作”。角色定义要简洁明确不需要长篇大论但必须让LLM理解它的任务边界。界面描述部分是把感知层获取的信息转换成LLM能理解的格式。这里有个关键取舍是传截图还是传控件树文本ARTEMIS的做法是两者都传但根据场景调整侧重。对于视觉信息重要的场景比如判断页面布局、识别图标含义以截图为主对于文本信息重要的场景比如读取列表内容、判断按钮文字以控件树文本为主。截图会做压缩处理通常缩放到宽度720像素左右既能保留足够的视觉信息又能控制Token消耗。任务描述部分是当前测试步骤的目标比如“在当前页面找到搜索入口并点击”。任务描述要具体但不啰嗦避免给LLM太多无关信息。输出格式约束部分是最关键的。LLM的输出必须是结构化的否则解析起来非常麻烦。ARTEMIS定义了一套JSON格式的输出规范包含操作类型、目标元素描述、操作参数、置信度等字段。Prompt中会明确要求LLM按照这个格式输出并且给出示例。实测下来只要格式约束写得清楚主流LLM都能稳定输出合规的JSON。4.2 多模态输入的取舍策略智能模式支持多模态输入但并不是每次调用都传截图。ARTEMIS根据步骤类型来决定输入模态步骤类型主要输入辅助输入理由元素定位控件树文本截图可选控件树文本Token消耗低定位信息足够页面判断截图控件树摘要页面类型判断依赖视觉布局信息异常处理截图控件树摘要弹窗识别需要视觉信息内容提取控件树文本无文本内容直接从控件树读取更准确操作决策截图控件树历史操作记录综合判断需要多维度信息这个取舍策略的核心逻辑是能用文本解决的就不用图像必须用图像的才用图像。因为图像输入的Token消耗远高于文本而且图像理解的计算延迟也更高。我做过对比测试纯文本输入的LLM调用平均耗时1.5秒带图像输入的调用平均耗时3.2秒差距非常明显。4.3 决策结果的解析与校验LLM返回的JSON结果需要经过严格的解析和校验才能执行。ARTEMIS的解析流程包括第一步是格式校验。检查返回内容是否是合法JSON字段是否完整字段类型是否正确。如果格式不合法会尝试从返回文本中提取JSON片段因为有些LLM会在JSON前后加一些解释性文字。第二步是语义校验。检查操作类型是否在支持的操作列表中目标元素描述是否为空坐标是否在屏幕范围内。这一步能过滤掉大部分明显不合理的输出。第三步是置信度过滤。LLM在输出中会给出一个置信度分数ARTEMIS设置了一个阈值默认0.7低于阈值的决策会被拒绝转而触发重试或者降级处理。第四步是执行前预检。在实际执行操作之前ARTEMIS会做一次快速预检比如检查目标坐标位置是否确实存在可交互元素检查输入文本是否包含非法字符。这一步能避免一些低级错误。如果解析或校验失败ARTEMIS会进行有限次数的重试。重试时会调整Prompt比如增加更明确的格式要求或者补充更多上下文信息。如果重试仍然失败则标记该步骤为“智能模式执行失败”并根据用例配置决定是跳过还是终止。4.4 上下文管理与Token控制智能模式的一个隐性成本是Token消耗。每次LLM调用都需要传入界面描述、任务描述、历史记录等信息如果不加控制Token数量会迅速膨胀。ARTEMIS用了几个策略来控制Token历史记录截断只保留最近N步的操作记录默认5步更早的记录做摘要处理。摘要只保留关键信息比如“已点击搜索按钮”“已输入关键词”不保留完整的界面描述。界面描述精简控件树信息只保留可见节点节点属性只保留类名、文本、坐标、可交互标志四个字段。截图做有损压缩质量参数设为60%到70%在视觉信息和文件大小之间取平衡。Prompt模板复用角色定义和输出格式约束部分是固定的可以缓存复用不需要每次重新生成。只有界面描述和任务描述部分是动态的。按需调用不是每个步骤都需要LLM介入只有触发条件满足时才调用。这个前面已经说过是控制成本的最关键策略。我粗略算过一笔账一个包含50个步骤的测试用例如果全部走智能模式大概需要调用LLM 50次Token消耗在10万到15万之间。如果采用双模式架构只有大约10到15个步骤需要智能模式Token消耗降到2万到3万成本降低了70%以上而测试覆盖率基本不受影响。5. 双模式协同的实操流程与配置方法5.1 环境准备与依赖安装在开始配置ARTEMIS之前需要准备好基础环境。我按照实际搭建过程来梳理设备端准备一台Android设备或者模拟器开启开发者选项和USB调试。建议使用Android 8.0以上版本因为部分控件树API在低版本上行为不一致。设备分辨率建议在1080x1920以上过低的分辨率会影响图像匹配的准确性。主机端准备Python 3.9以上版本安装ADB工具并确保设备能正常连接。ADB的版本建议用较新的老版本在某些设备上会有兼容性问题。可以通过adb devices命令确认设备连接状态。Python依赖安装ARTEMIS的核心依赖包括UI自动化库、图像处理库、HTTP客户端库等。安装命令如下pip install uiautomator2 opencv-python pillow requests numpy如果要用到更高级的图像匹配功能还可以安装scikit-imagepip install scikit-imageLLM服务配置智能模式需要调用LLM服务需要配置API地址和密钥。ARTEMIS支持多种LLM后端配置方式是在配置文件中指定服务类型和认证信息。建议将密钥放在环境变量中不要硬编码在代码里。5.2 用例定义与模式标记ARTEMIS的测试用例用YAML格式定义每个步骤可以标记执行模式。下面是一个示例test_case: 商品搜索流程 steps: - action: launch_app package: com.example.shop mode: fast - action: click target: 搜索框 locator: - type: resource_id value: com.example.shop:id/search_box - type: text value: 搜索 mode: fast - action: input target: 搜索框 text: 无线耳机 mode: fast - action: click target: 搜索按钮 locator: - type: text value: 搜索 mode: fast - action: verify target: 搜索结果页面 description: 确认当前页面显示的是搜索结果列表且包含至少一个商品条目 mode: smart - action: click target: 第一个商品 mode: smart fallback: fast这个用例中前四步都是确定性操作标记为fast模式。第五步需要判断页面类型标记为smart模式。第六步点击第一个商品这个操作在控件树中可能没有稳定的定位器因为商品列表是动态渲染的所以也标记为smart模式但设置了fallback: fast意思是如果智能模式失败尝试用快速模式的图像匹配兜底。5.3 模式切换的配置参数ARTEMIS提供了一组配置参数来控制模式切换行为这些参数可以在全局配置文件中设置也可以在每个用例中覆盖参数名默认值说明fast_mode_timeout5s快速模式单步超时时间smart_mode_timeout15s智能模式单步超时时间smart_trigger_on_failuretrue快速模式失败时是否自动切换智能模式smart_confidence_threshold0.7智能模式决策的最低置信度max_retry_per_step3单步最大重试次数llm_max_tokens2048单次LLM调用的最大输出Token数screenshot_quality65截图压缩质量1-100history_length5传给LLM的历史操作记录步数这些参数的调整需要根据实际应用的特点来定。比如一个UI非常稳定的应用可以把smart_trigger_on_failure设为false完全依赖快速模式只在明确标记为smart的步骤才调用LLM。反之一个UI变动频繁的应用可以把smart_trigger_on_failure设为true并且降低smart_confidence_threshold让更多步骤有机会走智能模式。5.4 执行监控与日志记录ARTEMIS在执行过程中会记录详细的日志包括每一步使用的模式、定位耗时、操作耗时、LLM调用耗时、Token消耗、决策结果等。这些日志对于后续优化非常重要。我通常会把日志分成三个级别INFO级别记录每一步的执行摘要包括步骤序号、模式、结果、耗时DEBUG级别记录详细的定位过程、LLM输入输出、图像匹配得分等ERROR级别只记录失败步骤和异常信息。在实际使用中我建议默认开启INFO级别在排查问题时临时开启DEBUG级别。DEBUG级别的日志量非常大一个50步的用例可能产生几万行日志长期开启会影响性能。日志中有一个关键指标需要特别关注智能模式触发率。这个指标反映了快速模式的稳定性。如果触发率持续偏高比如超过30%说明快速模式的定位器需要优化或者应用的UI变动太频繁需要考虑调整测试策略。如果触发率过低比如低于5%可能说明智能模式的触发条件设置得太保守有些本该由LLM处理的场景被快速模式勉强处理了虽然当时没报错但可能存在隐患。6. 常见问题排查与避坑经验实录6.1 快速模式定位失败的典型原因快速模式定位失败是最常见的问题我整理了几种典型情况和对应的排查思路情况一资源ID变化。有些应用在每次启动时会重新生成资源ID导致基于资源ID的定位器完全失效。排查方法是连续启动应用多次对比同一元素的资源ID是否一致。如果确实变化需要改用文本内容或者相对位置定位。情况二元素不可见但存在于控件树中。有些元素虽然在控件树中存在但实际被遮挡或者透明度为0点击操作会失败。排查方法是检查元素的visible属性和bounds坐标确认元素确实在屏幕可见区域内。ARTEMIS在定位成功后会做一次可见性检查如果元素不可见会尝试滚动屏幕或者等待元素出现。情况三WebView内元素定位不到。如果应用使用了WebViewWebView内部的元素在原生控件树中可能只显示为一个整体节点无法定位到内部的具体元素。这种情况下需要开启WebView调试或者切换到智能模式让LLM通过截图来定位。情况四动态加载内容。列表类页面通常采用懒加载初始时只渲染可见区域的元素滚动后才加载更多。如果定位器查找的元素在初始视口之外会定位失败。ARTEMIS的处理方式是先尝试滚动查找如果滚动到底部仍未找到则触发模式切换。6.2 智能模式决策异常的排查方法智能模式的问题通常更隐蔽因为LLM的输出看起来可能“有道理”但实际上不符合测试预期。我遇到过几种典型情况情况一LLM理解偏差。比如任务描述是“点击搜索按钮”但界面上有两个搜索相关的按钮一个是搜索框旁边的放大镜图标一个是底部的搜索TabLLM可能选错了目标。排查方法是检查Prompt中的任务描述是否足够明确必要时增加目标元素的特征描述比如“点击搜索框右侧的放大镜图标”。情况二截图信息不足。如果截图压缩得太厉害LLM可能看不清界面细节导致决策错误。排查方法是临时提高截图质量参数对比决策结果是否改善。如果确实是截图质量问题需要调整压缩参数在Token消耗和决策准确性之间找平衡。情况三LLM输出格式不合规。虽然Prompt中明确了JSON格式要求但LLM偶尔还是会输出带额外文字的内容。ARTEMIS的解析器做了容错处理会尝试从返回文本中提取JSON片段。如果提取失败会触发重试。如果重试多次仍然失败建议检查Prompt中的格式约束是否足够清晰或者考虑换一个对格式遵循更好的LLM。情况四决策置信度普遍偏低。如果LLM返回的置信度经常低于阈值说明LLM对当前场景的判断不够确定。可能的原因是界面信息太复杂或者任务描述太模糊。解决方法是精简界面描述突出关键信息同时把任务描述写得更具体。6.3 模式切换时的上下文丢失问题模式切换时快速模式和智能模式之间的上下文传递是一个容易被忽视的问题。快速模式执行到一半切换到智能模式智能模式需要知道之前执行了哪些步骤、当前处于什么状态否则可能做出错误的决策。ARTEMIS的解决方案是维护一个共享的执行上下文对象包含当前用例信息、已执行步骤列表、当前页面状态摘要、设备信息等。快速模式和智能模式都从这个上下文读取信息也都向这个上下文写入执行结果。切换模式时上下文对象保持不变只是决策引擎换了。这里有一个实操中的坑快速模式记录的页面状态摘要可能不够详细智能模式接手后需要重新感知界面。如果重新感知的耗时太长会影响整体执行效率。ARTEMIS的做法是快速模式在每次操作后都会缓存一份最新的界面快照控件树截图切换模式时直接复用这份快照避免重复感知。6.4 常见问题速查表问题现象可能原因排查方法解决方案快速模式定位超时定位器失效或元素未加载检查控件树中是否存在目标元素更新定位器或增加等待时间智能模式决策错误Prompt描述不清或截图质量差查看LLM输入输出日志优化Prompt或提高截图质量模式切换频繁快速模式稳定性差统计智能模式触发率优化快速模式定位器LLM调用超时网络问题或Token过多检查网络连接和Token数量减少输入Token或增加超时时间操作执行失败元素不可见或坐标偏移检查元素可见性和坐标范围增加滚动或调整坐标计算用例执行中断未处理的异常弹窗查看中断时的截图增加异常处理步骤或开启智能模式兜底避坑技巧在正式跑大批量用例之前先用少量用例做一轮“模式触发率”测试。具体做法是把所有步骤都标记为fast模式跑一遍完整用例统计有多少步骤触发了智能模式切换。如果触发率超过20%说明快速模式的定位器需要优化不要急着跑全量用例否则会浪费大量时间和Token。7. 性能调优与扩展思路7.1 执行速度的优化空间双模式架构的执行速度优化核心思路是“让快速模式处理更多步骤让智能模式处理更准”。具体来说有几个方向定位器自动修复当快速模式定位失败并切换到智能模式后智能模式成功定位到元素ARTEMIS会把智能模式的定位结果反向生成一个快速模式定位器加入定位器缓存。这样下次遇到同样的元素快速模式就能直接处理不需要再调用LLM。这个机制在实际使用中效果很好随着用例执行次数增加快速模式的覆盖率会逐步提升。并行执行对于不依赖同一设备状态的用例可以并行执行。ARTEMIS支持多设备并行每个设备独立运行用例共享LLM调用配额。并行执行时需要注意设备间的资源竞争比如ADB连接数限制、LLM服务的并发限制等。预热机制在正式执行用例之前先做一轮预热包括启动应用、加载基础页面、初始化定位器缓存等。预热可以减少正式执行时的冷启动开销。7.2 准确率的提升策略准确率提升的关键在于减少误判和漏判。ARTEMIS从几个方面入手多模型投票对于关键决策步骤可以同时调用两个不同的LLM对比它们的输出。如果一致则直接执行如果不一致则取置信度更高的结果或者触发人工确认。这个策略会增加成本但能显著提升关键步骤的准确率。规则兜底在智能模式之上再加一层规则校验。比如LLM决定点击某个坐标规则层会检查这个坐标是否在屏幕范围内、是否在可点击区域内、是否与当前任务相关。如果规则校验不通过则拒绝执行并触发重试。反馈学习记录每次智能模式决策的结果包括执行成功与否、是否达到预期效果。这些数据可以用来微调Prompt或者训练一个轻量级的分类器来预判LLM决策的可靠性。7.3 扩展到其他平台的可行性ARTEMIS目前主要针对Android平台但双模式架构的设计思路是可以扩展到其他平台的。扩展到iOS平台的主要挑战在于设备控制层的差异iOS的自动化控制需要通过WebDriverAgent或者类似的桥接方案控件树的结构和属性也与Android不同。但决策层和编排层的逻辑基本可以复用只需要替换感知层和设备控制层的实现。扩展到Web平台相对容易因为Web端的控件树DOM信息更丰富快速模式的定位能力更强。智能模式在Web端主要用于处理动态内容、验证码、复杂交互等场景。扩展到桌面应用Windows/macOS的难度较大因为桌面应用的控件树信息通常不如移动端和Web端规范可能需要更多依赖图像识别和LLM的视觉理解能力。7.4 成本控制的长期策略LLM调用成本是智能模式的主要开销。长期来看成本控制有几个方向模型分级不是所有智能模式步骤都需要用最强的模型。简单的页面判断可以用轻量级模型复杂的异常处理再用重量级模型。ARTEMIS支持按步骤配置模型等级在准确率和成本之间做精细化平衡。缓存复用对于重复出现的界面状态和决策场景可以缓存LLM的决策结果。比如“关闭弹窗”这个操作如果弹窗的样式和内容相似可以直接复用之前的决策不需要每次都调用LLM。缓存需要设置合理的失效策略避免因为界面变化导致缓存失效。本地化部署如果测试频率很高可以考虑在本地部署轻量级LLM减少对云端服务的依赖。本地部署的一次性投入较高但长期来看单位成本更低而且没有网络延迟问题。不过本地模型的决策能力通常不如云端大模型需要根据实际需求权衡。我个人在实际项目中的体会是双模式架构的价值不在于“用了LLM”而在于“知道什么时候该用LLM什么时候不该用”。很多团队一上来就追求全智能模式结果发现成本高、速度慢、稳定性差最后又退回到传统方案。ARTEMIS的思路更务实把LLM当作一个“专家系统”来用只在传统方法搞不定的场景下请它出马这样既能享受LLM的灵活性又能保持传统方案的高效和稳定。这个平衡点需要根据具体应用的特点来调整没有一刀切的标准但双模式架构提供了一个很好的起点。
1. 移动端自动化测试的现状与ARTEMIS的切入点移动端自动化测试这件事做过的人都懂它跟Web端自动化完全是两个世界的玩法。Web端你有一套相对稳定的DOM结构可以依赖元素定位、状态判断、断言逻辑都有一套成熟的体系。但到了移动端尤其是Android生态碎片化程度高得离谱——不同厂商的ROM、不同的分辨率、不同的系统版本、不同的输入法行为甚至同一个应用在不同设备上的渲染结果都可能存在细微差异。这就导致一个很现实的问题你写好的测试脚本在A设备上跑得好好的换到B设备上可能就各种超时、找不到元素、点击偏移。传统方案是怎么应对的主流做法无非两种一种是基于UI控件树的定位方式比如通过无障碍节点或者控件ID来查找元素另一种是基于图像识别的方案截屏后在画面上做模板匹配或者特征点匹配。这两种方案各有各的痛点。控件树方案依赖应用的可访问性支持很多应用尤其是游戏或者自绘UI的应用控件树信息非常稀疏甚至完全不可用。图像识别方案则对分辨率、主题、动效、弹窗极其敏感维护成本随着用例数量增长呈指数级上升。ARTEMIS这个项目要解决的核心问题就是在移动端自动化测试中引入大语言模型的能力让测试脚本具备一定的“理解”和“自适应”能力而不是死板地依赖固定的定位器或者像素坐标。它的双模式架构本质上是在回答一个问题当LLM作为测试执行的核心决策者时如何平衡执行效率和决策准确性这个问题的答案直接决定了这套方案能不能在真实的生产环境中跑起来而不是停留在Demo阶段。我接触过不少团队在尝试LLM自动化的组合大多数都卡在两个地方一是LLM调用延迟太高一个简单的点击操作要等好几秒二是LLM的输出不稳定同样的界面描述两次调用可能给出不同的操作决策。ARTEMIS的双模式架构恰恰是在这两个痛点上做了针对性的设计。接下来我会从架构设计、模式切换逻辑、核心实现细节、实操踩坑经验几个维度把这套方案拆开来讲清楚。2. 双模式架构的整体设计与选型逻辑2.1 为什么需要两种模式先说说ARTEMIS为什么不是单一模式。如果只用LLM来做所有决策理论上最灵活但实际上根本跑不动。我做过一个粗略的测算在一个中等复杂度的移动应用上完成一次完整的业务流程测试比如登录→搜索→加购→下单→支付大概需要执行30到50个操作步骤。如果每个步骤都调用一次LLM来做界面理解和决策按照当前主流模型的响应速度单次调用平均2到4秒光LLM调用就要花掉60到200秒。再加上截图、图像预处理、结果解析的时间一个用例跑下来可能要三五分钟。这还没算上LLM输出不稳定导致的重复尝试。反过来如果完全不用LLM那就退回到了传统的控件树或者图像匹配方案失去了引入LLM的意义。所以ARTEMIS的设计思路是把操作分成两类一类是“确定性操作”一类是“不确定性操作”。确定性操作指的是那些目标明确、定位方式稳定的步骤比如“点击屏幕底部导航栏的首页按钮”“在搜索框中输入关键词”“滑动列表直到出现某个文本”。这些操作完全可以用传统方式高效完成不需要LLM介入。不确定性操作指的是那些需要理解界面语义、处理动态变化、或者应对异常情况的步骤比如“判断当前页面是否加载完成”“识别弹窗类型并决定是否关闭”“在控件树信息缺失的情况下找到目标元素”。这些才是LLM真正能发挥价值的地方。基于这个分类ARTEMIS设计了两种模式快速模式和智能模式。快速模式走传统自动化路径执行速度快、资源消耗低适合处理确定性操作。智能模式走LLM决策路径灵活性强、适应面广适合处理不确定性操作。两种模式共享同一套设备控制层和结果校验层区别只在于“决策引擎”不同。2.2 模式切换的触发条件模式切换不是随机的ARTEMIS定义了一套触发规则。我把它归纳为三类触发条件第一类是定位失败触发。当快速模式尝试用控件树定位元素失败或者图像匹配置信度低于阈值时自动升级到智能模式。这个逻辑很直观传统方式搞不定了让LLM来试试。第二类是语义判断触发。有些步骤本身就需要语义理解比如“确认当前页面显示的是商品详情页而非列表页”。这种判断用传统方式很难做因为页面结构可能千变万化但用LLM来看截图或者控件树摘要就能给出相对可靠的判断。这类步骤在用例编写时就会标记为“需要智能模式”。第三类是异常处理触发。当测试执行过程中出现预期外的弹窗、广告、权限请求、网络异常提示时快速模式的脚本通常没有预设处理逻辑这时候切换到智能模式让LLM根据当前界面内容决定如何处理。这个触发机制在实际跑用例时特别有用因为移动端应用的弹窗行为实在太不可控了。注意模式切换的触发条件需要根据具体应用的稳定程度来调整。如果一个应用的UI非常稳定控件树信息完整那么智能模式的触发频率可以调低以提升整体执行速度。反之如果应用UI变动频繁或者大量使用自绘控件那么智能模式的触发频率就需要调高。2.3 双模式架构的分层设计ARTEMIS的整体架构分为四层我从下往上依次说明设备控制层是最底层负责与移动设备进行通信。这一层封装了ADB命令、截图获取、触摸事件注入、文本输入等基础能力。不管是快速模式还是智能模式最终的操作执行都要落到这一层。这一层的设计要点是稳定性和响应速度因为它是所有操作的基础通道。感知层负责获取当前界面的状态信息。在快速模式下感知层主要提取控件树信息包括节点的类名、资源ID、文本内容、坐标范围、可点击属性等。在智能模式下感知层除了控件树信息还会获取屏幕截图并对截图进行必要的预处理比如缩放、压缩、格式转换以便传给LLM做视觉理解。感知层的设计难点在于信息取舍控件树信息太详细会消耗大量Token太简略又可能导致LLM判断失误。ARTEMIS的做法是提取一个“精简控件树”只保留可见的、可交互的、有文本内容的节点并且对节点属性做裁剪只保留对决策有用的字段。决策层是双模式架构的核心。快速模式的决策层是一个基于规则的执行引擎它按照预设的步骤序列依次执行定位、操作、校验。智能模式的决策层是一个LLM调用模块它把感知层获取的界面信息、当前测试目标、历史操作记录组装成Prompt发送给LLM解析LLM返回的操作指令然后交给设备控制层执行。决策层还需要处理两种模式之间的切换逻辑以及切换时的上下文传递。编排层是最上层负责测试用例的解析、步骤调度、结果记录、报告生成。编排层不关心具体用哪种模式执行它只负责按照用例定义驱动整个测试流程。这种分层设计的好处是模式切换对上层透明用例编写者不需要关心底层用的是哪种决策方式只需要定义好测试步骤和预期结果即可。3. 快速模式的实现细节与优化要点3.1 控件树定位的增强策略快速模式的核心是控件树定位但原生控件树定位有几个常见的坑一是元素属性不稳定比如某些应用每次启动时生成的资源ID会变化二是元素层级过深导致XPath表达式冗长且脆弱三是存在多个匹配元素无法确定应该操作哪一个。ARTEMIS在原生定位基础上做了几层增强。第一层是多属性联合定位不依赖单一属性而是组合使用文本内容、类名、坐标范围、兄弟节点关系等多个维度来定位元素。比如一个按钮如果它的资源ID不稳定但它的文本内容是固定的且它位于某个特定容器的右下角那么就可以用“文本内容相对位置”来定位。第二层是定位器优先级排序。对于同一个目标元素ARTEMIS会生成多个候选定位器并按照稳定性排序。资源ID最稳定优先级最高其次是文本内容再次是相对位置最后是绝对坐标。执行时从高优先级开始尝试失败则降级到下一个。这个策略在实际使用中效果很明显大部分元素都能在前两个优先级内定位成功。第三层是定位结果缓存。对于在多个用例中重复出现的元素比如底部导航栏的各个TabARTEMIS会缓存成功的定位器后续用例直接复用减少重复查找的开销。缓存会设置过期时间并且在连续失败时自动失效避免因为UI改版导致缓存污染。3.2 图像匹配的加速技巧快速模式中也会用到图像匹配主要用于处理那些控件树信息缺失的场景。但图像匹配的计算量不小尤其是在高分辨率屏幕上做全屏模板匹配单次耗时可能超过一秒。ARTEMIS用了几个技巧来加速第一个技巧是区域限定。不总是做全屏匹配而是根据业务逻辑限定搜索区域。比如要点击“确认”按钮通常它出现在屏幕底部或者弹窗的右下角那么就可以只在屏幕下半部分做匹配。区域限定可以把搜索空间缩小到原来的四分之一甚至更小匹配速度提升非常明显。第二个技巧是多尺度模板。移动端设备分辨率差异大同一个按钮在不同设备上的像素尺寸可能不同。ARTEMIS会预先对模板图片做多尺度缩放生成一组不同尺寸的模板匹配时并行使用这些模板取最高置信度的结果。这样就不需要针对每种分辨率单独准备模板图片。第三个技巧是特征点匹配兜底。当模板匹配置信度低于阈值时切换到特征点匹配比如ORB或者SIFT。特征点匹配对缩放、旋转、亮度变化更鲁棒但计算量更大。所以ARTEMIS把它作为兜底方案只在模板匹配失败时启用。3.3 快速模式的执行流程快速模式执行一个测试步骤的完整流程是这样的解析步骤定义提取目标元素描述和操作类型点击、输入、滑动等。从定位器缓存中查找是否有可用的定位器如果有则直接使用。如果没有缓存则生成候选定位器列表按优先级排序。依次尝试每个定位器直到成功定位到元素。如果所有定位器都失败尝试图像匹配。如果图像匹配也失败触发模式切换升级到智能模式。定位成功后执行对应的操作。操作完成后进行结果校验比如检查页面是否跳转、元素是否存在。如果校验通过记录成功并继续下一步如果校验失败根据失败类型决定是重试、切换模式还是标记用例失败。这个流程看起来步骤不少但实际执行时大部分步骤都能在毫秒级完成因为定位器缓存和优先级排序大大减少了查找时间。我实测下来一个稳定的点击操作从开始定位到操作完成平均耗时在200到500毫秒之间完全能满足大部分测试场景的效率要求。实操心得快速模式的定位器缓存一定要设置合理的失效策略。我遇到过一种情况应用更新后某个按钮的资源ID变了但缓存里还是旧ID导致连续多个用例失败。后来加了“连续失败三次自动清空缓存”的机制问题就解决了。另外缓存最好按应用版本号隔离应用更新后自动失效旧缓存。4. 智能模式的LLM集成与决策逻辑4.1 Prompt工程的核心设计智能模式的效果好坏很大程度上取决于Prompt的设计。ARTEMIS的Prompt结构包含四个部分角色定义部分告诉LLM它扮演的是什么角色比如“你是一个移动端自动化测试执行引擎负责根据当前界面状态决定下一步操作”。角色定义要简洁明确不需要长篇大论但必须让LLM理解它的任务边界。界面描述部分是把感知层获取的信息转换成LLM能理解的格式。这里有个关键取舍是传截图还是传控件树文本ARTEMIS的做法是两者都传但根据场景调整侧重。对于视觉信息重要的场景比如判断页面布局、识别图标含义以截图为主对于文本信息重要的场景比如读取列表内容、判断按钮文字以控件树文本为主。截图会做压缩处理通常缩放到宽度720像素左右既能保留足够的视觉信息又能控制Token消耗。任务描述部分是当前测试步骤的目标比如“在当前页面找到搜索入口并点击”。任务描述要具体但不啰嗦避免给LLM太多无关信息。输出格式约束部分是最关键的。LLM的输出必须是结构化的否则解析起来非常麻烦。ARTEMIS定义了一套JSON格式的输出规范包含操作类型、目标元素描述、操作参数、置信度等字段。Prompt中会明确要求LLM按照这个格式输出并且给出示例。实测下来只要格式约束写得清楚主流LLM都能稳定输出合规的JSON。4.2 多模态输入的取舍策略智能模式支持多模态输入但并不是每次调用都传截图。ARTEMIS根据步骤类型来决定输入模态步骤类型主要输入辅助输入理由元素定位控件树文本截图可选控件树文本Token消耗低定位信息足够页面判断截图控件树摘要页面类型判断依赖视觉布局信息异常处理截图控件树摘要弹窗识别需要视觉信息内容提取控件树文本无文本内容直接从控件树读取更准确操作决策截图控件树历史操作记录综合判断需要多维度信息这个取舍策略的核心逻辑是能用文本解决的就不用图像必须用图像的才用图像。因为图像输入的Token消耗远高于文本而且图像理解的计算延迟也更高。我做过对比测试纯文本输入的LLM调用平均耗时1.5秒带图像输入的调用平均耗时3.2秒差距非常明显。4.3 决策结果的解析与校验LLM返回的JSON结果需要经过严格的解析和校验才能执行。ARTEMIS的解析流程包括第一步是格式校验。检查返回内容是否是合法JSON字段是否完整字段类型是否正确。如果格式不合法会尝试从返回文本中提取JSON片段因为有些LLM会在JSON前后加一些解释性文字。第二步是语义校验。检查操作类型是否在支持的操作列表中目标元素描述是否为空坐标是否在屏幕范围内。这一步能过滤掉大部分明显不合理的输出。第三步是置信度过滤。LLM在输出中会给出一个置信度分数ARTEMIS设置了一个阈值默认0.7低于阈值的决策会被拒绝转而触发重试或者降级处理。第四步是执行前预检。在实际执行操作之前ARTEMIS会做一次快速预检比如检查目标坐标位置是否确实存在可交互元素检查输入文本是否包含非法字符。这一步能避免一些低级错误。如果解析或校验失败ARTEMIS会进行有限次数的重试。重试时会调整Prompt比如增加更明确的格式要求或者补充更多上下文信息。如果重试仍然失败则标记该步骤为“智能模式执行失败”并根据用例配置决定是跳过还是终止。4.4 上下文管理与Token控制智能模式的一个隐性成本是Token消耗。每次LLM调用都需要传入界面描述、任务描述、历史记录等信息如果不加控制Token数量会迅速膨胀。ARTEMIS用了几个策略来控制Token历史记录截断只保留最近N步的操作记录默认5步更早的记录做摘要处理。摘要只保留关键信息比如“已点击搜索按钮”“已输入关键词”不保留完整的界面描述。界面描述精简控件树信息只保留可见节点节点属性只保留类名、文本、坐标、可交互标志四个字段。截图做有损压缩质量参数设为60%到70%在视觉信息和文件大小之间取平衡。Prompt模板复用角色定义和输出格式约束部分是固定的可以缓存复用不需要每次重新生成。只有界面描述和任务描述部分是动态的。按需调用不是每个步骤都需要LLM介入只有触发条件满足时才调用。这个前面已经说过是控制成本的最关键策略。我粗略算过一笔账一个包含50个步骤的测试用例如果全部走智能模式大概需要调用LLM 50次Token消耗在10万到15万之间。如果采用双模式架构只有大约10到15个步骤需要智能模式Token消耗降到2万到3万成本降低了70%以上而测试覆盖率基本不受影响。5. 双模式协同的实操流程与配置方法5.1 环境准备与依赖安装在开始配置ARTEMIS之前需要准备好基础环境。我按照实际搭建过程来梳理设备端准备一台Android设备或者模拟器开启开发者选项和USB调试。建议使用Android 8.0以上版本因为部分控件树API在低版本上行为不一致。设备分辨率建议在1080x1920以上过低的分辨率会影响图像匹配的准确性。主机端准备Python 3.9以上版本安装ADB工具并确保设备能正常连接。ADB的版本建议用较新的老版本在某些设备上会有兼容性问题。可以通过adb devices命令确认设备连接状态。Python依赖安装ARTEMIS的核心依赖包括UI自动化库、图像处理库、HTTP客户端库等。安装命令如下pip install uiautomator2 opencv-python pillow requests numpy如果要用到更高级的图像匹配功能还可以安装scikit-imagepip install scikit-imageLLM服务配置智能模式需要调用LLM服务需要配置API地址和密钥。ARTEMIS支持多种LLM后端配置方式是在配置文件中指定服务类型和认证信息。建议将密钥放在环境变量中不要硬编码在代码里。5.2 用例定义与模式标记ARTEMIS的测试用例用YAML格式定义每个步骤可以标记执行模式。下面是一个示例test_case: 商品搜索流程 steps: - action: launch_app package: com.example.shop mode: fast - action: click target: 搜索框 locator: - type: resource_id value: com.example.shop:id/search_box - type: text value: 搜索 mode: fast - action: input target: 搜索框 text: 无线耳机 mode: fast - action: click target: 搜索按钮 locator: - type: text value: 搜索 mode: fast - action: verify target: 搜索结果页面 description: 确认当前页面显示的是搜索结果列表且包含至少一个商品条目 mode: smart - action: click target: 第一个商品 mode: smart fallback: fast这个用例中前四步都是确定性操作标记为fast模式。第五步需要判断页面类型标记为smart模式。第六步点击第一个商品这个操作在控件树中可能没有稳定的定位器因为商品列表是动态渲染的所以也标记为smart模式但设置了fallback: fast意思是如果智能模式失败尝试用快速模式的图像匹配兜底。5.3 模式切换的配置参数ARTEMIS提供了一组配置参数来控制模式切换行为这些参数可以在全局配置文件中设置也可以在每个用例中覆盖参数名默认值说明fast_mode_timeout5s快速模式单步超时时间smart_mode_timeout15s智能模式单步超时时间smart_trigger_on_failuretrue快速模式失败时是否自动切换智能模式smart_confidence_threshold0.7智能模式决策的最低置信度max_retry_per_step3单步最大重试次数llm_max_tokens2048单次LLM调用的最大输出Token数screenshot_quality65截图压缩质量1-100history_length5传给LLM的历史操作记录步数这些参数的调整需要根据实际应用的特点来定。比如一个UI非常稳定的应用可以把smart_trigger_on_failure设为false完全依赖快速模式只在明确标记为smart的步骤才调用LLM。反之一个UI变动频繁的应用可以把smart_trigger_on_failure设为true并且降低smart_confidence_threshold让更多步骤有机会走智能模式。5.4 执行监控与日志记录ARTEMIS在执行过程中会记录详细的日志包括每一步使用的模式、定位耗时、操作耗时、LLM调用耗时、Token消耗、决策结果等。这些日志对于后续优化非常重要。我通常会把日志分成三个级别INFO级别记录每一步的执行摘要包括步骤序号、模式、结果、耗时DEBUG级别记录详细的定位过程、LLM输入输出、图像匹配得分等ERROR级别只记录失败步骤和异常信息。在实际使用中我建议默认开启INFO级别在排查问题时临时开启DEBUG级别。DEBUG级别的日志量非常大一个50步的用例可能产生几万行日志长期开启会影响性能。日志中有一个关键指标需要特别关注智能模式触发率。这个指标反映了快速模式的稳定性。如果触发率持续偏高比如超过30%说明快速模式的定位器需要优化或者应用的UI变动太频繁需要考虑调整测试策略。如果触发率过低比如低于5%可能说明智能模式的触发条件设置得太保守有些本该由LLM处理的场景被快速模式勉强处理了虽然当时没报错但可能存在隐患。6. 常见问题排查与避坑经验实录6.1 快速模式定位失败的典型原因快速模式定位失败是最常见的问题我整理了几种典型情况和对应的排查思路情况一资源ID变化。有些应用在每次启动时会重新生成资源ID导致基于资源ID的定位器完全失效。排查方法是连续启动应用多次对比同一元素的资源ID是否一致。如果确实变化需要改用文本内容或者相对位置定位。情况二元素不可见但存在于控件树中。有些元素虽然在控件树中存在但实际被遮挡或者透明度为0点击操作会失败。排查方法是检查元素的visible属性和bounds坐标确认元素确实在屏幕可见区域内。ARTEMIS在定位成功后会做一次可见性检查如果元素不可见会尝试滚动屏幕或者等待元素出现。情况三WebView内元素定位不到。如果应用使用了WebViewWebView内部的元素在原生控件树中可能只显示为一个整体节点无法定位到内部的具体元素。这种情况下需要开启WebView调试或者切换到智能模式让LLM通过截图来定位。情况四动态加载内容。列表类页面通常采用懒加载初始时只渲染可见区域的元素滚动后才加载更多。如果定位器查找的元素在初始视口之外会定位失败。ARTEMIS的处理方式是先尝试滚动查找如果滚动到底部仍未找到则触发模式切换。6.2 智能模式决策异常的排查方法智能模式的问题通常更隐蔽因为LLM的输出看起来可能“有道理”但实际上不符合测试预期。我遇到过几种典型情况情况一LLM理解偏差。比如任务描述是“点击搜索按钮”但界面上有两个搜索相关的按钮一个是搜索框旁边的放大镜图标一个是底部的搜索TabLLM可能选错了目标。排查方法是检查Prompt中的任务描述是否足够明确必要时增加目标元素的特征描述比如“点击搜索框右侧的放大镜图标”。情况二截图信息不足。如果截图压缩得太厉害LLM可能看不清界面细节导致决策错误。排查方法是临时提高截图质量参数对比决策结果是否改善。如果确实是截图质量问题需要调整压缩参数在Token消耗和决策准确性之间找平衡。情况三LLM输出格式不合规。虽然Prompt中明确了JSON格式要求但LLM偶尔还是会输出带额外文字的内容。ARTEMIS的解析器做了容错处理会尝试从返回文本中提取JSON片段。如果提取失败会触发重试。如果重试多次仍然失败建议检查Prompt中的格式约束是否足够清晰或者考虑换一个对格式遵循更好的LLM。情况四决策置信度普遍偏低。如果LLM返回的置信度经常低于阈值说明LLM对当前场景的判断不够确定。可能的原因是界面信息太复杂或者任务描述太模糊。解决方法是精简界面描述突出关键信息同时把任务描述写得更具体。6.3 模式切换时的上下文丢失问题模式切换时快速模式和智能模式之间的上下文传递是一个容易被忽视的问题。快速模式执行到一半切换到智能模式智能模式需要知道之前执行了哪些步骤、当前处于什么状态否则可能做出错误的决策。ARTEMIS的解决方案是维护一个共享的执行上下文对象包含当前用例信息、已执行步骤列表、当前页面状态摘要、设备信息等。快速模式和智能模式都从这个上下文读取信息也都向这个上下文写入执行结果。切换模式时上下文对象保持不变只是决策引擎换了。这里有一个实操中的坑快速模式记录的页面状态摘要可能不够详细智能模式接手后需要重新感知界面。如果重新感知的耗时太长会影响整体执行效率。ARTEMIS的做法是快速模式在每次操作后都会缓存一份最新的界面快照控件树截图切换模式时直接复用这份快照避免重复感知。6.4 常见问题速查表问题现象可能原因排查方法解决方案快速模式定位超时定位器失效或元素未加载检查控件树中是否存在目标元素更新定位器或增加等待时间智能模式决策错误Prompt描述不清或截图质量差查看LLM输入输出日志优化Prompt或提高截图质量模式切换频繁快速模式稳定性差统计智能模式触发率优化快速模式定位器LLM调用超时网络问题或Token过多检查网络连接和Token数量减少输入Token或增加超时时间操作执行失败元素不可见或坐标偏移检查元素可见性和坐标范围增加滚动或调整坐标计算用例执行中断未处理的异常弹窗查看中断时的截图增加异常处理步骤或开启智能模式兜底避坑技巧在正式跑大批量用例之前先用少量用例做一轮“模式触发率”测试。具体做法是把所有步骤都标记为fast模式跑一遍完整用例统计有多少步骤触发了智能模式切换。如果触发率超过20%说明快速模式的定位器需要优化不要急着跑全量用例否则会浪费大量时间和Token。7. 性能调优与扩展思路7.1 执行速度的优化空间双模式架构的执行速度优化核心思路是“让快速模式处理更多步骤让智能模式处理更准”。具体来说有几个方向定位器自动修复当快速模式定位失败并切换到智能模式后智能模式成功定位到元素ARTEMIS会把智能模式的定位结果反向生成一个快速模式定位器加入定位器缓存。这样下次遇到同样的元素快速模式就能直接处理不需要再调用LLM。这个机制在实际使用中效果很好随着用例执行次数增加快速模式的覆盖率会逐步提升。并行执行对于不依赖同一设备状态的用例可以并行执行。ARTEMIS支持多设备并行每个设备独立运行用例共享LLM调用配额。并行执行时需要注意设备间的资源竞争比如ADB连接数限制、LLM服务的并发限制等。预热机制在正式执行用例之前先做一轮预热包括启动应用、加载基础页面、初始化定位器缓存等。预热可以减少正式执行时的冷启动开销。7.2 准确率的提升策略准确率提升的关键在于减少误判和漏判。ARTEMIS从几个方面入手多模型投票对于关键决策步骤可以同时调用两个不同的LLM对比它们的输出。如果一致则直接执行如果不一致则取置信度更高的结果或者触发人工确认。这个策略会增加成本但能显著提升关键步骤的准确率。规则兜底在智能模式之上再加一层规则校验。比如LLM决定点击某个坐标规则层会检查这个坐标是否在屏幕范围内、是否在可点击区域内、是否与当前任务相关。如果规则校验不通过则拒绝执行并触发重试。反馈学习记录每次智能模式决策的结果包括执行成功与否、是否达到预期效果。这些数据可以用来微调Prompt或者训练一个轻量级的分类器来预判LLM决策的可靠性。7.3 扩展到其他平台的可行性ARTEMIS目前主要针对Android平台但双模式架构的设计思路是可以扩展到其他平台的。扩展到iOS平台的主要挑战在于设备控制层的差异iOS的自动化控制需要通过WebDriverAgent或者类似的桥接方案控件树的结构和属性也与Android不同。但决策层和编排层的逻辑基本可以复用只需要替换感知层和设备控制层的实现。扩展到Web平台相对容易因为Web端的控件树DOM信息更丰富快速模式的定位能力更强。智能模式在Web端主要用于处理动态内容、验证码、复杂交互等场景。扩展到桌面应用Windows/macOS的难度较大因为桌面应用的控件树信息通常不如移动端和Web端规范可能需要更多依赖图像识别和LLM的视觉理解能力。7.4 成本控制的长期策略LLM调用成本是智能模式的主要开销。长期来看成本控制有几个方向模型分级不是所有智能模式步骤都需要用最强的模型。简单的页面判断可以用轻量级模型复杂的异常处理再用重量级模型。ARTEMIS支持按步骤配置模型等级在准确率和成本之间做精细化平衡。缓存复用对于重复出现的界面状态和决策场景可以缓存LLM的决策结果。比如“关闭弹窗”这个操作如果弹窗的样式和内容相似可以直接复用之前的决策不需要每次都调用LLM。缓存需要设置合理的失效策略避免因为界面变化导致缓存失效。本地化部署如果测试频率很高可以考虑在本地部署轻量级LLM减少对云端服务的依赖。本地部署的一次性投入较高但长期来看单位成本更低而且没有网络延迟问题。不过本地模型的决策能力通常不如云端大模型需要根据实际需求权衡。我个人在实际项目中的体会是双模式架构的价值不在于“用了LLM”而在于“知道什么时候该用LLM什么时候不该用”。很多团队一上来就追求全智能模式结果发现成本高、速度慢、稳定性差最后又退回到传统方案。ARTEMIS的思路更务实把LLM当作一个“专家系统”来用只在传统方法搞不定的场景下请它出马这样既能享受LLM的灵活性又能保持传统方案的高效和稳定。这个平衡点需要根据具体应用的特点来调整没有一刀切的标准但双模式架构提供了一个很好的起点。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
