1. 航空软件需求追踪与测试设计导论

航空软件与普通商业软件最根本的差别，不在于代码规模，而在于它一旦失效可能直接危及飞行安全。因此，航空软件工程的核心问题不是"功能是否实现"，而是"能否证明它按预期实现，并且这种证明可被审查、可被追溯、可被复现"。本课程围绕这一核心，讲解如何把需求、设计、代码、测试与适航证据串成一条完整、可审计的链条。

课程目标与学习路径

学完本课程，你应当能够独立完成三件事：第一，把一份航空软件需求分解为可追踪、可验证的条目，并建立需求与设计、代码、测试之间的双向链接；第二，依据 DO-178C 的目标体系，为不同软件等级（DAL）确定所需的验证活动与证据；第三，设计出覆盖正常、边界与异常场景的测试用例，并说明每条用例对应哪条需求、依据什么判据判定通过。这三件事共同构成"需求追踪—测试设计—适航证据"的闭环。

课程不追求罗列标准条文，而是把标准要求落到具体工件上。例如，当你看到"需求必须可验证"时，需要能判断一条写成"系统应具备良好的响应性能"的需求为什么不合格，以及如何改写为"在 25℃、电源 28V 条件下，从输入指令到输出响应的时间不超过 50ms"这样可测量、可判定的表述。

航空软件的特殊性

航空软件的特殊性可以从四个维度理解。其一是安全关键性：软件失效的后果按严重程度分为灾难性、危险性、较大、较小、无安全影响五级，对应 DAL A 至 DAL E。DAL A 软件的一个未检出缺陷可能导致机毁人亡，因此其验证强度远高于普通软件。其二是确定性要求：在给定输入与状态下，输出必须可预测，禁止依赖未定义行为、动态内存分配失败或不可控的调度时序。其三是资源受限与实时性：机载处理器算力、内存、功耗都受限，软件必须在确定的周期内完成计算，例如飞控律每个周期 10ms 内必须完成一次解算。其四是长生命周期与可追溯性：一架飞机的软件可能服役数十年，期间经历多次修改，任何一次改动都必须能回溯到需求、评估影响范围并重新验证。

需求追踪与测试设计的关系

需求追踪与测试设计不是两个先后独立的阶段，而是同一证据链的两端。需求追踪回答"每条需求被哪些设计元素实现、被哪些测试用例验证"；测试设计回答"用什么输入、什么判据来证明需求被满足"。二者通过双向追溯矩阵连接：正向从需求查到测试用例，反向从任一测试用例查到它验证的需求。若某条需求没有任何测试用例覆盖，就是验证缺口；若某个测试用例找不到对应需求，就是范围蔓延或冗余测试。

在实际项目中，追踪关系通常以唯一标识符维护。例如需求标识 SRS-FCS-012，对应设计标识 DD-FCS-012，对应测试用例 TC-FCS-012-01 至 TC-FCS-012-04。当需求变更时，通过标识符即可定位受影响的设计与测试，评估回归范围。这正是适航审查中"影响分析"的基础。

DO-178C 等适航标准概览

DO-178C《机载系统和设备合格审定中的软件考虑》是航空软件适航符合性的核心标准。它不规定具体开发方法，而是规定"目标"（Objective）与"活动"（Activity），由申请人证明每个目标已达成。标准按软件等级列出目标表：DAL A 需满足 71 个目标，DAL B 为 69 个，DAL C 为 62 个，DAL D 为 26 个。等级越高，对需求追踪、覆盖率分析、独立验证的要求越严。

与 DO-178C 配套的还有 DO-330（工具鉴定）、DO-331（基于模型的开发）、DO-332（面向对象技术）、DO-333（形式化方法）等补充文件。此外，ARP4754A 覆盖飞机与系统级开发，ARP4761 覆盖安全评估过程，它们与 DO-178C 共同构成从系统到软件的完整适航证据体系。理解这些标准的分工，有助于在项目中判断某项活动应由系统层还是软件层承担。

全生命周期视角

航空软件的生命周期通常划分为：系统需求分配、软件需求、软件设计、软件实现、集成、验证、合格审定与运行维护。需求追踪贯穿始终：系统需求分配到软件需求时建立第一层链接，软件需求到设计、设计到代码、代码到测试逐层建立链接，最终形成从顶层系统需求到具体测试结果的完整链路。测试设计则在验证阶段集中体现，但其输入来自需求阶段的可验证性，其输出又反馈到需求阶段修正不完整条目。

下面这张图给出本节的核心关系：左侧是需求追踪链，右侧是测试设计链，中间通过双向追溯矩阵耦合，底部由 DO-178C 目标体系提供证据要求，顶部由 DAL 等级决定验证强度。

从图中可以看到，需求追踪链与测试设计链并非各自独立，而是通过双向追溯矩阵相互约束：需求侧每一条条目都应在测试侧找到验证手段，测试侧每一条用例都应能回溯到需求依据。底部的 DO-178C 目标体系则规定了这两条链必须产出哪些证据、达到何种严格程度，而顶部的 DAL 等级决定了这套证据的完整度要求。