端侧 AI UI 状态与可点击动作测试

直接回答

UI 状态测试验证的是应用状态与用户可见行为之间的产品契约：屏幕是否解释当前情况、只提供有意义的操作，以及用户操作是否通过预期状态所有者产生下一状态。它不是证明模型运行过的测试，不是验证 Flow 时序的 fake 引擎测试，也不是辅助技术审计。必须把这些证据边界分开，否则一个通过的截图或 Compose 点击用例会被误写成推理任务完成。 从状态类型和真实可达路径开始。共享 ModelState 枚举声明 NOT_DOWNLOADED、DOWNLOADING、DOWNLOADED、LOADING、READY 和 ERROR。当前 ModelManager 会为部分方法赋这些状态，但写测试前要查实际状态写入：下载错误与捕获到的加载异常当前会回到 NOT_DOWNLOADED，而 ERROR 虽在 UI 分支出现，可能没有 Manager 发射路径。把不可达分支当成契约差异调查，不能称其已由 Manager 触发。产品页面也可能根据权限、已选输入、输出校验再派生 UI 状态；要分别命名，不要压缩成一个 loading 布尔值。 先写状态到动作表。每个 UI 状态列出标题/说明、进度或结果区域、可用按钮，以及何种事件会让状态改变。缺少模型时可以提供已有的设置/下载操作；下载中可以显示进度，并按产品策略隐藏重复启动入口；模型已下载时仍可能尚未 READY，不能仅凭文件存在启用要求已加载引擎的动作；错误状态只有在应用确实实现重试或修复时才显示相应入口。不要因为其他应用有取消、设置、权限页面或后台完成按钮，就为当前产品臆造这些能力。 不启动 LiteRT-LM 也能测试状态化页面。Compose UI 测试可以用给定状态设置内容，通过文字或 semantics 查找节点、断言显示/启用状态并执行用户操作。若页面接收 ViewModel 或 provider，可用确定性 fake 触发下一状态。交互测试要断言两端：期望回调只调用一次，随后界面用响应状态呈现正确内容。静态状态下点击后节点仍可点，只能证明控件存在，不能证明状态转换发生。 每条转换也测试重要的禁止操作。产品不允许重复加载时，LOADING 不应再次启动；没有模型时不能呈现可完成的推理动作；失败或不可用不能显示成功；快速切换状态后不能保留过期结果。核对进度标签、错误说明和结果按钮是否与状态源一致。若 StateFlow 快速变化，测试应检查当前值和有意义的用户结果，而不是要求晚启动的 collector 一定观察到每个瞬态中间值。 Composable 不应拥有 native 模型。Preview 或 Compose 测试应接收状态和回调，不应在组合副作用里创建引擎。只有真实代码存在可注入边界时，才能用 fake repository 或状态持有者；当前 ModelManager 依赖 Context 并拥有具体依赖，不能声称它可从一个不存在的构造参数换成 fake。屏幕测试可用假状态源，另用独立测试验证 ModelManager 集成。 无障碍仍需单独评估。Compose 测试和 semantics 有关联，但本文不测 TalkBack 播报频率、switch access 或焦点移动。semantics matcher 可以作为查找和操作 UI 节点的测试方式，却不会自动把测试变成无障碍审计。视觉状态正确也不能证明私有请求没有离开设备或模型输出有效。结论只应涵盖夹具实际断言的内容。 使用稳定夹具并隔离状态。每个测试设置一种状态，断言对应文案和控件，执行有意义操作，再提供下一状态并断言新契约。不要 sleep 等待异步行为，应驱动 fake 事件或等待 Compose 同步。只有当页面契约拥有进程或导航行为时，才把这些列为此类测试。截图不应是按钮启用状态或任务完成与否的唯一断言。 报告应记录页面、状态夹具、事件、回调次数、前后状态、渲染说明、控件可用性和未测试部分。Compose 用例通过，仅证明该构建中的屏幕如何表示给定状态，并按用例调用操作；它不证明仓库已下载字节、runtime 已加载模型、生成结果正确，或所有用户都能使用该流程。

下载完成但模型还没有达到 READY

Compose 首页根据 ModelState 派生主操作。测试夹具报告 DOWNLOADED，但 runtime 尚未到 READY。团队需要确认用户能区分两种状态，点击后也不会被显示成任务已经运行。

决策

用给定状态分别渲染页面，断言文案和按钮可用性；后续事件进入独立 loading 或任务状态，不能伪造成功。

预期结果

界面只表达测试所覆盖的准确状态，并提供真实下一步，不声称模型文件已经加载或用户任务已经完成。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• COVE-LIFECYCLE-01：当前 ModelManager 声明并驱动模型下载、加载和 ready 等状态；需按实际赋值路径验证可达状态。
• ARCH-01：本内容系统把端侧 AI 定义为推理在用户设备执行；界面状态本身不能证明实际推理发生位置。

发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。

实施流程

1. 盘点可达和仅声明的状态. 阅读状态所有者与 UI 映射。区分当前代码会赋值的枚举和声明但无赋值路径的分支，并记录权限、输入、输出校验或导航派生状态。
2. 编写状态到动作表. 逐一列出说明、进度或结果、按钮启用规则和按钮发出的事件；包括产品禁止的操作，例如模型未就绪时推理或下载中的重复启动。
3. 使用给定状态渲染. 用屏幕状态与回调设置 Compose 内容，或使用真实存在的可注入状态源。查找节点、断言文字和启用状态，不在组合中构造 native 引擎。
4. 执行操作并驱动下一状态. 点击有效动作，断言回调或 provider 只调用一次，再提供响应状态并核对新界面。只测试按钮存在不是转换测试。
5. 覆盖禁止与过期状态. 确保缺失、失败和加载状态不会显示虚假成功，禁用的操作不可触发，新任务开始时旧结果会清除或明确标记。
6. 拆分相邻证据类型. 可用 semantics 查找元素，但不要据此声称已完成无障碍审计。ModelManager、fake Flow、native 推理、网络隐私和输出正确性分别验证。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 每个被测 UI 状态都有明确文案、可见控件、启停规则和预期事件映射。
• 有效操作只调用预期回调一次并呈现给定下一状态；静态按钮断言不会被报告成任务成功。
• 结果指出仅声明但不可达的状态，不从 Compose 断言推导模型执行、无障碍认证、隐私或输出正确性。

决策对照表

需要避免的失败模式

• 把枚举中存在的 ERROR 分支说成 ModelManager 一定会发出；当前实际状态更新要逐条检查。
• 把静态按钮可见或语义节点断言说成模型已加载、请求已完成或无障碍认证。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• 端侧 AI 架构概览
• Android Developers：测试 Compose 布局和交互
• Android Developers：Compose semantics
• Android Developers：使用测试替身

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题