中国航空工业集团公司第一飞机设计研究院 陈刚 罗旭升

民用飞机机载软件适航对RTCA DO-178C 的使用，与DO-178B 相比提高了软件验证工作中耦合覆盖的要求。本文以DO-178C 对耦合覆盖的要求为基础，分析并提出了一种能够满足目标要求的控制耦合和数据耦合分析方法，同时对商用工具的选择和工具的鉴定考虑给出了可行的建议，对我国民用飞机机载软件符合性举证过程具有重要的参考意义。

民用飞机机载软件适航标准RTCA DO-178C 中对A、B、C 等级的软件均提出了耦合覆盖（包括数据耦合和控制耦合）的要求[1]，其初衷在于评估测试的充分性。DO-178C 中对于数据耦合和控制耦合的定义如下：

数据耦合：由于软件组件中某数据不完全受控于本组件而导致的对其他组件的依赖性。

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

传统的软件研制过程一直强调高内聚、低耦合，其耦合也是依赖性的概念，强调软件设计过程中对函数、类或组件封装过程中应降低数据依赖及控制依赖。这两个概念的相似性导致一部分供应商通过软件设计标准或编码标准的方式提高软件设计的内聚性来满足目标要求，还有一部分供应商会通过设计评审和代码评审的方式来满足目标要求。

实际上，尽管耦合的概念类似，但DO-178C 提出该目标的目的并非为了降低组件间的耦合性，而是为了确认代码耦合关系与设计耦合关系的一致性，从而发现：

（1）测试的不充分；

（2）代码实现的多余功能。

DO-248C FAQ #67[2]虽然就该问题进行了解释，但其重点在于解释数据耦合和控制耦合的具体含义，并结合代码逻辑进行了说明，却仍然未能明确给出DO-178C 提出该目标的意义及其与传统耦合性之间的区别。本文在研究DO-178C 及相关标准的基础上，进一步阐明了耦合覆盖分析的目的，并提出了一种能够满足该目标的人工执行方法。

1 DO-178C 的耦合覆盖目标分析

DO-178C 中的耦合覆盖目标内容如下：

软件测试的结构覆盖率（数据耦合和控制耦合）达标。

由目标可知，DO-178C 中所提的数据耦合和控制耦合仅仅是结构覆盖率分析准则的一种，同样的结构覆盖率分析准则还包括语句覆盖、判定覆盖和MC/DC 覆盖，不同的准则覆盖了代码的不同结构。结构覆盖率的目的在于为测试充分性提供一定程度的度量，分析基于需求的测试是否能够覆盖所有的代码结构（语句、判定、条件、数据关系、调用关系等）。而数据耦合和控制耦合对应的代码结构即不同软件组件之间的数据依赖关系和控制依赖关系。

正常情况下，语句、DC 及MC/DC 覆盖率都会分别在组件级别的测试中进行收集后汇总得出分析结果。换句话说，软件组件内部的结构覆盖性可以因此得以保证，但是对软件集成测试，也就是集成后组件和组件之间的结构关系并未进行覆盖，而这也正是耦合覆盖分析的主要目的，对不同组件之间的依赖关系进行结构覆盖[3]。组件之间的依赖关系主要体现在以下几个方面：

（1）软件组件之间的调用关系；（2）通过任务调度、跳转、中断处理等触发的软件组件的执行关系；（3）软件组件间的参数传递；（4）多于一个组件使用的全局变量。在耦合覆盖分析之后，可以验证软件集成关系或依赖关系的正确性，同时证明软件测试的充分性。耦合覆盖分析结果与预期不符时，可能有两种情况：

1）测试不充分，需增加需求及测试用例或单独增加测试用例对未覆盖的耦合关系进行覆盖；2）代码冗余，应修改代码，去掉不应实现的依赖关系，若出于某种原因（如防御性编程）需要保留，应进行分析说明。

2 耦合覆盖分析的执行方法

完成耦合覆盖分析，需要完成以下几个活动：

（1）耦合分析活动的计划：在软件验证计划中具体说明数据耦合分析及控制耦合分析的方法；

（2）标准约束：前文提到的在标准文件中增加设计约束的方法，虽不能单独满足耦合覆盖目标，但仍然建议使用。可以大幅降低耦合覆盖分析的复杂度，可以考虑的因素包括限制全局变量的使用、限制同一变量在多处赋值的情况、限制类型的强制转换、限制直接跳转语句的使用等；

（3）软件架构设计：在软件架构设计时，明确组件间的接口、调用关系、调度策略、中断处理逻辑等。必要时采用控制流图、数据流图、时序图等图表方式表达；

（4）软件设计评审：在软件设计评审时，确认软件架构设计的合理性和正确性；

（5）代码耦合关系分析：提取源代码中已经实现的组件间的调用关系、变量的定义和使用关系、数据流等耦合关系，必要时可采用图形方式表达。一般情况下，这一步采用工具进行分析，若采用人工分析代码的形式，需要满足两个条件：

1）使用第（2）步的标准约束大幅降低人工分析的复杂度。如果不加限制，对于多处写一处读和多处写多处读的情况，当读写次序发生变化时，可能造成极其复杂的情况，人工分析无法保证覆盖所有可能的情况；2）源代码量在可接受范围以内。一般情况下，使用这一步骤分析得出的软件间的耦合关系可以向软件架构设计过程反馈，对于某两个组件间关系过于复杂的情况，可以考虑将这两个组件进行合并处理（可以使用工具的自动优化功能，优化出来的软件架构可能从设计方面并不符合人工的设计习惯，但耦合关系能够大为简化，可以参考执行）。对软件架构关系进行优化后，应从第(3）步重新开始执行；

（6）耦合覆盖对比分析：在动态测试中使用插桩或使用工具统计耦合关系的覆盖情况。将耦合覆盖结果与预期结果（即第（3）步在设计阶段明确的耦合关系）进行对比分析，主要关注以下方面[4]：

1）数据类型的一致性，即是否存在类型的隐式转换，并分析其带来的影响；2）数据含义的一致性，保证不同组件对同一个变量的含义有相同的理解和使用，好的变量名称定义可以降低此类错误发生概率；3）确认数据依赖的类型（如图1所示四种类型，指向Data 的表示数据的写入方，Data 指向的为数据的读取方），保证组件之间的数据写入和读取顺序与设计相一致，存在多方读操作或多方写操作时，操作顺序与设计结果一致；4）组件间调用关系、执行次序与设计一致；5）组件之间的通讯时效性检查（同步/异步，可能包含向寄存器或数据缓冲区的写入和读取操作）。

图1 四种数据依赖类型Fig.1 Four data dependency types

需要注意的是，在使用基于需求的测试对组件间的依赖关系进行覆盖时，也应同时考虑需求正常范围和异常范围的测试。另外，数据耦合覆盖分析和控制耦合覆盖分析是两个独立的验证方法，美国FAA 的立场文件CAST-19 中认为应该生成两个独立的报告。以DO-178C 的一贯作风，其实一个完整报告还是分开为两个报告并不重要，重要的是认识到这两个验证活动的独立性，即使生成同一报告也应该分章节对不同的覆盖准则进行描述和汇总。

3 工具选择及工具鉴定考虑

除上文所述方法外，由于软件结构复杂度的影响，很多情况下即使对软件架构进行了优化，仍然会有很高的耦合分析复杂度，此时最好的方法就是使用成熟商用工具，这也是国内外大部分民用飞机设备供应商的选择。在商用工具的选择方面，建议考虑以下几点：

（1）组件定义的灵活程度：不同项目对组件的划分方法不同，有的项目以文件为基本单元划分不同组件分别包含哪些文件，有些项目则喜欢以函数为基本单元划分组件。由于使用工具之前需要指定不同组件所包含的内容（如包含哪些文件或包含哪些函数），因此更灵活的组件定义方法可以适用于更多的机载软件研制项目；

（2）是否能用于架构优化：耦合分析工具能够根据软件源代码以及用户对组件的定义分析得出现有的软件组件间耦合关系。部分工具还带有架构自动优化功能，可以指导用户进一步优化软件架构，简化组件间的耦合关系；

（3）耦合关系识别的全面程度：耦合分析工具是否考虑了本文第2 节提出的所有可能关系，如分析不全面，仍需人工分析进行补充；

（4）插桩代码量：插桩的代码量关系到对源代码结构的影响，如果插桩的代码量较大，意味着插桩后代码与原软件产品的差异越大，局方给与的置信度也会越低。因此在选择工具时，必须考虑插桩代码对源代码结构的影响问题；

（5）耦合报告内容详细程度：为支持耦合覆盖分析结果（如覆盖率百分比），对已覆盖的耦合关系应给出耦合关系类型（如读写耦合、调用耦合等）、对应代码位置、覆盖该关系的测试用例等信息，对于未被覆盖的耦合关系也应至少给出耦合关系类型和对应的代码位置，以便于分析该段代码对应的需求完整程度或测试用例完整程度。

对于工具鉴定，RTCA DO-178C 中明确，如果满足以下两个条件，则需要对工具进行鉴定：

（1）由于工具的使用，造成了某个过程的自动执行、减少执行或不执行；（2）不会对工具的输出进行验证。

以耦合覆盖分析工具为例来说，该工具的使用是为了替代人工，也就是用于自动执行分析过程的。因此，如果我们信任工具的结果，不对结果进行再次核对和检查，则该工具需要执行工具鉴定。反过来说，如果该工具未进行鉴定，且不打算随机取证，则需要工具提供足够的中间数据，用以支撑用户对其结果进行核对和分析，从而人工确定其分析结果的正确性。

4 结语

软件的数据耦合覆盖分析和控制耦合分析是结构覆盖率分析的一种，是DO-178C 对A、B、C 级软件的强制要求。随着国内民机事业的不断发展，搞清楚DO-178C 提出耦合覆盖分析的目的，并知道如何去实施是势在必行的事情。本文在研究DO-178C、CAST Paper 及相关报告的基础上，提出了一种从计划阶段一直到验证阶段的符合性方法，并给出了耦合覆盖分析的若干分析要点，同时对工具的选择及鉴定考虑也给出了相关建议，对我国民用飞机机载软件的耦合覆盖分析举证过程具有相当的指导意义。