软件项目验收怎么验？企业验收环节的检查清单与避坑要点

验收不是最后一天走个形式，而是在合同里就写清的一条条可测条件。本文给出功能、性能、数据、安全、交付物五个维度的验收清单，说明验收前该准备什么、签字前必须拿到的六样东西，以及最容易扯皮的四类场景。

验收这件事，为什么总在最后关头翻车

做软件项目的企业，很少有人在立项时担心验收。真正到了验收那天才发现问题一大片：功能跟当初说的不太一样，后台账号密码还没给全，说好的操作手册只有一页纸，源代码什么时候交没人说得清。

问题的根源不在于供应商不老实，而在于验收标准从来没有被写成一个可以逐条打勾的清单。口头说「界面要好看」「用起来要顺」，这种描述在开发阶段还能凑合，到了验收阶段就没法判断合格与否，双方只能凭感觉吵。

青梅睿创在定制开发项目里通常建议客户在签合同阶段就把验收清单做出来，不用很复杂，一页 A4 就够，但每一条都必须能被验证。这一页纸省下的时间，往往比开发阶段省的多。

验收到底在验什么

很多人把验收等同于「点一遍功能能不能用」。实际上一套系统的验收至少包含五个维度，缺一个都会留下隐患。

功能验收：把需求清单变成打勾表

功能验收最有效的做法，是把当初的需求文档拆成一条条操作步骤，每一条写清楚「怎么操作、期望结果是什么」。

比如「订单可以导出」这种条目就没法验，要改成「进入订单列表，选择时间范围，点导出，三秒内生成 Excel，字段包含订单号、客户、金额、状态、下单时间」。这样写下来，验收的时候不用争，照着做就行。

还有一类常被忽略的是异常流程。正常下单能跑通不代表系统就合格，还要测：金额填 0 会怎样、手机号填 12 位会怎样、网络断了再提交会怎样、两个人同时改同一条数据会怎样。异常流程走不通的系统，上线后几乎一定会出事。

性能验收：用真实数据量说话

性能测试最容易做假的地方，是用十几条测试数据跑出漂亮结果。等真实业务数据进来，几万条订单一加载，列表页转半分钟出不来。

验收时建议准备一份接近真实体量的数据，哪怕是从老系统导出的历史数据脱敏后使用，要求列表在常规数据量下两秒内加载完成、批量导出五千条以内能正常完成、十个人同时操作不出现卡顿。

这些数字不必写得很精细，但要有，而且要在验收时实际跑一遍，不要只听描述。

数据验收：报表数字必须对得上

如果项目涉及从老系统迁移数据，数据验收是重中之重。建议做三件事：

一是在迁移后做总数核对，老系统有多少条客户、多少条订单，新系统必须一致，差一条都要查清楚原因。

二是抽查关键字段，随机抽二三十条，逐字段比对，尤其看日期格式、金额小数位、状态枚举值有没有错位。

三是让财务或业务人员自己算一遍，用他们的口径核对系统报表。业务方认可的报表才开始有意义，技术方算得再对，业务不敢用也是白搭。

安全验收：三类最容易漏的检查

另外还有一条最基础的：上线前必须换掉所有默认密码，包括数据库、后台、服务器。这件事听起来低级，但历次安全事件里，因为默认密码被攻破的占比一直不低。

交付物验收：签字前必须拿到的六样东西

这一块是扯皮高发区。很多企业签完验收单才发现，想要的东西都还在供应商手里。建议在验收单上明确列明，六样东西交齐了才签字：

• 源代码，包含完整可编译的工程文件，不是只有部署后的运行包
• 数据库结构说明，表结构、字段含义、关键逻辑说明
• 账号清单，服务器、数据库、后台超管、第三方平台（支付、短信、地图等）的全部账号与密码
• 部署文档，换一台服务器能不能照着文档装起来
• 操作手册，给业务人员看的，图文为主，不是给程序员看的
• 知识产权相关材料，商标、备案、软件著作权登记的主体归属说明

第三项特别提醒：第三方平台的账号，一定要用企业自己的主体去注册，不要用供应商的账号代开。用供应商主体开的支付号、短信通道，一旦停止合作，迁移会非常麻烦。

最容易扯皮的四类场景

场景一：功能做了但和想象的不一样。 界面风格、交互方式这类主观描述，最容易被理解成两个样子。规避方法是设计阶段出原型，客户签字确认后再开发。

场景二：说好包含但没写在合同里。 口头承诺在验收时没有效力。规避方法是需求变更全部走书面确认，微信聊天记录也算，但要归档到一起。

场景三：源代码什么时候交。 有的项目约定尾款付清才交源码，有的约定验收就交。这件事必须在合同里写清时点，不要留模糊空间。

场景四：验收完出问题算谁的。 验收不等于免责，但责任边界要谈清。通常做法是约定一段质保期，期内修复缺陷不额外收费，期外的功能新增另行报价。青梅睿创在定制开发项目里通常会把这两件事分开写：修 bug 属于质保，加功能属于新需求，这样双方都不会觉得吃亏。

验收流程建议按这五步走

第一步，提前一周发出验收通知和清单，让双方都有准备时间，不要当天临时通知当天验。

第二步，供应商自测并提交自测报告，说明哪些条目已通过、哪些有已知问题。这一步能过滤掉大部分低级的返工。

第三步，企业方按清单逐条验证，边验边记录，通过的打勾，不通过的写清现象和复现步骤。

第四步，把不通过项按严重程度分级，阻断性问题和一般问题分开列，约定修复期限。小问题不必卡着不签字，但必须写进遗留问题表。

第五步，全部阻断性问题清零后签字，同时收齐六样交付物。签字前再核一遍交付物清单，别签完再要。

常见问题

问：验收单签了以后发现问题还能找供应商吗？

答：能。验收通常不免除质量责任，合同里一般会约定质保期。关键是签字时把已知遗留问题写进附件，附件的效力比口头约定强得多。

问：功能都通过但界面不满意，能拒收吗？

答：取决于设计阶段有没有确认过原型。如果原型签字确认过，验收时再改属于需求变更，一般要另行计费。所以设计确认这一步不要走过场。

问：源代码一定要拿到吗？

答：看合作方式。如果后续还打算让原供应商维护，源代码的实际意义会小一些，但仍是重要保障。多数定制项目在合同里明确约定交付源代码，这是行业里的常规做法。

问：验收要花多长时间？

答：视系统复杂度。单模块的小系统通常半天到一天可以完成，多模块综合系统建议留三到五天，并且分模块验，不要攒到最后一次全验。

问：验收时发现的问题，供应商拖着不修怎么办？

答：合同里写清修复期限和逾期处理方式，这是最有效的手段。已经在合作中的项目，可以把尾款支付节点和遗留问题清零挂钩。

问：能不能先上线再验收？

答：可以并行，但不建议完全跳过验收。常见的折中做法是先上线试运行一段时间，用真实业务跑一轮再正式验收，这样暴露的问题更真实。

小结

验收不是最后一道形式，而是整个项目最需要提前设计的一环。把需求拆成可验证的条目、把交付物列成清单、把质保和新增需求的边界谈清，这三件事做在前面，验收当天就不会变成扯皮大会。青梅睿创科技在定制开发项目里通常会随合同附一份验收清单模板，客户照着改就行，比自己从零想省事得多。