交付验收要能回答三个问题：这个版本交付了什么、每条需求验到哪一步、证据在哪里。做法是建立一条可追溯链，把需求条目、测试用例与执行结果、缺陷关闭情况、版本与构建标识串起来，最终形成验收证据包。本文按追溯链搭建、验收前核对、证据包编制、角色分工、示例和完成检查的顺序展开，适用于一次研发交付的完成确认。
要点总览（TL;DR）
- 交付验收的追溯链以需求条目为主键，向下挂测试用例与执行结果、缺陷状态，再挂版本号与构建号，最终汇总为验收证据包。
- 验收前按需求清单逐条核对，结论分为通过、有条件通过、未覆盖、证据缺失四类；核心需求未覆盖或证据缺失时须补测补证后再进入验收。
- 证据包按需求编号与版本号双索引组织，包含变更清单、需求验收对照表、测试报告、缺陷关闭记录、发布记录和遗留问题说明，版本变更后只更新受影响条目并保留修订记录。
- 角色按提供方、核对方、签字方划分：需求负责人、测试负责人、版本/发布负责人提供材料，交付负责人汇编并主持验收，验收方抽查证据后签字。
- 完成判定看六项检查：需求全覆盖、测试结论完整、缺陷闭环、版本一致、证据包可定位、签字归档齐全；核心需求未覆盖、阻断级缺陷未关闭、版本不一致属于阻断项。
先定追溯链：需求、测试结果与版本证据怎么串起来
追溯链的核心是以需求条目为主键，向下挂测试与缺陷，再挂版本与构建标识，最后汇总为证据包。这样验收时从任意一条需求出发，都能找到对应的测试结论和所属版本；从任意一个版本出发，也能反查它覆盖了哪些需求、哪些需求尚未验证。
一条完整的追溯链包含四个环节：
- 需求条目：验收范围的起点，每条需求有唯一编号、验收标准、优先级和负责人。
- 测试用例与执行结果：每条需求关联至少一个验证用例，记录执行结果、执行时间和执行人。
- 缺陷状态：测试中发现的缺陷关联到需求，记录严重级别、修复状态和关闭时间。
- 版本与构建标识：需求、用例、缺陷都标注所属版本号和构建号，确保结论对应的是实际交付物。
每条需求在验收前应具备以下关联字段，可作为最小字段清单：
| 字段 | 说明 | 示例 |
|---|---|---|
| 需求编号 | 唯一标识，贯穿全链 | REQ-1024 |
| 验收标准 | 可判定的完成条件 | 支持批量导入并给出错误行提示 |
| 关联用例 | 验证该需求的用例编号 | TC-3301、TC-3302 |
| 执行结果 | 通过/失败/未执行，附执行时间 | 通过，2025-03-12 |
| 关联缺陷 | 缺陷编号与当前状态 | BUG-778，已关闭 |
| 所属版本 | 版本号与构建号 | V2.3.0 / build 20250312.4 |
| 证据位置 | 测试报告、发布记录等证据的存放位置 | 证据包第 3 节 |
版本证据通常包括四类内容：构建号与构建产物记录、发布记录（发布时间、发布范围、回滚方案）、变更清单（本版本新增、修改、修复的需求与缺陷列表）、测试报告（用例执行汇总与缺陷统计）。关联动作的输入是需求清单和版本发布信息，做法是逐条补齐上述字段，输出是一张需求—测试—版本对照表，作为后续核对和证据包编制的基础。
验收前如何逐条核对需求与测试结论
核对按需求清单逐条进行，顺序是先看覆盖、再看结论、最后看缺陷。具体步骤：
- 从需求清单取一条需求，确认它是否关联了验证用例。没有关联用例的，直接标记为“未覆盖”。
- 查看关联用例在本次交付版本上的执行结果，确认执行时间晚于该版本最后一次代码变更。
- 查看该需求关联缺陷的状态，确认阻断级和严重级缺陷均已关闭，一般缺陷有明确的处理结论。
- 确认需求、用例、缺陷三者的版本号一致，避免用旧版本的测试结论支撑新版本验收。
每条需求给出四类判定之一：
| 判定 | 含义 | 处理方式 |
|---|---|---|
| 通过 | 用例已执行且通过，缺陷已关闭，版本一致 | 纳入放行清单 |
| 有条件通过 | 主流程通过，存在已知一般缺陷且有规避方案 | 附条件放行，缺陷列入后续版本计划 |
| 未覆盖 | 无用例或用例未在本次版本执行 | 补测后再判定，不得直接放行 |
| 证据缺失 | 有测试结论但报告、记录或版本标识不全 | 补齐证据后重新核对 |
遇到未覆盖或证据缺失时，先判断影响范围：核心需求必须补测补证后才能进入验收；边缘需求可由需求负责人和验收方共同确认是否降级处理，并将结论写入核对记录。核对结果建议以对照表形式记录，每行一条需求，列出判定、依据和责任人，作为验收会议的讨论材料。在工具层面，ONES 通过统一的需求池与任务、测试、缺陷管理形成全流程闭环，测试用例、缺陷、版本和发布过程可以关联到需求链路中，核对时能沿关联关系直接查看每条需求的测试结论和所属版本，减少在多张表格之间人工比对的工作量。
版本证据包怎么编：内容、格式与版本对应
证据包是验收签字的依据，编制原则是按需求编号和版本号双索引组织，做到打开包就能定位任意一条需求的全部证据。一个可复用的目录结构如下：
- 封面与版本信息：版本号、构建号、交付日期、编制人与审核人。
- 变更清单：本版本涉及的需求列表与缺陷修复列表，标注新增、修改、删除。
- 需求验收对照表：每条需求的验收标准、测试结论、判定结果。
- 测试报告：用例执行汇总、通过率、未执行项说明、缺陷统计。
- 缺陷关闭记录：阻断级与严重级缺陷的修复验证记录。
- 发布记录：发布时间、发布范围、回滚方案与演练结果。
- 遗留问题与风险说明：已知问题、规避方案和后续计划。
每项证据都要标注对应的需求编号和版本号，例如测试报告按需求分组呈现，缺陷记录注明所属版本和构建号。证据的生成时点应尽量贴近事实发生时间：测试报告在测试轮次结束时生成，发布记录在发布完成后生成，变更清单在版本冻结时确定。责任人方面，测试报告由测试负责人出具，发布记录由版本或发布负责人出具，变更清单由需求负责人汇总，证据包整体由交付负责人汇编。
版本变更后，证据包按影响范围更新：只替换受影响需求的测试结论和缺陷记录，新增变更条目，保留旧版本证据的对应关系并在封面注明修订记录。这样验收方能看到每个结论对应的具体版本，也能追溯版本之间的差异。ONES 围绕需求、基线、版本和变更建立统一管理对象，并集成流水线实时监控构建与部署状态，版本和构建信息可以直接作为证据包中的版本标识来源，减少人工抄录导致的版本错配。
角色分工与交付物：谁提供、谁核对、谁签字
验收关联过程按提供方、核对方、签字方三层划分职责，各角色的动作和交付物如下：
| 角色 | 验收前 | 验收中 | 验收后 | 主要交付物 |
|---|---|---|---|---|
| 需求负责人 | 确认需求清单与验收标准，汇总变更清单 | 解释需求范围与判定口径 | 确认遗留问题处理计划 | 需求清单、变更清单 |
| 测试负责人 | 提供用例执行结果与缺陷状态，出具测试报告 | 说明未覆盖项与缺陷处理结论 | 补测并更新报告 | 测试报告、缺陷关闭记录 |
| 版本/发布负责人 | 提供版本号、构建号与发布记录 | 确认交付物与版本一致 | 归档发布记录 | 发布记录、构建产物清单 |
| 交付负责人 | 汇编证据包，组织核对 | 主持验收会议，记录结论 | 归档证据包 | 验收证据包、验收纪要 |
| 验收方 | 确认验收范围与判定口径 | 抽查证据，签署验收结论 | 接收归档证据 | 签字确认的验收结论 |
交接节点有三个：验收前由各提供方把材料交给交付负责人汇编，形成证据包初稿；验收中由交付负责人向验收方提交证据包并逐条说明；验收后由验收方签字，交付负责人完成归档。出现争议或缺口时，按严重程度升级：单条需求的证据缺口由需求负责人和测试负责人协商补证；涉及核心需求未覆盖或版本不一致的，升级到交付负责人决定是否延期验收；验收方对结论有异议的，由验收方与交付负责人共同裁定并记录理由。
一个交付验收的关联示例
以下为演示情景，用于说明追溯链的串联方式，不代表真实项目数据。
某内部系统交付 V2.3.0 版本，交付范围包含 12 条需求，其中 3 条为核心需求。验收前，交付负责人从需求清单出发逐条核对：核心需求 REQ-1024“批量导入并提示错误行”关联用例 TC-3301 和 TC-3302，两条用例均在 build 20250312.4 上执行通过，关联缺陷 BUG-778 已关闭，判定为通过。需求 REQ-1031“导入模板下载”只有用例 TC-3310，执行记录停留在上一版本，判定为未覆盖。
核对中发现两个问题：REQ-1031 需要在当前版本补测；REQ-1038 的测试报告缺少构建号标注，判定为证据缺失。测试负责人当天在 build 20250312.4 上补测 TC-3310 并通过，同时补全 REQ-1038 报告的版本标识。交付负责人更新证据包中受影响的两个条目，保留修订记录。
验收会议上，验收方抽查了 4 条需求，包括 2 条核心需求，证据与结论一致。最终 12 条需求中 11 条通过、1 条有条件通过（存在一个一般缺陷，已约定下个版本修复），验收方签署验收结论。验收后，证据包连同签字纪要归档，版本号、构建号与证据包的对应关系一并保留，供后续回溯。
完成检查：验收关联是否做到位
验收关联工作完成前，按以下清单逐项检查，每项都应有明确的是或否结论：
- 需求覆盖率：交付范围内每条需求都有判定结果，无遗漏条目。
- 测试结论完整性：每条通过的需求都有本次版本上的用例执行记录，执行时间晚于最后一次代码变更。
- 缺陷闭环：阻断级和严重级缺陷全部关闭并有验证记录，一般缺陷有处理结论。
- 版本一致性：需求、用例、缺陷、证据包中的版本号和构建号一致，无旧版本结论混入。
- 证据包完整：目录齐全，每项证据可定位到需求编号和版本号。
- 签字与归档：验收结论已签字，证据包与验收纪要已归档并可检索。
阻断项包括：核心需求未覆盖或证据缺失、存在未关闭的阻断级缺陷、证据包版本与交付版本不一致。出现任一阻断项时暂停验收签字，补齐后重新核对。放行条件为：全部阻断项清零，有条件通过的条目已记录遗留问题和处理计划，验收方完成签字。满足这些条件，才能认为本次交付的需求、测试结果与版本证据已经形成完整、可回溯的关联。
常见问题
验收时发现某条需求的测试结论是上一版本执行的，应该怎么处理？
这类情况按“证据缺失”处理，不能直接用旧结论支撑新版本验收。先确认该需求在本次交付版本上是否有代码变更：有变更的，必须在当前构建上重新执行关联用例；无变更的，由测试负责人出具说明，注明结论沿用的依据和版本差异，并附在证据包中，由验收方确认是否接受。无论哪种处理，都要在核对记录中写明判定依据和责任人。
需求在验收前临时变更，已经核对过的测试结论和证据包怎么更新？
先评估变更影响范围：变更涉及的需求条目、关联用例和缺陷都要重新核对。测试结论只替换受影响需求的执行记录，证据包更新变更清单和需求验收对照表中的对应行，并在封面修订记录中注明变更时间、内容和更新人。旧版本的证据保留对应关系，便于验收方对比版本差异。如果变更影响核心需求且来不及补测，应升级到交付负责人决定是否延期验收。
有条件通过的条目，验收签字后还需要做什么？
有条件通过意味着验收方接受了已知的一般缺陷及其规避方案。签字后需要把遗留问题写入证据包的遗留问题与风险说明，明确修复责任人和计划版本，并在后续版本验收时核对关闭情况。如果遗留问题在约定版本中未修复，应在下一次验收前重新评估影响，避免问题在多个版本间累积而失去追踪。
用工具管理追溯链时，需求、测试和版本记录分散在不同系统，怎么保证关联不断？
关键是统一主键和关联字段：需求编号作为全链唯一标识，用例、缺陷、构建记录都引用同一需求编号和版本号。工具层面可以选择把需求、测试、缺陷和版本放在同一管理链路中的方案，例如 ONES 通过统一的需求池与任务、测试、缺陷管理形成闭环，测试用例、缺陷、版本和发布过程可关联到需求链路，核对时沿关联关系直接查看每条需求的测试结论和所属版本。若系统暂时无法打通，至少在证据包中保留人工对照表，并指定每次交付的更新责任人。
交付范围较小、需求只有几条时，还需要完整的证据包吗？
证据包的详细程度可以随交付规模调整，但追溯关系不能省。需求少时可以把变更清单、需求验收对照表和测试报告合并为一份简表，仍要保证每条需求能定位到测试结论、缺陷状态和版本号。签字与归档环节同样保留，因为后续回溯问题时，验收依据是否可查与交付大小无关。
