深入解析RTCA/DO-178C标准：机载软件数据耦合与控制耦合测试覆盖要求

编者注：本文的作者是翱坤科技，它是一家航空工程综合服务机构。“适航思维”在此对其无私的知识和经验分享表示感谢。

概述

RTCA/DO-178C 即《机载系统和设备认证中的软件考虑》，它提出了对机载软件结构的测试覆盖目标要求。这些要求中包含了对数据耦合（DC）和控制耦合（CC）的测试覆盖。本文依据工程经验，简要谈谈对耦合分析的理解与认识。

目标 8 在 DO-178C 表 A-7 中，对于 A、B 和 C 级软件要求达到软件结构（包括数据耦合和控制耦合）的测试覆盖（如 6.4.4.d 所述），具体情况如下表所示：

DO-178C 6.4.4.2 c 中的活动包含这样一项内容：通过分析来确定基于需求的测试已经对代码部件之间的数据耦合和控制耦合进行了检查。

术语

DO-178C附录B给出了耦合分析相关术语的定义：

数据耦合：一个软件部件对不完全由其控制的数据的依赖。

控制耦合：一个软件部件影响另一个软件部件执行的方式或程度。

部件是执行系统的一个清晰功能的零部件，它是自包含的；或者是零部件、分组件、单元的组合。

耦合的测试覆盖目标解析

结构覆盖分析能够为基于需求的软件测试（RBT）活动提供完整性的度量方式。如果能够满足结构覆盖准则，那么软件测试的完整性就是可被接受的。

不同研制等级的软件，“完整性”的要求有所不同。研制等级越高，对完整性的要求就越高。比如，C 级软件的结构覆盖分析只需满足语句覆盖；B 级软件需要满足语句覆盖和判定覆盖；A级软件在 B 级要求的基础上，还增加了修正/判定覆盖（MC/DC）。

这些覆盖测量和分析活动能够保证执行的 RBT 满足软件部件自身的结构覆盖要求。然而，部件之间的交互和依赖关系的正确性并未得到验证。因此，增加了数据耦合和控制耦合分析，目的是验证架构和集成的正确性。也就是说，通过耦合分析可以表明软件部件是以预期的方式相互影响的，不会以非预期的方式导致计划外、异常或错误的行为。

耦合分析的本质在于对软件集成测试的完整性展开评估。分析需要以在集成环境中执行的 RBT 测试为基础，以此来确保软件部件的交互以及依赖关系是正确的，同时要满足软件需求和软件架构。

软件部件并非一个指代清晰的名词，它可以被定义为函数、过程、能够单独进行编译的文件或者整个软件系统。所以在软件架构设计中，需要对软件的组成以及软件部件的指代进行明确的描述。耦合分析主要针对的是软件部件之间的依赖关系，对于单个部件的内部而言，并不需要进行耦合分析。因此，对部件的颗粒度进行定义，是进行耦合分析的基础。

耦合分析工作开展步骤

为了满足 DC/CC 的测试覆盖目标，软件研制单位在整个软件生命周期活动中需要对耦合相关的因素加以考虑，如下面的图所示。并且在开发过程中，应当尽早对耦合进行相关的考虑。

在软件策划阶段，借助软件开发标准（SDS）以及软件编码标准（SCS）来明确相关设计和实现过程中对耦合的限制，这样能较好地推动耦合分析实践。比如，可以合理地进行模块划分，提升模块的内聚性，降低模块之间的耦合度，对模块的扇入扇出数加以限制，简化软件架构，减少条件分支的使用等。

在软件开发过程中，需要考虑数据流并将其描述出来，这属于软件开发工作的一部分。同时也要考虑控制流并进行描述。要明确定义软件部件之间的接口，在软件架构中说明与数据或控制流相关的内容，比如数据结构、软件架构、内部和外部输入/输出、设计的数据流和控制流、调度过程、处理器内/任务内通信机制以及分区方法等，还要对软件部件进行说明。

步骤 3 要对软件架构和代码的一致性进行评审工作，同时进行分析，并且要记录下耦合信息。

目标 9 为确保软件架构的一致性，其中包含要确保软件架构中各部件的关系正确，这种关系存在于数据流和控制流中。若较高等级软件部件与较低等级软件部件之间存在接口，需确认软件具备合适的保护机制，以避免来自较低软件等级的潜在错误输入。

DO-178C 表 A-5 的目标 2 是要确保源代码符合软件架构。对于耦合覆盖方面，需要进行评审，以确保软件源代码与软件架构中所定义的数据流和控制流相匹配。

验证人员提出 PR 进行更改。

步骤 4 要执行基于需求的集成测试。软件集成测试的目的是确保软件组件能够正确地进行交互，并且满足软件需求以及软件体系结构（DO-178C 6.4.3.b）。

集成测试的目的是识别以下类型的错误：

变量和常量的不正确的初始化

参数传递错误

数据破坏（特别是全局数据）

事件和操作的不正确顺序

不恰当的端到端数值解析。

在设计评审过程中，已经验证了软件架构与需求之间的一致性。所以，基于需求的测试不仅包含了对需求的检查，也对软件架构实施了检查。

步骤 5 需对基于需求的测试进行分析。要识别出耦合覆盖测试用例和程序，并且建立与开发数据之间的追踪关系。同时，要确认基于需求的测试检查了部件之间的 DC/CC。

在架构评审中已识别出相关耦合信息，在需求评审中也已识别出相关耦合信息，在代码评审中同样已识别出相关耦合信息。通过分析，找到了耦合覆盖对应的测试用例、程序以及测试结果，以确保耦合路径能通过相应测试程序的执行而被正确覆盖。

步骤 5 的分析通常会对上述步骤 2 到 4 的工作进行迭代。如果在设计阶段没有很好地定义接口以及软件部件之间的依赖关系，那么就难以通过基于需求的测试来证明耦合覆盖的目标得以满足。

使用耦合分析工具

当软件达到一定的规模和复杂度时，分析代码中数据耦合和控制耦合路径的工作量会变得很大，并且容易出现错误。通常会想到借助工具来进行分析。目前，在业界普遍使用的是进行语句、判定和 MC/DC 结构覆盖分析的工具，然而，进行耦合分析的工具的使用还不是很广泛。在选择用工具来进行耦合分析或者借助工具进行耦合分析时，一方面要考虑工具是否需要进行鉴定，另一方面要考虑工具是否能满足耦合分析的目标需求。

总结

DO-178C 把数据耦合/控制耦合的测试覆盖率划分到表 A-7 的目标 8 中。这属于验证层面的验证。其目的是要保证基于需求的测试（RBT）涵盖了代码部件之间的数据耦合和控制耦合，从而为集成测试的完整性提供度量标准。耦合分析工作涉及 DO - 178C 的表 A - 4 目标 9 以及表 A - 5 目标 2。需对软件架构和代码的一致性进行评审与分析，以确保软件架构的正确性，且代码能准确实现架构设计的控制流和数据流。若在架构设计和代码评审时未考虑数据耦合和控制耦合相关信息，那么在测试阶段实现耦合覆盖目标将极具挑战性，甚至可能导致返工。因此耦合分析工作的顺利开展离不开设计和验证人员的共同参与。

笔者注：本文参考了 DO-178C 和 CAST-19，通过总结公司多位实际参与 C919 研发的同仁的经验来编制。本文旨在分享一些工程经验与观点，在审定过程中，对于耦合分析的具体实施要求，申请人应当与局方审查员进行充分的沟通联络。

——The End——

@HuangShuoqiao

获取专业的适航培训和取证服务