ASPICE L2 证据链怎么准备：一张追溯矩阵贯穿需求-设计-代码-测试（附清单）
ASPICE 评估里最“致命”的问题，往往不是文档缺一份，而是证据链断在关键一环：需求变更没闭环、设计与代码对不上、测试用例找不到来源。很多团队直到预评估才发现，自己并不是“没写”，而是“没法证明自己做过”。
本文以 ASPICE L2 常见抽样逻辑为线索，给出一套可落地的证据准备方法：用统一编号体系把 SYS.2 / SWE.1 / SWE.2 / SWE.4 / SWE.5 / SWE.6 的工作产品串起来，并提供一份项目组可直接照做的证据清单。
在深圳华赛信息咨询的辅导实践中，导致 L2 评估返工的证据问题高度集中：最常见的 3 类断链问题通常占到整改工作量的 约 70%；同时，临近评估才“补作业”会让项目至少损失 15%-25% 的迭代产能。
为什么评估师总说“证据链断了”？
很多项目组自认为“工具都齐了”：Jira 有需求，Git 有代码，测试平台也有用例。但评估师的关注点不是“有没有东西”，而是“能不能从同一个起点一路追到终点”。
在 L2 抽样中，评估师通常会从若干条关键系统需求（或软件需求）出发，要求你证明它们在生命周期里经历了：定义、评审、分解、设计、实现、验证/确认，以及变更控制。我们在项目辅导中观察到，抽样追溯经常会覆盖 10-20 条关键需求，并要求每条需求至少能连到 2-3 层下游证据（设计、代码、测试）。
真相一：证据链不是 Excel，而是“可追溯的工作流”
很多团队把追溯理解成“做一张 Excel 表”。这会带来两个问题：第一，维护成本巨大；第二，一旦需求变更，Excel 永远跟不上真实状态。
可落地的做法是把追溯固化到日常动作里：
- 唯一 ID： 从系统需求（SYS.2）到软件需求（SWE.1），再到设计（SWE.2/SWE.3）与测试（SWE.4/SWE.5/SWE.6），每个对象都有稳定且唯一的编号；编号在工具里是字段，不是正文里的文字。
- 强制关联： 合并代码（Merge Request / Pull Request）必须选择关联需求 ID；测试用例必须引用需求 ID；缺陷单必须关联测试用例与版本/基线。
- 可审计变更： 需求变更要有状态流转、影响分析、审批记录、下游更新证据；否则就是“变更失控”。
真相二：评审记录要能回答“谁、何时、按什么标准、结论是什么”
很多评审记录只有一句“已评审通过”，这在 ASPICE 里基本等于没做。评估师需要看到的是：评审对象、评审参与者、评审准入条件、评审检查清单（Checklist）、发现的问题及关闭状态。
建议把评审分为三类，并各自留证：
- 需求评审： SYS.2/SWE.1 的一致性、可测试性、完整性、可追溯性。
- 设计评审： SWE.2/SWE.3 的接口、依赖、约束、关键风险与可验证性。
- 代码评审： 合规性（规则/静态检查）、关键逻辑、边界条件、可测试性，以及是否满足需求与设计。
真相三：测试证据要体现“覆盖”，而不只是“跑过”
只提交一份“测试报告”通常不够。更有效的证据是：测试用例与需求的对应关系、执行记录、结果、缺陷闭环、版本信息（基线）。尤其在 L2，评估师很在意你是否能证明：当需求变更时，测试用例是否同步更新，回归是否执行。
ASPICE L2 证据清单：从需求到测试怎么摆证据
| 链路环节 | 建议证据 | 常用存放位置 | 责任角色 | 最常见踩坑 |
| SYS.2 系统需求 | 系统需求条目、版本/基线、评审记录、变更记录 | ALM/需求库 + 评审记录（会议纪要/工单） | 系统工程/产品/需求负责人 | 需求无唯一 ID；需求变更无影响分析 |
| SWE.1 软件需求 | 软件需求分解、与 SYS.2 的双向追溯、评审记录 | ALM/需求库 | 软件需求/架构负责人 | 只做单向追溯；需求与测试缺乏可测试性说明 |
| SWE.2/SWE.3 设计 | 架构/详细设计、接口定义、设计评审记录、变更记录 | 设计文档库 + 评审记录 | 架构师/模块负责人 | 设计不引用需求 ID；评审只有“签字”没缺陷关闭 |
| 实现（代码） | 提交记录、MR/PR、Code Review 证据、静态检查/构建记录 | Git 平台 + CI/CD | 开发负责人/配置管理员 | 提交信息不含需求 ID；评审不记录问题与整改 |
| SWE.4 单元验证 | 单元测试用例与执行记录、覆盖证据、缺陷闭环 | 测试平台 + CI 报告 | 开发/测试 | 只有“执行通过”无需求关联；缺陷未关联到版本 |
| SWE.5/SWE.6 集成与确认 | 集成计划、集成测试用例、测试报告、回归记录、发布基线 | 测试平台 + 发布记录/基线清单 | 测试负责人/项目经理 | 测试报告无基线；回归触发条件不清晰 |
| SUP.8 配置管理 | 基线策略、配置项清单、发布记录、变更控制证据 | 配置库 + 发布平台 | 配置管理员 | 基线没有“冻结点”；发布产物不可复现 |
一套能快速见效的“证据链落地三步法”
第一步：先定义“评估要看的样子”，再反推日常动作
把评估抽样当成一条“演示脚本”：从某条系统需求开始，依次点开它的评审记录、分解到软件需求、链接到设计、链接到代码提交与评审、链接到测试用例与执行记录、链接到缺陷闭环与发布基线。脚本跑不通，就说明日常工作流缺关键字段或缺关键动作。
第二步：把追溯做成“默认动作”，而不是“额外任务”
最有效的方式，是在工具里设置必填项与校验规则：需求必须有状态与版本；MR 必须关联需求；测试用例必须引用需求；发布必须生成基线清单。这样工程师不是“被要求写证据”，而是在正常开发中自然沉淀证据。
第三步：用模拟抽样把风险提前暴露
在正式评估前做 2-3 轮模拟抽样，每次抽样都按“从需求追到测试”的方式走一遍，并记录断点。断点清单就是整改计划。比起评估前一周全员补文档，这种方式更省成本、风险更可控。
华赛咨询如何帮助企业把 ASPICE 证据链做“真落地”？
深圳华赛信息咨询的做法不是给模板，而是把证据链固化到工具链与团队习惯里：
- 现状诊断： 用抽样脚本快速定位断链环节，明确要补的是字段、流程还是职责边界。
- 工具链配置： 基于现有 Jira/Polarion/Codebeamer/Git 平台配置工作流、字段与校验规则，确保追溯“自动生成”。
- 陪跑演练： 以真实项目为载体开展评审与抽样演练，把证据沉淀变成项目节奏的一部分，而不是评估前的突击任务。
常见问题解答 (FAQ)
Q1：ASPICE L2 的证据是不是越多越好？
A： 不是。评估更看重证据是否一致、是否可追溯、是否能复现。冗余文档反而会引入矛盾点，增加抽样风险。
Q2：没有 Polarion/Codebeamer，只用 Jira + GitLab 能做出证据链吗？
A： 可以。关键不在工具品牌，而在字段、链接规则、基线策略与执行纪律。很多团队缺的是“可审计的流程配置”，而不是工具本身。
Q3：证据链落地通常需要多长时间？
A： 如果已有稳定项目节奏与工具基础，通常 6-10 周可以完成第一轮落地（含模拟抽样），并在后续 1-2 个迭代中固化成习惯。越早开始，越能避免评估前的集中返工。
ASPICE 的难点从来不是“写文档”，而是“能证明你按流程交付”。把证据链做成日常工作的一部分，你就不会害怕抽样和飞行检查。
如果您希望快速定位团队的断链位置，并把 ASPICE L2 证据链落到工具与项目节奏里，欢迎联系深圳华赛信息咨询获取一份可执行的改进方案。