一、验收不是“试一遍”，而是确认一组证据
很多项目的验收方式是：开发团队开会演示，老板点几下页面，觉得差不多，就在验收单上签字。
这种方式有三个问题：
- 演示通常只覆盖正常流程，异常、权限和数据问题看不出来；
- 演示环境能运行，不代表生产环境可以稳定运行；
- 签字后才追源码、账号和部署资料，议价与协调空间已经很小。
验收应该围绕“证据”展开。每一条需求是否完成、每一个问题是否关闭、每一项资料是否移交，都需要有可回看的记录。
二、第一类资料：需求基线和变更记录
验收的第一份资料不是测试报告，而是“到底按什么验”。
1. 已确认的需求范围
可以是需求规格说明书、功能清单、原型、用户故事或双方确认的表格，但必须能对应到具体功能。
至少要写清：
- 用户角色；
- 功能模块；
- 关键业务流程；
- 数据输入与输出；
- 权限规则；
- 重要异常场景；
- 本期不包含的内容。
只有一句“开发某某管理系统”的合同，无法支撑有效验收。
2. 原型和 UI 确认版本
如果项目包含产品和设计工作，应保留最终确认的原型、页面设计和交互说明。
验收时不要只比较截图是否一样，还要确认：
- 页面状态是否完整；
- 表单校验是否一致；
- 加载、失败、空数据和无权限状态是否实现；
- 移动端或不同分辨率是否在约定范围内适配。
3. 需求变更清单
开发期间新增、删除或调整的需求，应记录：
- 变更内容；
- 提出日期；
- 对费用和周期的影响；
- 双方确认结果；
- 最终纳入哪个版本。
如果没有变更记录，验收时很容易出现两种相反说法：甲方认为“早就说过”，乙方认为“从来不在范围内”。
三、第二类资料：功能测试和缺陷闭环
测试报告不一定要写成几十页，但必须让人看出测了什么、结果如何、还剩什么问题。
1. 功能测试用例
每条核心业务流程至少要覆盖：
- 正常操作；
- 必填和格式校验；
- 重复提交；
- 无权限操作；
- 状态不允许时的操作；
- 数据为空或数据异常；
- 外部接口失败；
- 网络中断或超时。
例如“订单退款”不是只看按钮能不能点击，还要验证退款金额、订单状态、支付状态、通知、操作日志和重复退款防护是否一致。
2. 测试结果
测试结果应当能够对应功能或用例，常见字段包括：
- 测试项；
- 预期结果；
- 实际结果；
- 是否通过；
- 问题编号；
- 测试时间；
- 测试版本。
3. 缺陷清单和关闭记录
项目有缺陷并不等于不能验收，关键是双方要知道剩余问题的级别和处理方式。
可以按影响分为：
- 阻断问题：核心流程无法完成、数据严重错误或存在明显安全风险；
- 严重问题：重要功能受影响，但存在临时绕行方式；
- 一般问题：局部体验或非核心功能异常；
- 优化建议：不影响约定功能，后续版本再处理。
正式验收前，阻断和严重问题通常应关闭；仍保留的问题，要写清修复时间和是否影响付款。具体标准应在合同或验收方案中提前约定。
四、第三类资料：性能、兼容和安全检查
不是所有项目都需要大型压测和专业渗透测试，但必须根据项目风险明确检查范围。
1. 性能资料
至少确认：
- 约定并发或业务量下的响应情况；
- 大数据量列表、导出和报表是否可用；
- 文件上传和批量处理是否会超时；
- 服务端是否有基础监控；
- 出现慢请求时能否定位。
不要把一句“支持高并发”当作验收指标。并发人数、操作类型、数据规模、测试环境和通过标准都要具体。
2. 兼容性资料
根据产品类型确认：
- 浏览器范围；
- 手机系统版本；
- 屏幕尺寸；
- 小程序基础库；
- 企业内部设备；
- 打印机、扫码枪或其他硬件。
合同没有约定“支持所有设备”时，不要在最后一刻无限扩展兼容范围；反过来，乙方也不能只用开发者自己的电脑通过一次就算完成。
3. 安全与权限检查
至少要检查：
- 未登录是否能访问受保护数据；
- 普通用户是否能越权查看或修改其他数据；
- 管理员权限是否可以分级；
- 密码、密钥和敏感配置是否直接写进代码；
- 上传文件是否有限制；
- 关键操作是否有日志；
- 备份数据是否受到保护。
涉及支付、医疗、金融、政务或大量个人信息时，需要根据实际合规和安全要求增加专项检查，不能用通用清单代替专业评估。
五、第四类资料：源代码和构建材料
“源码已交付”不是收到一个压缩包就结束。
完整的源代码交付通常包括：
- 前端代码；
- 后端代码；
- App、小程序或其他客户端代码；
- 数据库建表与升级脚本；
- 定时任务和后台脚本；
- 构建配置；
- 环境配置样例；
- 依赖说明和锁定文件；
- 代码仓库提交历史；
- 分支与版本标签；
- 第三方组件及授权说明。
验收时最好做一次独立构建：在一台没有开发者本地缓存的新环境中，根据文档拉取代码、安装依赖并生成可部署版本。
如果只能在原开发者电脑上运行，或者缺少私有依赖、密钥和构建脚本，源码的可接管价值会大幅下降。
六、第五类资料：部署、环境和运维文档
系统已经上线，不代表部署资料不重要。真正需要它的时候，往往是服务器故障、证书过期或原团队无法联系的时候。
部署资料建议至少包含：
环境清单
- 开发、测试和生产环境地址；
- 服务器和云资源；
- 数据库、缓存、消息队列和对象存储；
- 域名、SSL 证书和 CDN；
- 应用市场与开放平台；
- 日志、监控和告警。
部署步骤
- 构建命令；
- 配置项说明；
- 数据库升级顺序；
- 服务启动与停止；
- 反向代理和网络端口；
- 发布前检查；
- 发布后验证；
- 回滚方法。
备份和恢复
- 备份对象；
- 备份频率；
- 保留周期；
- 存放位置；
- 恢复步骤；
- 最近一次恢复演练结果。
只有“每天自动备份”的截图不够。没有验证过恢复流程的备份，不能确认真的可用。
七、第六类资料：账号、权限和第三方服务
很多项目交接失败，不是因为没有代码，而是关键账号都在个人手机或乙方公司名下。
验收前应形成账号清单：
| 类型 | 常见项目 | 验收重点 |
|---|---|---|
| 云资源 | 服务器、数据库、存储、CDN | 甲方是否拥有管理员权限 |
| 域名证书 | 域名、DNS、SSL | 注册主体、到期时间和续费方式 |
| 开放平台 | 微信、支付、地图、短信、推送 | 主体、权限、密钥和回调地址 |
| 应用商店 | iOS、Android 各市场 | 开发者主体和发布权限 |
| 代码与协作 | Git 仓库、设计稿、接口平台 | 管理员、成员和导出能力 |
| 监控运维 | 日志、告警、统计 | 接收人、阈值和账号归属 |
敏感密钥不要直接写在交付文档里到处传播。更稳妥的做法是通过安全渠道移交，并在交接后重新生成或轮换。
八、第七类资料：数据库和数据校验
只要项目涉及历史数据、财务数据、库存、订单、客户或业务状态，数据验收就不能只看总条数。
建议至少包含：
- 数据库结构说明；
- 关键表和字段说明；
- 数据字典；
- 初始化数据；
- 历史数据迁移记录；
- 数量校验；
- 金额或汇总校验；
- 关联关系校验；
- 异常数据清单；
- 数据备份文件；
- 数据恢复验证。
例如订单数量一致，并不能证明数据正确。还要核对总金额、订单状态、退款关联、客户归属和时间范围。
九、第八类资料：用户手册、培训和运营交接
项目能运行，不等于使用团队会操作。
根据系统复杂度，可以准备：
- 管理员操作手册；
- 普通用户使用说明；
- 常见问题；
- 角色和权限说明；
- 初始化设置；
- 基础数据维护方法；
- 报表口径；
- 故障上报方式；
- 培训记录或培训视频。
运营规则还没有定清时，不要用一份通用产品说明书代替实际交接。
十、第九类资料：验收报告、遗留项和质保约定
正式验收文件建议写清：
- 项目名称和版本；
- 本次验收范围；
- 验收环境；
- 验收依据；
- 已完成项目；
- 遗留问题；
- 后续处理计划；
- 质保起止方式；
- 双方确认日期。
验收报告应当引用前面的需求、测试、源码和交付清单，而不是只有一句“功能符合要求，同意验收”。
十一、推荐采用四阶段验收
第一阶段：内部预验收
开发团队先按需求和测试清单自查，关闭明显问题，不把基础测试转嫁给甲方。
第二阶段：业务用户验收
让真正使用系统的人按实际业务操作，而不是只让老板和项目经理看演示。
第三阶段：生产试运行
在真实环境、小范围用户和真实数据下观察一段时间，重点检查数据、权限、接口、性能和运营流程。
第四阶段：正式验收与交接
确认阻断问题关闭、资料齐全、账号完成移交，再签署验收报告并进入质保或维护阶段。
四阶段不一定都要很长。项目越小，流程可以越轻；但“范围、测试、交付、接管”四件事不能省。
十二、尾款支付前，至少完成这张清单
- 最终需求范围和变更记录已确认
- 核心业务流程已通过
- 阻断和严重缺陷已关闭
- 遗留问题有明确处理计划
- 生产环境完成部署和验证
- 源代码与仓库管理员权限已移交
- 数据库脚本、数据字典和备份已交付
- 服务器、域名、证书和开放平台账号已核对
- 构建与部署文档可被第三方复现
- 备份恢复或回滚方法已经验证
- 用户手册与培训已完成
- 验收报告和质保边界已确认
这张清单不能替代合同，但可以避免“尾款付完后才发现缺资料”。
十三、五个常见验收误区
误区一：开发环境能跑，就等于项目完成
真正交付要在约定环境运行，并具备部署、监控、备份和恢复能力。
误区二：没有严重报错，就可以签字
数据错误、越权访问、重复提交和接口异常，未必会在页面上弹出报错。
误区三：收到源码压缩包，就能更换团队
缺仓库历史、依赖、数据库脚本、配置和部署文档，其他团队仍然很难接手。
误区四：所有问题都必须修完才能验收
小问题可以进入遗留清单，但要明确级别、责任和处理时间。把所有问题混在一起，只会让双方反复争论。
误区五：验收后乙方就不再负责
验收、质保和长期维护是三个不同阶段。哪些属于原交付缺陷，哪些属于新增需求，应提前写清。
常见问题
软件项目验收报告由甲方还是乙方提供？
通常由项目管理方先准备模板，再由双方共同确认内容。谁起草不重要，重要的是验收依据、结果和遗留项必须真实、可追溯。
小程序和 App 还需要额外验收什么？
需要增加开放平台账号、隐私权限、版本提交、审核反馈、签名证书、消息推送和应用商店权限等资料。
没有需求文档还能验收吗？
可以整理合同、原型、聊天确认、会议纪要和版本记录，形成补充基线。但资料越零散，双方解释空间越大。
是否必须做第三方测评？
一般企业项目不一定需要。涉及合同约定、行业监管、高安全要求或重大业务风险时，再根据实际要求安排第三方测试或测评。
试运行多久才能正式验收？
没有适用于所有项目的固定天数。应根据业务周期、用户量、接口稳定性和合同约定决定，并提前写清试运行通过条件。
参考来源与口径说明
本文清单是面向一般企业软件项目的交付与接管检查框架，不替代合同、招标文件、行业监管要求或法定测评。关于版本管理、构建、测试、缺陷与漏洞处置、发布完整性等安全开发证据，可参考 NIST 的Secure Software Development Framework（SSDF）。具体项目仍应把适用条款转成双方可执行、可留痕的验收标准。
结语：验收的目标不是挑错，而是确认项目能够被接管
好的验收不是把开发团队逼到“零问题”，也不是为了尽快付款而走流程。它要确认系统能运行、数据可信、风险可控，甲方也真正拿到了继续运营和更换团队的能力。
如果你正在准备验收、接手旧项目或发现交付资料缺失，可以先查看华茂思捷的技术审计与软件项目服务。也可以通过联系页面提交现有合同、功能清单和交付目录，先做一次只读资料核对。
相关决策文章可继续阅读《软件外包合同里最容易埋坑的 4 件事》，或浏览老板必读栏目。
