把“没问题”换成一组可观察的结果
示例工具把订单表导入登记台账。验收目标可以写成：“A001和A002各新增一条；相同内容再次导入不新增；订单号缺失的行进入异常表；原表不改动。”这些要求都能通过记录和文件核查。
先保存输入样本和预期结果，再交给工具运行。如果运行后才依据输出解释“这样也算对”，就失去了验收标准。业务负责人负责确认订单的正确含义；实施人员负责说明工具怎样处理这些条件。
用六种小样本覆盖关键失误
| 样本 | 输入条件 | 预期结果 |
|---|---|---|
| 正常新增 | A001、A002各一行 | 新增2条，来源行可回查 |
| 完全重复 | 再次导入同一份文件 | 新增0条，2条标记已处理 |
| 关键项缺失 | 一行无订单号 | 拒绝该行，说明缺少字段 |
| 同号不同值 | A001的数量被改动 | 进入冲突清单，不悄悄覆盖 |
| 执行中断 | 一部分写入后停止运行 | 已完成与未完成可区分，续跑不重复 |
| 权限不足 | 只读账号尝试导入 | 不写入，提示缺少操作权限 |
这是一组起点，不是所有工具通用的完整测试。改名工具要加重名与原路径被占用；报表工具要加截止时刻与空值；涉及对外发送的流程还要验证试运行不会发送真实通知。
先检查结果，再检查提示是否诚实
运行“同号不同值”样本后，既要看到冲突提示，也要去台账确认A001原数量没有被改。运行中断样本后，不能只看“可重试”按钮，还应核对已经提交的记录与再次运行后的总数。
每次验收记录工具版本、配置、输入文件、实际结果和证据位置。出错后修复了程序，应保留原失败记录，并在新版本下复测同一个样本。只重新跑一个正常样本，不能证明导致故障的条件已消除。
决定什么问题必须阻止投入使用
可先约定三类处理：丢数据、算错关键结果、越权读取、重复写入属于阻断项；无法回查失败记录或缺少必要提示，应在正式操作前补齐；不影响使用的文字和间距问题可以登记后续日期。分类应结合业务影响，不按“修改起来难不难”来定。
性能也应落到实际规模，例如用团队现有的一批订单记录完成计时，记录运行设备、条数和耗时，再由使用方判断是否满足工作时间。没有实际数据就不承诺“支持任意大文件”。
让将来真正使用的人完成最后一轮
接手人员仅依据操作说明，完成选择文件、预览、执行、查异常、修正后重跑的全流程。需要开发者不断口头提醒的地方，补到页面提示或文档里。最终验收单写明通过的版本、未解决问题、允许使用范围及复验条件；不能用一次演示通过代替后续所有变更的验收。