软件外包验收时怎么对照需求、测试记录和交付物

软件外包验收最怕“演示通过、交付不完整”：现场点了几个页面，不代表需求已经满足；一份测试报告，也不代表源码、部署材料和使用文档都能接手。稳妥的做法是建立一张对照表，让每条合同需求都能找到测试证据、交付文件和最终状态。合同及其附件已经约定验收标准的，先按约定执行；没有写清的部分，再参考双方确认的需求基线、测试方案和适用的软件质量标准。

验收不是只看功能能不能点通，而是逐条证明“约定了什么、测了什么、交付了什么、还差什么”。任何未完成项都要有责任人、整改期限和复验记录。

先把验收口径锁在同一份基线里

先收齐合同正文、技术协议、需求规格说明书、原型或接口清单，以及双方确认过的变更单。给每条需求编号，例如 F-012 表示订单查询，P-003 表示并发性能，A-005 表示管理员权限。若开发过程中发生范围调整，要把“原需求、变更内容、批准人和生效日期”放在同一行，不能拿旧版本文档和新系统混合比较。

国家标准信息公共服务平台显示，GB/T 25000.51-2016 目前为现行标准，可作为软件产品质量要求和测试细则的参考；它不能自动替代合同中的专用指标。涉及付款、违约或争议时，应以合同约定和专业意见为准。

用需求追踪表把测试证据串起来

验收表至少保留下面这些字段。测试记录不是“通过”两个字，而应能说明测试环境、输入条件、实际结果和证据位置。

对功能验收，要覆盖正常、空值、重复提交、越权和失败恢复等场景；对性能验收，要写清数据量、并发模型、硬件环境和统计口径。只展示最顺利的一次，不足以证明边界条件。

交付物要按“能接手”而不是“有文件”检查

交付清单建议分为四组：一是源码、构建脚本、依赖清单和版本标签；二是可部署的软件包、数据库脚本、配置模板、回滚说明和环境变量说明；三是接口、数据字典、管理员手册、用户手册、培训材料和测试报告；四是账号权限、证书或授权材料、第三方依赖清单以及数据迁移结果。每项都记录版本、格式、存放位置、接收人和校验方式。

北京市市场监督管理局公开的计算机信息系统集成合同示范文本，也将交付内容、文档形式、阶段验收和第三方测评能力写入合同条款。对定制开发项目，这种“文件清单+验收节点”的写法比一句“系统正常运行”更容易执行。

不合格项如何留痕和复验

把问题分成阻断验收的缺陷、影响部分功能的缺陷和不影响使用但必须补齐的文档项。每条记录写明现象、复现步骤、影响需求、责任方、整改期限和复验人。验收报告中不要只写“基本通过”；应明确通过范围、保留问题、是否允许带缺陷交付，以及保留问题的关闭条件。

中国人大网对承揽成果验收的释义强调，交付时应同时提供必要技术资料和质量证明，发现质量或数量不符合约定时应及时通知。实际项目中，验收不合格就按合同约定整改并重新验收，每次复验都保留新的记录，避免把第一次失败结果覆盖掉。

一张表完成最终签字前的检查

• 需求：每条需求都有版本、验收标准和变更依据。
• 测试：用例、环境、数据、结果、日志和缺陷编号可互相追溯。
• 交付：源码、部署、文档、权限、培训和数据迁移都有接收记录。
• 收尾：遗留问题有期限和关闭条件，双方确认验收结论和后续责任。

常见问题

测试报告通过了，为什么还不能直接验收？

测试报告只覆盖其中的验证活动，不能自动证明全部合同需求、文档、源码和权限已经交付。还要回到需求追踪表和交付清单逐项核对。

需求没有写性能指标，验收时能不能临时定一个？

临时指标容易引发争议。应先查合同、技术协议和双方确认的方案；若仍没有约定，建议由双方书面确认补充口径，再安排测试。

允许带着小问题上线，验收单怎么写？

可以在合同允许的前提下写明问题编号、影响范围、修复期限、复验方式和逾期责任，不要用“后续优化”这种无法判断是否完成的表述。