直接回答
图像批次是一组可分别识别的任务。好的测试不会把全部输入压缩成一个转圈图标和最终成功提示。每个项目都要保留身份，并显示排队、执行、完成、跳过、拒绝、取消或失败等状态。一张文件损坏时，应用不应静默删除此前结果，也不应把所有项目标为成功。MEMORY-01 与 COVE-OCR-01 支持把资源行为和图像文字处理拆成可测阶段，却不说明 Cove 已支持批处理或能处理固定张数。 围绕用户真实选择的入口定义测试：图片选择器、文档 URI、应用内相机，或用户明确同意后复制的导入文件。这些入口的授权和生命周期不同。将导入、文件头检查、解码、变换、推理、结果审核、保存和导出分别记录。一个批次可能混用 OCR 与图像理解，但每项任务的标签和评估必须指出实际运行了哪条路径，不能用可读描述替代文字识别验收，也不能反过来。 批次的主要风险常是状态和资源数量一起增长。Android 位图指南指出，解码像素占用可能远高于压缩文件，多个同时解码或保留的位图会造成资源压力。这是对目标实现做测量的理由，不是编造安全批量阈值的依据。记录同时在途项目、源流关闭时间、变换图像释放时间和当前工作由哪个运行时会话持有。所有测量注明确切构建和设备；不能把平台文档中的示例换算成 Cove 容量。 运行前冻结清单。给每张图稳定 ID 和预期类别，覆盖普通、旋转、大尺寸、损坏、重复、不支持及空输入，并设定项目之间和项目执行中的取消点。使用合成或明确获准的图像可降低诊断泄漏风险。观察模型输出前先写好预期分类和必要字段。记录样例版本及变换，使后续运行可比较。若用户能重排选择项，验证结果按身份关联，而不是按当前列表位置串号。 说明进度是临时还是可持久恢复。若前台流程会在应用关闭后丢失工作，要如实说明并提供安全重启方式，不能暗示可续跑。持久 worker 需要单独做进程重建与取消测试，涵盖每个选择项 URI 授权期限。批次取消、单项失败和用户移除也要分别建模。某些 Android 工作 API 中取消可能是尽力行为，因此应检查真实 worker、解码器和推理生命周期，而不是认为按钮已经停止 native 工作。 每项都记录阶段起止、失败类别、是否有结果、审核状态和源文件当前是否可访问。普通分析事件和崩溃日志不要放原始照片或识别文字。预览缩略图、中间裁剪图、OCR 字符串及生成输出也属于派生用户数据，应检查存放位置和删除含义。用户可能只想移除一张而保留其他完成项，因此删除测试需落实到单项。 正确性与生命周期分开评估。每个样例都对照预先写好的预期类别或字段。不能只看最后一项，也不能用平均数掩盖失败图像。分别记录识别正确性、队列是否正常结束和任何时延或内存测量。如果重试产生新结果，保留尝试之间的关系，以免未经提示覆盖已审核结果。 报告说明队列策略、逐项状态、受测中断点、资源观察、用户审核和已知排除项。它可以描述这组样例和这个构建，不能从小规模运行推导普遍兼容、离线准备度、性能、隐私或最大容量。批处理测试的价值恰恰在于如实呈现部分结果与不确定性，而不是让多图功能显得比证据更可靠。
外勤人员审核一组巡检图像
外勤人员在进入预期无网络的地点前选择一组获准巡检图像。一张输入损坏，另一张可能在审核后被移除。人员需要逐项结果、清晰批次状态，以及应用进程停止后的安全续跑或重启方式。
决策
冻结稳定清单并分开记录逐项和批次结果；测试 URI 授权与进程中断，不能假设每张图像始终可访问。
预期结果
测试显示哪些项目已完成、失败、移除或待重试，同时保留先前已审核结果。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- MEMORY-01：按确切任务阶段观察资源
- COVE-OCR-01：图像文字任务需有独立证据
任务质量需要有版本记录的语料和验收规则；流畅的单条样例不等于准确度结果。
实施流程
- 冻结项目清单. 为有效、旋转、大尺寸、损坏、重复和空输入分配稳定 ID 与预期类别，记录来源入口及已授权的变换。
- 观察阶段和资源归属. 分别记录导入、解码、预处理、推理、持久化和审核，包含活动项目数及文件流、位图和运行时工作的释放。
- 注入单项错误并移除项目. 让一项解码失败、拒绝一项不支持输入、在选择后移除另一项，确认每次状态始终关联正确源文件。
- 中断并取消批次. 在开始前和执行期间取消，重建应用进程并测试任何声称的持久 worker，核对解码/推理是否停止及 URI 是否仍可访问。
- 审核保留与重试行为. 重试一项失败输入，比较多次尝试而不覆盖已审核结果，再删除一个来源，检查预览和派生文字是否遵循策略。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每项输入都有稳定身份和明确状态；批次成功不能掩盖失败、取消、移除或跳过项目。
- 可复现中断与取消结果；未通过进程死亡测试时，报告不得声称能够续跑。
- 报告区分任务正确性、队列完成度与实测资源，不作通用容量或性能承诺。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 单图运行 | 验证一条处理路径 | 可以检查阶段行为，却无法覆盖队列状态与资源累积。 |
| 只有最终状态的批次 | 只显示整体成功或失败 | 隐藏部分完成，并使单项安全恢复更困难。 |
| 逐项可追踪批次 | 保留稳定 ID 和逐项结果 | 便于审核、重试、移除和处理部分结果，但不承诺容量。 |
需要避免的失败模式
- 用一个最终旋转图标覆盖逐项失败
- 将压缩文件大小当作解码后资源需求
- 未经进程恢复验证就声称可续跑
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
一张图处理成功能证明离线批次可用吗？
不能。要分别测试每种输入入口、任务阶段、失败状态和重新联网行为。离线运行是对受测流程的观察，不可从一次成功推断。
一张图失败是否应该取消其他全部项目？
这是需要定义和测试的产品策略。无论采用何种方式，都应保留已完成结果、显示失败项目，不能在还有未解决工作时报告整批成功。
取消批次就能从中断处精确恢复吗？
只有实现了经测试的持久工作契约时才能这样说。描述续跑前要验证进程恢复、源 URI 授权、项目身份和避免重复处理，并确认部分完成结果不会被静默覆盖。