3. 压力与稳定性测试需求捕获

压力与稳定性测试不是“把网络跑满看看会不会崩”，而是要把飞机级功能、系统级接口、适航条款和客户规范中隐含的可靠性期望，逐层转化为可执行、可观测、可判定的测试需求。需求捕获的质量直接决定后续测试用例是否有效：如果只写“网络应稳定”，测试人员无法设计负载曲线，也无法给出通过与否的结论；如果写成“在链路利用率 85%、持续 30 分钟条件下，端到端时延 99 分位不超过 10 ms，且无丢包”，测试就有了明确的输入、观测点和判据。

需求捕获的四类来源与转化逻辑

机载通信网络的压力与稳定性需求通常来自四个方向，它们关注的层次不同，但最终都要落到“测试指标 + 通过准则”上。

• 飞机级功能：例如飞行控制、显示、告警、导航等功能的可用性和完整性要求。飞机级功能不会直接说“交换机队列深度”，但它会规定“关键功能在最大预期负载下仍能按指定周期完成数据交换”。转化时要把功能失效的容忍度映射为网络性能门限，如时延上限、抖动范围、丢包率上限和恢复时间。
• 系统级接口：包括 ARINC 664、AFDX、CAN、ARINC 429、以太网等接口的带宽、帧格式、虚拟链路（VL）配置、冗余管理策略。接口定义中往往包含 BAG（带宽分配间隔）、Lmax（最大帧长）、VL ID 等参数，这些是构造压力剖面的直接输入。
• 适航条款：如 CCAR/FAR 25.1309、25.1317 等对系统安全性、失效概率和电磁环境的要求。适航条款通常以“概率”和“失效影响”表述，需要转化为可测试的故障注入场景和稳定性判据，例如“单条链路中断后，冗余切换应在 100 ms 内完成，且不引起功能降级”。
• 客户规范：航空公司或飞机制造商可能提出高于适航最低要求的指标，如“客舱网络在 200 个终端并发接入时，视频流卡顿率低于 1%”。这类需求更贴近使用场景，需要拆解为并发数、业务类型、持续时间、允许降级程度等参数。

四类来源的转化不是简单抄录，而是“向下分解、向上追溯”。向下分解是把功能/条款拆成可测量的网络行为；向上追溯是确保每个测试指标都能回答“它支撑哪条飞机级功能或哪条适航条款”。缺少追溯关系时，测试容易遗漏关键场景，或者产生大量与安全性无关的冗余用例。

从需求到可验证指标的转化方法

一个可验证的测试需求至少包含五个要素：测试对象、负载条件、持续时间、观测指标、通过准则。以 ARINC 664 网络为例，假设某飞机级功能要求“飞行控制数据在最大负载下仍能按时到达”，可以按以下方式转化：

测试对象：飞行控制 VL（VL ID 0x101，BAG=2 ms，Lmax=256 B）
负载条件：在 80% 网络利用率基础上，叠加 20% 突发流量，持续 30 min
观测指标：端到端时延、时延抖动、丢包率、VL 队列溢出计数
通过准则：99 分位时延 ≤ 5 ms，抖动 ≤ 1 ms，丢包率 = 0，无队列溢出
追溯关系：飞机级功能 FC-03；适航条款 25.1309(b)；客户规范 NET-07

这里的关键是“负载条件”必须可复现。网络利用率、突发流量比例、帧长分布、VL 配置都要写清楚，否则不同人执行会得到不同结果。对于稳定性测试，持续时间也不能随意写“长时间”，而应结合飞行阶段和任务剖面确定，例如地面加油、滑行、爬升、巡航、下降各阶段分别持续多久，或者用加速寿命试验的思路折算等效时长。

需求捕获的实操流程

实际项目中，需求捕获通常按以下顺序推进，但每一步都可能反向修正前一步：

1. 收集源文件：飞机级功能清单、系统接口控制文件（ICD）、适航符合性方法（MOC）、客户技术规范。重点标记其中涉及通信、时序、冗余、恢复的条目。
2. 建立追溯矩阵：用表格把“源需求编号—网络行为—测试指标—通过准则—测试用例编号”对应起来。矩阵不追求一次完整，但必须保证每条安全相关需求都有落点。
3. 定义压力剖面：根据接口参数和任务阶段，确定正常负载、峰值负载、过载和故障注入四类剖面。正常负载用于基线，峰值负载用于验证余量，过载用于找拐点，故障注入用于验证冗余和恢复。
4. 确定观测点与采集方法：机载网络通常不能随意抓包，需要利用交换机镜像端口、端系统统计寄存器、总线分析仪或嵌入式探针。观测点要能覆盖时延、丢包、队列深度、CPU 占用、温度等关键量。
5. 评审与冻结：由系统、适航、测试三方评审，确认指标可测、判据明确、追溯完整。冻结后的需求变更要走变更控制，避免测试执行中口径漂移。

通过准则的写法与常见误区

通过准则必须可判定，通常采用“阈值 + 统计口径 + 持续时间”的形式。例如：

常见误区包括：用平均值掩盖尾部时延；把“无丢包”写成“丢包率低”；忽略故障注入后的恢复时间；以及把通过准则写成“满足设计要求”这类循环表述。另一个容易被忽视的点是“测试环境与装机环境的差异”。实验室台架可能用线缆短、负载模拟器代替真实端系统，需求捕获时要明确哪些差异会影响指标，并在判据中留出合理余量或注明“台架结果需经装机验证”。

需求捕获完成后，建议做一次“可测性走查”：随机抽取若干条测试需求，让未参与编写的测试人员尝试设计用例。如果对方无法确定负载怎么加、数据从哪里采、结果怎么判，说明需求还不够具体。走查通过后，这些需求就可以作为测试用例设计、台架搭建和装机验证的共同基线。