1. 航空软件测试数据与证据管理导论

航空软件与普通商业软件最根本的差别,不在于代码规模或算法复杂度,而在于它必须向适航审定方证明"我确实安全、确实符合要求"。这种"证明"不是靠开发者的口头说明,而是靠一整套可追溯、可审查、可复现的测试数据与证据。本课程围绕这套数据与证据如何产生、如何组织、如何保存、如何被审查展开,共30章,从概念、标准、工具到实操逐步深入。

一、为什么航空软件需要"证据"

在民用航空领域,机载软件属于"审定项目"的一部分。以运输类飞机为例,软件通常按 DO-178C《机载系统和设备合格审定中的软件考虑》进行开发与验证,其软件等级由失效状态对飞机安全的影响决定:A级(灾难性)、B级(危险性)、C级(较大)、D级(较小)。等级越高,对验证目标、独立性、覆盖率和数据的要求越严格。例如A级软件要求实现目标(如语句覆盖、判定覆盖、MC/DC)必须由独立于开发的人员完成,且所有验证结果都要形成可审查的记录。

这意味着,测试活动本身只是"做实验",而测试数据与证据才是"提交给审定方的答卷"。审定方(如中国民航局、美国FAA、欧洲EASA)不会重新跑一遍你的测试,而是审查你的证据链:需求是否被测试覆盖、测试是否按计划执行、结果是否与预期一致、异常是否被记录并处理、软件构型是否与测试时一致。任何一环缺失,都可能导致审定问题甚至驳回。

核心认识:在航空软件中,"测过了"不等于"证明了"。只有形成结构化、可追溯、可复现的数据与证据,测试结论才具备适航意义。

二、测试数据与证据的定义与边界

本课程把"测试数据"定义为:在测试活动全过程中产生、采集、记录和使用的各类信息,包括测试输入、激励信号、预期结果、实际结果、环境参数、构型信息、执行日志等。而"证据"是其中能够支撑某个验证目标或符合性声明的那部分数据,它必须满足可追溯、可审查、可复现三个条件。

两者关系可以这样理解:测试数据是"原材料",证据是"经过组织、关联和确认后可用于证明的成品"。同一份测试日志,孤立存放时只是数据;当它与某条需求、某个测试用例、某次构型基线关联起来,并能说明"该需求已被验证且结果符合预期"时,它才成为证据。

管理范围通常包括:测试计划与说明、测试用例与规程、测试脚本与自动化资产、测试环境与工具鉴定记录、执行日志与结果文件、缺陷与异常记录、覆盖率分析报告、追溯矩阵、构型与基线记录、评审与批准记录。这些对象并非孤立存在,而是通过"需求—设计—代码—测试—结果"的追溯链相互连接。

三、生命周期框架:数据与证据如何流动

航空软件测试数据与证据不是测试阶段才出现的,它贯穿软件生命周期。下图给出一个简化的生命周期数据流框架,说明各阶段产生什么数据、如何汇入证据体系,以及最终如何支撑符合性声明。

航空软件测试数据与证据生命周期框架 需求与计划 设计与开发 测试准备 测试执行 分析与报告 产出数据 需求规格 验证计划 软件等级判定 产出数据 设计文档 源代码 构型基线 产出数据 测试用例 测试规程 环境鉴定记录 产出数据 执行日志 实际结果 缺陷记录 产出数据 覆盖率报告 追溯矩阵 符合性声明 测试数据与证据库 结构化存储 · 版本受控 · 可追溯 · 可复现 追溯性 需求↔用例↔结果↔缺陷 可复现性 环境·构型·输入·步骤一致 可审查性 记录完整·签署·受控 支撑适航符合性声明与审定审查

从图中可以看到,证据不是测试阶段的"副产品",而是从需求阶段就开始积累、逐阶段丰富、最终汇聚成库的系统工程产物。需求阶段确定软件等级和验证目标,决定了后续证据的严格程度;设计与开发阶段形成构型基线,决定了测试对象的可复现性;测试准备阶段设计用例和规程,决定了证据的覆盖范围;测试执行阶段产生原始数据;分析与报告阶段把数据组织成可审查的证据。

四、贯穿全课程的三条主线

本课程后续章节将围绕三条主线展开,理解它们有助于把握整体脉络。

  • 标准主线:DO-178C及其补充文件(DO-330工具鉴定、DO-331基于模型、DO-332面向对象、DO-333形式化方法)规定了"要做什么、做到什么程度"。不同软件等级对应不同的数据要求,例如D级软件的部分验证目标可以简化,但数据仍需受控。
  • 数据主线:从测试用例设计、执行记录、结果采集到覆盖率分析,关注"数据怎么产生、怎么记录、怎么关联"。这条线强调数据的完整性、一致性和可追溯性。
  • 证据主线:从数据组织、评审、签署到构型管理和审定提交,关注"数据怎么变成证据、证据怎么被审查"。这条线强调证据的受控状态、版本基线和审查准备。

三条主线并非独立,而是相互约束:标准决定数据要求,数据支撑证据形成,证据反过来验证标准符合性。例如,当DO-178C要求A级软件达到MC/DC覆盖时,测试数据必须记录每个判定条件的取值组合,覆盖率分析报告要能逐条对应到源代码结构,最终形成可提交的覆盖证据。

五、一个具体场景:从测试执行到证据形成

假设某飞控软件的一个A级模块需要验证"迎角超限时触发告警"这条需求。测试人员在半物理仿真环境中注入迎角信号,从正常值逐步增加到超限阈值,记录告警触发时刻、触发值和系统响应。这一过程产生以下数据:测试用例(输入信号序列、预期告警阈值)、环境配置(仿真模型版本、接口板卡型号、软件构型号)、执行日志(时间戳、信号值、告警标志)、实际结果(告警触发值)、缺陷记录(若触发值偏离预期)。

这些数据要成为证据,还需要:与需求条目建立追溯链接;确认测试环境经过工具鉴定或验证;确认软件构型与基线一致;由独立验证人员评审并签署;纳入受控库并分配版本号。只有完成这些步骤,这份记录才能在审定审查中回答"这条需求是否被验证、验证是否可信、结果是否可复现"。

教学提示:后续章节会反复出现"追溯矩阵""构型基线""工具鉴定""覆盖率"等概念。建议在学习时始终问三个问题:这份数据对应哪条需求?它是否在受控状态下产生?审定方能否据此复现并确认结论?

六、本课程的学习目标

完成本课程后,学习者应能够:理解DO-178C对测试数据与证据的基本要求;根据软件等级确定数据管理的严格程度;设计可追溯的测试用例与记录结构;组织测试数据并形成可审查的证据包;使用常见工具进行覆盖率分析和追溯管理;识别数据管理中的常见缺陷并采取纠正措施;为适航审定审查准备完整的数据与证据材料。