第三章 需求分析与测试策划：从顶层飞机需求分解到飞控系统需求
说实话，很多团队在飞控测试上栽跟头，不是因为测试技术不行，而是从一开始需求就没理清楚。我见过太多项目，飞控代码都写完了，测试用例还在拍脑袋想——这哪行？
这一章，我们就聊聊怎么从顶层飞机需求，一步步分解到飞控系统需求，再落地成测试计划和测试用例。嗯，这是整个测试流程的根基，根基不稳，后面全是白忙活。
3.1 顶层飞机需求长什么样？
先搞清楚源头。顶层飞机需求，通常来自型号总师或者客户。它不会告诉你飞控该怎么做，只会告诉你飞机要达成什么目标。
举个例子，我参与过的一个eVTOL项目，顶层需求里有一条：
“飞机在单发失效后，必须能安全着陆。”
你看，这句话里没有“飞控”两个字，但它直接决定了飞控系统要做什么。说白了，顶层需求是“what”，不是“how”。
常见的顶层需求包括：
- 安全性需求：如失效概率、故障容限等级
- 性能需求：如巡航速度、爬升率、航程
- 环境适应性需求：如抗风等级、温度范围
- 适航符合性需求：如满足CCAR-23或SC-VTOL条款
我个人习惯，拿到顶层需求后，先做一件事：画一张需求分解树。把每一条顶层需求，拆成若干条子系统需求。飞控系统只是其中一条分支。
3.2 从飞机需求到飞控系统需求
这一步是关键。怎么拆？我总结了一个三步法：
- 识别飞控相关项：从顶层需求里，找出哪些跟飞控直接相关。比如“单发失效后安全着陆”，飞控必须能检测失效、切换控制律、引导着陆。
- 量化指标：把模糊的描述变成可测量的数字。比如“安全着陆”太虚，要变成“着陆时垂直速度不超过2m/s，滚转角不超过5°”。
- 分配功能：把量化后的指标，分配给飞控的具体功能模块。比如“检测失效”归给故障检测模块，“切换控制律”归给控制律管理模块。
我记得有一次，顶层需求里写“飞机应具备自动返航能力”。乍一看很简单，但一量化就发现问题了：返航高度是多少？返航路径怎么规划？遇到障碍物怎么办？这些不拆清楚，测试根本没法写。
下面这张图，是我常用的需求分解逻辑：
你看，从顶层需求到飞控需求，再到测试用例，是一条清晰的链路。每个测试用例，都能追溯到一条顶层需求。这就是所谓的需求可追溯性。
3.3 编写测试计划
需求分解完了，下一步就是写测试计划。测试计划不是写出来应付评审的，它是整个测试工作的作战地图。
我写测试计划，一般包含这几个部分：
| 章节 | 内容 | 我的经验 |
|---|---|---|
| 测试范围 | 明确测什么、不测什么 | 一定要写清楚边界，否则后面扯皮 |
| 测试策略 | 用什么方法、什么工具、什么环境 | 我习惯分阶段：单元→集成→系统→验收 |
| 资源计划 | 人员、设备、时间 | 别忘了HIL台架的排期，经常是瓶颈 |
| 风险与缓解 | 识别风险，提前准备预案 | 比如“飞控软件延迟交付”这种，要提前想好 |
| 交付物 | 测试报告、问题清单、覆盖率报告 | 每个交付物都要有模板，别临时拼凑 |
小技巧：测试计划里，我建议加一个“测试停止准则”。比如“发现A类缺陷超过5个，暂停测试，等开发修复后再继续”。这能避免测试团队陷入无底洞。
3.4 测试策略怎么定？
测试策略，说白了就是回答一个问题：怎么测才能既快又准？
飞控系统测试，我一般分四个层次：
- 单元测试：测单个函数、单个模块。比如控制律算法、传感器滤波算法。用MIL/SIL环境跑。
- 集成测试：测模块之间的接口。比如飞控和舵机之间的通信协议。用PIL环境。
- 系统测试：测整个飞控系统在真实硬件上的表现。用HIL台架，接入真实传感器和执行器。
- 验收测试：在整机上进行，验证是否满足顶层需求。比如单发失效后的着陆测试。
每个层次，测试策略都不一样。单元测试追求覆盖率，系统测试追求场景真实性。你想想看，如果在单元测试阶段就追求全场景覆盖，那成本太高了，不划算。
避坑指南：我曾经在一个项目里，把大量时间花在了单元测试上，结果系统测试时发现接口不匹配，整个重来。后来我学乖了：先做接口测试，再做功能测试。接口通了，后面才稳。
3.5 测试用例设计方法
测试用例怎么设计？我常用的方法有这几种：
3.5.1 等价类划分
把输入数据分成若干类，每类选一个代表。比如飞控的输入电压范围是24V~32V，那就测24V、28V、32V三个点。中间的值，理论上不用全测。
3.5.2 边界值分析
很多bug都出在边界上。比如飞控的滚转角限制是±45°，那就要测45°、-45°、44.9°、-44.9°、45.1°、-45.1°。嗯，边界值往往比中间值更容易出问题。
3.5.3 场景法
模拟真实飞行场景。比如“起飞→爬升→巡航→下降→着陆”这个完整流程。场景法最能发现系统级问题。我记得有一次，单独测每个阶段都没问题，但一跑完整场景，飞控在过渡阶段就抖起来了——这就是场景法的价值。
3.5.4 错误推测法
靠经验猜哪里容易出bug。比如传感器数据跳变、通信超时、电源波动。这些在需求里可能没写，但实际飞行中经常遇到。
下面是一个测试用例的模板，我一直在用：
测试用例编号：TC-FCS-001
测试名称：单发失效后自动着陆
测试依据：需求REQ-SAF-003
前置条件：飞机处于巡航状态，高度500m，速度80km/h
测试步骤：
1. 模拟左前电机失效
2. 观察飞控是否在2秒内检测到失效
3. 观察飞控是否自动切换至应急控制律
4. 观察飞控是否引导飞机着陆
预期结果：
- 失效检测时间 ≤ 2s
- 着陆时垂直速度 ≤ 2m/s
- 着陆时滚转角 ≤ 5°
实际结果：（测试后填写）
结论：（通过/失败）
关键点：每个测试用例，必须能追溯到一条具体的需求。如果找不到对应的需求，那这个用例就是多余的。我见过有些团队写了上千条用例，结果一大半跟需求无关——纯粹是浪费资源。
3.6 需求变更怎么办？
做飞控测试，最怕的就是需求变更。顶层需求一变，下面的分解、测试计划、用例全得跟着改。
我的做法是：建立需求变更影响分析流程。每次变更，先分析影响范围，再决定是修改现有用例，还是新增用例。千万别一上来就改代码，改完才发现测试跟不上。
我曾经吃过这个亏。有一次客户临时改了返航高度，我直接让开发改了代码，结果测试用例没更新，最后验收时才发现测试结果对不上。从那以后，我坚持“需求变更→影响分析→测试更新→代码修改”这个顺序，一步都不能跳。
3.7 小结
这一章的内容，说白了就是一句话：测试不是从代码开始的，是从需求开始的。需求分解得越清楚，测试计划写得越扎实，后面的测试工作就越顺畅。
你想想看，如果连需求都没理清，测试用例写得再漂亮，也是空中楼阁。所以，别急着写代码，先花时间把需求分解和测试策划做好。这个时间，花得值。