为满足DO-178B/C的要求，软件验证工作不管是从技术上还是工作量上都有非常大的增加。适航领域软件验证的目的是保证软件的质量，尽可能发现更多的软件问题从而减少软件故障的发生。软硬集成测试相比低级测试可更多发现问题，尤其是集成带来的接口问题。因此需要合理选择测试策略和测试方法，使其既满足适航要求，又不会对工作量造成很大影响。

对于软件验证如何满足DO-178B/C的要求，主要技术复杂性和难点包括以下几个方面：

1. 测试用例设计

2. 测试环境

3. 结构覆盖要求

4. 关键技术分析

5. 工具鉴定

6. 适航审查

一、测试用例设计

从测试用例设计方法上来讲，基于需求的测试要复杂的多。测试用例设计并不是基于代码为了满足结构覆盖100%的要求而设计用例，而是从需求功能角度出发，在充分理解需求的前提下来设计的用例，这就需要测试人员花时间去理解需求，和开发人员不断的沟通，不断的迭代需求，从而另一方面也从需求的正确性和可验证性上进行了逐条评审。

在测试用例设计方法上面，适航领域更看重软硬集成测试方法，即整个软件加载至目标机的黑盒测试。在适航领域，应做到尽测皆测，如果软硬集成测试方法无法实现，可以考虑采用软件集成测试、低级测试或人工代码分析，若采用人工代码分析方法，要有充足的理由证明确实无法采用测试的方式进行验证。

从测试用例的数量上，基于需求的测试用例数量要呈指数级增长。如果只是为了满足结构覆盖，对于分支覆盖，可能两个用例即可满足：条件为真的用例和条件为假的用例。而基于需求的测试需要针对所有的正常情况和异常情况（包括边界值），采用MC/DC原则设计用例和验证输出。比如当判断变量A<0的情况，考虑其取值范围为[-10,10]，那么正常情况用例需要设计3个：A=-1, A=-5，A=-10，异常情况的用例需要设计6个：A=0, A=1，A=5, A=10, A=-11, A=11。

二、测试环境

基于需求的测试包括软硬集成测试、软件集成测试和低级测试。这三种测试都需要真实的目标机环境，不同的需求测试方法不同，所需的测试环境也不同。如何考虑这些测试环境，并且搭建出满足需求的测试环境，且通过测试环境获取所需的结构覆盖信息，都是需要解决的问题。

同样，测试用例设计需要考虑实际的测试环境，测试用例中设置的输入和输出测试环境是否能满足：比如模拟量信号的边界值，需要考虑测试环境如何能最大程度的消除误差满足边界的情况，并且对测试环境误差的范围需要有明确的界限。如果无法提供这样的测试环境，还需要进一步迭代测试用例，直至设计出可以在测试环境执行得到测试结果的测试用例。

软件测试环境架构

三、结构覆盖要求

从结构覆盖率分析方法上来讲，适航领域的结构覆盖分析要复杂的多。适航领域的结构覆盖分析并不是为了达到100%而通过单元测试或基于代码的测试收集覆盖率，如果通过单元测试或基于代码的测试使结构覆盖达到100%，是无法发现冗余代码，而适航领域是不允许存在冗余代码，另外针对需求或代码的原因导致无法覆盖的情况，不可以直接基于代码增加测试用例，而是要和开发部门沟通确认问题，并且迭代回归。适航领域的结构覆盖分析是为了发现软件中是否存在问题，首先执行基于需求的用例，并且优先采用软硬集成测试获取的结构覆盖信息，针对未覆盖的情况需要分析具体原因。其次再通过低级测试获取结构覆盖信息，再次进行结构覆盖分析。

四、关键技术分析

适航验证过程中除了测试和结构覆盖工作外，特别是针对数据耦合和控制耦合分析、堆栈分析、最坏执行时间分析这些在适航领域独有的要求也是适航验证的难点工作。尤其是软件耦合分析和最坏执行时间分析的难度和工作量，与软件的规模和复杂度以及软件架构息息相关。

耦合分析一般通过评审、测试、分析三个方法相结合开展：首先，评审软件需求与软件结构及代码的一致性；其次，分析提取组件间存在耦合点和耦合关系；然后，设计测试用例测试覆盖耦合点；最后，针对不能通过测试覆盖的耦合点，进行原因分析。关于耦合分析的详细内容见：《如何实现数据耦合控制耦合覆盖分析》。

最坏执行时间分析通常包含静态分析和动态测试两种方法。针对规模较大、逻辑复杂的软件，需静态分析提供软件可能的最坏执行路径（通常由开发人员实施或协助实施），验证人员结合静态分析出的可能最坏执行路径设计测试用例，动态测试多条可能的最坏执行路径的执行时间，分析得出软件最坏执行时间是否满足软件设计要求。

五、工具鉴定

对验证阶段满足相应适航目标所使用的工具，需要依据DO-330标准开展工具鉴定工作。工具的全生命周期阶段包括：计划阶段、开发阶段、验证阶段、完成阶段。

以TQL-5等级工具为例，工具鉴定需要输出的产物包含：软件合格审定计划中补充工具部分、工具鉴定计划（非必须）、工具验证计划（非必须）、工具操作需求、工具安装报告、工具操作验证与确认的测试用例和规程、工具操作验证与确认的测试结果、工具完成综述（非必须）、工具配置索引（非必须）、每个输出产物对应的评审记录。

同一个项目中，不同处理器的软件验证过程中使用相同的工具，工具鉴定工作需要针对不同处理器开展，即工具操作验证与确认的测试用例和规程需要在不同处理器执行。

关于工具鉴定的详细内容见：《TQL-5工具鉴定过程》。

六、适航审查

适航审查要求非常严格，严格的要求同样带来工作量的增加。以测试用例设计为例，不仅要设计出测试用例，还要详尽的进行测试分析，文字化描述需求的输入和输出以及测试思路，方便自己不遗漏测试用例，也方便局方审查，更重要的是，为以后的测试用例的维护带来便利，以防人员的流失或变动而追溯不了最初测试设计者的思想。如下图所示，绿色字体部分为文字化描述测试分析和真值表。

适航的严格要求还体现在适航证据的符合性上，所有的过程记录都要保留，比如评审记录、问题报告记录、变更记录等，不仅要有这些记录，而且要真实的数据，这就要求在每个过程中都要严格执行，不可敷衍了事。

总结

随着国内民机产业发展、技术复杂性以及安全性需求，使得民机适航取证的流程非常严格。作为机载软件生命周期的一个重要阶段，适航验证受到广泛重视。本文主要对适航验证活动中的一些技术难点进行剖析，阐述了一些基础的解决方法和基本流程。不同的系统软件，适航要求会存在一定差异，如对于安全等级为A级的软件，需进行额外目标码的验证，等等。

综上所述，适航验证工作中的难点和工作量大的特点应提前考虑和规划，避免时间节点紧张导致人员不足的风险！