双向追溯是 ASPICE 评估的高频检查项，几乎所有工程过程域都会核查追溯关系。很多团队觉得只要做了追溯矩阵，把需求、设计、测试用例连上线就没问题，但实际评估下来，追溯相关的弱项依旧很多。问题往往不是追溯覆盖率低，而是追溯本身是无效的，看起来有很多关联线，但经不起细节核查。评估师一深挖，就会发现各种问题，直接判定追溯不充分。

评估中常见的无效追溯，主要有五类典型情形，很多项目都或多或少存在。

第一类是只有编号没有实质内容的空追溯。很多团队的追溯矩阵里只有编号对应关系，点进去看不到具体内容，需求条目只有一句话，测试用例只有标题，没有具体步骤和预期结果。评估师无法判断二者是不是真的对应，还是只是强行拉了条线凑数量。这类追溯看起来覆盖率很高，实际没有证明力，评估师不会认可。有效的追溯，每个条目都要有完整明确的内容，能够清晰看出来上下游之间的对应关系，而不是只有一个编号。

第二类是变更不同步的过期追溯。项目初期搭建了完整的追溯矩阵，但后续需求发生变更，只改了需求文档，没有同步更新下游的设计、代码、测试用例，也没有调整追溯关系。时间久了，追溯矩阵里大量链接指向已经废弃的旧版本内容，或者新增的需求没有下游追溯。评估师抽样核对变更过的需求，很容易发现追溯和实际版本脱节。有效的追溯必须和变更同步，任何需求、设计、测试的改动，都要同步更新对应的追溯链路，清理失效的旧关联。

第三类是只有正向没有反向的单向追溯。很多团队只做从需求到设计、到测试的正向追溯，确保每条需求都有对应的测试。但反过来，从测试用例反向回溯到需求，就会出现大量测试用例找不到对应的原始需求，或者用例覆盖的需求不在正式需求范围内。ASPICE 要求的是双向追溯，既要证明所有需求都被覆盖，也要证明所有测试都有对应的需求依据，没有多余的无来源测试。

第四类是颗粒度严重不匹配的错位追溯。比如一条大颗粒度的系统需求，直接对应几十条底层测试用例，中间没有经过软件需求、详细设计的分层拆解；或者反过来，非常细的软件需求，只对应一条很笼统的系统测试用例。上下游颗粒度差太多，无法清晰说明需求是怎么一步步拆解到测试的，追溯链路是断裂的。有效的追溯要和开发层级匹配，逐层拆解、逐层对应，每一层的颗粒度保持均衡，不能跳级强拉关系。

第五类是只覆盖功能不覆盖安全的片面追溯。很多团队的追溯矩阵只覆盖普通功能需求，功能安全需求、网络安全需求单独放在安全文档里，没有纳入统一的追溯体系。评估师抽查安全相关需求，就会发现没有对应的设计、测试追溯，安全需求的落地情况无法验证。有效的追溯必须覆盖全部类型的需求，功能、性能、安全、合规类需求都要纳入追溯链路，不能漏掉安全相关条目。

想要做出评估认可的有效追溯，不用追求 100% 的覆盖率数字，重点是保证每一条追溯都真实、对应、同步、完整。先把核心需求的追溯做扎实，分层对应，变更同步更新，双向都能对上，再逐步扩大覆盖范围。比起凑数量的空追溯，少而精的真实追溯反而更容易获得评估师认可。

很多团队在追溯上花了大量时间，结果还是被扣分，核心就是只追求表面的覆盖率数字，不关注追溯的实际有效性。避开这五类常见的无效情形，把追溯做真做实，就可以用不多的投入，大幅提升追溯证据的认可度，减少 ASPICE 评估的失分。