一物一码项目如何验收？从扫码可用到业务可用的检查清单

一物一码项目上线前，最常见的演示是拿出手机扫一个码，页面立即显示产品资料。这证明了一个入口能工作，却尚未证明码与实物一致、发货记录准确、权限有效或历史能够恢复。本文建议把验收拆成可检查的任务，每项都有输入、操作、预期和证据。

先冻结验收对象

建议写明当前软件版本、配置版本、样品编号、设备及网络条件。不能上午测试一个版本，下午修改后直接沿用上午结论。测试标识应与正式投放标识区分，并保留清单；涉及真实业务时，应由有权人员批准样本和操作，避免在生产数据上随意制造异常。

如果项目采用GS1标识，单件层面的标识组合要符合约定含义。来源：GS1单件序列化说明。采用其他内部编码时，也应记录唯一性范围和生命周期规则，不能只验证字符串没有重复。

七组任务覆盖业务底线

不要把“查询成功”写成唯一预期

每个测试用例应列出具体字段。例如扫描箱码后，预期显示哪几个子码、对应哪张出库单、属于哪个经销商；退货后哪些状态应改变，哪些历史必须保留。测试人员不能仅凭“页面看起来正常”打勾，也不应使用全部由系统自己生成的报表证明系统自己没有错误。

建议从实物抽到记录，也从单据反向抽到实物或标识清单。这种双向检查可以发现漏采和错配。对大批量数据，样本方案应结合风险制定；本文不把某个固定抽样比例宣称为法定或行业通用标准。

严重缺陷先解决再放行

建议把导致身份混淆、跨组织数据泄露、重复业务记账或无法解释历史的缺陷列为阻断项。文字错别字、非关键布局等问题可以另列修复计划，但也应有负责人和完成时间。是否带缺陷上线，应由业务和项目负责人依据影响作出明确决定，不能由开发人员自行宣布通过。

缺陷关闭后应重测受影响链路，并保留修复前后证据。只修改截图或数据库结果，不代表原操作流程已经正确。对于无法在验收时验证的高峰负载或长期材料耐久性，应注明验证方法、已覆盖条件与剩余限制。

交付包决定系统能否持续使用

验收资料建议包含操作手册、岗位培训记录、管理员交接、字段字典、接口责任表、备份策略和故障联系人机制。查询域名、证书及账号的控制权也应清楚。最终结论应写“在什么范围和条件下通过”，而不是笼统写“所有功能正常”。这样，后续扩展、换人维护或供应商变更时，企业仍有可靠依据。