测试策略制定：基于风险的测试策略、测试等级划分、测试环境搭建原则

说到测试策略，我见过不少团队一上来就铺开全量测试，结果资源全砸在低风险模块上，真正要命的地方反而漏了。说白了，航天嵌入式软件测试，钱要花在刀刃上。今天我就把这三块核心内容掰开揉碎了讲清楚。

基于风险的测试策略

为什么一定要基于风险？你想想看，航天软件动辄几十万行代码，全部测一遍，时间和经费都不允许。我个人的习惯是，先做风险分析，再定测试优先级。

风险 = 故障发生的概率 × 故障造成的后果。这个公式很简单，但落地时要注意几点：

• 故障概率评估：看模块的复杂度、变更频率、开发人员经验。我在项目中遇到过，一个看似简单的状态机模块，因为换了新人开发，bug率比老手高出三倍。
• 后果严重度：看是否涉及安全关键功能。比如星务管理中的姿控指令、火工品点火，这些一旦出错就是灾难。
• 风险矩阵：把模块按概率和后果分成高、中、低三档。高风险模块要投入70%的测试资源，中风险20%，低风险10%。

嗯，这里要注意，风险分析不是一次性的。随着项目推进，风险等级会变化。我建议每轮迭代结束后重新评估一次。

测试等级划分

航天软件的测试等级，我习惯分成四级。这四级不是拍脑袋定的，而是根据DO-178C和GJB/Z 141的要求来的。

测试等级	测试对象	测试目标	典型方法
单元测试	单个函数/模块	验证逻辑正确性、覆盖率达标	白盒测试、MC/DC覆盖
集成测试	模块间接口	验证数据传递、时序配合	接口测试、背靠背测试
系统测试	完整软件系统	验证功能、性能、可靠性	黑盒测试、边界测试
验收测试	交付版本	确认满足需求规格	用户场景测试、回归测试

我个人经验是，单元测试最容易被人忽视。很多人觉得「代码能跑就行」，结果集成时接口对不上，查问题查到崩溃。我曾经在一个项目中，因为单元测试没做充分，集成阶段花了三周才把接口调通，教训深刻。

集成测试这块，我特别强调接口测试。航天软件里模块间通信经常用1553B总线或CAN总线，数据格式、时序要求都很严格。我建议用背靠背测试，就是两个版本同时跑，一个是被测版本，一个是参考版本，对比输出是否一致。

测试环境搭建原则

测试环境搭建，说白了就是模拟真实飞行环境。但真实环境太贵了，动不动就是几百万的仿真设备。所以我们要在成本和逼真度之间找平衡。

我总结了四个原则：

1. 分层模拟原则：能软件模拟的就不上硬件。比如传感器数据，用数据注入工具模拟就行，没必要接真实传感器。
2. 关键接口全实物原则：涉及安全关键功能的接口，必须用实物。比如火工品点火指令，必须接真实驱动板测试。
3. 可重复性原则：测试环境要能一键恢复初始状态。我见过有人手动配置环境，结果每次测试条件都不一样，数据没法对比。
4. 可观测性原则：测试过程中要能实时监控内部状态。比如CPU使用率、内存占用、任务调度情况，这些数据对定位问题至关重要。

具体到环境搭建，我建议分三步走：

• 第一步：搭建纯软件仿真环境。用QEMU或SkyEye模拟CPU，跑目标代码。适合单元测试和早期集成测试。
• 第二步：搭建半实物仿真环境。把关键接口换成实物板卡，其他用软件模拟。适合中后期集成测试。
• 第三步：搭建全实物仿真环境。所有接口都用真实硬件，跑完整的飞行场景。适合系统测试和验收测试。

嗯，这里有个小技巧。测试环境里一定要加故障注入功能。我习惯在总线上加一个故障注入节点，可以模拟通信中断、数据错误、时序抖动等异常情况。你想想看，如果只在理想环境下测试，那跟没测有什么区别？

最后说一句，测试环境搭建文档一定要写清楚。包括硬件连接图、软件配置参数、环境恢复步骤。我曾经接手过一个项目，前任工程师离职了，环境怎么搭的没人知道，只能从头摸索，浪费了两周时间。

好了，测试策略这块就讲到这里。下一章我们聊测试用例设计，到时候我会分享一些我自己总结的边界值选取技巧。