3. 测试数据与证据的分类体系
在航空软件适航审定中，测试数据与证据不是一堆散落的文件，而是一套需要被检索、追溯、复用和审查的结构化资产。如果分类体系设计得不好，最直接的后果是：审查方要一份"某软件等级下、某测试阶段产生的、用于覆盖率验证的原始数据"，团队需要人工翻找数天，甚至无法证明数据与需求的追溯关系。因此，本节要解决的核心问题是——如何用一套稳定的分类维度和编码规则，把测试数据与证据组织成可管理、可追溯的对象。
一、四个分类维度及其正交关系
航空软件测试数据与证据的分类，通常从四个维度切入，它们之间是正交的，即一条数据记录会同时携带四个维度的属性，而不是被归入其中某一个类别。
- 按测试阶段分类：单元测试、部件测试、配置项测试（CSCI 级）、系统测试、验收测试。阶段维度决定了数据的"产生时机"和"责任主体"，也决定了它与 DO-178C 生命周期数据的对应关系。
- 按测试类型分类：功能测试、接口测试、性能测试、鲁棒性测试、边界与等价类测试、结构覆盖率测试（语句/判定/MC/DC）。类型维度决定了数据的"验证目标"。
- 按软件等级分类：A、B、C、D 级（依据 DO-178C 的失效影响等级）。等级维度决定了数据的"严格程度要求"，例如 A 级要求 MC/DC 覆盖率证据，C 级通常只要求语句覆盖。
- 按数据用途分类：测试输入数据、预期结果、实际结果、覆盖率报告、测试日志、缺陷记录、追溯矩阵、审查记录。用途维度决定了数据在证据链中"扮演什么角色"。
这四个维度组合起来，才能唯一描述一条证据。例如："配置项测试阶段 + 结构覆盖率测试 + A 级 + 覆盖率报告"，指向的是 DO-178C 表 A-7 中要求的目标证据。只用一个维度分类，检索和追溯都会失效。
二、分类编码规则的设计
分类维度确定后，需要把它们固化为可机读的编码。推荐采用分段式编码，格式为：PH-TY-DL-US-序号。各段取值如下表所示。
| 段位 | 含义 | 取值示例 |
|---|---|---|
| PH | 测试阶段 | UT（单元）、CT（部件）、CSCI（配置项）、SYS（系统）、ACC（验收） |
| TY | 测试类型 | FUN（功能）、IF（接口）、PERF（性能）、ROB（鲁棒性）、BND（边界）、COV（覆盖率） |
| DL | 软件等级 | A、B、C、D |
| US | 数据用途 | IN（输入）、EXP（预期）、ACT（实际）、RPT（覆盖率报告）、LOG（日志）、DEF（缺陷）、TRC（追溯）、REV（审查） |
| 序号 | 流水号 | 4 位数字，如 0017 |
例如编码 CSCI-COV-A-RPT-0017 表示：配置项测试阶段、结构覆盖率测试、A 级软件、覆盖率报告、第 17 号记录。审查方看到这个编码，无需打开文件就能判断其性质。这种"自描述"能力是分类体系的核心价值。
三、元数据模型：让证据可追溯、可验证
仅有编码还不够，每条证据记录必须携带一组元数据字段，才能支撑追溯和审查。建议的最小元数据集包括：
- 标识类：唯一 ID、版本号、文件哈希（SHA-256），用于防篡改和版本比对。
- 来源类：生成工具及版本（如测试执行工具、覆盖率分析工具）、运行环境（目标机/仿真环境）、配置项版本。
- 追溯类：关联的需求 ID、测试用例 ID、上级证据 ID，形成双向追溯链。
- 状态类：执行结果（通过/失败/阻塞）、覆盖率数值、缺陷关联 ID。
- 责任类：执行人、复核人、签署时间，满足独立性要求。
- 保留类：保留期限、密级、存储位置，满足数据管理要求。
四、落地示例：一条覆盖率证据的完整记录
下面给出一条 A 级软件配置项测试的覆盖率证据记录示例（数据为教学假设，非实测结果）：
{
"evidence_id": "CSCI-COV-A-RPT-0017",
"version": "1.2",
"file_hash": "sha256:9f2c...a71d",
"phase": "CSCI",
"test_type": "COV",
"software_level": "A",
"usage": "RPT",
"tool": "CoverageAnalyzer v3.4",
"environment": "目标机 PowerPC MPC755",
"config_item": "FCU-SW-2.1",
"requirement_ids": ["REQ-FCU-045", "REQ-FCU-046"],
"test_case_ids": ["TC-FCU-112", "TC-FCU-113"],
"result": "PASS",
"coverage": {
"statement": "100%",
"decision": "100%",
"mc_dc": "98.7%"
},
"defect_ids": [],
"executor": "张工",
"reviewer": "李工",
"signed_at": "2025-03-12T14:30:00+08:00",
"retention": "型号寿命周期+5年",
"classification": "内部"
}这条记录的价值在于：审查方可以通过 requirement_ids 追溯到需求，通过 test_case_ids 追溯到用例，通过 coverage.mc_dc 判断是否满足 A 级要求，通过 file_hash 验证文件未被篡改，通过 reviewer 确认独立性。任何一个字段缺失，追溯链就会断裂。
五、分类体系落地时的常见问题
在实际项目中，分类体系最容易出问题的地方有三个。第一是维度混用：把"测试类型"和"数据用途"混为一谈，例如把"覆盖率报告"既当作类型又当作用途，导致编码冲突。第二是等级信息丢失：数据从测试团队移交到审定团队时，软件等级字段被丢弃，审查方无法判断该证据是否满足对应等级的严格程度。第三是追溯字段空置：元数据模板里有 requirement_ids，但实际录入时留空，导致证据无法与需求建立关联。