移动端自动化测试架构：LLM角色级模型拆分与工程实践

1. 从"一个模型打天下"到角色级拆分：移动端自动化测试的架构拐点

移动端自动化测试这件事，做过的人都懂——它和Web端自动化完全是两个世界。Web端你至少有一个相对稳定的DOM树可以依赖，元素定位、状态断言、页面跳转都有比较清晰的边界。但移动端不一样，屏幕尺寸碎片化、系统权限弹窗随机出现、App内部状态机复杂、渲染层和原生层交织在一起，再加上网络抖动、动画延迟、软键盘遮挡这些"玄学"问题，传统基于控件树的自动化方案经常陷入"写三天、修五天"的泥潭。

大语言模型介入移动端自动化之后，情况发生了根本性变化。以前我们靠find_element_by_id这种硬编码方式定位元素，现在可以让模型"看着"屏幕截图，理解当前界面在干什么，然后决定下一步该点哪里、该输入什么。这个思路听起来很美好，但真正落地的时候，第一个撞上的墙就是：一个模型根本不够用。

为什么？因为移动端自动化测试这个任务链条太长了。它至少包含这些环节：理解当前屏幕内容、判断当前处于什么状态、决定下一步操作、生成具体的操作指令（点击坐标、输入文本、滑动方向）、验证操作结果是否符合预期、在出现异常时决定重试还是上报。如果你把这些全部塞给一个通用大模型，会出现几个致命问题：响应延迟高得离谱（每次操作都要等好几秒）、Token消耗巨大（每步都要传完整截图和上下文）、准确率不稳定（模型在不同任务间"精神分裂"）、成本不可控（跑一轮回归测试烧掉的钱够买一台真机）。

所以，角色级模型拆分就成了移动端自动化测试架构设计的必然选择。这个思路的核心是：不让一个模型干所有事，而是把整个测试流程拆成若干个"角色"，每个角色只负责一个明确的子任务，用最适合这个子任务的模型来驱动。比如，有的角色专门负责"看屏幕"，有的角色专门负责"做决策"，有的角色专门负责"执行动作"，有的角色专门负责"判断结果"。每个角色可以用不同规模、不同能力侧重的模型，甚至可以用不同的提示词策略和不同的输入输出格式。

这个架构思路在DroidRun和Mobilerun这类移动端自动化框架里体现得特别明显。它们不是简单地把GPT-4接进来就完事，而是设计了一套角色分工机制，让每个模型在自己的"岗位"上发挥最大价值。接下来我会从架构设计、角色划分、模型选型、提示词工程、实测调优这几个维度，把这个方案彻底拆开讲清楚。如果你正在做移动端自动化测试，或者正在考虑把LLM引入测试流程，这套思路可以直接参考。

2. DroidRun/Mobilerun的角色拆分逻辑：谁该干什么活

2.1 为什么不能用一个模型端到端搞定

先把这个事情说透。很多人第一反应是：我直接用GPT-4V或者Claude这种多模态大模型，把截图丢进去，让它输出"点击(500, 800)"不就行了吗？为什么要搞这么复杂？

我一开始也是这么想的，直到实际跑了一轮完整的测试用例。一个典型的登录流程测试，大概需要15-20步操作。如果用单模型端到端方案，每一步都要把当前截图、历史操作记录、测试目标全部塞进Prompt，然后等模型输出下一步动作。实测下来，单步平均响应时间在3-5秒，整个用例跑完要一分多钟。这还只是一个用例，如果你有200个回归用例，光等待时间就是三四个小时。更别说Token成本了——每步都传一张1080P截图，按GPT-4V的计价方式，跑一轮回归够你心疼好几天。

除了成本和速度，单模型方案还有一个更隐蔽的问题：任务干扰。当你让一个模型同时做"理解屏幕"和"决策下一步"这两件事时，它会在两个任务之间产生认知冲突。比如屏幕上有一个广告弹窗和一个登录按钮，模型需要先判断"这个弹窗是不是需要关闭"，再决定"关闭后应该点哪里"。如果这两个判断在同一个推理步骤里完成，模型很容易被弹窗的视觉特征带偏，忽略掉真正的测试目标。这在实测中表现为：模型频繁点击无关元素，或者在弹窗出现时陷入"关闭-再出现-再关闭"的死循环。

角色级拆分的本质，是把一个复杂的多模态推理任务，分解成若干个单模态或弱多模态的子任务，每个子任务用一个专门的模型来处理。这样做的好处是：每个模型的输入输出格式可以高度定制化，推理路径更短，准确率更高，而且可以用小模型替代大模型来降低成本。

2.2 四个核心角色的职责边界

在DroidRun/Mobilerun的架构里，我把它拆成了四个核心角色。这四个角色不是随便分的，而是按照"感知-决策-执行-验证"这个闭环来设计的。

第一个角色是"屏幕理解器"（Screen Interpreter）。它的任务很纯粹：输入一张截图，输出当前屏幕的结构化描述。这个描述包括：当前页面是什么（登录页、首页、设置页）、有哪些可交互元素（按钮、输入框、列表项）、每个元素的位置和状态（可点击、已禁用、已选中）、有没有弹窗或遮罩层。这个角色不需要知道测试目标是什么，它只负责"看懂"屏幕。因为任务单一，这个角色可以用一个相对小的多模态模型来承担，比如7B参数级别的视觉语言模型，经过针对性微调后，在屏幕元素识别这个任务上可以做到接近大模型的准确率，但速度快5-10倍。

第二个角色是"决策规划器"（Decision Planner）。它接收屏幕理解器的输出（结构化描述）和当前测试目标（比如"完成登录"），然后决定下一步应该做什么。这个角色的输入是纯文本的，不需要处理图像，所以可以用一个纯文本大模型来承担。它的输出是一个高层级的动作指令，比如"在用户名输入框中输入测试账号"、"点击登录按钮"、"等待页面跳转"。注意，它输出的是"做什么"，而不是"怎么做"——具体的坐标计算、输入法调用这些底层操作不归它管。

第三个角色是"动作执行器"（Action Executor）。它接收决策规划器的高层级指令，结合屏幕理解器提供的元素位置信息，生成具体的底层操作指令。比如"在用户名输入框中输入测试账号"这个指令，执行器需要把它翻译成：点击坐标(320, 450)、等待200毫秒、输入文本"testuser001"、隐藏软键盘。这个角色需要处理一些设备相关的细节，比如不同分辨率下的坐标映射、输入法的兼容性处理、滑动操作的加速度曲线等。它可以用一个轻量级的规则引擎或者小模型来实现，不需要大模型参与。

第四个角色是"结果验证器"（Result Validator）。每次操作执行完后，它需要判断操作是否成功、当前状态是否符合预期。比如点击登录按钮后，页面是否跳转到了首页？输入文本后，输入框里是否显示了正确的字符？这个角色需要对比操作前后的屏幕状态，判断是否出现了预期变化。它可以用一个专门训练的视觉差异检测模型，或者一个多模态小模型来实现。

这四个角色串起来，就形成了一个完整的自动化测试闭环。每个角色只做自己最擅长的事，模型选型、提示词设计、输入输出格式都可以独立优化。

2.3 角色之间的通信协议设计

角色拆分之后，下一个关键问题是：它们之间怎么通信？如果通信协议设计得不好，角色拆分的优势会被抵消掉。

在DroidRun/Mobilerun的实践里，角色之间的通信采用了一种"结构化中间表示"的方案。屏幕理解器输出的不是自然语言描述，而是一个结构化的JSON对象。这个JSON对象包含几个关键字段：screen_type（页面类型）、elements（元素列表，每个元素有id、type、text、bounds、state这些属性）、popups（弹窗列表）、keyboard_visible（软键盘是否可见）。决策规划器接收这个JSON对象，输出一个action_plan对象，包含action_type（动作类型）、target_element_id（目标元素ID）、parameters（动作参数）。动作执行器接收action_plan，结合屏幕理解器提供的元素坐标信息，生成最终的设备操作指令。

这种结构化通信的好处是：每个角色的输出都是可验证、可调试的。如果测试失败了，你可以清楚地看到是哪个环节出了问题——是屏幕理解器没识别出登录按钮，还是决策规划器选错了目标元素，还是动作执行器坐标算错了。这比单模型端到端方案的"黑盒"调试体验好太多了。

提示：结构化中间表示的设计要遵循"最小必要信息"原则。屏幕理解器不需要输出屏幕上所有文字内容，只需要输出与当前测试目标相关的元素信息。这样可以大幅减少Token消耗，同时降低决策规划器的认知负担。

3. 模型选型：每个角色该配什么"大脑"

3.1 屏幕理解器的选型逻辑与实测对比

屏幕理解器是整个流水线的入口，它的准确率直接决定了后续所有环节的上限。如果它把"登录按钮"识别成了"注册按钮"，后面决策规划器再聪明也没用。

这个角色的核心任务是：输入一张手机截图（通常是1080x2340或类似分辨率），输出结构化的屏幕元素描述。它需要具备的能力包括：OCR（识别屏幕上的文字）、目标检测（定位可交互元素的位置）、状态判断（按钮是否可点击、输入框是否为空）、页面分类（当前是什么页面）。

在模型选型上，我实测过几种方案。第一种是直接用GPT-4V或Claude 3这类通用多模态大模型，准确率确实高，但单次推理成本在0.01-0.03美元之间，而且响应时间在2-4秒。如果你要跑大量测试用例，这个成本和时间都很难接受。第二种是用开源的视觉语言模型，比如Qwen-VL、CogVLM、InternVL这些，7B到13B参数级别的模型在屏幕元素识别这个特定任务上，经过少量微调后可以达到接近GPT-4V的准确率，但推理速度快3-5倍，成本降低一个数量级。第三种是传统的CV方案加OCR，比如用YOLO做元素检测、用PaddleOCR做文字识别，然后规则化地组装成结构化描述。这种方案速度最快、成本最低，但泛化能力差，遇到没见过的UI风格就容易翻车。

我的建议是：如果你的测试场景相对固定（比如只测自家App的几个核心页面），用微调后的7B级别视觉语言模型性价比最高。如果你需要覆盖大量不同App的测试场景，可以考虑用GPT-4V做冷启动，同时收集数据微调自己的小模型，逐步替换。

这里有一个实测数据可以参考：在某次对比测试中，我用Qwen-VL-7B（经过500张标注截图微调）和GPT-4V分别跑同一个登录页面的元素识别任务，各跑100次。Qwen-VL-7B的元素定位准确率是94%，GPT-4V是97%，差距只有3个百分点。但Qwen-VL-7B的单次推理时间平均是0.8秒，GPT-4V是3.2秒；Qwen-VL-7B的推理成本几乎可以忽略（本地部署），GPT-4V每次调用要花钱。这个对比说明，在屏幕理解这个任务上，小模型经过针对性优化后完全可以胜任。

3.2 决策规划器：为什么纯文本模型就够了

决策规划器是四个角色里唯一不需要处理图像的。它的输入是屏幕理解器输出的结构化JSON，加上当前测试目标和历史操作记录。输出是一个高层级的动作指令。

因为输入是纯文本的，这个角色可以用纯文本大模型来承担，不需要多模态能力。这带来了几个好处：第一，纯文本模型的推理速度比多模态模型快很多；第二，纯文本模型的Token成本更低；第三，纯文本模型的上下文窗口可以更大，能容纳更长的历史操作记录。

在模型选型上，我建议用中等规模的纯文本模型，比如7B到14B参数级别的模型。这个规模的模型在指令遵循和逻辑推理任务上已经足够强了，而且推理速度快、成本低。如果你用GPT-4这种超大模型来做决策规划，反而可能因为"过度思考"导致决策不稳定——它会考虑太多可能性，有时候会做出一些出人意料的决策。

决策规划器的提示词设计是关键。你需要把测试目标、当前屏幕状态、历史操作记录、可用动作空间这些信息清晰地组织成Prompt。我的经验是：用"系统提示词+少样本示例+当前状态"的三段式结构。系统提示词定义角色和输出格式，少样本示例展示几个典型的决策场景，当前状态提供实时信息。这样模型能快速理解任务边界，输出稳定的决策结果。

3.3 动作执行器与结果验证器的轻量化方案

动作执行器和结果验证器这两个角色，其实不需要大模型参与。它们可以用规则引擎或者极轻量级的模型来实现。

动作执行器的核心逻辑是：把决策规划器输出的"高层级指令"翻译成"底层设备操作"。比如"在用户名输入框中输入testuser001"这个指令，执行器需要做这几件事：从屏幕理解器的输出中查找"用户名输入框"的坐标范围、计算点击中心点坐标、调用设备API执行点击、等待输入框获得焦点、调用输入法输入文本、隐藏软键盘。这些操作都是确定性的，用规则引擎完全可以处理。只有在遇到一些特殊情况时（比如输入框被软键盘遮挡、点击后没有响应），才需要引入一些简单的启发式规则或者小模型来判断。

结果验证器的核心逻辑是：对比操作前后的屏幕状态，判断是否出现了预期变化。比如点击登录按钮后，页面是否从登录页变成了首页？这个判断可以通过对比屏幕理解器输出的screen_type字段来实现。如果操作前是"登录页"，操作后还是"登录页"，那说明登录可能失败了。更精细的验证可以对比特定元素的状态变化，比如"登录按钮"是否从"可点击"变成了"已禁用"（表示正在加载），或者页面上是否出现了"登录成功"的提示文字。

这两个角色用规则引擎实现的好处是：速度快（毫秒级）、成本为零、可解释性强（出问题时能清楚看到是哪条规则触发了）。只有在规则覆盖不到的场景下，才需要考虑引入模型。

4. 提示词工程：让每个角色稳定输出

4.1 屏幕理解器的输出格式约束

屏幕理解器最大的挑战不是"看不懂屏幕"，而是"输出格式不稳定"。如果你不严格约束输出格式，模型有时候输出JSON，有时候输出自然语言，有时候字段名还变来变去。这会让下游的决策规划器非常痛苦。

我的做法是：用JSON Schema严格约束输出格式，并在提示词里给出完整的示例。具体来说，屏幕理解器的输出必须是一个合法的JSON对象，包含以下字段：

{ "screen_type": "login_page", "elements": [ { "id": "elem_001", "type": "input", "text": "用户名", "bounds": [100, 400, 980, 500], "state": "enabled", "value": "" }, { "id": "elem_002", "type": "button", "text": "登录", "bounds": [100, 700, 980, 800], "state": "enabled" } ], "popups": [], "keyboard_visible": false }

在提示词里，我会明确告诉模型：bounds字段是[left, top, right, bottom]格式的像素坐标，state字段只能是enabled、disabled、selected、checked这几个值之一，type字段只能是button、input、text、image、list_item、checkbox、radio、switch、slider、tab、link、icon、other这些值之一。如果模型输出了不在枚举范围内的值，后处理逻辑会自动把它映射到other。

这种严格约束的好处是：下游角色可以放心地按照固定格式解析数据，不需要做复杂的容错处理。实测下来，经过格式约束的屏幕理解器，输出格式合规率从最初的70%左右提升到了99%以上。

4.2 决策规划器的少样本示例设计

决策规划器的提示词设计，核心是"让模型理解任务边界"。你需要通过少样本示例告诉模型：在什么情况下应该做什么决策。

我通常会准备5-8个少样本示例，覆盖典型的决策场景。比如：

• 场景一：当前在登录页，用户名和密码输入框都为空，测试目标是"完成登录"。决策：先在用户名输入框中输入测试账号。
• 场景二：当前在登录页，用户名已输入，密码为空。决策：在密码输入框中输入测试密码。
• 场景三：当前在登录页，用户名和密码都已输入，登录按钮可点击。决策：点击登录按钮。
• 场景四：当前在登录页，出现了"账号或密码错误"的提示。决策：上报测试失败，记录错误信息。
• 场景五：当前在首页，测试目标是"完成登录"。决策：登录已完成，结束当前测试用例。

这些示例要覆盖正常流程和异常流程，让模型学会在不同情况下做出正确决策。示例的格式要统一：输入是当前屏幕状态和测试目标，输出是决策结果。决策结果的格式也要严格约束，比如：

{ "action_type": "input_text", "target_element_id": "elem_001", "parameters": { "text": "testuser001" }, "reasoning": "当前在登录页，用户名输入框为空，需要先输入用户名" }

注意reasoning字段——让模型输出决策理由，一方面可以帮助调试（出问题时能看到模型是怎么想的），另一方面可以提升决策质量（模型在输出理由的过程中会进行更深入的推理）。

4.3 角色间提示词的解耦与复用

四个角色的提示词是独立设计的，但它们之间有一些共享的约定。比如，屏幕理解器输出的元素ID格式（elem_001、elem_002）会被决策规划器引用，决策规划器输出的target_element_id会被动作执行器解析。这些跨角色的约定需要在每个角色的提示词里都明确说明，确保数据流转不会断链。

另外，我建议把一些通用的提示词片段抽出来做成模板，比如"输出格式约束"、"错误处理规则"、"坐标系统说明"这些。这样在调整某个角色的提示词时，不需要重复修改这些通用部分，减少出错概率。

注意：提示词版本管理很重要。每次修改提示词后，都要用一组固定的测试用例回归验证，确保修改没有引入新的问题。我通常会维护一个"提示词变更日志"，记录每次修改的内容、原因和回归测试结果。

5. 实测调优：角色拆分方案的真实表现与踩坑记录

5.1 延迟与成本的量化对比

角色拆分方案到底比单模型方案好多少？我用一组实测数据来说明。

测试场景：一个包含15步操作的登录流程测试用例，在同一个Android模拟器上运行。对比方案A（单模型端到端，用GPT-4V）和方案B（角色拆分，屏幕理解器用微调后的Qwen-VL-7B，决策规划器用Qwen-7B-Chat，动作执行器和结果验证器用规则引擎）。

从数据可以看出，角色拆分方案在延迟、成本、准确率三个维度上都优于单模型方案。延迟降低的主要原因是屏幕理解器和决策规划器都是小模型，推理速度快；成本降低的主要原因是Token消耗大幅减少；准确率提升的主要原因是每个角色只做单一任务，减少了任务干扰。

5.2 角色边界模糊导致的典型故障

角色拆分方案也不是没有坑。我踩过的最大的坑是：角色边界模糊导致的"踢皮球"问题。

有一次，测试流程在"点击登录按钮"这一步卡住了。屏幕理解器识别出了登录按钮，决策规划器也输出了"点击登录按钮"的指令，但动作执行器执行点击后，页面没有任何变化。排查了半天才发现：登录按钮被一个透明的遮罩层挡住了，点击事件被遮罩层拦截了。屏幕理解器没有识别出遮罩层的存在（因为它只关注可交互元素），决策规划器不知道有遮罩层（因为屏幕理解器没告诉它），动作执行器点击了按钮的坐标但实际点到了遮罩层上。

这个问题的根源是：屏幕理解器的职责边界没有覆盖"遮罩层检测"这个场景。修复方案是在屏幕理解器的输出里增加一个overlay字段，用来标识当前屏幕上是否存在遮罩层或弹窗。如果存在遮罩层，决策规划器会优先输出"关闭遮罩层"的指令，而不是直接执行目标操作。

这个坑给我的教训是：角色拆分不是越细越好，但每个角色的职责边界必须覆盖所有可能影响决策的屏幕状态。在设计角色时，要多问自己：这个角色漏掉什么信息会导致下游角色做出错误决策？

5.3 从失败案例反推角色拆分粒度

另一个值得分享的经验是：角色拆分的粒度需要根据实际失败案例来调整。

一开始我把"结果验证"和"决策规划"合并成了一个角色，让决策规划器同时负责"判断上一步操作是否成功"和"决定下一步做什么"。结果发现，模型经常在验证环节出错——比如点击登录按钮后，页面还在加载中（转圈动画），模型就判断"登录失败"了，然后输出"重新点击登录按钮"的指令，导致重复点击。

后来我把"结果验证"拆出来作为独立角色，专门负责判断操作结果。这个角色有一个明确的规则：如果页面上存在加载动画或进度条，就等待而不是判断失败。这个规则用规则引擎实现，比让模型去判断要可靠得多。

这个案例说明：当一个角色承担了两种不同性质的判断任务时，就容易出错。把不同性质的判断拆开，用最适合的方式来实现，才能保证稳定性。

6. 可复用的角色拆分设计清单

6.1 角色定义模板

如果你要为自己的移动端自动化测试项目设计角色拆分方案，可以参考这个模板：

这个模板不是固定的，你可以根据自己项目的实际情况调整。比如，如果你的测试场景里弹窗特别多，可以增加一个"弹窗处理器"角色；如果你的测试需要处理复杂的表单填写，可以增加一个"表单填写器"角色。

6.2 角色间接口的版本管理

角色拆分之后，角色之间的接口就变成了一个需要认真管理的对象。我建议给每个接口定义明确的版本号，比如screen_description_v1、action_plan_v1。当某个角色的输出格式发生变化时，版本号要升级，同时要确保下游角色能兼容新旧两个版本。

在实际操作中，我会把接口定义写成JSON Schema文件，放在代码仓库里统一管理。每次修改接口，都要走代码审查流程，确保上下游角色都同步更新。这样可以避免"上游改了格式，下游解析失败"这种低级错误。

6.3 灰度上线与回滚策略

角色拆分方案上线时，不要一次性全量替换。我建议采用灰度上线策略：先让新方案和旧方案并行运行，对比两者的输出结果。如果新方案在某个测试用例上表现不如旧方案，可以快速回滚到旧方案。

具体操作上，可以在测试框架里加一个开关，控制每个角色使用哪个版本的模型或规则。比如，屏幕理解器可以配置为"使用GPT-4V"或"使用微调后的Qwen-VL-7B"。灰度期间，可以按测试用例维度逐步切换，观察每个用例的表现。

回滚策略也很重要。如果新方案上线后出现大面积失败，要能快速切回旧方案。我的做法是：保留旧方案的完整代码和配置，新方案以"插件"的形式接入，切换时只需要改一个配置项。

7. 关于这套架构的一些个人体会

角色级模型拆分这个思路，我从第一次尝试到现在，大概经历了三轮大的调整。第一轮是"拆得太粗"，只分了"理解"和"决策"两个角色，结果发现决策角色负担太重，经常出错。第二轮是"拆得太细"，分了七八个角色，结果角色之间的通信开销比模型推理本身还大，整体延迟反而上升了。第三轮才找到比较平衡的四个角色划分。

我的体会是：角色拆分的粒度，应该以"每个角色的输出可以被独立验证"为标准。如果一个角色的输出你没法单独验证对错，那说明这个角色承担了太多职责，需要继续拆。反过来，如果两个角色之间的通信成本已经超过了它们各自推理的成本，那说明拆得太细了，应该合并。

另外，不要迷信"大模型一定比小模型好"。在屏幕理解这个任务上，一个经过500张截图微调的7B模型，表现可以接近甚至在某些场景下超过GPT-4V。关键是你愿不愿意花时间去收集数据、标注数据、微调模型。如果你只是想把LLM接进来跑个Demo，那用大模型确实省事；但如果你要把它做成一个能稳定运行的测试系统，小模型加微调才是可持续的方案。

最后说一个容易被忽略的点：日志和可观测性。角色拆分之后，每个角色的输入输出都要完整记录日志。这样当测试失败时，你可以清楚地看到是哪个角色出了问题。我通常会把每个角色的输入输出存成JSON文件，按测试用例和时间戳组织目录结构。排查问题时，直接看日志就能定位到具体环节，不需要重新跑一遍测试。这个习惯帮我节省了大量调试时间。