机载系统和设备合格审定中的软件考虑
软件设计过程、软件编码过程或软件计划过程，以作为澄清或纠正的反馈。
5.4.3 综合考虑
下列是对无效码和软件修补的考虑。设计的机载系统或设备可包括几种配置，但不是所有的都计划在每一种应用中使用。这可能产生不能被执行的无效的编码或不被使用的数据。着一点不用于在术语汇编中定义的或在6.4.4.3条中讨论的死码。对无效编码和修补的指南包括：
a. 无效代码不能在不打算使用它的环境中使用。由于异常的系统状态造成的无效代码的不希望动作与活化代码的不希望动作是一样禁止的。
b.处理无效码的方法要符合软件计划。
c.提交给合格审定的航空器或发动机使用的软件不使用修补来实现需求或结构中的更改，或在软件验证过程中发现必须的更改。例如，修补使用于受限的具体实例，以解决软件开发环境中已知的缺陷，如一个已知的编译程序问题。
d. 当使用修补时，这些将是可用的： （1） 软件配置管理过程能有效地追踪修补的证实； （2） 能提供修补满足由正常方法开发的软件的所有目标的证据的回归分析； （3） 在软件实施概要中使用修补的理由。
5．5 可追踪性
可追踪性指南包括：
a. 要提供在系统需求和软件需求之间的可追踪性，以能够验证实施系统需求的完整性，并给出明确的派生需求。
b. 要提供在低级需求和高级需求之间的可追踪性，以便在软件设计过程期间给出明确的派生需求和所做的结构设计决策，并容许验证实现高级需求的完整性。
c. 要提供在源代码和低级需求之间的可追踪性，以能够验证非书面源代码的缺乏性以及验证低级需求实现的完整性。
6．0 软件验证过程
这一章论述软件验证过程的目标和活动。验证是软件开发过程和软件验证过程两者结果的技术评估。在软件计划过程（第4章）和软件验证计划（11.3条）中定义了实施的和软件验证过程。
验证不仅仅是测试。一般来说，测试不能表明没有错误。所以，在以下几节中当所述的软件验证过程目标兼有评审、分析和测试时，则使用术语“验证”而不用“测试”。
附录A中表A—３到表A—７按软件等级列出了软件验证过程的目标和输出。
注：对较低的软件等级，较少强调如下方面： ? 低层需求的验证 ? 软件体系结构的验证 ? 测试覆盖程度 ? 验证规程的控制 ? 软件验证过程活动的独立性 ? 软件验证过程活动的重叠，即在几种软件验证活动中，每一种活动都能检测到同一类 错误
? 鲁棒测试 ? 对预防错误或检测错误有间接作用的验证活动，如软件开发标准的符合性验证
26
机载系统和设备合格审定中的软件考虑
6.1 软件验证过程目标
软件验证过程的目的是检测和报告在软件开发过程中可能已形成的错误。消除这些错误是软件开发过程的一种活动。软件验证过程的总目标是验证：
a. 分配给软件的系统需求已发展成满足这些系统需求的软件高层需求。 b. 高层需求已发展成满足这些高层需求的软件体系结构和低层需求。如果在高层需求和低层需求之间建立了一层或多层软件需求，那么相邻层次需求的建立应使每一相邻的较低层需求满足其较高层需求。如果从高层需求直接生成代码，那么本项目标不适用。
c. 软件体系结构和低层需求已发展成满足低层需求和软件体系结构的源代码。
d. 可执行目标码满足软件需求。
e. 用于满足上述目标的方法对所定的软件等级而言在技术上是正确的且完整的。
6.2 软件验证过程活动
通过评审、分析、开发测试用例和规程，以及运行测试规程等各种活动的组合来达到软件验证过程的目标。评审和分析对软件需求、软件体系结构和源代码的准确性、完整性和可验证性给予评估。测试用例的开发可对需求的内部一致性和完整性提供进一步的评估。测试规程的运行提供是否符合需求的演示。
软件验证过程的输入包括系统需求、软件需求和结构、可追踪性数据、源代码、可执行目标码和软件验证计划。
软件验证过程的输出记录在软件验证用例和规程（第11.13小节）和软件验证结果（第11.14小节）中。
在软件中实现了需求之后，由于要求需求是可验证的，因此要对软件开发过程提出额外的要求和约束。
软件验证过程要提供在软件需求的实现与对软件需求的验证之间的可追踪性： ? 由基于需求的覆盖分析完成软件需求与测试用例之间的可追踪性 ? 由结构覆盖分析完成代码结构与测试用例之间的可追踪性 软件验证活动的指导原则是：
a. 应验证高层需求以及到高层需求的可追踪性。
b. 可追踪性分析以及基于需求和结构的覆盖分析应表明每一项软件需求可追踪到实现它的代码以及验证它的评审、分析或测试用例。
c. 如果被测代码与机载软件不完全相同，应规定并说明其差别。
d. 如果不能通过在真实的测试环境中运行软件来验证具体的软件需求时，应提供其它手段及说明来满足软件验证计划或软件验证结果中所定义的软件验证目标。
e. 应向软件开发过程报告在软件验证过程中发现的缺陷和错误，以便于澄清和纠正。
6.3 软件评审和分析
评审和分析适用于软件开发过程和软件验证过程的结果。评审与分析的一个差别是分析提供正确性的可重复证据，而评审提供正确性的定性评估。评审可以是一种以一张检查清单或类似辅助手段为指导而进行的对某种输出的检查过程。分析可以是对一个软件部件的功能、性能、可追踪性、安全性影响、以及它与机载
27
机载系统和设备合格审定中的软件考虑
系统或设备中其它部件的关系进行详细检查。
6.3.1 高层需求的评审和分析
高层需求的评审和分析的目标是发现和报告在软件需求开发过程中可能已产生的需求错误。这些评审和分析要证实高层需求满足下列目标：
a. 与系统需求的符合性：该目标是确保已定义了的软件要完成的系统功能，软件的高层需求能满足系统的与功能、性能和有关安全的需求，并正确地定义了派生的需求及其成立的原因。
b. 准确性和一致性：该目标是确保每一项高层需求被准确地、无歧义地和充分地细化，并且需求之间没有冲突。
c. 与目标机的兼容性：该目标是确保在高层需求与目标机的硬件/软件特征之间，特别是与系统的响应时间和输入/输出硬件之间不存在冲突。
d. 可验证性：该目标是确保每一项高层需求是可验证的。 e. 与标准的符合性：该目标是确保在软件需求开发过程中遵循了软件需求标准，并对偏离标准的方面作了说明。
f. 可追踪性：该目标是确保分配到软件的系统功能、性能和有关安全的需求已发展成软件的高层需求。
g. 算法方面：该目标是确保所提出的算法的精度和特性，特别是在不连续区域。
6.3.2 低层需求的评审和分析
低层需求的评审和分析的目标是发现和报告在软件设计过程中可能已产生的需求错误。这些评审和分析要证实软件低层需求满足下列目标：
a. 与高层需求的符合性：该目标是确保软件低层需求满足软件高层需求，并正确地定义了派生需求及其之所以成立的设计基础。
b. 准确性和一致性：该目标是确保每一项低层需求是准确的、无歧义的，并且低层需求之间没有冲突。
c. 与目标机的兼容性：该目标是确保在软件需求与目标机的硬件/软件特征之间，特别是与资源的使用（如总线负载）、系统响应时间和输入/输出硬件之间不存在冲突。
d. 可验证性：该目标是确保每一项低层需求是可验证的。
e. 与标准的符合性：该目标是确保在软件设计过程中遵循了软件设计标准，并对偏离标准的方面作了说明。
f. 可追踪性：该目标是确保高层需求及派生需求已发展成低层需求。
g. 算法方面：该目标是确保所提出的算法的精度和特性，特别是在不连续区域。
6.3.3 软件体系结构的评审和分析
软件体系结构的评审和分析的目标是发现和报告在开发软件体系结构中可能已产生的错误。这些评审和分析要证实软件体系结构满足下列目标：
a. 与高层需求的符合性：该目标是确保软件体系结构与高层需求没有矛盾，特别是与保证系统完善性的功能（如划分方案）没有矛盾。
b. 一致性：该目标是确保软件体系结构中各部件的关系是正确的。这种关系存在于数据流和控制流之中。
c. 与目标机的兼容性：该目标是确保在软件体系结构与目标机的硬件/软件
28
机载系统和设备合格审定中的软件考虑
之间，特别是与初始化、异步操作、同步和中断之间不存在冲突。
d. 可验证性：该目标是确保软件体系结构是可验证的，如没有无限递归算法。 e. 与标准的符合性：该目标是确保在软件设计过程中遵循了软件设计标准，并对偏离标准的方面，特别是不符合系统安全性目标的复杂性限制和设计结构作了说明。
f. 划分的完整性：该目标是确保防止或隔离了划分的分叉。
6.3.4 源代码的评审和分析
源代码的评审和分析的目标是发现和报告在软件编码过程中可能已产生的错误。这些评审和分析要证实软件编码过程的输出是准确的、完整的和可验证的。应主要考虑代码相对于软件需求和软件体系结构的正确性以及与软件编码标准的符合性。这些评审和分析通常局限于源代码。应包括下列论题：
a. 与低层需求的符合性：该目标是确保源代码对于软件低层需求而言是准确的和完整的，并且源代码中没有实现未规定的功能。
b. 与软件体系结构的符合性：该目标是确保源代码与软件体系结构中定义的数据流和控制流相匹配。
c. 可验证性：该目标是确保源代码不包含不能被验证的语句和结构，也不包含只有通过更改才能对其测试的代码。
d. 与标准的符合性：该目标是确保在代码开发过程中，特别是建立应符合系统安全性目标的复杂性限制和代码约束时，遵循了软件编码标准。复杂性包括软件部件之间的耦合、控制结构的嵌套层数以及逻辑或数值表达式的复杂程度。这种分析也要确保对偏离标准的方面作出说明。
e. 可追踪性：该目标是确保软件低层需求已发展成源代码。
f. 准确性和一致性：该目标是确保源代码的正确性和一致性，包括堆栈的使用，定点算术运算溢出和处理，资源争夺、最恶劣情况的执行时间、异常处理、未初始化变量或常量的使用、未使用的变量或常量以及由于任务或中断冲突造成的数据失效。
6.3.5 集成过程输出的评审和分析
对集成过程输出进行评审和分析的目标是确保集成过程的输出是完整的和正确的。可通过详细检查链接、加载数据和内存映象来进行这类评审和分析。应考虑的论题是：
a. 不正确的硬件地址。 b. 内存重叠。 c. 遗漏软件部件。
6.3.6 测试用例、规程和结果的评审和分析
测试用例、规程和结果的评审和分析的目标是确保已开发了代码测试，并正确和完整地执行了测试。应考虑的论题是：
测试用例：在6.4.4节中说明了测试用例的验证。
测试规程：该目标是要验证测试用例已被正确地发展成测试规程和期望的结果。
测试结果：该目标是确保测试结果是正确的，并且解释了真实结果与期望结果之间的差异。
29
机载系统和设备合格审定中的软件考虑
基于软件需求的 测试生成
低级测试 软件综合测试 硬件/软件综合测试
软件需求覆盖分析
软件结构覆盖分析 直接路径
条件路径 附加验证 测试结束
图6-1 软件测试过程
注： 如果已为硬件/软件综合测试或软件综合测试开发和执行了一个测试用例及其相应的测试规程，并且满足了基于需求的覆盖和结构覆盖，那么就不必对低层测试重复这个测试。因减少全部功能测试总量而用标称等价的低层测试来替代高层测试可能是低效的。
6.4 软件测试过程
机载软件的测试有两个相互补充的目标。一个目标是演示软件满足其需求。另一个目标是以高置信度演示可能导致由系统安全性评估过程确定为不可接受的失效状态的错误已被消除。
图6-1 是软件测试过程图。图中三类测试的目标是： ? 硬件/软件综合测试：验证软件在目标机环境中的正确运行。 ? 软件综合测试：验证软件需求和部件之间的内部关系，验证软件需求和软件部件在软件体系结构中的实现。
? 低层测试：验证软件低层需求的实现。
为了满足软件测试目标：
a. 测试用例应主要以软件需求为基础。
b. 测试用例应开发成能验证正确的功能和建立能暴露潜在错误的条件。 c. 软件需求覆盖分析应确定哪些软件需求未被测试。 d. 结构覆盖分析应确定哪些软件结构未被运行。 6.4.1 测试环境
为满足软件测试的目标，可能需要多个测试环境。一个优秀的测试环境应能把
30