2. 航空软件适航标准与证据要求
在航空软件适航审定中，标准体系决定了“什么算证据、证据要长什么样、证据之间如何关联”。DO-178C《机载系统和设备合格审定中的软件考虑》是软件适航的核心标准，它并不直接规定测试工具或数据格式，而是通过“目标—活动—证据”的框架，要求申请人证明软件生命周期各阶段的目标已达成。测试数据与证据正是这一证明链条中最关键的部分。
一、标准族的分工：从核心到补充
DO-178C 本身覆盖软件生命周期过程、生命周期数据、验证与配置管理要求。围绕它，RTCA 发布了多项补充文件：DO-330《软件工具鉴定考虑》规定工具鉴定等级（TQL-1 至 TQL-5）及工具鉴定数据；DO-331《基于模型的开发和验证补充》针对模型化开发，明确模型作为生命周期数据时的验证与追溯要求；DO-332 面向面向对象技术，DO-333 面向形式化方法。它们共同构成“核心标准 + 技术补充”的体系。
对测试数据与证据而言，最直接相关的是 DO-178C 第 6 章“软件验证过程”和第 11 章“软件生命周期数据”。第 6 章要求验证过程必须覆盖需求、设计、代码和集成各层级，并明确测试目标；第 11 章则列出必须受配置管理的生命周期数据，包括测试计划、测试用例、测试规程、测试结果、覆盖分析报告和问题报告。这些数据不是“做完测试后顺手保存的附件”，而是适航审查中必须提交、可追溯、可复现的正式证据。
二、证据类型：从计划到结果的分层
按 DO-178C 的框架，测试相关证据可分为四层。第一层是计划类证据，如软件验证计划（SVP）、软件配置索引（SCI），说明“打算怎么测、测什么”。第二层是定义类证据，如测试用例与测试规程，描述输入、预期输出、前置条件和判定准则。第三层是执行类证据，如测试日志、测试结果、实际输出与预期输出的比对记录。第四层是分析类证据，如结构覆盖分析（语句、判定、MC/DC）、需求覆盖分析和追溯矩阵。
DO-331 进一步要求，当使用模型作为开发产物时，模型本身及其与代码、测试用例之间的追溯关系也必须作为证据。例如，若用 Simulink 模型生成代码，则模型级别的测试、模型到代码的等价性检查、模型覆盖分析都要纳入证据集。DO-330 则规定：若测试工具的输出被用于合格审定证据，且工具可能引入错误而未在其它过程中被发现，则必须进行工具鉴定，并产生工具鉴定数据（TQD），包括工具需求、工具验证用例和工具配置索引。
三、可追溯性：证据链的骨架
可追溯性是适航审查中最容易被质疑的环节。DO-178C 要求建立双向追溯：从系统需求到软件需求、从软件需求到设计、从设计到代码、从代码到测试用例、从测试用例到测试结果。对测试数据而言，这意味着每一条测试用例都必须能追溯到至少一条软件需求，每一个测试结果都必须能追溯到对应的测试用例和测试规程，每一次覆盖分析都必须能追溯到具体的代码结构或需求项。
实际操作中，追溯通常通过需求管理工具（如 DOORS、Polarion）和测试管理工具（如 TestRail、VectorCAST）维护。但工具只是载体，审查方关注的是追溯关系是否完整、是否一致、是否可验证。例如，若某条需求没有对应的测试用例，或某条测试用例没有对应的需求，都会形成“追溯缺口”，必须在问题报告中记录并处理。
四、审定方关注点：从“有没有”到“可不可信”
适航审定方（如 FAA、EASA 及其授权代表 DER）在审查测试数据与证据时，通常围绕四个问题展开。第一，证据是否完整：DO-178C 表 A-1 至 A-7 列出了各过程的目标和输出数据，审查方会逐项核对是否缺失。第二，证据是否一致：测试用例与需求、测试结果与用例、覆盖报告与代码之间是否存在矛盾。第三，证据是否可复现：测试环境、工具版本、配置参数是否被记录，第三方能否在相同条件下复现结果。第四，证据是否受控：所有生命周期数据是否纳入配置管理，变更是否经过影响分析和审批。
以 DO-330 为例，若使用自动生成测试用例的工具，审查方会关注工具鉴定等级是否与工具在生命周期中的角色匹配。若工具输出直接作为合格审定证据且工具可能引入未被后续过程发现的错误，则通常需要 TQL-1 至 TQL-3 级别的鉴定，并提交工具需求、工具验证用例和工具配置索引。若工具仅用于辅助分析、输出不直接作为证据，则鉴定要求可降低。
五、实操要点：建立可审查的证据包
在实际项目中，建议从三个动作入手。第一，在验证计划中明确证据清单和追溯规则，规定每条需求对应的测试层级、覆盖准则和判定依据。第二，使用需求管理工具建立需求—设计—代码—测试用例—测试结果的双向链接，并定期运行追溯完整性检查。第三，对测试工具进行角色分类：哪些工具输出直接进入证据包，哪些仅用于内部调试；前者按 DO-330 评估鉴定需求，后者在配置索引中说明用途即可。
此外，DO-331 下的模型测试需要额外注意：模型级别的覆盖分析不能替代代码级别的覆盖分析，除非能证明模型与代码之间的等价性。若采用自动代码生成，应保留模型到代码的追溯记录、生成器配置和版本信息，并将这些纳入证据包。
总体而言，DO-178C 及其补充标准对测试数据与证据的要求，核心不是“多”，而是“可追溯、可复现、可审查”。测试数据只有嵌入需求—设计—代码—测试—覆盖的完整证据链，并经过配置管理和工具鉴定，才能成为适航审定中真正可信的证据。