第二章：追溯矩阵基础概念

什么是追溯矩阵？

追溯矩阵，说白了就是一张“谁跟谁有关系”的表格。

我习惯把它想象成一个大型项目的通讯录。你想想看，一个汽车电子系统里，有需求、有设计文档、有代码、有测试用例……这些东西之间不是孤立的。需求A催生了设计B，设计B又变成了代码C，代码C被测试用例D验证。追溯矩阵就是把这些关系一一记录下来。

举个例子，我参与过一个车身控制模块的项目。当时客户提了个需求：“车窗防夹功能要在10毫秒内响应”。这个需求必须追溯到对应的软件设计、代码实现、还有测试用例。如果没有追溯矩阵，你根本不知道哪个测试用例是专门验证这个需求的。

所以，追溯矩阵本质上是一个关系映射表。它告诉你：

• 每个需求对应哪些设计元素
• 每个设计元素对应哪些代码模块
• 每个代码模块对应哪些测试用例
• 反过来，每个测试用例验证了哪个需求

为什么需要它？

这个问题我经常被问到。有人觉得追溯矩阵是“形式主义”，是给审核员看的。嗯，我以前也这么想过，直到踩了坑。

我曾经负责一个ADAS（高级驾驶辅助系统）的项目。项目做到一半，客户突然说：“这个功能的需求变了，你们得改。” 当时团队里一片混乱。因为没有追溯矩阵，我们根本不知道这个需求影响了哪些设计、哪些代码、哪些测试。结果呢？改了一个地方，漏了三个地方。最后测试阶段才发现问题，返工成本高得吓人。

所以，追溯矩阵的核心价值在于：

• 变更影响分析：需求变了，你能立刻知道哪些地方要跟着改
• 覆盖率检查：确保每个需求都被实现了，每个实现都被测试了
• 合规性证明：ASPICE审核时，审核员会直接问：“你的追溯矩阵在哪？”
• 问题定位：测试失败了，你能顺着追溯链找到是哪个需求或设计出了问题

核心术语：工件、链接、覆盖度

追溯矩阵里有三个核心概念，我一个个说。

1. 工件（Artifact）

工件就是你在开发过程中产生的任何“东西”。说白了，就是文档、代码、模型、测试用例等等。

常见的工件包括：

• 系统需求规格书
• 软件需求规格书
• 软件架构设计文档
• 详细设计文档
• 源代码文件
• 单元测试用例
• 集成测试用例
• 系统测试用例

每个工件都有一个唯一的标识符。我习惯用“项目名_类型_编号”的格式，比如“BCM_SRS_001”表示车身控制模块的系统需求第1条。

2. 链接（Link）

链接就是工件之间的关系。它告诉你“A跟B有关系”。

链接的类型通常有：

• 正向追溯：从需求到设计，再到代码，再到测试。比如“需求R1 → 设计D1 → 代码C1 → 测试T1”
• 反向追溯：从测试往回找，看它验证了哪个需求。比如“测试T1 → 代码C1 → 设计D1 → 需求R1”
• 水平追溯：同一层级之间的关联，比如需求之间的依赖关系

我记得有一次审核，审核员问我：“这个测试用例到底验证了哪个需求？” 我打开追溯矩阵，顺着反向链接一查，3秒钟就给出了答案。审核员当场就满意了。

链接的表示方式也很简单，通常就是一张表：

源工件	链接类型	目标工件
SRS_001	正向追溯	SDD_001
SDD_001	正向追溯	CODE_001
CODE_001	正向追溯	TEST_001
TEST_001	反向追溯	SRS_001

3. 覆盖度（Coverage）

覆盖度是个量化指标。它告诉你“追溯得够不够全”。

常见的覆盖度指标有：

• 需求覆盖度：有多少需求被追溯到了设计和测试？理想情况是100%
• 测试覆盖度：有多少代码或功能被测试用例覆盖了？
• 双向覆盖度：每个需求都有对应的测试，每个测试都对应某个需求

覆盖度的计算其实很简单。比如你有100条需求，其中95条找到了对应的测试用例，那需求覆盖度就是95%。

但这里有个坑：覆盖度只告诉你“有没有”，不告诉你“好不好”。也就是说，即使覆盖度是100%，也不代表你的测试用例写得足够好。这一点我在项目中深有体会——有一次覆盖度报表显示100%，但实际测试时还是漏了一个边界条件。

总结一下

追溯矩阵不是什么高深的东西。它就是一张关系表，记录了工件之间的链接，然后用覆盖度来衡量是否完整。

我个人建议，项目一开始就要建立追溯矩阵。别等到快审核了才临时抱佛脚。那时候你会发现，很多链接已经找不到了，很多关系已经模糊了。

嗯，下一章我会讲怎么实际搭建一个追溯矩阵，包括工具选择和具体步骤。到时候咱们再细聊。