2. 测试标准与规范：ECSS标准、DO-178C标准、GJB 438B标准的核心要求

做航天嵌入式软件测试，绕不开三个字：标准。

我个人习惯把标准比作「游戏规则」。你代码写得再漂亮，测试用例设计得再巧妙，如果不符合标准要求，那在评审会上就是白搭。今天咱们就聊聊三个最核心的标准：ECSS、DO-178C 和 GJB 438B。嗯，这里要注意，它们虽然都是标准，但侧重点完全不同。

2.1 ECSS 标准：欧洲的航天「宪法」

ECSS（European Cooperation for Space Standardization）是欧洲航天局搞的一套标准体系。说白了，它是一整套从项目管理到产品保证的「百科全书」。

核心要求有哪些？

• 分级管理：ECSS 把软件关键性分了 A、B、C、D、E 五个等级。A 级最高，载人航天那种；E 级最低，地面支持工具。不同等级，测试深度天差地别。
• 全生命周期覆盖：从需求分析到退役，每个阶段都有对应的测试活动。我见过不少团队只盯着编码后的单元测试，结果需求阶段的问题拖到系统测试才暴露，返工成本高得吓人。
• 独立验证：ECSS 明确要求测试团队不能是开发团队的人。这一点，我在项目中深有体会——自己测自己的代码，就像自己给自己判卷，很难发现隐藏的坑。

2.2 DO-178C 标准：航空领域的「铁律」

DO-178C 是航空机载软件的标准。你想想看，飞机上的软件出问题，那可是要出人命的。所以这个标准的核心思想就一个字：严。

核心要求有哪些？

• 软件等级划分（DAL）：A 级（灾难性）到 E 级（无影响）。A 级软件，比如飞控系统，要求测试覆盖率达到 100% 的语句、分支、MC/DC（修正条件/判定覆盖）。
• 目标导向：DO-178C 不规定你用什么方法，只规定你要达成什么目标。比如，它要求「测试用例应能检测出需求中的错误」，至于你是用等价类划分还是边界值分析，它不管。
• 工具鉴定：如果你用自动化测试工具，工具本身也要经过鉴定。我记得有一次，团队用了一个第三方工具做覆盖率分析，结果工具本身有个 bug，导致覆盖率数据虚高。从那以后，我对工具鉴定这件事就特别上心。

2.3 GJB 438B 标准：中国的军用「规矩」

GJB 438B 是咱们国家军用软件开发的标准。它和 ECSS、DO-178C 最大的区别在于：它更强调文档的规范性。

核心要求有哪些？

• 文档驱动：GJB 438B 规定了 20 多种文档的编写要求，从《软件研制任务书》到《软件版本说明》。说白了，你写什么文档、怎么写、写多详细，它都给你框死了。
• 阶段评审：每个开发阶段结束，必须进行正式评审。评审不通过，不能进入下一阶段。我刚开始觉得这太死板，后来发现，这种「卡点」机制确实能拦住不少低级错误。
• 配置管理：对代码、文档、测试用例的变更控制非常严格。每一次修改，都要走正式的变更申请流程。

2.4 三个标准的对比与选择

你可能会问：这三个标准，我到底该用哪个？

其实不冲突。ECSS 适合欧洲背景的航天项目，DO-178C 适合航空或高安全性的航天项目，GJB 438B 是咱们国内军品项目的标配。如果你做的是商业航天，可能还要参考 NASA 的 NPR 7150.2。