建立需求与验证证据对应表

这个场景能帮你做什么

需求表、设计说明和测试报告各自完整，仍可能有要求从未验证。WorkBuddy 可以把需求编号与实现、测试和证据关联，找出断点。这张表用于检查覆盖，工程风险对应的专项验证计划另行展开。

开始前需要准备什么

准备已确认的需求版本、设计或实现说明、测试用例、执行结果和报告。保留需求编号、适用版本、验收条件、用例编号及证据位置。草稿用例与实际执行记录要区分。

具体怎么做

第一步：确定追踪范围

先列本轮有效需求，标出新增、修改、取消和暂缓。已取消要求不能因旧报告存在而重新纳入，修改后的要求也不能直接沿用旧验证结论。

第二步：建立对应关系

按编号及内容关联设计、实现、测试和结果。没有共同编号时只提出候选对应，保留匹配理由和待确认关系，不能靠标题相似自动认定覆盖。

第三步：检查证据是否真正支持要求

核对测试条件、阈值、对象和版本。正常流程通过不证明异常分支已经验证；有报告文件不证明每项要求达标。区分未设计测试、未执行、失败和证据不可读。

第四步：形成补齐清单

按需求列缺口、影响、应补材料和负责人。对无法定位证据的要求保持未确认，由测试或项目人员核实后更新。

可以直接交给 WorkBuddy 的完整要求

请针对指定版本建立需求—设计/实现—用例—执行结果—证据对应表。
每项保留原编号、验收条件和来源位置。无明确对应只提候选，不把语义相似当成验证完成。
核对对象、版本、工况和判定条件，分别标未覆盖、未执行、失败、证据缺失和待确认。
列出补齐动作，不修改原始测试数据、不宣称通过验收，也不把旧版本通过自动迁移到新版。

完成后会得到什么

一张可从需求走到证据、也可从报告反查需求的表，以及有责任人的补齐事项。

结果应该怎么检查

从需求抽查到原始结果，再从几份测试记录反查对应要求。检查一项测试是否被不恰当地用于证明多个不同条件，失效记录是否被汇总“通过”掩盖。

遇到这些情况怎么处理

编号变化时取得正式对应关系。测试报告只给总体结论时补原始记录。要求本身不可验证时退回澄清，不能由 AI 创建标准后自判通过。

哪些必须人工决定

研发确认实现关联，测试确认覆盖和结果，授权人员决定接受偏差或放行。AI 负责整理追踪关系与缺口。