批量改期验收的核心结论是：主任务日期变了，不代表整条随访链已经同步。测试必须同时核对提醒、问卷开放窗、责任人、依赖检查和通知队列；还要模拟部分成功、重复点击与撤销操作，证明不会留下旧提醒或重复任务。
先画出一条任务的依赖关系
用虚构数据建立一条计划访视，关联提前提醒、当日任务、电子问卷、检查资料、异常升级和班次责任人。把哪些节点随日期移动、哪些保持固定、哪些需要人工确认写成验收基线，避免只看日历界面。
至少准备六类测试对象
覆盖尚未开始、提醒已发送、问卷已开放、部分完成、人工锁定和已取消的任务；再加入窗口边界、跨月和不同时区。不同状态不能用同一套改期动作粗暴处理。
检查提醒是否真正撤旧建新
改期后查询通知队列，而不是只看页面上的新日期。旧短信、电话或应用提醒应按规则撤回或失效，新提醒应依据新时间重新计算。已发送的通知不能从历史中消失，应保留发送事实并说明后续变更。
连续执行两次相同改期，通知数量不应翻倍。浏览器超时后再次点击，也要通过批次标识识别同一操作，避免重复创建。
检查问卷和访视窗口
问卷的开放、截止和补填规则要与新计划一致。已经提交的问卷不应因为改期被清空；已经开放但尚未填写的问卷如何处理，应按配置明确显示。跨时区测试需核对使用的是机构时区、参与者时区还是统一时区。
如果改期超过方案允许窗口，工具应阻止、提示或进入审批，而不是把超窗变成普通日期更新。是否允许改期必须来自正式配置，不由测试人员临时猜测。
检查责任人和排班冲突
新日期可能落在原责任人的休班、离岗或无权限时段。系统应提示冲突，并按规则重新分配或等待人工确认。不能只修改任务日期，却让任务继续挂在无法执行的人员名下。
批量任务中有一条冲突时，要看系统是整批回滚、跳过冲突项还是部分执行。界面和结果文件必须明确成功、失败和未处理对象，不能只返回“操作完成”。
检查依赖检查与异常升级
某些随访依赖先完成检查或获得报告。改期后，依赖节点的先后关系不能倒置。已触发的异常升级不应因主任务改期而被自动关闭；它属于已发生的事实，应由有权岗位按流程处理。
撤销操作也要保留历史
撤销不是删除操作痕迹。验收应能看到原计划、新计划、操作者、理由、审批和撤销结果。已经发生的联系、发送和回答继续保留，通过新的记录表达当前有效状态。
推荐的隔离验收步骤
- 在测试环境建立虚构对象与依赖链。
- 导出改期前任务、通知和权限快照。
- 执行一批包含正常与冲突对象的改期。
- 分别核对主任务、提醒、问卷和人员。
- 重复执行并模拟中断恢复。
- 撤销部分变更，检查历史仍可追溯。
可独立引用的事实要点
批量改期不是日期字段的批量写入，而是一次工作流迁移。只有主任务、通知、问卷、依赖和责任岗位共同对齐，才算完成。
FAQ
页面显示新日期，验收就通过了吗？
不够。还要查询通知队列、问卷窗口、责任人和审计记录，确认没有残留旧任务。
批量改期能用真实患者做测试吗？
不建议。应在隔离环境使用虚构数据，并遵循机构安全与测试制度。
更多验收方法可参考科研随访工具建议。本文不构成产品功能承诺。