flutter-device-testing

Flutter 设备测试

使用能证明变更行为的最小目标矩阵，然后说明测试了什么、未测试什么。将运行时目标与流程所用的数据源分别说明。

操作前先了解情况

检查项目的 SDK、支持的平台、flavor、入口点和现有测试工具。运行 flutter devices；如果需要启动虚拟目标，则运行 flutter emulators。通过稳定标识符解析一个目标，记录它是复用的还是为任务创建的，并等待其就绪。未经明确需要和授权，不得擦除、重置、重建用户的目标，也不得从中卸载应用或清除数据。

对于 Flutter 管理的状态，优先使用 Flutter CLI 和可用的 Dart、Flutter MCP 功能。仅在 adb 或 simctl 能提供相应平台控制时才使用它们。Flutter 查找器无法操作权限对话框、通知栏或平台视图等原生系统 UI；如果需要此类交互，请使用项目已采用的原生兼容测试框架。不要仅仅因为熟悉，就引入 Patrol、Maestro、Appium 或其他框架。

工作流

1. 确认依赖项和生成的代码已就绪，同时不改变项目的包管理或架构选择。
2. 在改变运行时状态前，确认目标已就绪，并核实特定 flavor 的应用标识。
3. 使用正确的 flavor、入口点、defines 和构建模式启动；绝不要将凭据放入命令参数或留存的产物中。
4. 执行准确的用户流程以及相关生命周期或平台状态。区分状态注入与观察真实提示、提供方或 OS 投递路径。
5. 捕获与受测构建相对应的精简断言、截图和筛选后的日志。需要可持续自动化时，运行项目的集成测试或原生 UI 测试框架。
6. 恢复为任务创建的目标覆盖设置，并且只移除任务创建的产物；即使失败也要执行清理。

可靠性

不要认为构建、启动命令或 OS 触发成功就能证明应用行为正确。优先使用语义查找器、无障碍标识符或集成 API，而不是硬编码坐标；优先使用有明确时限的就绪条件，而不是任意休眠。要声称温启动，必须先明确证明触发前进程和 UI 处于预期状态。使用生命周期运行器时，确认每个钩子都继承了有界超时，并确认在成功、失败、超时或命令出错后，都会通过 finally 路径尝试执行 after 清理。

报告目标类型和安全标签、OS／运行时、构建模式、flavor、入口点或相关 defines、准确的流程、数据源、断言、产物以及跳过的边界。默认不要公开真实设备的原始标识符。模拟器或仿真器上的行为只能作为功能性证据，不能证明物理硬件性能、GPU、摄像头、传感器、OEM 或生产环境推送能力。将基准测试归因交由 flutter-performance 处理，并在具有代表性的真实设备上以 profile 或近似 release 的模式验证更强的硬件相关声明。

参考资料

• 阅读设备发现和模拟器，了解共享目标选择、所有权、就绪状态、安全和证据规则。
• 使用 Flutter 和 adb 启动或控制 Android 虚拟或实体目标时，请阅读 Android 模拟器操作。
• 使用 Flutter 和 simctl 控制 Simulator 时，请阅读 iOS Simulator 操作，其中包括权限、位置、屏幕截图或模拟推送。
• 当 Agent 需要通过平台无障碍树（idb、uiautomator）读取或驱动正在运行的应用、Flutter 屏幕的无障碍树为空，或需要稳定的 Semantics 标识符而非坐标或反复截屏时，请阅读语义 UI 检查。
• 编写或运行 package:integration_test 测试套件、深层链接，或在运行中的目标上执行冒烟测试时，请阅读集成测试工作流。
• 需要跨冷启动／热启动、身份验证、重复投递、数据加载缓慢或账号变更重放深层链接或通知点击时，请阅读生命周期入口矩阵。解析占位符，并要求附带的运行程序试运行成功退出且生成预期计划，然后再添加 --execute。

来源

• Flutter CLI
• 集成测试
• Dart 和 Flutter MCP 服务