需求测试关联表要解决的是把每条需求与验证它的测试项逐条对应起来，并分别回答“测没测”和“过没过”。设计前先确定需求拆解粒度，再固定字段与唯一标识，然后按步骤登记关联、回填状态和证据。本文给出字段定义表、操作流程、角色分工、填写示例与覆盖判定清单，适合测试负责人、需求负责人和测试设计人员共同使用。
要点总览（TL;DR）
- 需求测试关联表以“需求标识+测试项标识”为组合唯一约束，一条需求对应多条测试项时逐行登记，防止重复关联。
- 建表前先按“可独立验证”原则拆需求：一条需求只包含一个可单独判定通过与否的行为，避免覆盖判定失真或维护成本失控。
- 覆盖状态（未覆盖、部分覆盖、已覆盖）与验证结论（未执行、通过、失败、阻塞）必须分字段记录，分别回答“测没测”和“过没过”。
- 建表按提取可验证条目、匹配测试项、回填覆盖状态、执行并挂接证据、评审定版五步推进，每步有明确完成标志。
- 覆盖判定以检查清单为准：无未覆盖需求、状态与结论一致、通过和失败均有证据链接、变更已同步、评审问题关闭。
关联表先定粒度：需求拆到哪一层
关联表的行数由需求条目数量决定，需求拆得太粗或太细都会影响表的可用性。合适的粒度标准是“可独立验证”：一条需求条目应当只包含一个可以单独判定通过与否的行为或结果。满足这个条件，它就能对应一组测试项，覆盖状态也有明确含义。
判断方法可以按三步走。先读需求描述，找出其中包含的多个可分别判定的行为；再检查每个行为是否有独立的预期结果；最后确认每个行为能否由至少一条测试项验证。若一条需求里出现“并且”“同时”“以及”连接的两个不同预期结果，通常应拆成两条需求条目。
拆分示例：原始需求“用户登录支持手机号与邮箱两种方式，连续输错五次锁定账户”。这里包含三个可独立判定的行为：手机号登录成功、邮箱登录成功、连续输错五次后锁定。按可独立验证原则拆为三条需求条目，分别关联各自的测试项。若保留为一条，当手机号登录通过而锁定逻辑未测时，覆盖状态只能填“部分覆盖”，判定会变得模糊。
粒度过粗的代价是覆盖判定失真：一条需求对应十几条测试项，部分失败时无法说清哪部分没覆盖。粒度过细则维护成本上升：把界面文案、按钮颜色都拆成需求条目，关联表会迅速膨胀，评审和更新都难以持续。取舍点在于：只拆到“业务上需要单独确认通过与否”的层级，界面细节作为测试项内的检查点，不单独占一行需求。
表结构设计：必备字段与字段规则
关联表的核心结构是“一条需求—一条测试项”为一行记录，同一需求对应多条测试项时占多行。主键建议使用“需求标识+测试项标识”的组合唯一约束，防止同一对关联被重复登记。需求标识在需求创建时分配且不再复用，测试项标识同理，两者都不随标题修改而变化。
| 字段名 | 含义 | 取值 | 必填性 | 填写规则 |
|---|---|---|---|---|
| 需求标识 | 需求条目的唯一编号 | 按团队编号规则，如 REQ-001 | 必填 | 创建时分配，不复用、不随标题变更 |
| 需求标题 | 需求条目的简短描述 | 文本 | 必填 | 与需求库保持一致，便于人工核对 |
| 需求版本 | 该需求条目当前生效的版本 | 版本号或修订号 | 必填 | 需求内容变更时递增，关联表同步更新 |
| 测试项标识 | 测试用例或测试项的编号 | 按团队编号规则，如 TC-101 | 必填 | 与测试用例库一致，一条测试项可关联多条需求时分别成行 |
| 测试类型 | 该测试项所属的验证类型 | 功能、接口、性能、安全、兼容性等 | 必填 | 按团队枚举填写，不自由输入 |
| 覆盖状态 | 该需求是否已被有效测试项覆盖 | 未覆盖、部分覆盖、已覆盖 | 必填 | 按需求维度汇总填写，不由单条测试项结果直接决定 |
| 验证结论 | 测试执行后的通过情况 | 未执行、通过、失败、阻塞 | 必填 | 按测试项执行结果填写，与覆盖状态分开维护 |
| 证据链接 | 支撑结论的执行记录或附件地址 | 链接或附件编号 | 验证结论为通过或失败时必填 | 指向测试报告、日志、截图或缺陷单 |
| 更新人 | 最后修改该行的人员 | 姓名或账号 | 必填 | 每次状态变更时自动或手工记录 |
| 更新时间 | 最后修改时间 | 日期时间 | 必填 | 用于识别过期记录 |
覆盖状态与验证结论必须分开记录。覆盖状态回答“这条需求有没有被有效测试项覆盖”，验证结论回答“执行结果是否通过”。两者混在一个字段里，会出现“测试失败但已覆盖”和“未覆盖所以没有结论”被写成同一种状态的情况，覆盖判定就失去依据。例如某需求有一条测试项已执行但失败，覆盖状态应为“已覆盖”，验证结论为“失败”；若测试项尚未设计，覆盖状态为“未覆盖”，验证结论为“未执行”。
枚举值要固定，避免“基本覆盖”“差不多通过”这类自由文本。覆盖状态只允许未覆盖、部分覆盖、已覆盖三值；验证结论只允许未执行、通过、失败、阻塞四值。必填与选填的划分原则是：影响覆盖判定的字段全部必填，证据链接在结论为通过或失败时必填，未执行时可暂空。
建立关联的操作步骤
建表过程从需求清单出发，到关联表通过评审结束。每一步都应有明确输入、动作和输出，避免边填边改导致口径不一。
- 提取可验证条目。输入为需求库中当前版本的需求清单；动作为按“可独立验证”原则拆分并分配需求标识；输出为需求条目清单，完成标志是每条需求都有唯一标识和版本号。
- 匹配测试项并登记关联。输入为需求条目清单与测试用例库；动作为为每条需求找到至少一条有效测试项，按“需求—测试项”成行登记，一条需求对应多条测试项时逐行写入；输出为关联表初稿，完成标志是每条需求至少有一行记录。
- 回填覆盖状态。输入为关联表初稿；动作为按需求维度检查测试项是否覆盖该需求的全部可判定行为，填写未覆盖、部分覆盖或已覆盖；输出为带覆盖状态的关联表，完成标志是没有空白覆盖状态。
- 执行测试并挂接证据。输入为已覆盖的关联表与测试计划；动作为执行测试项，填写验证结论，将测试报告、日志或缺陷单链接写入证据字段；输出为带结论和证据的关联表，完成标志是通过和失败的记录都有证据链接。
- 评审确认完整性。输入为完整关联表；动作为由需求负责人和测试负责人共同核对需求条目是否齐全、关联是否遗漏、状态是否一致；输出为评审记录和修订后的关联表，完成标志是评审意见关闭、关联表定版。
当团队使用 ONES 管理需求与测试时，测试用例可以与产品需求、研发任务关联，测试计划与迭代关联，关联关系随工作项状态变化保持同步。这样关联表不必完全靠手工维护，需求侧和测试侧的状态可以在同一流程中核对。自定义用例属性可用于补充测试类型等字段，具体可配置范围以实际产品为准。
角色分工与各环节交付物
关联表涉及需求侧、测试侧和评审三方，职责边界不清会出现需求改了表没改、测试项漏挂的情况。下表按角色列出动作、写入范围和交付物。
| 角色 | 主要动作 | 写入范围 | 更新时点 | 交付物 |
|---|---|---|---|---|
| 需求负责人 | 拆分需求条目、分配需求标识、维护需求版本 | 需求标识、需求标题、需求版本 | 需求创建或变更时 | 需求条目清单、变更说明 |
| 测试设计人员 | 设计测试项、登记需求与测试项的关联、初判覆盖状态 | 测试项标识、测试类型、覆盖状态 | 测试设计完成时 | 关联表初稿、测试项清单 |
| 测试执行人员 | 执行测试项、填写验证结论、挂接证据 | 验证结论、证据链接、更新人、更新时间 | 每次执行后 | 执行记录、缺陷单、测试报告 |
| 评审者 | 核对关联完整性与状态一致性、确认覆盖判定 | 评审意见，不直接改业务字段 | 版本发布前或需求变更后 | 评审记录、问题清单 |
写入权限按字段划分比按整表划分更实用：需求负责人只改需求侧字段，测试设计人员维护关联和覆盖状态，执行人员只更新结论与证据。交接物要可追溯，需求变更说明交给测试设计人员作为更新关联的依据，测试报告交给评审者作为覆盖判定的证据。评审记录应保留评审时间、参与人和关闭情况，便于后续版本对照。
填写示例：一条需求的完整关联记录
以下为演示情景，用于说明字段如何填写，不代表真实项目数据。假设需求“连续输错五次密码后锁定账户 30 分钟”被拆为一条需求条目，标识 REQ-007，版本 V1.2。
| 需求标识 | 需求版本 | 测试项标识 | 测试类型 | 覆盖状态 | 验证结论 | 证据链接 |
|---|---|---|---|---|---|---|
| REQ-007 | V1.2 | TC-201 | 功能 | 已覆盖 | 通过 | 测试报告 R-2024-031 第 4 节 |
| REQ-007 | V1.2 | TC-202 | 功能 | 已覆盖 | 通过 | 测试报告 R-2024-031 第 5 节 |
| REQ-007 | V1.2 | TC-203 | 接口 | 已覆盖 | 失败 | 缺陷单 BUG-118 |
填写过程如下：测试设计人员先确认该需求包含“达到五次失败计数”“触发锁定”“锁定持续 30 分钟”三个可判定行为，分别设计 TC-201、TC-202、TC-203 三条测试项并登记关联。覆盖状态按需求维度判断，三条测试项覆盖了全部行为，因此填“已覆盖”。执行后 TC-201、TC-202 通过，TC-203 失败，验证结论按测试项分别填写，失败项挂接缺陷单。此时覆盖状态仍为“已覆盖”，因为覆盖回答的是有没有测，失败属于验证结论，修复后重新执行并更新结论与证据即可。
若后续需求变更为锁定 60 分钟，需求版本升为 V1.3，测试设计人员需更新 TC-203 的预期结果并重新执行，关联表同步修改需求版本和验证结论，旧版本记录保留用于追溯。
覆盖判定与完成检查
关联表是否可用，取决于能否据此判断每条需求都被有效验证。检查按下表逐项执行，全部满足才可判定覆盖完整。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 需求条目完整性 | 当前版本每条需求都有唯一标识和版本号 | 补拆或补编号后重新登记 |
| 每条需求至少一条有效测试项 | 不存在覆盖状态为“未覆盖”的需求 | 补充测试设计或标记为阻断项 |
| 覆盖状态与验证结论一致 | 已覆盖的需求有执行结论；未执行的不标为通过 | 核对执行记录后修正状态 |
| 无空缺字段 | 必填字段无空白，通过和失败记录均有证据链接 | 补齐证据或回退结论 |
| 变更同步 | 需求版本变更后关联记录已更新，旧版本可追溯 | 按变更说明更新关联并记录更新时间 |
| 评审关闭 | 评审问题全部关闭并有评审记录 | 未关闭问题列为阻断项，暂不定版 |
阻断项的判定条件是：存在未覆盖需求且无合理豁免说明，或存在通过结论但无证据链接的记录。出现阻断项时关联表不能作为覆盖判定依据，需在问题关闭后重新检查。完成标志是检查表全部通过、评审记录归档、关联表版本与需求版本一致。需求变更后应重新执行本检查，避免关联表停留在旧版本上。
常见问题
需求变更后，关联表里的旧记录应该删除还是保留？
保留旧记录，新增或更新当前版本记录。具体做法是：需求内容变更时递增需求版本号，测试设计人员按新版本更新对应测试项的预期结果和关联记录，旧版本行保留用于追溯。检查时以最新版本为准，旧版本记录不参与当前覆盖判定。若团队表结构只允许一行对应一条需求，可另设历史表或版本字段区分，避免覆盖历史证据。
一条测试项同时验证多条需求时，关联表怎么记？
按“需求—测试项”成对拆行登记，一条测试项关联几条需求就写几行，每行使用相同的测试项标识、不同的需求标识。这样每条需求的覆盖状态都能独立判定，不会因为共用测试项而互相牵连。执行结果回填时，同一测试项的验证结论在各行保持一致，证据链接可指向同一份执行记录。
覆盖状态填“已覆盖”但测试失败，这条需求算验证通过吗？
不算。覆盖状态说明该需求已被有效测试项覆盖，验证结论说明执行结果。测试失败时覆盖状态仍为“已覆盖”，验证结论为“失败”，并挂接缺陷单作为证据。需求是否可判定为验证通过，要看失败项修复后重新执行的结果，而不是覆盖状态本身。评审时应同时查看两个字段，避免把“已覆盖”误读为“已通过”。
团队规模较小、需求数量不多时，还需要单独建关联表吗？
可以用工具内的关联关系替代独立表格，但字段口径仍需保留。需求数量少时，在需求工作项上直接关联测试用例、用自定义属性记录覆盖状态和验证结论，能减少手工维护。前提是关联关系可查询、状态字段有固定枚举、证据可挂接。需求数量增长或需要按版本汇总覆盖情况时，再考虑导出为独立关联表做核对。
关联表建好后，多久检查一次覆盖完整性？
至少在每个版本发布前和每次需求变更后各检查一次。版本发布前按检查清单逐项核对，确认无未覆盖需求、状态与结论一致、证据齐全；需求变更后重点检查关联是否同步、旧版本是否可追溯。迭代节奏快的团队可在每次迭代评审时顺带核对新增和变更的需求行，避免问题积累到发布前集中暴露。
