4. 回归验证在适航审定中的定位

在航空软件适航审定中，回归验证（Regression Verification）并不是一个孤立的测试活动，而是变更管理闭环中的关键证据环节。它的核心使命是回答审查方最关心的问题：当软件发生变更后，原有已确认的安全裕度是否仍然成立？要理解回归验证的定位，必须把它与增量验证、验证独立性、目标与证据要求放在同一张“审定地图”上审视。

回归验证与增量验证：两条并行的证据链

软件变更通常同时触发两类验证工作。增量验证针对“新引入或修改的部分”，回答“新功能/新逻辑是否正确实现”；回归验证针对“未修改但可能受影响的既有部分”，回答“原有功能是否被破坏”。二者不是替代关系，而是互补关系。

以DO-178C的视角看，变更影响分析（Change Impact Analysis）是分叉点：分析结果决定哪些生命周期数据需要更新、哪些测试需要重跑。若某需求被修改，其对应的测试用例属于增量验证；若某需求未变，但其实现代码、接口、共享资源或时序环境发生变化，则相关测试必须纳入回归范围。实践中常见的误区是“只测改动的函数”，而忽略了全局变量、中断优先级、内存布局、通信协议时序等隐性耦合。

例如，某飞控软件将高度滤波器的定点位宽从Q15调整为Q23，表面只改了一个数据类型，但该变量同时被自动驾驶仪和显示模块引用。此时增量验证覆盖滤波器新精度，回归验证则必须覆盖自动驾驶仪高度保持逻辑和显示刷新逻辑，因为数值范围和舍入行为已改变。

验证独立性的要求

适航审定强调验证独立性，即验证活动应由不直接参与该软件项开发的人员执行，或至少由独立于实现过程的工具与环境完成。回归验证同样受此约束：不能由修改代码的工程师“自测通过”就作为符合性证据。独立性体现在三个层面：

• 人员独立：回归测试用例的设计与执行由独立验证人员完成；
• 环境独立：回归测试应在受控的、与开发环境隔离的验证环境中运行，避免开发调试残留影响结果；
• 数据独立：测试预期结果应来自需求或独立模型，而非从修改后的代码反推。

对于A级软件，独立性要求最为严格；B级允许一定程度的开发人员参与，但回归结论仍需独立评审。审查方会重点检查回归测试记录中“执行人”与“代码修改人”是否为同一人，以及测试环境配置是否与基线一致。

目标与证据要求

回归验证的目标不是“跑完所有测试”，而是证明变更未引入非预期影响。因此证据链必须完整：变更影响分析报告 → 回归测试范围确定 → 回归测试用例及预期结果 → 执行记录 → 覆盖分析 → 偏离与问题报告 → 回归结论。每一环都要可追溯到需求、代码或上一版基线。

审查方通常要求回归证据满足以下属性：可追溯性（每个回归用例对应哪条需求或哪个变更影响项）、可重复性（相同基线、相同环境、相同输入得到相同结果）、完整性（影响分析中识别出的所有受影响项均有对应回归覆盖）、以及结论明确性（通过/失败/偏离均有处理记录）。

适航审查关注点及常见问题

在适航审查中，审查方对回归验证的关注点集中在“范围合理性”和“证据充分性”上。常见问题包括：影响分析过于粗略，仅按文件或函数粒度划分，未考虑数据耦合与控制耦合；回归测试用例直接复用旧版本用例而未更新预期结果，导致“通过”但实际行为已变；回归环境与目标机环境不一致，例如未覆盖编译器优化选项差异；以及回归记录中缺少对未执行用例的偏离说明。

下面这张图把回归验证在审定中的定位、与增量验证的分工、独立性约束以及证据链关系集中呈现出来，便于对照审查关注点快速定位薄弱环节。

从图中可以看出，回归验证位于“变更影响分析”之后、“证据链闭合”之前，与增量验证并行但目标不同。审查方不会只看最终测试报告，而是沿着证据链逐环核对：影响分析是否识别了所有受影响项、回归范围是否与影响分析一致、预期结果是否独立于修改后的代码、执行环境是否受控、未通过项是否闭环。

一个实用的做法是建立“变更—影响项—回归用例—执行结果”四列追踪矩阵。例如某次变更修改了大气数据计算机的ARINC 429标签解析逻辑，影响分析识别出三个受影响项：标签校验和、数据刷新周期、故障上报逻辑。追踪矩阵中每一行对应一个影响项，并列出覆盖它的回归用例编号、预期结果来源（需求文档或独立模型）、执行日期与结论。这样审查时可以直接展示“每个影响项都有对应用例且已执行”，而不是用“测试全部通过”一句结论代替。

最后需要强调，回归验证的结论必须明确回答“变更未引入非预期影响”这一命题，并说明支撑该结论的证据边界。若存在未覆盖的受影响项，应在结论中如实说明并给出风险评估或补充验证计划，而不是回避。适航审定的本质是信任但验证，回归验证正是这种信任得以建立的技术基础。