1. 航空软件版本变更与回归验证导论

航空软件不同于一般商业软件，它一旦装机使用，其失效可能直接威胁飞行安全。因此，航空软件的任何一次版本变更，都不能只以“功能是否正常”作为验收标准，而必须回答三个问题：改了什么、可能影响什么、如何证明没有引入新的不可接受风险。本课程围绕这三个问题展开，目标是让学习者建立从适航要求到工程实践的完整认知，并掌握版本变更控制与回归验证的基本方法。

一、为什么航空软件必须“管住版本”

现代民用飞机大量采用综合模块化航电（IMA）架构，一个机柜内可能同时驻留飞行管理、显示、通信、维护等多个软件功能。软件之间通过ARINC 653分区、共享内存或总线交换数据，耦合关系复杂。某一次看似局部的修改，例如修改大气数据解算中的滤波系数，可能改变高度输出，进而影响自动驾驶接通逻辑、告警门限和飞行指引显示。若只验证被修改的函数，而不验证其下游功能，风险就会被遗漏。

适航规章对机载软件提出了明确要求。以RTCA DO-178C《机载系统和设备合格审定中的软件考虑》为例，它按软件级别（A至E）规定了目标、活动和数据。A级软件失效会导致灾难性后果，要求最严格；C级软件失效为重大后果，要求相对降低。版本变更后，必须判断变更对软件级别、生命周期数据、验证覆盖的影响，并决定回归验证的范围。与之配套的DO-330（工具鉴定）、DO-331（基于模型的开发）、DO-332（面向对象技术）、DO-333（形式化方法）等补充文件，也为不同开发方式提供了符合性路径。

二、版本变更与回归验证的基本概念

版本变更指软件构型项在基线确定后发生的任何修改，包括源代码、可执行目标码、参数数据、配置文件、构建脚本以及开发工具链的变更。变更可来源于缺陷修复、需求新增、硬件适配、适航指令或供应商升级。变更必须经过申请、评估、批准、实施、验证和归档的闭环控制。

回归验证是在变更后重新执行部分或全部验证活动，以确认原有功能未被破坏、新功能符合需求、且未产生非预期影响。回归验证不是简单“重跑一遍测试”，而是基于影响分析确定的最小充分集合。影响分析通常沿三条线索展开：需求追溯链、代码调用链、数据流链。

为便于理解，下面用一张关系图展示“变更—影响分析—回归范围—证据”的传导关系。图中左侧是变更输入，中间是三类影响分析，右侧是回归验证对象与最终符合性证据。

三、从适航要求到工程实践的知识框架

本课程的知识框架可以概括为“一条主线、四个层面”。一条主线是构型管理与变更控制：任何变更都必须有标识、有审批、有记录、可追溯。四个层面分别是：

• 要求层：DO-178C的目标与软件级别、审定基础、合格审定计划（PSAC）、软件合格审定计划（SCMP）、软件验证计划（SVP）等。
• 分析层：变更影响分析、需求追溯、代码影响分析、接口与数据流分析、工具鉴定影响评估。
• 验证层：单元测试、集成测试、系统测试、覆盖分析、结构覆盖、鲁棒性验证、回归测试选择与优先级排序。
• 证据层：测试用例与结果、覆盖报告、问题报告、构型索引、符合性矩阵、适航审查记录。

这四个层面不是线性顺序，而是相互反馈。例如，覆盖分析发现某判定未覆盖，可能需要补充测试用例；补充用例又可能暴露需求描述不完整，从而触发需求变更。因此，回归验证是一个迭代收敛的过程。

四、学习路径与实操示例

建议的学习路径是：先理解适航要求和软件级别，再掌握变更影响分析方法，然后学习回归测试设计与覆盖分析，最后通过完整案例走通“变更申请—影响分析—回归执行—证据归档”的闭环。

下面给出一个教学示例，用于说明影响分析如何决定回归范围。假设某飞行管理软件（软件级别C）需要修改燃油预测算法中的积分步长，变更编号CR-2024-017。影响分析记录可参考如下字段：

基于上述分析，回归测试集可确定为：原有用例中覆盖FMS-FUEL-021和FMS-FUEL-022的全部用例，加上新增的3个边界用例，以及显示分区和飞行计划分区的接口一致性用例。执行后需检查：所有用例通过、修改函数判定覆盖和MCDC覆盖达到100%、无新增问题报告、构型索引与基线一致。只有全部满足，才能判定回归验证通过。