RTCA DO-178B机载系统和设备合格审定中的软件考虑(7)

机载系统和设备合格审定中的软件考虑

软件加载到目标机中，并在目标机环境的高保真仿真环境中对其进行测试。

注：在许多情况下，只有在一个全综合环境中通过比一般情况更为精确的控制和监视测试输入和代码执行才能达到必要的基于需求的覆盖和结构覆盖。可能需要对一个与其他软件部件功能隔离的小的软件部件进行这种测试。

用目标机仿真器或宿主机模拟机进行测试可给出取证置信度。这类测试环境的指导原则是：

a. 应在综合的目标机环境中运行选定的测试，因为某些错误只能在这种环境中被发现。

6.4.2 基于需求的测试用例的选择

强调基于需求的测试是因为这类测试发现错误的效率是最高的。选择基于需求测试用例的指导原则是：

a. 为实现软件测试目标，应包括两类测试用例：正常范围测试用例和鲁棒(异常范围)测试用例。

b. 应根据软件需求和软件开发过程中内在的错误源来开发专用的测试用例。

6.4.2.1 正常范围测试用例

正常范围测试用例的目标是演示软件响应正常输入和状态的能力。正常范围测试用例包括：

a. 应该用有效等价类和边界值方法来测试实型和整型输入变量。

b. 对与时间有关的功能，如滤波器、积分器和延时，应该用代码的多次迭代来检查该功能在上下文环境中的特性。

c. 对于状态转换，应开发能在正常运行中遍历各种可能的转换的测试用例。 d. 对于用逻辑方程表达的软件需求，正常范围测试用例应能验证变量的使用和布尔算符。

注：一种方法是使用测试变量的所有组合。对于复杂表达式，由于所需的测试用例数很大，这种方法是不可行的。 另一种策略是保证能建立所需的覆盖。例如，对于A级软件，可通过分析或评审来验证布尔算符，为了补充这种活动，可建立满足修改的条件/判定覆盖的测试用例。

6.4.2.2 鲁棒测试用例

鲁棒测试用例的目标是演示软件响应异常输入和状态的能力。鲁棒测试用例包括：

a. 应该用无效值的等价类来测试实型和整型量。 b. 应在异常状态下测试系统的初始化。 c. 应确定输入数据的可能的失效模式，特别是来自外部系统的复杂的数字数据串。

d. 对于循环计数是一个计算值的循环，应开发企图计算超出范围的循环计数值的测试用例，然后演示与循环有关代码的鲁棒性。

e. 应检查用于超出帧时间的保护机制是否能正确响应。

f. 对与时间有关的功能，如滤波器、积分器和延时，应开发算术溢出保护机制的测试用例。

g. 对于状态转换，应开发能引发软件需求不允许的转换的测试用例。 6.4.3 基于需求的测试方法

基于需求的测试方法包括基于需求的硬件/软件综合测试，基于需求的软件综合测试和基于需求的低层测试。除硬件/软件综合测试外，这些方法不规定具体的测试环境或策略。指导原则是：

31

机载系统和设备合格审定中的软件考虑

a. 基于需求的硬件/软件综合测试：这种测试方法应把重点放在与目标机环境中运行的软件有关的错误源和高层功能上。基于需求的硬件/软件综合测试的目标是确保目标机中的软件满足高层需求。通过这种测试方法揭示的典型错误有：

? 不正确的中断处理。 ? 不能满足执行时间需求。 ? 对软件瞬变或硬件失效的不正确的软件响应，如启动顺序、瞬变输入负载和输入电压瞬变。

? 数据总线和其它资源争用问题，如存储映象。 ? 机内自测试不能检测到失效。 ? 硬件/软件接口错误。 ? 反馈回路的不正确行为。 ? 对存储器管理硬件或其它硬件设备的不正确的软件控制。 ? 堆栈溢出。 ? 用于确认外场可加载软件的正确性和兼容性的机制的不正确运行。

? 软件划分的越界。 b. 基于需求的软件综合测试：这种测试方法应把重点放在软件需求之间的内部关系，以及软件体系结构对需求的实现。基于需求的软件综合测试的目标是确保软件部件之间正确地相互作用并满足软件需求和软件体系结构。这种方法的实施途径可以是通过逐步地综合软件部件和相应地扩大测试用例的作用域来扩展需求的作用域。用这种测试方法揭示的典型错误是：

? 变量和常量的不正确的初始化。 ? 参数传递错误。 ? 数据失效，特别是全局数据。 ? 不适当的端点间分辨率。 ? 不正确的事件和操作顺序。 c. 基于需求的低层测试：这种测试方法应把重点放在演示每个软件部件符合其低层需求。基于需求的低层测试的目标是确保软件部件满足其低层需求。

用这种测试方法揭示的典型错误是： ? 一个算法不能满足软件需求。 ? 不正确的循环操作。 ? 不正确的逻辑判定。 ? 不能正确地处理输入状态的合法组合。 ? 不能正确地响应丢失的或失效的输入数据。 ? 不能正确地处理异常，如算术故障或数组越界。 ? 不正确的计算顺序。 ? 不适当地算法精度，准确度或性能。

6.4.4测试覆盖分析

测试覆盖分析分两步进行，即基于需求的覆盖分析和结构覆盖分析。第一步分析与软件需求有关的测试用例，以证实所选的测试用例满足指定的准则。第二步证实基于需求的测试规程测试了代码结构。结构覆盖分析可能不满足指定的准则。对于处理死代码这样情况的解决方法提出了附加的指导原则(见6.4.4.3节)。

32

机载系统和设备合格审定中的软件考虑

6.4.4.1 基于需求的测试覆盖分析

这种分析的目标是确定基于需求的测试对软件需求的实现的验证情况。这种分析可能要求增加基于需求的测试用例。基于需求的测试覆盖分析应表明：

a. 每一项需求都有测试用例。

b. 测试用例满足6.4.2节定义的正常和鲁棒测试准则。

6.4.4.2 结构覆盖分析

这种分析的目标是确定基于需求的测试规程未测试到的代码结构。基于需求的测试用例可能没有测试到所有代码结构，所以要执行结构覆盖分析，并进行额外的验证以达到结构覆盖。指导原则包括：

a. 分析应证实结构覆盖的程度适应所定的软件等级。

b. 除软件等级是 A 级并且编译器产生的目标码不能直接追踪到源代码语句外, 可以对源代码直接进行结构覆盖分析。然后,对目标码进行附加验证以确定所产生的代码序列的正确性。由编译器生成的数组边界检查的目标码是不能直接追踪到源代码的一个例子。

c. 分析应证实代码部件之间的数据耦合和控制耦合。

6.4.4.3 结构覆盖分析方法

结构覆盖分析可揭示在测试中未被执行到的代码结构。解决方法是进行附加的软件验证活动。这种未执行的代码结构可能是下列原因造成的：

a. 基于需求的测试用例或规程的不足：应补充测试用例或修改测试规程以补全遗漏的覆盖。可能需要评审用以执行基于需求的覆盖分析的方法。

b. 软件需求的缺陷：应修改软件需求， 增加测试用例和运行相应的测试规程。

c. 死代码：应消除这种代码，并进行分析以评定其影响和是否需要重新验证。 d. 停止使用的代码：对于在飞机或发动机的任何配置中不打算被执行的停止使用的代码， 应结合分析和测试来表明已采用了某种手段，它能防止，隔离或消除因疏忽而运行这类代码。对于只在目标机环境的某些配置中执行的停止使用代码，应建立正常执行这类代码所需的运行配置，并开发附加的测试用例和测试规程来满足所需的覆盖目标。

7. 0 软件配置管理过程

这一章讨论软件配置管理（SCM）过程的目标和活动。在软件计划过程（第4章）和软件配置管理计划（11.4条）中定义了SCM过程。SCM过程的输出记录在软件配置管理记录（11.18条）或其它的软件生成周期资料中。

附件A中的表A－8总结了SCM过程的目标和输出。

7.1 软件配置管理过程目标

SCM过程同其它软件生成周期过程一并进行，这有助于满足总的目标： a．提供在软件整个生存周期中定义的和受控的软件配置。

b．提供始终为软件制造重现可执行目标代码或在对要求调查或修改的场合重新产生可执行目标代码的能力。

c．在软件生存周期期间，提供过程输入和输出的控制，以保证过程活动的一致性和可重复性。

33

机载系统和设备合格审定中的软件考虑

d．通过对配置项控制和基线的确定，为评审、评估状态和更改控制提供已知的点。

e．要提供控制，以保证问题引起注意且更改得以记录、批准和实施。 f．通过控制软件生成周期过程的输入，来提供软件批准的证据。 g．帮助软件产品符合需求的评估。

h．确保对配置项安全地进行物理归档、恢复和控制的维护工作。

SCM的目标与软件等级无关。然而，两类软件生成周期资料的存在是基于适用于该种资料的SCM控制。

7.2 软件配置管理过程活动

SCM过程包括配置标识、更改控制、基线确定和软件产品（包括有关的软件生存周期资料）归档活动。下列指南定义了每一个SCM过程活动的目标。当软件产品被合格审定机构接受时，SCM过程不能停止，而是持续到机载系统或设备的使用期限。

7.2.1 配置标识

配置标识活动的目标是清楚地为每一个配置项（及其逐次版本）打标记，以便为配置项的控制和参考确定一个基准。指南包括：

a． 要对软件生存周期资料确定配置标识。

b． 要对每一个配置项、配置项的每一个独立的控制部件和组成一个软件产品的配置项的组合确定配置标识。

c． 要在更改控制实施并记录可追踪资料之前对配置项进行配置标识。 d． 在其它的软件生成周期使用之前、其它的软件生成周期资料引用之前或软件制造或软件使用之前，要对该配置项进行配置标识。

e． 如果软件产品标识不能有物理检查（如部件号铭牌检查）确定，那么可执行目标码要包含可由机载系统或设备的其它部件存取的配置标识。这可能适用于外场可加载软件（2.5条）。

7.2.2 基线和可追踪性

确定基线的目标是为进一步的软件生成周期过程活动确定一个基准，并允许在配置项之间参照、控制和可追踪。指南包括：

a． 要为用于合格审定置信度的配置项确定基线（确定的中间基线有助于控制软件生存周期过程的活动）。

b． 要对软件产品确定软件产品基线，并在软件配置索引（11.16条）中定义。 注：在软件产品基线中并不包括用户可更改软件，但它的有关防护和边界部件例外。所以，只要不影响软件产品基线的配置标识，就可以对用户可更改软件进行更改。

c． 要在受控的软件库（物理的、电子的或其它的）中确定基线，以保证它们的完整性。一旦确定了基线，不要对其进行更改。

d． 更改控制活动将从一个确定的基线跟随到开发一个派生基线。 e． 如果合格审定置信度被看作是软件生存周期过程的活动，或者是与以前基线的开发有关的资料，那么基线要能追踪到其派生出的那个基线。

f． 如果合格审定置信度被看作是软件生存周期过程的活动，或者是与以前配置项的开发有关的资料，那么配置项要能追踪到其派生出的那个配置项。

34

机载系统和设备合格审定中的软件考虑

g． 基线或配置项要追踪到它表明的输出或与之有关的过程。

7.2.3 问题报告、追踪和纠正活动

问题报告、追踪和纠正活动的目标是记录不符合软件计划和标准的过程、记录软件生存周期过程输出的缺陷、记录软件产品的异常状态并确保这些问题的解决。

注：软件生存周期过程和软件产品问题可在问题报告系统中分别记录。 指南包括： a． 要编制描述过程不符合计划、输出缺陷或软件异常状态及采取的纠正措施的问题报告，正象11.17条定义的那样。

b． 对受影响的配置项的配置标识或受影响的过程活动、问题报告的状态报告和问题报告的批准和封存，要提交问题报告。

c． 对软件产品或软件生存周期过程的输出的纠正活动的问题报告将引用更改控制活动。

注：问题报告和更改控制活动是相关的。

7.2.4 更改控制

更改控制活动的目标是在软件生存周期内为更改提供记录、评估、处理和批准。指南包括：

a． 更改控制要通过对它们的更改提供防护来保持配置项和基线的完整性。 b． 更改控制确保对每一个配置项的任何更改都需要对其配置标识进行更改。 c． 在更改控制下对基线和配置项的更改要加以记录、批准和追踪。由于报告的问题的处理可能导致配置项或基线的更改，所以问题报告与更改控制有关。 注：一般认为，尽早实现更改控制有助于软件生存周期过程活动的控制和管理。

d． 软件更改要追踪到更改影响它们输出的原始处，并从该处重复软件生存周期过程。例如，在硬件 / 软件综合阶段发现的错误，如果表明由不正确设计引起的，那么将导致与综合过程活动有关的设计更改、编码更改和重复。

e． 在整个更改活动中，要更新受更改影响的软件生存周期资料。要保存更改控制活动的记录。

可通过更改评审活动帮助更改控制活动。

7.2.5 更改评审

更改评审活动的目标是确保问题及更改得以评定、批准或不批准，批准的更改得以实施，并给在整个问题报告中受影响的过程和在软件计划过程期间所定义的更改控制方法提供反馈。更改评审活动将包括：

a． 证实受影响的配置项得以配置标识；

b． 对影响反馈到系统安全性评估过程的与安全性有关的需求的评估； c． 问题或更改（包括采取措施的决定）的评估； d． 问题报告的反馈或更改影响过程的决定。

7.2.6 配置状态纪实

状态纪实活动的目标是为软件生存周期过程的配置管理提供资料。主要关系到配置标识、基线、问题报告和更改控制。状态纪实活动将包括：

a． 对配置项标识、基线标识、问题报告状态、更改历史和发放状态的报告。

35

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库RTCA DO-178B机载系统和设备合格审定中的软件考虑(7)在线全文阅读。