定制软件验收不能只按功能菜单打勾。一个按钮能点、一个页面能打开，只能说明界面存在；业务是否能从录入走到审批、计算、提醒、报表和异常处理，需要用完整用例证明。
验收争议常在开发前就埋下。客户说要“订单系统”，实际可能包含销售报价、库存占用、生产排程、发货对账和回款提醒；服务商若只按页面理解，双方看到的“完成”并不相同。测试前应把这些动作逐项对应到合同、需求和用例，未约定的新增内容单列变更，已约定的链路不能用页面演示代替。
把需求条目改写成可执行标准
“支持订单管理”“权限灵活”“报表方便”都无法直接验收。可执行标准应包含前置数据、操作角色、步骤、预期字段变化和异常结果。例如，销售提交订单后由谁审批，驳回后哪些字段可改，库存何时占用，作废后是否释放，财务能看到哪些金额。
验收前应确认五份依据：合同范围、需求规格、最终原型、数据与权限规则、验收用例。临时口头约定要么补进文件，要么明确列为范围外事项。
功能验收要跑完整业务链
单个模块测试通过，不代表模块之间能协同。选择一笔可识别的测试业务，从创建、审批、流转、修改、查询到归档走完，并核对每一步的状态、通知和责任人。涉及导入导出时，还要检查字段格式、重复数据和失败提示。
跨系统流程应同时核对源系统和目标系统，不能只看接口返回“成功”。订单、库存、合同、回款等关键对象要确认数据方向和主系统，避免两边都能修改却没有覆盖规则。
数据验收要对口径和边界
金额、数量、日期、状态和汇总指标都应有计算规则。验收人员可从报表结果追溯到原始单据，再从原始单据重算汇总，确认筛选范围、舍入方式、作废记录和历史版本是否处理一致。
历史数据迁移要核对总量之外的细节，包括编码、关联关系、附件、空值和重复记录。若某类数据不迁移，应在交付范围中明确，而不是上线时才发现。
权限验收用角色矩阵逐格检查
权限不能只测试“能不能进入菜单”。每个角色都要核对可查看、可新增、可修改、可删除、可导出和可审批的范围；部门隔离、数据负责人变更、离职交接等场景也要覆盖。
敏感字段即使不显示在页面，也应检查导出文件、接口返回和操作日志是否暴露。管理员权限、临时授权和授权回收需要有明确记录。
异常用例比正常演示更能发现问题
验收清单应包含重复提交、必填项缺失、库存不足、审批撤回、流程超时、接口失败、网络中断和无权限操作。预期结果不仅是“不报错”，还包括用户能否看懂提示、数据是否保持一致、任务是否可继续处理。
缺陷、需求变更和使用问题要分开登记。缺陷对应原约定未实现；变更是新增或调整范围；使用问题通过说明和培训解决。分类清楚后，修复责任和验收节奏才不会混在一起。
签字前核对证据与交接物
每个验收项应保留测试账号、输入数据、结果截图或日志、问题状态和确认人。最终交接还应包含部署说明、账号权限、数据备份与恢复方式、操作手册、源代码或构建物的交付边界，以及售后响应方式。
验收单可以保留遗留项，但要写明影响范围、临时处理方式、完成条件和责任方。没有证据的“基本可用”不应替代明确的验收结论。
