1. 课程导入
无人机已经从航拍玩具演变为物流运输、电力巡检、应急救援、农业植保和军事侦察中的关键装备。当无人机承担载人运输、医疗物资投送、城市空域飞行等任务时，其软件一旦失效，后果可能从财产损失升级为人员伤亡。因此，安全关键软件（Safety-Critical Software）成为无人机系统中最需要被严格验证的部分。本课程围绕“如何系统化地测试无人机安全关键软件”展开，帮助学习者建立从标准、方法、工具到工程实践的完整能力体系。
本节核心问题：无人机安全关键软件到底“关键”在哪里？测试工程师需要掌握哪些知识？这些知识在真实产业中如何落地？
一、学习目标：从“会测功能”到“能证明安全”
本课程的学习目标不是简单掌握某个测试工具，而是建立一套面向安全关键系统的测试工程思维。具体包括四个层次：
- 标准与合规层：理解 DO-178C、DO-254、ARP4754A、ISO 26262（借鉴）、ASTM F3442/F3472 等标准对无人机软件生命周期、需求追溯、验证与确认的要求。
- 方法与技术层：掌握需求基测试、结构覆盖分析、形式化验证、故障注入、边界与鲁棒性测试、实时性与资源约束测试等方法。
- 工具与平台层：能够使用静态分析、单元测试框架、硬件在环（HIL）、软件在环（SIL）、模型在环（MIL）以及覆盖率分析工具。
- 工程与复盘层：能够编写测试计划、测试用例、追溯矩阵、问题报告，并针对失效案例进行根因分析与测试改进。
换句话说，普通软件测试关注“功能是否实现”，而安全关键软件测试必须回答“在异常、故障和极端条件下，系统是否仍然可控、可预期、可恢复”。
二、核心概念：安全、关键、适航与验证
在进入具体技术之前，需要先厘清几个高频概念。它们贯穿整门课程，也是后续章节反复引用的基础。
| 概念 | 含义 | 在无人机中的典型体现 |
|---|---|---|
| 安全关键软件 | 失效可能导致人员伤害、设备损毁或环境危害的软件 | 飞控律、避障决策、返航逻辑、电池管理 |
| 适航符合性 | 证明产品满足适航规章与标准要求的过程 | DO-178C 目标、生命周期数据、追溯性 |
| 验证与确认 | 验证“正确地构建产品”，确认“构建正确的产品” | 需求评审、测试覆盖、飞行试验 |
| 失效安全 | 系统失效后进入可控或低风险状态 | 失控返航、降落伞触发、地理围栏悬停 |
| 追溯性 | 需求、设计、代码、测试之间双向可追踪 | 需求覆盖矩阵、变更影响分析 |
其中，追溯性是安全关键软件测试的“生命线”。没有追溯，就无法证明测试是否充分，也无法在需求变更时评估影响范围。很多无人机事故的复盘都指向同一个问题：某个异常分支从未被需求覆盖，也从未被测试执行。
三、整体知识框架：一条主线、四个维度
本课程的知识框架可以概括为“一条主线、四个维度”。主线是安全关键软件的生命周期，从需求、设计、编码、集成、验证到运行维护。四个维度分别是标准合规、测试方法、工具平台和工程管理。下面的 SVG 展示了这一框架的整体关系。
从图中可以看出，标准合规提供“依据”，测试方法提供“手段”，工具平台提供“支撑”，工程管理保证“可重复、可追溯、可审计”。四者缺一不可。只懂工具不懂标准，测试结果无法被适航审查接受；只懂标准不懂方法，无法设计出高覆盖率的测试用例。
四、方法流程：安全关键软件测试的基本闭环
安全关键软件测试不是“写完代码再测”，而是与开发同步进行的持续活动。一个典型的测试闭环包括以下步骤：
- 需求分析与安全等级划分：识别哪些需求与安全相关，确定软件等级（如 DO-178C 的 A 至 E 级）。
- 测试计划与策略制定：明确测试范围、方法、环境、进入与退出准则。
- 测试用例设计：基于需求、边界、状态机和故障模式设计用例，并建立需求追溯。
- 测试执行与环境搭建：在 MIL、SIL、HIL 或飞行试验中执行，记录原始数据。
- 覆盖分析与缺陷管理：检查语句、分支、MC/DC 覆盖，跟踪缺陷直至关闭。
- 验证总结与符合性证据：形成测试报告、追溯矩阵和适航符合性材料。
下面是一段典型的测试用例追溯记录示例，用于说明“需求—用例—结果”的绑定关系：
REQ-ID: NAV-021
需求描述: 当 GPS 信号丢失超过 3 秒时，飞控应切换至视觉定位并保持当前航向。
TEST-ID: TC-NAV-021-03
测试方法: HIL 故障注入
输入条件: GPS 信号中断 3.5s，视觉定位可用
预期结果: 模式切换标志 = VISUAL_HOLD，航向偏差 ≤ 5°
实际结果: 模式切换标志 = VISUAL_HOLD，航向偏差 3.2°
覆盖类型: 需求覆盖 / 分支覆盖 / MC/DC
结论: 通过
这段记录体现了安全关键测试的核心要求：每个测试用例都能追溯到具体需求，每个结果都有可量化判据，每个覆盖类型都有明确说明。缺少任何一项，审查时都可能被判定为证据不足。
五、案例与场景：从一次返航失效说起
某型物流无人机在城郊执行配送任务时，遇到强侧风。飞控软件检测到航向偏差超限，触发返航逻辑。然而返航过程中，电池管理系统报告电压骤降，飞控请求紧急降落。由于返航与紧急降落两个状态机的优先级未在需求中明确定义，软件进入了一个未预期的状态组合，最终导致无人机迫降在非安全区域。
事后复盘发现三个测试缺口：
- 需求层面：未定义“返航中电池告警”的优先级与状态迁移条件。
- 测试层面：状态机测试只覆盖了单一故障，未覆盖“多故障并发”场景。
- 工具层面：HIL 环境未注入电池电压骤降与侧风耦合的故障组合。
警示：安全关键软件的失效往往不是单点故障，而是多个正常逻辑在异常组合下产生的“涌现行为”。测试设计必须主动构造故障组合，而不是等待它们在实际飞行中暴露。
六、常见误区与学习建议
初学者在进入本课程时，容易陷入以下误区：
- 误区一：把覆盖率当成安全证明。100% 语句覆盖不等于 100% 安全，覆盖只是必要条件，不是充分条件。
- 误区二：只测正常流程。安全关键软件的价值恰恰体现在异常、降级和恢复路径上。
- 误区三：忽视需求质量。需求模糊、矛盾或缺失，会让后续所有测试失去基准。
- 误区四：工具万能论。工具能提高效率，但测试策略、判据和追溯关系仍需工程师设计。
学习建议：每学完一个方法，尝试把它映射到一个真实的无人机功能上，例如“避障决策”“失控返航”“电池管理”。同时养成记录追溯关系的习惯，把需求、用例、结果和缺陷串成一条线。这样在后续章节中，你会更容易理解标准条款背后的工程意图。
本课程后续将沿着“标准—方法—工具—案例—复盘”的路径逐步展开。你现在需要建立的，是一张属于自己的知识地图：知道每个概念在整体框架中的位置，知道每个方法解决什么问题，知道每个工具在什么阶段使用。只有这样，面对复杂的无人机安全关键软件时，才能做到测试有据、验证有方、结论可信。