表格较宽时，可以用键盘方向键或触控手势横向滚动查看完整内容。
软件项目验收，不是开一次演示会，也不是负责人登录后点几下页面。真正的验收要回答三个问题：系统是否按约定工作、真实员工能否完成业务、出现问题后是否能够恢复和追责。
这份指南适合订单、库存、售后、客户、项目管理和轻量生产系统。复杂 MES、ERP、医疗、金融或关键信息系统还需要结合合同、行业规范和专业测试要求，不能只依赖通用清单。
验收前先收齐 8 项资料
| 资料 | 用途 | 没有时的风险 |
|---|---|---|
| 合同与范围附件 | 确认交付边界 | 演示内容与合同无法对应 |
| 最终原型或需求清单 | 确认页面和流程 | 双方依赖口头记忆 |
| 变更记录 | 确认新增、取消和延期项 | 临时需求混入验收 |
| 角色权限表 | 检查数据访问边界 | 只测管理员账号 |
| 数据迁移说明 | 核对数量和字段 | 数据缺失无法定位责任 |
| 部署与备份说明 | 验证运行和恢复 | 只知道“服务器已部署” |
| 操作手册 | 让真实员工独立操作 | 培训结束后无人会用 |
| 已知问题清单 | 决定阻断或限期修复 | 问题被口头带过 |
如果需求本身还没有形成可测试场景，先用7 天需求盘点方法补齐“操作—预期结果”。
第一步：建立验收台账
不要在聊天记录里零散反馈。建立统一表格，每个问题有编号、证据和处理结论。
| 编号 | 场景 | 操作步骤 | 预期结果 | 实际结果 | 证据 | 严重度 | 状态 |
|---|---|---|---|---|---|---|---|
| UAT-001 | 销售提交订单 | 选择客户并提交 | 进入主管待审列表 | 符合 | 截图/日志 | — | 通过 |
| UAT-002 | 越权查看客户 | 修改 URL 访问其他组客户 | 返回无权限 | 显示了客户名称 | 录屏 | 阻断 | 修复中 |
建议把严重度分为三档：
- 阻断：核心流程不能完成、数据错误、越权、无法恢复；
- 重要：有替代办法，但会明显影响日常使用或效率；
- 一般：文字、间距、非关键提示等，不妨碍业务闭环。
“是否通过”应按合同和业务风险决定，不宜只按问题数量决定。一个越权漏洞可能比二十个样式问题更严重。
第二步：按真实业务做功能验收
从真实业务中选择 5—10 个脱敏样本，不要只用开发方准备的“完美数据”。至少覆盖：
- 正常创建并完成一条记录；
- 修改、撤回或退回；
- 缺少必填信息；
- 重复提交；
- 跨部门流转；
- 查询、筛选和导出；
- 已结束记录再次操作。
每个场景都由实际岗位员工操作，项目负责人只观察，不替员工点击。记录完成时间、卡住位置和是否需要口头指导。员工只有在开发人员提示下才能完成的流程，不能算真正可用。
第三步：做权限验收
为每个角色准备独立账号，逐项检查“能做什么”和“不能做什么”。尤其要测试直接访问链接、导出、批量操作和离职账号。
| 权限场景 | 验收动作 | 通过标准 |
|---|---|---|
| 部门数据隔离 | A 部门账号访问 B 部门记录链接 | 页面和接口都拒绝访问 |
| 审批权限 | 普通员工尝试调用审批操作 | 操作不可执行并有日志 |
| 敏感字段 | 非财务角色查看回款或成本 | 字段隐藏或脱敏 |
| 导出权限 | 无导出权限角色发起导出 | 无法生成或下载文件 |
| 离职处理 | 禁用账号后再次登录 | 会话失效，历史归属保留 |
只隐藏按钮不等于权限控制。验收时应确认后端接口同样拒绝未授权操作。
第四步：核对迁移数据
数据验收不要逐条全看，也不能只对总行数。采用“总量核对 + 分层抽样 + 关键金额汇总”：
- 比较客户、订单、产品等各表总数；
- 按年份、部门、状态分组比较数量；
- 抽查最新、最早、金额最大、字段最全和存在空值的记录；
- 对订单金额、回款金额、库存数量等做汇总核对；
- 检查附件能否打开、原始编号是否保留；
- 记录未迁移数据及其保留位置。
| 数据集 | 源数据 | 新系统 | 差异 | 结论 |
|---|---|---|---|---|
| 有效客户 | 1,248 | 1,248 | 0 | 数量通过，继续抽样 |
| 近两年订单 | 8,420 | 8,417 | -3 | 查明三条失败原因后复测 |
表中数字只是格式示例，实际验收必须使用企业自己的核对结果。
第五步：测试异常与恢复
正常流程通过后，主动制造可控异常：网络中断、重复点击、上传错误格式、审批人停用、第三方消息失败、导入文件缺列。
重点观察四件事：是否给出可理解提示、是否产生重复数据、是否记录错误、恢复后是否能继续处理。
不要在生产环境直接断数据库或删除真实数据。涉及基础设施故障的演练，应在测试环境执行，并由运维人员准备回滚方案。
第六步：验收性能和容量
“打开很快”不是验收口径。先选择关键操作，再约定数据规模、并发条件和可接受时间。例如：在 10 万条订单数据下，按订单号查询；20 名员工同时提交；导出一个月数据。
| 关键操作 | 测试条件 | 记录指标 | 业务判断 |
|---|---|---|---|
| 订单查询 | 约定数据量、公司网络 | 响应时间、失败率 | 是否影响客服接单 |
| 批量导入 | 约定文件行数 | 总耗时、错误明细 | 是否能定位失败行 |
| 月度导出 | 约定字段和范围 | 生成时间、文件完整性 | 是否满足财务使用 |
具体阈值应在合同或需求阶段商定，不能从其他项目直接套用。国家标准信息公共服务平台对 GB/T 25000.23-2019 的说明指出，该标准提供系统和软件产品质量测量的基本集合，适用于开发、获取和维护等活动。这里可借鉴的原则是：质量判断应落到明确测量条件，而不是形容词。
第七步：验证备份、恢复和日志
要求服务商现场说明并演示：
- 数据库和上传文件分别怎样备份；
- 备份频率、保留周期和存放位置；
- 谁能访问备份；
- 最近一次备份是否成功；
- 如何恢复到测试环境；
- 关键操作是否有用户、时间、对象和结果记录；
- 日志保留多久，谁负责查看告警。
“配置了自动备份”不等于可恢复。至少应完成一次不影响生产的恢复验证，并记录耗时和结果。
第八步：完成文档与账号交接
上线验收还应包括所有权交接：
| 交接项 | 应确认内容 |
|---|---|
| 域名与云账号 | 注册主体、管理员、二次验证、续费人 |
| 源代码与仓库 | 访问权限、分支、部署说明、第三方依赖 |
| 数据库与存储 | 账号归属、备份、容量和费用 |
| 第三方服务 | 短信、邮件、地图、支付、AI API 的归属 |
| 文档 | 操作、部署、恢复、接口和已知问题 |
| 支持边界 | 质保期、响应方式、收费变更和紧急联系人 |
密码不要写进验收报告或通过普通群聊长期保存。使用密码管理工具交接，并在人员变动后轮换密钥。
一个可直接使用的验收评分表
评分只能辅助决策，不能覆盖阻断问题。建议先设置“一票阻断项”：核心流程失败、严重越权、关键数据不一致、无可用备份等未解决时，不进入最终验收。
| 维度 | 建议权重 | 评分依据 |
|---|---|---|
| 核心业务流程 | 30% | 约定场景通过率与阻断问题 |
| 权限与安全 | 20% | 角色、接口、敏感数据和日志 |
| 数据准确性 | 20% | 总量、抽样、汇总和附件 |
| 性能与稳定性 | 10% | 约定条件下的测量结果 |
| 易用性与培训 | 10% | 真实员工能否独立完成 |
| 文档与交接 | 10% | 账号、代码、备份和支持边界 |
每项按 0—5 分评价，再乘权重。验收会议必须同时查看分数、阻断项和遗留清单，而不是只看总分。
遗留问题怎样处理？
不影响核心使用的一般问题，可以形成附条件验收，但必须写清：问题编号、影响、解决方案、负责人、截止日期、复测方式，以及逾期如何处理。
不要接受“后面优化”“有时间再做”这类无期限表述。也不要把新需求伪装成缺陷；是否属于原范围，应回到合同、原型和变更记录判断。
AHAX 的交付建议
AHAX 的项目方法强调先把范围和验收方式写清，再进入开发。第一阶段不追求功能最多，而要保证一条关键流程能够被真实员工使用、被证据验收、出现问题能够恢复。
如果企业正准备评估系统开发，也可以先查看服务范围和企业数字化项目预算拆解。需要沟通现有项目时，可通过联系页面提供脱敏需求、当前阶段和最担心的验收风险。
参考依据
- 国家标准信息公共服务平台：GB/T 25000.51-2016：用于说明质量要求与测试细则的关系；本文为通用实操指南，不代表替代标准全文或专业认证。
- 全国标准信息公共服务平台：GB/T 25000.23-2019：用于说明软件产品质量测量应对应明确特性、条件和用途。
- 工业和信息化部：《中华人民共和国数据安全法》：用于数据处理、交接、备份和访问责任的合规提醒。
- NIST Secure Software Development Framework：用于交付阶段的安全验证、角色责任和持续维护参考。