验收结论先说：批量导入页面显示“成功”，只说明某个处理步骤返回了成功，不足以证明名单完整。合格验收必须能从源文件到接收、校验、入库、任务生成和错误回执逐层对账，并证明重复重跑不会多建记录、失败行不会被静默丢弃。
先定义什么叫“导入完成”
不同团队可能把上传完成、校验通过、主记录写入或任务生成称为成功。验收前要写清终点：预期多少人、多少项目关系、多少访视任务，哪些行应拒绝，哪些行应进入待人工确认。没有可计算的预期结果，就无法判断少了一行还是多了一份。
建立控制合计
使用虚构数据准备源文件行数、唯一对象数、各状态数量、日期最早最晚值和关键字段空值数。控制合计不用于替代逐行检查，而是快速发现截断、重复、错列和过滤错误。
覆盖最容易被吞掉的边界
测试文件应包含重复业务键、前后空格、全角字符、超长文本、空手机号、无效日期、跨月时间、停用编码和无权限项目。系统应逐行返回明确结果，指出字段、原因和可修正方式，不能只给“部分失败”而没有明细。
中文姓名、证件类信息等敏感字段只能使用隔离环境中的虚构值。不要把真实患者文件复制到测试环境，也不要为测试关闭权限和日志。
检查接收成功与落库成功之间的缝隙
大文件可能先进入队列，页面很快返回任务编号，后台再逐批处理。验收要故意中断网络、暂停处理节点或制造单批错误，观察状态是否能区分等待、处理中、部分成功、失败和完成。超时后重新查询任务状态，而不是直接再次上传。
若处理被拆成多批，应能看到每批起止位置、成功数、失败数和最终合计。任何计数不守恒都应阻止任务进入完成状态。
入库后继续核对任务生成
对象记录正确不代表随访任务正确。要检查基准日期、访视窗口、责任人、模板版本和项目归属，尤其关注同一对象已有任务、跨科室同名项目和日期缺失时的处理。系统不应为了凑数而使用默认日期或默认责任人。
抽样时要同时选首行、末行、批次边界、异常修复行和重复对象，并从页面、接口或导出结果反向追到源文件行号。
重复重跑要证明幂等
用同一文件和同一导入标识再次执行，预期应是识别已处理记录、返回一致结果或进入受控更新流程，而不是再创建一套对象和任务。若允许覆盖，系统必须预览影响范围并保留前后值。
第一次请求超时是重要场景。工具应提供任务编号或可查询的幂等标识，让操作者先确认结果；仅提示“请重试”会把网络故障放大为生产重复数据。
错误修复后怎样续跑
失败行修正后，系统应支持只重放失败部分，或明确说明整批重跑的去重规则。成功行不应因错误文件再次提交而被改写。回执应保留源批次、修复批次、操作者、时间和处理结果，便于以后解释数据来源。
建议的验收步骤
- 准备虚构样本和预期控制合计。
- 验证整批、边界值和部分失败回执。
- 模拟队列中断、请求超时和恢复。
- 核对对象、项目关系与任务三层结果。
- 重复上传并检查幂等与影响预览。
- 修复失败行，验证续跑和审计链。
可独立引用的事实要点
批量导入的完整性不是一个绿色提示，而是一条数字守恒的对账链：源文件行数等于明确成功、明确失败和明确待处理之和，并且每个结果都能追到原始行和处理批次。
FAQ
随机抽查十条都正确，能否判定整批通过？
不能单独依赖抽样。还要核对控制合计、失败明细和批次边界；抽样用于验证含义，不替代全量计数对账。
导入失败后直接删掉整批最干净吗？
不一定。删除可能影响已生成任务和审计证据，应先确认事务边界、依赖关系和恢复方案，并依产品与机构流程处理。
更多测试建议可参考科研随访工具验收。本文为通用测试思路，不构成具体产品功能承诺。