定制软件项目验收：功能、数据与文档怎么核对

验收前先确认“按什么验收”

合同、需求文档、原型和变更记录，是验收的依据。如果过程中有过口头调整，最好在验收前补成书面清单，注明哪些纳入本期、哪些放到后续版本。否则双方对“应该有什么”的判断不一致，验收很容易变成谈判。

一、功能核对：按业务路径走，而不是按菜单点

用真实场景串起来

不要只逐个菜单点开，看页面是否存在。按角色走完整流程：谁录入、谁审核、谁查看、异常如何处理。例如一条订单从创建到关闭，中间涉及状态变化、通知、撤回和超时。走通一条链路，比点二十个页面更容易发现问题。

边界情况要有清单

空数据、超长文本、重复提交、并发操作、网络中断后重试，这些情况最容易在上线后暴露。可以让开发方提供自测记录，验收时按记录抽查，而不是完全随机点选。

二、权限与数据

角色与可见范围

列出所有角色，逐一确认能看到什么、能操作什么。特别注意跨部门、跨层级的数据可见性，以及人员离职或调岗后的账号处理方式。权限设计如果只靠前端隐藏按钮，也要在验收时确认后端是否做了校验。

数据准确性

抽查统计口径：列表数量与详情是否一致，导出文件与页面数据是否一致，时间范围是否按预期时区计算。涉及金额、库存、积分的计算，建议准备一组已知答案的测试数据，逐项核对结果。

数据迁移

如果从旧系统迁移，要核对总量、抽样明细和附件是否完整。迁移前做好备份，迁移后保留回滚方案。迁移脚本由谁执行、执行多久、期间是否停止录入，也需要提前约定。

三、接口与文档

第三方接口

短信、支付、地图、发票等外部服务，要确认账号归属、额度、失败重试和日志记录。接口不可用时，系统给出什么提示，也需要实际验证。很多上线故障不是主流程写错，而是外部服务异常时没有兜底处理。

技术文档

至少应有部署说明、账号与权限说明、数据结构或接口说明、常见问题处理。文档不是形式，换人维护时能省下大量沟通成本。验收时可以现场按文档操作一遍，看是否与系统实际一致。

四、上线切换

时间与回滚

选择业务低峰期切换，提前约定回滚条件和操作人。上线后的一段时间内，安排人盯关键指标，而不是等用户反馈后再排查。

培训与交接

给实际使用者的操作说明要简短、按场景写。管理员需要知道账号怎么开、权限怎么改、日志在哪里查看。交接时确认服务器、域名、第三方账号的实际控制权归属。

验收清单示例

• 需求清单逐项标记：通过、待修、不纳入本期。
• 角色权限矩阵，注明每个角色的可见范围与操作权限。
• 关键业务流程走查记录，包含异常分支。
• 数据迁移核对结果，含总量与抽样明细。
• 文档与账号交接清单。
• 遗留问题及处理时间约定。

遗留问题怎么处理

验收很少一次全部通过。把问题分为阻塞上线、影响使用、体验优化三类，分别约定处理方式。阻塞项修完再上线，体验类可以列入后续版本。所有约定写进验收记录，由双方确认，避免口头答应后无人跟进。

结语

验收的目标不是挑错，而是确认系统能按约定支撑业务。清单越具体，后续维护越省心；记录越完整，出现分歧时越容易说清楚。