研发交付验收报告可以按“一张主表加四张附表”组织：报告基本信息、交付物清单、验收证据、验收结论、遗留问题。验收结论限定为通过、有条件通过、不通过三种取值，并引用证据编号；遗留问题至少记录描述、影响、等级、责任人、计划关闭时间和复验方式。下面先给可复制的空白表格，再说明字段口径、必填规则和一份完整填写示例。
要点总览（TL;DR）
- 研发交付验收报告用一张主表加四张附表组织：报告基本信息、交付物清单、验收证据、验收结论、遗留问题，五张表通过编号互相引用。
- 验收结论限定为通过、有条件通过、不通过三种取值，并引用证据编号；有条件通过必须同时列出遗留问题编号和关闭期限作为放行条件。
- 遗留问题表至少记录编号、描述、影响范围、等级、责任人、计划关闭时间和复验方式，关闭以复验结果为准。
- 报告基本信息、交付物清单和验收结论中的关键字段为必填，缺失时报告不进入签署环节；有条件通过时遗留问题的责任人、关闭时间转为必填。
- 模板可按软件、硬件、文档等交付类型增减字段，并通过版本号和变更记录维护，已归档报告不随模板升级而修改。
可复制空白模板：验收报告主表与三张附表
模板共五张表。报告基本信息表确定本次验收的对象和范围；交付物清单表列出被验收的成果；验收证据表把每条验收标准对应到证据；验收结论表给出总体判定和签署；遗留问题表承接未关闭事项。五张表通过编号互相引用，填写时保持编号一致。
表1 报告基本信息
| 字段 | 填写内容 |
|---|---|
| 报告编号 | |
| 项目/产品名称 | |
| 交付版本/批次 | |
| 交付方 | |
| 验收方 | |
| 验收日期 | |
| 验收范围 | |
| 验收依据 | |
| 编制人/编制日期 |
表2 交付物清单
| 交付物编号 | 名称 | 类型 | 版本 | 存放位置 | 对应需求/任务 |
|---|---|---|---|---|---|
| D-01 | |||||
| D-02 | |||||
| D-03 |
表3 验收证据
| 证据编号 | 验收项 | 验收标准 | 证据类型 | 证据位置 | 核验人 | 核验结果 |
|---|---|---|---|---|---|---|
| E-01 | ||||||
| E-02 | ||||||
| E-03 |
表4 验收结论
| 字段 | 填写内容 |
|---|---|
| 验收结论 | □ 通过 □ 有条件通过 □ 不通过 |
| 结论依据 | 引用证据编号及关键说明 |
| 放行条件（有条件通过时填写） | 引用遗留问题编号及关闭期限 |
| 交付方签署角色/日期 | |
| 验收方签署角色/日期 | |
| 质量或测试代表签署角色/日期 |
表5 遗留问题
| 问题编号 | 问题描述 | 影响范围 | 等级 | 责任人 | 计划关闭时间 | 复验方式 | 状态 |
|---|---|---|---|---|---|---|---|
| I-01 | |||||||
| I-02 | |||||||
| I-03 |
字段说明：每个字段记录什么、怎么填
字段说明解决“填什么、填到什么程度”的问题。下表按模板顺序列出关键字段的含义与填写口径，示例值取自后文示例情景。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 报告编号 | 本次验收记录的唯一标识 | 建议采用“项目代号-版本号-验收-序号”，同一项目内不重复 | CRM-V2.3-ACC-01 |
| 交付版本/批次 | 被验收成果的版本或生产批次 | 软件写版本号，硬件写批次号，文档写文档版本 | V2.3 |
| 验收范围 | 本次验收覆盖与不覆盖的内容 | 写清模块、功能或交付物边界，范围外事项明确排除 | 客户管理模块及报表导出，不含移动端 |
| 交付物编号 | 交付物的唯一标识 | 以D开头顺序编号，与证据表引用一致 | D-01 |
| 对应需求/任务 | 交付物来源的需求或任务编号 | 填写需求管理系统中的原始编号，便于回溯 | REQ-118、REQ-121 |
| 验收项 | 被核验的具体功能或特性 | 一项一条，避免一条覆盖多个功能点 | 客户批量导入 |
| 验收标准 | 判定合格的量化或可观察条件 | 写可核验的条件，避免“运行正常”这类模糊表述 | 1000条数据导入成功率100%，耗时不超过5分钟 |
| 证据类型 | 证明标准达成的材料形式 | 测试报告、截图、日志、演示录屏、评审记录等，与标准性质匹配 | 测试报告 |
| 证据位置 | 证据的存放路径或链接 | 写到文件或目录级，保证验收方可以直接打开 | 测试库/导入测试/TR-20240612 |
| 核验结果 | 该验收项的核验判定 | 填“符合”“不符合”或“部分符合”，部分符合须关联遗留问题编号 | 符合 |
| 验收结论 | 本次交付的总体判定 | 三选一：通过、有条件通过、不通过 | 有条件通过 |
| 结论依据 | 支撑结论的证据与说明 | 引用证据编号，说明未达标项的处理方式 | E-01至E-05符合，E-06部分符合，见I-01 |
| 问题等级 | 遗留问题对交付使用的影响程度 | 建议分三级：阻断使用、影响部分场景、轻微缺陷 | 影响部分场景 |
| 复验方式 | 关闭前如何确认问题已解决 | 写明复验动作和判定人，如回归测试、现场演示、文档复核 | 回归测试并由验收方确认 |
| 状态 | 遗留问题的处理阶段 | 建议取值：待处理、处理中、待复验、已关闭、转后续版本 | 待复验 |
验收结论的三种取值需要明确判定口径。通过指全部验收项核验结果为符合，无未关闭的阻断或影响类问题；有条件通过指主体功能符合标准，存在已登记、有责任人和关闭计划的遗留问题，允许在限定条件下交付使用；不通过指存在未达标的阻断项，或关键验收标准缺少证据，交付方需整改后重新验收。有条件通过的结论必须同时引用遗留问题编号，否则结论缺少放行依据。
必填与选填：哪些字段不能空
必填字段决定报告能否成立，选填字段根据交付类型补充。缺失必填项时，报告不应进入签署环节；选填项缺失不影响结论，但应在备注中说明原因。
| 所在表 | 必填字段 | 选填字段 | 缺失处理 |
|---|---|---|---|
| 报告基本信息 | 报告编号、项目/产品名称、交付版本/批次、交付方、验收方、验收日期、验收范围 | 验收依据、编制人 | 必填缺失时退回编制人补录，补录后重新提交签署 |
| 交付物清单 | 交付物编号、名称、类型、版本、对应需求/任务 | 存放位置 | 存放位置缺失时须在证据表中间接可查，否则补齐 |
| 验收证据 | 证据编号、验收项、验收标准、核验结果 | 证据类型、证据位置、核验人 | 核验结果为“符合”但无证据位置时，视为证据不足，不得判定通过 |
| 验收结论 | 验收结论、结论依据、验收方签署角色与日期 | 交付方签署、质量代表签署 | 结论为空或依据未引用证据编号时，报告不生效 |
| 遗留问题 | 问题编号、问题描述、影响范围、等级、责任人、计划关闭时间 | 复验方式、状态 | 复验方式可在首次复验前补充；状态在跟踪过程中更新 |
有条件通过时，遗留问题表中的问题编号、责任人和计划关闭时间转为必填，因为这三项构成放行条件。若遗留问题在验收时尚未确定责任人，应先明确责任团队并指定临时负责人，再签署结论。报告签署后发现必填项遗漏的，采用补录方式处理：保留原报告编号，在变更记录中注明补录字段、补录人和时间，不重开新报告。
填写示例：一次版本交付的完整验收记录
以下示例为虚构情景，用于说明各表如何联动填写，不代表真实项目。某客户关系管理系统的V2.3版本向业务部门交付，验收范围为客户管理模块与报表导出功能，不含移动端。
基本信息与交付物
报告编号填“CRM-V2.3-ACC-01”，交付方为研发中心，验收方为业务运营部，验收日期为2024年6月14日，验收依据为V2.3需求说明书与测试计划。交付物清单列出三项：D-01客户管理模块程序包（V2.3，对应REQ-118）、D-02报表导出功能（V2.3，对应REQ-121）、D-03接口说明文档（V1.2，对应REQ-125）。
验收证据的对应填写
| 证据编号 | 验收项 | 验收标准 | 证据类型 | 证据位置 | 核验人 | 核验结果 |
|---|---|---|---|---|---|---|
| E-01 | 客户信息新增与修改 | 字段校验规则全部生效，异常输入有提示 | 测试报告 | 测试库/客户模块/TR-0610 | 测试负责人 | 符合 |
| E-02 | 客户批量导入 | 1000条数据导入成功率100%，耗时不超过5分钟 | 测试报告与日志 | 测试库/导入测试/TR-0612 | 测试负责人 | 符合 |
| E-03 | 报表导出 | 导出字段与页面展示一致，Excel可正常打开 | 演示录屏 | 共享盘/验收/E-03.mp4 | 业务代表 | 符合 |
| E-04 | 大数据量导出 | 5万条数据导出在10分钟内完成 | 测试报告 | 测试库/导出测试/TR-0613 | 测试负责人 | 部分符合 |
| E-05 | 接口文档完整性 | 覆盖全部对外接口，含参数与错误码 | 文档评审记录 | 文档库/评审/RV-0608 | 架构负责人 | 符合 |
E-04部分符合的原因是5万条数据导出耗时12分钟，超出标准2分钟。该验收项关联遗留问题I-01，证据表与遗留问题表通过编号对应，读者可以从结论追溯到具体证据和问题。
验收结论的表述
结论填“有条件通过”，依据写为：“E-01、E-02、E-03、E-05核验符合；E-04部分符合，导出性能未达标准，已登记I-01，计划在V2.3.1修复。主体功能满足业务使用要求，允许在I-01关闭前限制单次导出数据量不超过3万条。”放行条件引用I-01及关闭期限。交付方由研发经理签署，验收方由业务运营部负责人签署，质量代表由测试负责人签署，日期均为2024年6月14日。
遗留问题的写法
| 问题编号 | 问题描述 | 影响范围 | 等级 | 责任人 | 计划关闭时间 | 复验方式 | 状态 |
|---|---|---|---|---|---|---|---|
| I-01 | 5万条数据导出耗时12分钟，超出10分钟标准 | 报表导出的大数据量场景，日常导出不受影响 | 影响部分场景 | 后端开发负责人 | 2024年7月12日 | 回归测试5万条导出并记录耗时，由验收方确认 | 处理中 |
| I-02 | 导出文件名未包含日期，与需求描述不一致 | 仅影响文件识别，不影响数据内容 | 轻微缺陷 | 前端开发负责人 | 2024年6月28日 | 功能演示确认文件名格式 | 待处理 |
问题描述写清现象、实测值和标准值，避免只写“导出慢”。影响范围说明受影响的业务场景和不受影响的部分，帮助验收方判断放行风险。等级与结论挂钩：影响部分场景的问题可以进入有条件通过，阻断使用的问题应导致不通过。状态在每次跟踪后更新，关闭以复验结果为准。
调整与维护方法：按交付类型裁剪模板
模板需要随交付类型调整字段，但五张表的基本结构保持不变。裁剪的原则是增加与交付形态相关的追溯字段，减少与本次交付无关的核验列，保证验收标准和证据仍然一一对应。
- 软件交付：在交付物清单增加部署环境和版本号字段，在证据表增加回归测试范围；涉及多版本并行时，报告编号中加入迭代标识。
- 硬件交付：在交付物清单增加批次号、序列号范围，在证据表增加抽检比例和检测设备记录。
- 文档或方案交付：在证据表增加评审记录编号和评审结论，交付物清单的版本字段改为文档版本。
- 混合交付：按交付物类型分行填写，不为每类交付物单独建表，避免编号体系分裂。
遗留问题的跟踪节奏按等级区分：阻断使用的问题在验收前必须关闭或转为不通过；影响部分场景的问题按计划关闭时间每周跟踪一次，临近期限未关闭时升级到项目负责人；轻微缺陷可合并到后续版本处理，但需在报告中注明转出版本。复验完成后更新状态并记录复验日期和复验人，报告归档时以最终状态为准。
模板本身需要版本管理。在模板页脚标注版本号和生效日期，例如“验收报告模板 V1.2，2024年6月生效”；字段增删、取值调整和必填规则变化都记入变更记录，写明变更内容、原因和影响范围。已归档报告不随模板升级而修改，新模板只适用于生效日期之后的验收。
模板还要与验收清单和问题跟踪记录衔接。验收清单中的检查项直接对应证据表的验收项，避免两套口径；遗留问题在问题跟踪工具中建立对应条目，报告中的问题编号与跟踪记录编号保持一致，复验结果回写到报告。对于需求明确、交付周期固定的项目，可以把验收报告作为里程碑交付物管理，将交付物清单、证据和遗留问题关联到需求与版本记录中，便于交付结果回溯。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，并支持把测试用例、缺陷、版本和发布过程关联到需求链路，团队可以据此把验收证据和遗留问题挂接到对应的需求与版本上；交付物模板和评审节点也可以沉淀为可复用资产，减少每次验收重新搭建记录结构的工作。是否采用工具承载，取决于团队已有的需求与缺陷管理方式，模板本身保持独立可用。
常见问题
验收结论填了“有条件通过”，但遗留问题还没有确定责任人，报告能签署吗？
不建议直接签署。有条件通过的放行依据来自遗留问题编号、责任人和计划关闭时间三项，缺少责任人时结论缺少可执行的跟踪对象。处理方式有两种：一是在签署前明确责任团队并指定临时负责人，把临时负责人填入遗留问题表后再签署；二是将结论改为“不通过”，待责任人确定后重新组织验收。如果情况紧急，也可以先记录责任团队，在变更记录中注明责任人待补充，但需在放行条件中写明补充时限。
验收证据表中“核验结果”填了“符合”，但证据位置是空的，这种情况怎么处理？
证据位置为空时，“符合”的判定缺少可追溯依据，应视为证据不足，不能据此判定通过。处理方式：要求交付方补充证据位置并重新核验；若确实无法提供位置，将该验收项的核验结果改为“部分符合”或“不符合”，并关联遗留问题编号。报告签署前发现此类问题的，退回编制人补录；签署后发现，采用补录方式在原报告编号下记录补录字段、补录人和时间，不重开新报告。
遗留问题在计划关闭时间前没有关闭，验收报告需要重新签署吗？
不需要重新签署验收报告。遗留问题的状态在跟踪过程中更新，报告归档时以最终状态为准。临近计划关闭时间未关闭的，按等级处理：影响部分场景的问题升级到项目负责人，并在跟踪记录中说明延期原因和新的关闭计划；轻微缺陷可合并到后续版本处理，在报告中注明转出版本。若问题升级后影响交付使用，应重新评估验收结论是否仍满足有条件通过的条件。
软件交付和硬件交付用同一份验收报告模板，需要改哪些字段？
五张表的基本结构保持不变，按交付形态增减追溯字段即可。软件交付可在交付物清单增加部署环境和版本号字段，在证据表增加回归测试范围；硬件交付可在交付物清单增加批次号和序列号范围，在证据表增加抽检比例和检测设备记录；文档或方案交付可在证据表增加评审记录编号和评审结论。混合交付按交付物类型分行填写，不为每类交付物单独建表，避免编号体系分裂。
验收报告和问题跟踪工具里的记录如何对应，避免两套编号？
在问题跟踪工具中为每条遗留问题建立对应条目，报告中的问题编号与跟踪记录编号保持一致，复验结果回写到报告。验收清单中的检查项直接对应证据表的验收项，两处使用同一套验收项名称和编号。对于需求明确、交付周期固定的项目，可以把验收报告作为里程碑交付物管理，将交付物清单、证据和遗留问题关联到需求与版本记录中，便于交付结果回溯。ONES 的方案支持把测试用例、缺陷、版本和发布过程关联到需求链路，团队可以据此把验收证据和遗留问题挂接到对应的需求与版本上。
