移动端LLM自动化测试：双模式架构设计与工程实践

1. 为什么移动端 LLM 测试需要一套双模式架构移动端跑大模型自动化测试这件事在两年前还属于“实验室玩具”的范畴。那会儿大家的主流做法是把模型塞进一个 App手动点几下看看输出是不是人话就算测过了。但到了今天端侧模型参数量从 1B 一路卷到 7B、13B推理框架从早期的单一方案扩展到多种后端并行测试场景也从“能不能出结果”变成了“在不同设备、不同负载、不同交互路径下输出质量是否稳定”。手工测试在这个量级面前已经完全不够用了。ARTEMIS 这个项目就是在这个背景下被推出来的。它的核心定位是一套面向移动端 LLM 应用的自动化测试框架而它最值得拿出来讲的设计就是双模式架构。所谓双模式简单说就是同一套测试用例既能在真实设备上以“黑盒交互”的方式跑也能在模拟环境中以“白盒注入”的方式跑。前者贴近真实用户路径后者追求执行效率和可观测性。两者共享同一套用例描述、同一套断言引擎、同一套报告体系但底层执行器完全不同。这个设计解决了一个非常实际的矛盾移动端测试如果只做真机黑盒成本高、速度慢、不稳定因素多如果只做模拟环境白盒又容易脱离真实运行条件测出来的结论没有说服力。双模式架构的本质是让“验证逻辑”和“执行环境”解耦你可以根据测试目的灵活切换而不是被迫二选一。这篇文章适合三类人看一是正在做端侧模型落地的测试工程师二是负责移动端 AI 应用质量保障的技术负责人三是对自动化测试架构设计感兴趣、想借鉴思路的开发者。我会从架构设计思路讲起把两种模式各自的实现要点、切换机制、常见坑都拆开说清楚尽量做到你看完就能对照自己的项目做取舍。2. 双模式架构的整体设计与选型考量2.1 两种模式到底分别是什么先把概念钉死不然后面容易混。模式一设备交互模式Device Interaction Mode。这个模式下ARTEMIS 把被测应用当成一个完全的黑盒。它通过移动端自动化驱动层比如基于 UI 树解析和无障碍节点定位的那套机制去操作真实设备上的 App模拟用户的点击、输入、滑动、等待然后从界面上抓取模型输出的文本结果。整个过程中框架不关心 App 内部怎么调用模型、用了什么推理后端它只关心“用户看到什么”。模式二运行时注入模式Runtime Injection Mode。这个模式下ARTEMIS 通过一个轻量级的测试代理层直接挂载到应用的模型调用链路上。它可以在模型推理前后插入钩子拿到原始输入、推理耗时、显存占用、token 流式输出等细粒度数据甚至可以注入特定的 prompt 或强制触发某条分支逻辑。这个模式不依赖 UI执行速度极快适合做大批量的回归验证。两种模式的关系不是替代而是互补。我个人的经验是功能验收和端到端场景用设备交互模式性能基线和大规模回归用运行时注入模式。这个分工在后面讲实操时会反复提到。2.2 为什么不是单模式打天下有人可能会问既然运行时注入模式又快又能拿到细粒度数据为什么不只用它原因在于“真实性”这三个字。移动端的运行环境极其复杂不同厂商的调度策略、不同芯片的 NPU 驱动差异、内存回收时机、热管理降频、后台进程抢占资源这些因素在注入模式下很多是被抽象掉的。你测出来推理耗时 200ms到了真机上可能是 800ms甚至因为降频直接超时。只靠注入模式你会得到一份“实验室里很美”的报告但上线后用户该卡还是卡。反过来只用设备交互模式也有问题。一个包含 500 条用例的回归套件在真机上跑一遍可能要三四个小时而且 UI 定位本身就有偶发失败率维护成本高得吓人。更关键的是很多模型层面的问题比如某个 token 概率异常、上下文截断逻辑错误在 UI 上根本看不出来你只能看到“输出不对”但不知道哪里不对。所以双模式的核心价值是让每种模式做它最擅长的事。设备交互模式负责“用户视角的正确性”运行时注入模式负责“系统视角的可观测性和效率”。两者结合才能既保证质量结论可信又保证测试成本可控。2.3 架构分层与关键模块ARTEMIS 的整体分层大致是这样的用例描述层用统一的 DSL 或 YAML 描述测试意图包括输入、预期断言、执行模式标记、超时策略等。这一层是模式无关的。调度与编排层根据用例标记决定分发到哪个执行器管理并发、重试、资源池。执行器层分为设备交互执行器和运行时注入执行器各自封装底层驱动。断言与评估层对模型输出做语义匹配、关键词校验、格式校验、性能阈值判断。报告与追踪层统一收集两种模式的执行数据生成可对比的报告。这个分层的关键在于用例描述层和执行器层之间是松耦合的。一条用例写好后理论上可以不改任何内容就在两种模式下运行只是执行路径不同。这一点在实操中非常重要因为它意味着你的测试资产不会因为执行方式变化而作废。提示分层设计时最容易犯的错误是把断言逻辑写进执行器里。一旦断言和执行器耦合切换模式时就要重写断言双模式的意义就没了。断言层必须独立。3. 设备交互模式的核心实现要点3.1 元素定位策略与稳定性处理设备交互模式最头疼的问题永远是元素定位。移动端 UI 不像 Web 那样有稳定的 DOM 结构同一个按钮在不同机型、不同系统版本、不同语言下的节点属性可能完全不同。ARTEMIS 在这块采用的是多策略优先级定位优先用无障碍标识如果开发规范到位其次用文本内容匹配再次用相对位置和层级路径最后才用坐标兜底。每条定位策略都带重试和降级逻辑比如无障碍标识找不到时自动降级到文本匹配。实测下来这套策略能把定位失败率从早期的 8% 左右压到 1% 以内。但要注意降级定位是有代价的文本匹配在输入框有内容变化时可能误命中坐标兜底在屏幕旋转或分辨率变化时直接失效。所以我的建议是在用例里显式标注“允许的降级层级”对于关键路径用例宁可失败也不要降级到坐标避免产生假阳性。3.2 等待与同步机制移动端 LLM 应用有个特点模型推理是异步的输出可能是流式的。你不能点完按钮就立刻断言必须等待输出完成。常见的错误做法是写死一个sleep(5)。这在实验室里可能没问题但真机上模型加载慢一点、设备热一点5 秒就不够了反过来设备性能好时又白白浪费时间。ARTEMIS 用的是条件等待 流式结束检测轮询界面上的输出区域检测是否出现“生成完成”标志比如光标消失、按钮恢复可点击同时设置一个最大超时兜底。这里有个细节值得说流式输出的结束判断不能只看文本是否还在变化因为模型可能在思考阶段停顿。更可靠的做法是结合 UI 状态比如停止生成按钮是否消失和文本稳定性连续两次采样文本一致双重判断。我在实际项目里踩过这个坑只靠文本稳定性判断遇到模型输出长段落中间停顿的情况会误判为已完成导致断言截断。3.3 真机资源池管理设备交互模式要跑得起来背后得有一个稳定的真机资源池。ARTEMIS 支持多设备并行但并行度不是越高越好。每台设备上跑 LLM 应用本身就是高负载场景。如果一台机器上同时跑多个测试实例内存和算力会互相抢占导致推理超时、UI 卡顿、定位失败率飙升。我的经验是中端设备一台只跑一个实例高端设备最多两个而且要根据设备的内存和芯片规格做分组把性能相近的设备放在同一批次里跑避免快设备等慢设备。另外设备池要有健康检查机制。长时间跑测试后设备可能出现过热降频、内存碎片、应用残留进程等问题。ARTEMIS 在每轮测试前会做一次轻量级预热和状态重置包括清理后台、重置应用、检查可用内存。这一步看起来不起眼但能显著降低“莫名其妙失败”的比例。4. 运行时注入模式的核心实现要点4.1 注入点的选择与埋桩方式运行时注入模式的关键是找到合适的注入点。ARTEMIS 支持三个层级的注入应用层注入在应用的模型调用封装处埋桩拦截输入输出。这种方式最贴近业务逻辑能拿到完整的 prompt 和原始输出。推理框架层注入在推理引擎的 API 边界埋桩能拿到 token 级别的流式数据、耗时分解、显存占用。系统层注入在更底层的位置采集资源指标比如 CPU/GPU/NPU 利用率、内存带宽。选择哪个层级取决于你要测什么。如果测的是“业务逻辑是否正确组装了 prompt”用应用层如果测的是“推理性能是否达标”用推理框架层如果测的是“资源占用是否在预算内”用系统层。实操中我建议优先在应用层埋桩因为这一层的接口相对稳定不容易随推理框架版本升级而失效。推理框架层的钩子虽然数据更细但不同框架的 API 差异大维护成本高。4.2 数据采集与性能指标定义运行时注入模式最大的优势是数据丰富。ARTEMIS 默认采集的指标包括指标名称含义采集位置首 token 延迟从请求发出到第一个 token 返回推理框架层总推理耗时从请求发出到最后一个 token 返回推理框架层token 生成速率每秒生成的 token 数推理框架层峰值内存占用推理过程中内存峰值系统层输入 token 数prompt 长度应用层输出 token 数生成结果长度应用层这些指标单独看意义不大要结合基线对比才有价值。比如首 token 延迟在冷启动和热启动下可能差好几倍。ARTEMIS 的做法是为每个指标维护一条历史基线每次运行后自动对比超出阈值就标记异常。这里有个容易忽略的点token 生成速率不是恒定的。模型在生成不同内容时速率会有波动尤其是遇到需要“思考”的复杂问题时。所以判断性能异常不能只看平均值要看分位数比如 P95、P99。我在项目里就遇到过平均值正常但 P99 严重超标的情况追查下去发现是某些特定输入触发了长上下文处理导致个别请求特别慢。4.3 注入模式下的断言策略注入模式的断言和设备交互模式不太一样。设备交互模式主要断言“用户看到的输出对不对”注入模式则可以断言更底层的东西prompt 组装断言检查实际发给模型的 prompt 是否符合预期模板有没有多拼、漏拼、转义错误。输出格式断言检查模型返回的结构化数据比如 JSON是否合法字段是否齐全。性能阈值断言检查各项性能指标是否在预算内。资源约束断言检查内存、显存占用是否超过设备上限。这些断言在设备交互模式下要么做不了要么做起来很别扭。比如 prompt 组装你在 UI 上根本看不到只能靠注入模式来验证。注意注入模式的断言不要过度依赖模型输出的具体内容。模型有随机性同样的输入可能给出不同措辞。断言应该聚焦在“结构、格式、关键信息是否存在”上而不是逐字匹配。5. 两种模式的切换机制与协同策略5.1 用例标记与自动分发ARTEMIS 的用例描述里有一个mode字段可以填device、inject或both。调度器根据这个字段决定执行路径。标device的用例走设备交互执行器适合端到端场景验证。标inject的用例走运行时注入执行器适合性能回归和逻辑校验。标both的用例会在两种模式下各跑一遍然后对比结果。both这个标记很有用但不要滥用。因为两种模式的执行环境不同有些结果天然会有差异比如耗时强行对比只会产生噪音。我一般只在**验证“注入模式结论是否能代表真机表现”**时用both比如新引入一个推理后端先用注入模式跑一批再用设备模式抽样验证确认两者结论一致后后续回归就只用注入模式。5.2 结果对比与差异归因当同一批用例在两种模式下跑出不同结果时需要一套归因逻辑。ARTEMIS 的报告会把差异分成几类输出内容差异设备模式和注入模式拿到的模型输出不一致。这通常意味着 UI 层有截断、格式化或缓存逻辑干扰。性能差异注入模式快、设备模式慢。这是正常的差异幅度才是关注点。断言结果差异一种模式通过、另一种失败。这往往是最有价值的信号说明某个问题只在特定环境下暴露。我在实际使用中最常遇到的是“注入模式通过、设备模式失败”的情况。追查下来大部分是 UI 层的异步处理问题比如输出还没渲染完就被断言了或者流式输出在 UI 上做了节流导致文本不完整。这类问题在纯注入模式下永远发现不了这也是双模式架构存在的意义。5.3 执行顺序与资源调度两种模式的执行顺序也有讲究。我的建议是先跑注入模式快速筛掉明显的逻辑错误和性能退化。注入模式通过后再跑设备模式做端到端确认。如果时间紧张设备模式可以只跑核心路径用例全量回归交给注入模式。这样安排的好处是大部分问题在快速阶段就被拦截了不会浪费宝贵的真机时间。ARTEMIS 的调度器支持这种“分级执行”策略你可以在配置里定义哪些用例属于“快速筛选层”哪些属于“最终确认层”。6. 实操中常见的坑与排查技巧6.1 设备交互模式的典型问题问题一定位成功但点击无效。这种情况通常是元素被遮挡或者点击坐标落在了不可点击区域。排查方法是先截图确认元素位置再检查是否有透明遮罩层。ARTEMIS 在点击后会校验界面是否发生了预期变化如果没有变化会重试并记录。问题二流式输出抓取不完整。前面提过结束判断太早会截断。解决办法是增加“文本稳定窗口”比如连续 1.5 秒文本无变化才认为结束。但这个窗口不能太长否则会拖慢整体执行。我的经验值是 1 到 2 秒之间根据模型输出速度调整。问题三多设备并行时结果互相干扰。如果测试用例涉及账号登录或本地存储多设备共享同一套测试数据会出问题。解决办法是为每个设备分配独立的数据空间或者用设备标识做数据隔离。6.2 运行时注入模式的典型问题问题一注入钩子随版本升级失效。这是注入模式最大的维护痛点。缓解办法是尽量在稳定的接口层埋桩并且为钩子写自检逻辑启动时先验证钩子是否生效不生效就快速失败并告警。问题二采集数据本身影响性能。如果钩子里做了大量计算或同步 IO会拖慢推理本身导致测出来的性能数据失真。原则是钩子里只做轻量级数据收集重处理放到异步队列里。问题三注入模式下的内存占用和真机不一致。注入模式跑在模拟环境或开发机上内存模型和真机不同。所以资源类断言要以真机数据为准注入模式的数据只能做趋势参考。6.3 问题速查表现象可能原因排查方向设备模式定位失败率高UI 结构变化或降级策略不当检查无障碍标识、调整定位优先级注入模式性能数据异常好钩子未生效或环境过于理想验证钩子自检、对比真机基线两种模式输出不一致UI 层截断或格式化干扰对比原始输出和界面输出并行执行超时增多设备资源抢占降低并行度、做设备分组断言偶发失败模型输出随机性改用结构化断言、增加重试7. 我对这套架构的实际体会双模式架构听起来是个“既要又要”的设计但真正落地后你会发现它最大的价值不是让你同时拥有两种能力而是强迫你把测试意图和执行方式分开思考。以前写测试脑子里想的是“怎么点这个按钮”现在想的是“我要验证什么用哪种方式验证最合适”。这个思维转变比任何工具都重要。我在几个项目里推行这套模式后最直观的变化是回归测试时间从半天压缩到一小时以内同时线上暴露的端侧问题反而少了。原因很简单注入模式帮你快速覆盖了大量逻辑分支设备模式帮你守住了真实体验的底线两者各司其职没有短板。如果你正准备给自己的移动端 LLM 应用搭测试体系我的建议是先从注入模式做起把核心逻辑和性能基线跑通再逐步补设备交互模式。不要一上来就追求双模式全量覆盖那样维护成本会让你怀疑人生。先把一条路径跑顺再扩展这才是可持续的做法。