6.0 软件验证过程 SOFTWARE VERIFICATION PROCESS
本节讨论软件验证过程的目标和活动。 验证是对软件计划过程、软件开发过程和软件验证过程的输出的技术评估。 软件验证过程按照软件计划过程（参见 4）和软件验证计划（参见 11.3）的定义进行应用。 规划过程输出的验证见 4.6。
This section discusses the objectives and activities of the software verification process. Verification is a technical assessment of the outputs of the software planning process, software development processes, and the software verification process. The software verification process is applied as defined by the software planning process (see 4) and the Software Verification Plan (see 11.3). See 4.6 for the verification of the outputs of the planning process.
验证不仅仅是测试。 一般来说，测试不能表明不存在错误。 因此，以下各节使用术语“验证”而不是“测试”来讨论软件验证过程活动，这些活动通常是评审、分析和测试的组合。
Verification is not simply testing. Testing, in general, cannot show the absence of errors. As a result, the following sections use the term "verify" instead of "test" to discuss the software verification process activities, which are typically a combination of reviews, analyses, and tests.
附件 A 的表 A-3 到 A-7 包含按软件级别划分的软件验证过程的目标和输出的摘要。
Tables A-3 through A-7 of Annex A contain a summary of the objectives and outputs of the software verification process, by software level.
注意：对于较低的软件级别，不太强调：Note: For lower software levels, less emphasis is on:
• 源代码验证。Verification of Source Code.
• 验证低级需求。Verification of low-level requirements.
• 验证软件架构。Verification of the software architecture.
• 测试覆盖程度。Degree of test coverage.
• 验证程序的控制。Control of verification procedures.
• 软件验证过程活动的独立性。Independence of software verification process activities.
• 重叠的软件验证过程活动，即多个验证活动，每个验证活动都可能能够检测同一类错误。Overlapping software verification process activities, that is, multiple verification activities, each of which may be capable of detecting the same class of error.
• 健壮性测试。Robustness testing.
• 对错误预防或检测有间接影响的验证活动，例如，符合软件开发标准。Verification activities with an indirect effect on error prevention or detection, for example, conformance to software development standards.
6.1 软件验证的目的 Purpose of Software Verification
软件验证过程的目的是检测并报告在软件开发过程中可能引入的错误。 消除错误是软件开发过程的一项活动。 软件验证过程验证：
The purpose of the software verification process is to detect and report errors that may have been introduced during the software development processes. Removal of the errors is an activity of the software development processes. The software verification process verifies that:
a. 分配给软件的系统需求已开发为满足这些系统需求的高级需求。The system requirements allocated to software have been developed into high-level requirements that satisfy those system requirements.
b. 高级需求被开发成满足高级需求的软件体系结构和低级需求。如果在高级需求和低级需求之间开发了一个或多个软件需求级别，则开发了连续的需求级别，以便每个连续的较低级别满足其较高级别的需求。如果代码是直接从高级需求生成的，则不适用。The high-level requirements have been developed into software architecture and low-level requirements that satisfy the high-level requirements. If one or more levels of software requirements are developed between high-level requirements and low-level requirements, the successive levels of requirements are developed such that each successively lower level satisfies its higher level requirements. If code is generated directly from high-level requirements, this does not apply.
c. 软件架构和低级需求已开发成满足低级需求和软件架构的源代码。The software architecture and low-level requirements have been developed into Source Code that satisfies the low-level requirements and software architecture.
d. 可执行目标码满足软件需求（即预期的功能），并确保不存在非预期功能。The Executable Object Code satisfies the software requirements (that is, intended function), and provides confidence in the absence of unintended functionality.
e. 可执行目标码对于软件需求而言是稳健的，因此它可以正确响应异常输入和条件。The Executable Object Code is robust with respect to the software requirements such that it can respond correctly to abnormal inputs and conditions.
f. 用于执行此验证的方法在技术上是正确的并且对于软件级别来说是完整的。The means used to perform this verification are technically correct and complete for the software level.
6.2 软件验证过程活动概述 Overview of Software Verification Process Activities
软件验证过程的目标是通过评审、分析、测试用例和过程的开发以及这些测试过程的后续执行的组合来满足的。 评审和分析提供对软件需求、软件架构和源代码的准确性、完整性和可验证性的评估。 测试用例和程序的开发可以进一步评估需求的内部一致性和完整性。 测试程序的执行提供了符合要求的证明。
Software verification process objectives are satisfied through a combination of reviews, analyses, the development of test cases and procedures, and the subsequent execution of those test procedures. Reviews and analyses provide an assessment of the accuracy, completeness, and verifiability of the software requirements, software architecture, and Source Code. The development of test cases and procedures may provide further assessment of the internal consistency and completeness of the requirements. The execution of the test procedures provides a demonstration of compliance with the requirements.
软件验证过程的输入包括系统需求、软件需求、软件架构、跟踪数据、源代码、可执行目标码和软件验证计划。
The inputs to the software verification process include the system requirements, the software requirements, software architecture, Trace Data, Source Code, Executable Object Code, and the Software Verification Plan.
软件验证过程的输出记录在软件验证案例和程序（见11.13）、软件验证结果（见11.14）和相关跟踪数据（见11.21）中。
The outputs of the software verification process are recorded in the Software Verification Cases and Procedures (see 11.13), the Software Verification Results (see 11.14), and the associated Trace Data (see 11.21).
一旦需求在软件中实现，就需要对其进行验证，这本身可能会对软件开发过程施加额外的需求或约束。
The need for the requirements to be verifiable once they have been implemented in the software may itself impose additional requirements or constraints on the software development processes.
软件验证考虑因素包括：Software verification considerations include:
a. 如果测试的代码与机载软件不同，则应指定这些差异并证明其合理性。If the code tested is not identical to the airborne software, those differences should be specified and justified.
b. 当无法通过在实际测试环境中运行软件来验证特定的软件需求时，应提供其他方法及其满足软件验证计划或软件验证结果中定义的软件验证过程目标的理由。When it is not possible to verify specific software requirements by exercising the software in a realistic test environment, other means should be provided and their justification for satisfying the software verification process objectives defined in the Software Verification Plan or Software Verification Results.
c. 在软件验证过程中发现的缺陷和错误应报告给其他软件生命周期过程，以便在适用时进行澄清和纠正。 Deficiencies and errors discovered during the software verification process should be reported to other software life cycle processes for clarification and correction as applicable.
d. 应在可能影响先前验证功能的纠正措施和/或更改之后进行重新验证。 重新验证应确保修改已正确实施。Reverification should be conducted following corrective actions and/or changes that could impact the previously verified functionality. Reverification should ensure that the modification has been correctly implemented.
e. 当验证活动是由被验证项目的开发人员以外的人执行时，就实现了验证独立性。 可以使用工具来实现与人工验证活动的等效性。 为了独立性，创建一组基于低级需求的测试用例的人不应与根据这些低级需求开发相关源代码的人不同。Verification independence is achieved when the verification activity is performed by a person(s) other than the developer of the item being verified. A tool may be used to achieve equivalence to the human verification activity. For independence, the person who created a set of low-level requirements-based test cases should not be the same person who developed the associated Source Code from those low-level requirements.
6.3 软件评审和分析 Software Reviews and Analyses
对软件开发过程的输出进行评审和分析。 评审和分析之间的一个区别是，分析提供了正确性的可重复证据，而评审提供了正确性的定性评估。 评审可能包括在清单或类似帮助的指导下对流程的输出进行检查。 分析可以详细检查软件组件的功能、性能、可追溯性和安全影响，以及它与系统或设备内其他组件的关系。
Reviews and analyses are applied to the outputs of the software development processes. One distinction between reviews and analyses is that analyses provide repeatable evidence of correctness and reviews provide a qualitative assessment of correctness. A review may consist of an inspection of an output of a process guided by a checklist or similar aid. An analysis may examine in detail the functionality, performance, traceability, and safety implications of a software component, and its relationship to other components within the system or equipment.
在某些情况下，仅通过评审和分析可能无法完全满足本节中描述的验证目标。 在这种情况下，可以通过对软件产品进行额外的测试来满足这些验证目标。 例如，可以开发审查、分析和测试的组合来确定最坏情况的执行时间或堆栈使用情况的验证。
There may be cases where the verification objectives described in this section cannot be completely satisfied via reviews and analyses alone. In such cases, those verification objectives may be satisfied with additional testing of the software product. For example, a combination of reviews, analyses, and tests may be developed to establish the worst-case execution time or verification of the stack usage.
6.3.1 高级需求的评审和分析Reviews and Analyses of High-Level Requirements
这些评审和分析活动检测并报告在软件需求过程中可能引入的需求错误。 这些评审和分析活动确认高级需求满足以下目标：
These review and analysis activities detect and report requirements errors that may have been introduced during the software requirements process. These review and analysis activities confirm that the high-level requirements satisfy these objectives:
a. 符合系统需求：目标是确保定义软件要执行的系统功能，高级需求满足系统的功能、性能和安全相关需求，以及派生需求以及它们存在的原因都得到了正确的定义。Compliance with system requirements: The objective is to ensure that the system functions to be performed by the software are defined, that the functional, performance, and safety-related requirements of the system are satisfied by the high-level requirements, and that derived requirements and the reason for their existence are correctly defined.
b. 准确性和一致性：目标是确保每个高级需求都是准确的、明确的、足够详细的，并且这些需求不会相互冲突。Accuracy and consistency: The objective is to ensure that each high-level requirement is accurate, unambiguous, and sufficiently detailed, and that the requirements do not conflict with each other.
c. 与目标计算机的兼容性：目标是确保高级需求与目标计算机的硬件/软件特性之间不存在冲突，特别是系统响应时间和输入/输出硬件。Compatibility with the target computer: The objective is to ensure that no conflicts exist between the high-level requirements and the hardware/software features of the target computer, especially system response times and input/output hardware.
d. 可验证性：目标是确保每个高级需求都可以得到验证。Verifiability: The objective is to ensure that each high-level requirement can be verified.
e. 符合标准：目标是确保在软件需求过程中遵循软件需求标准，并且与标准的偏差是合理的。Conformance to standards: The objective is to ensure that the Software Requirements Standards were followed during the software requirements process and that deviations from the standards are justified.
f. 可追溯性：目标是确保分配给软件的系统功能、性能和安全相关的需求被开发成高级需求。 Traceability: The objective is to ensure that the functional, performance, and safety-related requirements of the system that are allocated to software were developed into the high-level requirements.
g. 算法方面：目标是确保所提出算法的准确性和行为，特别是在不连续性领域。Algorithm aspects: The objective is to ensure the accuracy and behavior of the proposed algorithms, especially in the area of discontinuities.
6.3.2 低级需求的评审和分析 Reviews and Analyses of Low-Level Requirements
这些评审和分析活动检测并报告在软件设计过程中可能引入的需求错误。 这些评审和分析活动确认低级需求满足这些目标：
These review and analysis activities detect and report requirements errors that may have been introduced during the software design process. These review and analysis activities confirm that the low-level requirements satisfy these objectives:
a. 符合高级需求：目标是确保低级需求满足高级需求，并正确定义派生需求及其存在的设计基础。Compliance with high-level requirements: The objective is to ensure that the lowlevel requirements satisfy the high-level requirements and that derived requirements and the design basis for their existence are correctly defined.
b. 准确性和一致性：目标是确保每个低级需求准确且明确，并且低级需求不会相互冲突。Accuracy and consistency: The objective is to ensure that each low-level requirement is accurate and unambiguous, and that the low-level requirements do not conflict with each other.
c. 与目标计算机的兼容性：目标是确保低级需求与目标计算机的硬件/软件功能之间不存在冲突，特别是总线负载、系统响应时间和输入/输出等资源的使用 硬件。Compatibility with the target computer: The objective is to ensure that no conflicts exist between the low-level requirements and the hardware/software features of the target computer, especially the use of resources such as bus loading, system response times, and input/output hardware.
d. 可验证性：目标是确保每个低级需求都可以得到验证。 Verifiability: The objective is to ensure that each low-level requirement can be verified.
e. 符合标准：目标是确保在软件设计过程中遵循软件设计标准，并且与标准的偏差是合理的。Conformance to standards: The objective is to ensure that the Software Design Standards were followed during the software design process and that deviations from the standards are justified.
f. 可追溯性：目标是确保将高级需求和派生需求开发为低级需求。Traceability: The objective is to ensure that the high-level requirements and derived requirements were developed into the low-level requirements.
g. 算法方面：目标是确保所提出算法的准确性和行为，特别是在不连续性领域。Algorithm aspects: The objective is to ensure the accuracy and behavior of the proposed algorithms, especially in the area of discontinuities.
6.3.3 软件架构的评审与分析Reviews and Analyses of Software Architecture
这些评审和分析活动检测并报告在软件架构开发过程中可能引入的错误。 这些评审和分析活动确认软件架构满足以下目标：
These review and analysis activities detect and report errors that may have been introduced during the development of the software architecture. These review and analysis activities confirm that the software architecture satisfies these objectives:
a. 与高级需求的兼容性：目标是确保软件架构与高级需求不冲突，特别是保证系统完整性的功能，例如分区方案。Compatibility with the high-level requirements: The objective is to ensure that the software architecture does not conflict with the high-level requirements, especially functions that ensure system integrity, for example, partitioning schemes.
b. 一致性：目标是确保软件架构的组件之间存在正确的关系。 这种关系通过数据流和控制流而存在。 如果接口是连接到较低软件级别的组件，则还应该确认较高软件级别组件具有适当的保护机制，以保护其自身免受来自较低软件级别组件的潜在错误输入的影响。Consistency: The objective is to ensure that a correct relationship exists between the components of the software architecture. This relationship exists via data flow and control flow. If the interface is to a component of a lower software level, it should also be confirmed that the higher software level component has appropriate protection mechanisms in place to protect itself from potential erroneous inputs from the lower software level component.
c. 与目标计算机的兼容性：目标是确保软件架构与目标计算机的硬件/软件功能之间不存在冲突，特别是初始化、异步操作、同步和中断。Compatibility with the target computer: The objective is to ensure that no conflicts exist, especially initialization, asynchronous operation, synchronization, and interrupts, between the software architecture and the hardware/software features of the target computer.
d. 可验证性：目标是确保软件架构是可验证的，例如不存在无界递归算法。 Verifiability: The objective is to ensure that the software architecture can be verified, for example, there are no unbounded recursive algorithms.
e. 符合标准：目标是确保在软件设计过程中遵循软件设计标准，并且对标准的偏差是合理的，例如，对复杂性限制和设计构造规则的偏差。Conformance to standards: The objective is to ensure that the Software Design Standards were followed during the software design process and that deviations to the standards are justified, for example, deviations to complexity restriction and design construct rules.
f. 分区完整性：目标是确保防止分区破坏。Partitioning integrity: The objective is to ensure that partitioning breaches are prevented.
6.3.4 源代码的评审和分析 Reviews and Analyses of Source Code
这些评审和分析活动检测并报告在软件编码过程中可能引入的错误。 主要关注点包括代码相对于软件需求和软件架构的正确性，以及对软件代码标准的一致性。 这些评审和分析活动通常仅限于源代码，并确认源代码满足以下目标：
These review and analysis activities detect and report errors that may have been introduced during the software coding process. Primary concerns include correctness of the code with respect to the software requirements and the software architecture, and conformance to the Software Code Standards. These review and analysis activities are usually confined to the Source Code and confirm that the Source Code satisfies these objectives:
a. 符合低级需求：目标是确保源码对于低级需求是准确和完整的，并且没有源码实现未记录的功能。Compliance with the low-level requirements: The objective is to ensure that the Source Code is accurate and complete with respect to the low-level requirements and that no Source Code implements an undocumented function.
b. 符合软件架构：目标是确保源码与软件架构中定义的数据流和控制流相匹配。Compliance with the software architecture: The objective is to ensure that the Source Code matches the data flow and control flow defined in the software architecture.
c. 可验证性：目标是确保源码没有包含无法验证的语句和结构，并且无需更改代码即可对其进行测试。Verifiability: The objective is to ensure the Source Code does not contain statements and structures that cannot be verified and that the code does not have to be altered to test it.
d. 符合标准：目标是确保在代码开发过程中遵循软件编码标准，例如复杂性限制和编码约束。 复杂度包括软件组件之间的耦合程度、控制结构的嵌套级别以及逻辑或数值表达式的复杂度。 该分析还确保了对标准的偏差是合理的。Conformance to standards: The objective is to ensure that the Software Code Standards were followed during the development of the code, for example, complexity restrictions and code constraints. Complexity includes the degree of coupling between software components, the nesting levels for control structures, and the complexity of logical or numeric expressions. This analysis also ensures that deviations to the standards are justified.
e. 可追溯性：目标是确保低级需求开发成源码。Traceability: The objective is to ensure that the low-level requirements were developed into Source Code.
f. 准确性和一致性：目标是确定源码的正确性和一致性，包括堆栈使用情况、内存使用情况、定点算术溢出和分辨率、浮点算术、资源争用和限制、最坏情况执行时序、异常处理 、未初始化变量的使用、缓存管理、未使用的变量以及由于任务或中断冲突而导致的数据损坏。 编译器（包括其选项）、链接器（包括其选项）和某些硬件功能可能会对最坏情况下的执行时序产生影响，应评估这种影响。Accuracy and consistency: The objective is to determine the correctness and consistency of the Source Code, including stack usage, memory usage, fixed point arithmetic overflow and resolution, floating-point arithmetic, resource contention and limitations, worst-case execution timing, exception handling, use of uninitialized variables, cache management, unused variables, and data corruption due to task or interrupt conflicts. The compiler (including its options), the linker (including its options), and some hardware features may have an impact on the worst-case execution timing and this impact should be assessed.
6.3.5 集成过程输出的评审和分析 Reviews and Analyses of the Outputs of the Integration Process
这些评审和分析活动检测并报告集成过程中可能引入的错误。 目标是：
These review and analysis activities detect and report errors that may have been introduced during the integration process. The objective is to:
a. 确保集成过程的输出是完整且正确的。 活动包括对编译、链接和加载数据以及内存映射进行详细检查。 典型的潜在错误示例包括：Ensure that the outputs of the integration process are complete and correct. Activities include conducting a detailed examination of the compiling, linking and loading data, and memory map. Typical examples of potential errors include:
• 编译器告警。 Compiler warnings.
• 硬件地址不正确。 Incorrect hardware addresses.
• 踩内存 Memory overlaps.
• 缺少软件组件。 Missing software components.
6.4 软件测试 Software Testing
软件测试用于证明软件满足其要求，并以高度的可信度证明系统安全评估过程确定的可能导致不可接受的故障情况的错误已被消除。
Software testing is used to demonstrate that the software satisfies its requirements and to demonstrate with a high degree of confidence that errors that could lead to unacceptable failure conditions, as determined by the system safety assessment process, have been removed.
软件测试的目标是执行软件以确认：The objectives of software testing are to execute the software to confirm that:
a. 可执行目标码符合高级需求。The Executable Object Code complies with the high-level requirements.
b. 可执行目标码足够健壮，可以满足高级需求。The Executable Object Code is robust with the high-level requirements.
c. 可执行目标码符合低级需求。The Executable Object Code complies with the low-level requirements.
d. 可执行目标码具有健壮性，可满足低级需求。The Executable Object Code is robust with the low-level requirements.
e. 可执行目标码与目标计算机兼容。The Executable Object Code is compatible with the target computer.
图 6-1 是可用于实现软件测试目标的软件测试活动的图。 该图显示了三种类型的测试，它们是：
Figure 6-1 is a diagram of the software testing activities that may be used to achieve the software testing objectives. The diagram shows three types of testing, which are:
• 硬件/软件集成测试：验证软件在目标计算机环境中的正确运行。Hardware/software integration testing: To verify correct operation of the software in the target computer environment.
• 硬件/软件集成测试：验证软件在目标计算机环境中的正确运行。Software integration testing: To verify the interrelationships between software requirements and components and to verify the implementation of the software requirements and software components within the software architecture.
• 低级测试：验证低级需求的实现情况。Low-level testing: To verify the implementation of low-level requirements.
注：如果测试用例及其相应的测试过程是为软硬件集成测试或软件集成测试而开发和执行的，并且满足基于需求的覆盖率和结构覆盖率，则无需重复进行低级测试的测试 。 由于测试的总体功能量减少，用名义上等效的低级测试代替高级测试可能效果较差。
Note: If a test case and its corresponding test procedure are developed and executed for hardware/software integration testing or software integration testing, and satisfy the requirements-based coverage and structural coverage, it is not necessary to duplicate the test for low-level testing. Substituting nominally equivalent low-level tests for high-level tests may be less effective due to the reduced amount of overall functionality tested.
图 6-1 软件测试活动
Figure 6-1 Software Testing Activities
6.4.1 测试环境 Test Environment
可能需要多个测试环境来满足软件测试的目标。 优选的测试环境包括加载到目标计算机中并在与目标计算机环境的行为非常相似的环境中进行测试的软件。
More than one test environment may be needed to satisfy the objectives for software testing. A preferred test environment includes the software loaded into the target computer and tested in an environment that closely resembles the behavior of the target computer environment.
注意：在许多情况下，只有通过比完全集成环境中通常可能实现的测试输入和代码执行更精确的控制和监视，才能实现必要的基于需求的覆盖范围和结构覆盖范围。 此类测试可能需要在功能上与其他软件组件隔离的小型软件组件上执行。
Note: In many cases, the requirements-based coverage and structural coverage necessary can be achieved only with more precise control and monitoring of the test inputs and code execution than generally possible in a fully integrated environment. Such testing may need to be performed on a small software component that is functionally isolated from other software components.
使用目标计算机模拟器或主机模拟器完成的测试可以获得认证积分。 与测试环境相关的活动包括：
Certification credit may be given for testing done using a target computer emulator or a host computer simulator. Activities related to the test environment include:
a. 所选测试应在集成目标计算机环境中执行，因为某些错误仅在该环境中检测到。Selected tests should be performed in the integrated target computer environment, since some errors are only detected in this environment.
6.4.2 基于需求的测试选择 Requirements-Based Test Selection
强调基于需求的测试是因为这种策略被发现在揭示错误方面是最有效的。 基于需求的测试选择活动包括：
Requirements-based testing is emphasized because this strategy has been found to be the most effective at revealing errors. Activities for requirements-based test selection include:
1. 应开发具体的测试用例，包括正常范围测试用例和健壮性（异常范围）测试用例。Specific test cases should be developed to include normal range test cases and robustness (abnormal range) test cases.
2. 具体的测试用例应该根据软件需求和软件开发过程中固有的错误源来开发。The specific test cases should be developed from the software requirements and the error sources inherent in the software development processes.
注意：健壮性测试用例是基于需求的。 如果软件需求没有指定对异常条件和输入的正确软件响应，则无法完全满足健壮性测试标准。 测试用例可能会揭示软件需求的不足，在这种情况下，应该修改软件需求。 相反，如果存在涵盖所有异常条件和输入的完整需求集，则健壮性测试用例将从这些软件需求中得出。
Note: Robustness test cases are requirements-based. The robustness testing criteria cannot be fully satisfied if the software requirements do not specify the correct software response to abnormal conditions and inputs. The test cases may reveal inadequacies in the software requirements, in which case the software requirements should be modified. Conversely, if a complete set of requirements exists that covers all abnormal conditions and inputs, the robustness test cases will follow from those software requirements.
3. 测试程序是从测试用例生成的。Test procedures are generated from the test cases.
6.4.2.1 正常范围测试用例 Normal Range Test Cases
正常范围测试用例证明软件响应正常输入和条件的能力。 活动包括：
Normal range test cases demonstrate the ability of the software to respond to normal inputs and conditions. Activities include:
a. 实数和整数输入变量应使用有效的等价类和边界值来执行。Real and integer input variables should be exercised using valid equivalence classes and boundary values.
b. 对于与时间相关的函数，例如滤波器、积分器和延迟，应执行代码的多次迭代以检查上下文中函数的特性。For time-related functions, such as filters, integrators, and delays, multiple iterations of the code should be performed to check the characteristics of the function in context.
c. 对于状态转换，应开发测试用例来测试正常操作期间可能的转换。For state transitions, test cases should be developed to exercise the transitions possible during normal operation.
d. 对于用逻辑方程表达的软件需求，正常范围测试用例应该验证变量的使用和布尔运算符。For software requirements expressed by logic equations, the normal range test cases should verify the variable usage and the Boolean operators.
6.4.2.2 健壮性测试用例 Robustness Test Cases
健壮性测试用例证明了软件响应异常输入和条件的能力。 活动包括：
Robustness test cases demonstrate the ability of the software to respond to abnormal inputs and conditions. Activities include:
a. 实数和整数变量应使用无效值的等价类选择来执行。Real and integer variables should be exercised using equivalence class selection of invalid values.
b. 系统初始化应在异常情况下进行。System initialization should be exercised during abnormal conditions.
c. 应确定输入数据的可能故障模式，特别是来自外部系统的复杂数字数据字符串。The possible failure modes of the incoming data should be determined, especially complex, digital data strings from an external system.
d. 对于循环计数是计算值的循环，应开发测试用例来尝试计算超出范围的循环计数值，从而证明循环相关代码的健壮性。For loops where the loop count is a computed value, test cases should be developed to attempt to compute out-of-range loop count values, and thus demonstrate the robustness of the loop-related code.
e. 应进行针对超出帧时间的保护机制正确响应的检查。A check should be made to ensure that protection mechanisms for exceeded frame times respond correctly.
f. 对于与时间相关的功能，例如滤波器、积分器和延迟，应开发算术溢出保护机制的测试用例。For time-related functions, such as filters, integrators, and delays, test cases should be developed for arithmetic overflow protection mechanisms.
g. 对于状态转换，应开发测试用例以引发软件需求不允许的转换。For state transitions, test cases should be developed to provoke transitions that are not allowed by the software requirements.
6.4.3 基于需求的测试方法 Requirements-Based Testing Methods
本文讨论的基于需求的测试方法是基于需求的硬件/软件集成测试、基于需求的软件集成测试和基于需求的低级测试。 除了硬件/软件集成测试之外，这些方法没有规定特定的测试环境或策略。 活动包括：
The requirements-based testing methods discussed in this document are requirements-based hardware/software integration testing, requirements-based software integration testing, and requirements-based low-level testing. With the exception of hardware/software integration testing, these methods do not prescribe a specific test environment or strategy. Activities include:
a. 基于需求的硬件/软件集成测试：这种测试方法应该集中于与目标计算机环境中运行的软件相关的错误源以及高级功能。 基于需求的硬件/软件集成测试可确保目标计算机中的软件满足高级需求。 该测试方法揭示的典型错误包括：Requirements-Based Hardware/Software Integration Testing: This testing method should concentrate on error sources associated with the software operating within the target computer environment, and on the high-level functionality. Requirementsbased hardware/software integration testing ensures that the software in the target computer will satisfy the high-level requirements. Typical errors revealed by this testing method include:
• 中断处理不正确。Incorrect interrupt handling.
• 未能满足执行时间要求。Failure to satisfy execution time requirements.
• 软件对硬件瞬态或硬件故障的响应不正确，例如启动排序、瞬态输入负载和输入电源瞬态。Incorrect software response to hardware transients or hardware failures, for example, start-up sequencing, transient input loads, and input power transients.
• 数据总线和其他资源争用问题，例如内存映射。Data bus and other resource contention problems, for example, memory mapping.
• 内置测试无法检测故障。Inability of built-in test to detect failures.
• 硬件/软件接口错误。Errors in hardware/software interfaces.
• 控制循环的不正确行为。Incorrect behavior of control loops.
• 对内存管理硬件或软件控制下的其他硬件设备的控制不正确。Incorrect control of memory management hardware or other hardware devices under software control.
• 栈溢出.Stack overflow.
• 用于确认现场可加载软件的正确性和兼容性的机制操作错误。Incorrect operation of mechanism(s) used to confirm the correctness and compatibility of field-loadable software.
• 违反软件分区规定。Violations of software partitioning.
b. 基于需求的软件集成测试：这种测试方法应该集中于软件需求之间的相互关系以及软件架构对需求的实现。 基于需求的软件集成测试可确保软件组件之间正确交互并满足软件需求和软件架构。 该方法可以通过代码组件的连续集成以及测试用例范围的相应扩展来扩展需求范围来执行。 这种测试方法揭示的典型错误包括：Requirements-Based Software Integration Testing: This testing method should concentrate on the inter-relationships between the software requirements, and on the implementation of requirements by the software architecture. Requirements-based software integration testing ensures that the software components interact correctly with each other and satisfy the software requirements and software architecture. This method may be performed by expanding the scope of requirements through successive integration of code components with a corresponding expansion of the scope of the test cases. Typical errors revealed by this testing method include:
• 没有正确初始化的变量和常量。Incorrect initialization of variables and constants.
• 参数传递错误。Parameter passing errors.
• 数据损坏，尤其是全局数据。Data corruption, especially global data.
• 端到端数值分辨率不足。Inadequate end-to-end numerical resolution.
• 事件和操作的顺序不正确。Incorrect sequencing of events and operations.
c. 基于需求的低级测试：此测试方法应集中于证明每个软件组件都符合其低级需求。 基于需求的低级测试可确保软件组件满足其低级需求。 该测试方法揭示的典型错误包括：Requirements-Based Low-Level Testing: This testing method should concentrate on demonstrating that each software component complies with its low-level requirements. Requirements-based low-level testing ensures that the software components satisfy their low-level requirements. Typical errors revealed by this testing method include:
• 算法无法满足软件要求。Failure of an algorithm to satisfy a software requirement.
• 循环操作不正确。Incorrect loop operations.
• 错误的逻辑决策。Incorrect logic decisions.
• 未能正确处理输入条件的合理组合。Failure to process correctly legitimate combinations of input conditions.
• 对丢失或损坏的输入数据的响应不正确。Incorrect responses to missing or corrupted input data.
• 异常处理不正确，例如算术错误或违反数组限制。Incorrect handling of exceptions, such as arithmetic faults or violations of array limits.
• 计算顺序不正确。Incorrect computation sequence.
• 算法精度、准确性或性能不足。Inadequate algorithm precision, accuracy, or performance.
6.4.4 测试覆盖率分析 Test Coverage Analysis
测试覆盖率分析是一个包含基于需求的覆盖率分析和结构覆盖率分析的两步过程。 第一步根据软件需求分析测试用例，以确认所选测试用例满足指定的标准。 第二步确认基于需求的测试程序按照适用的覆盖标准执行了代码结构。 如果结构覆盖率分析显示未满足适用的覆盖率，则确定额外的活动来解决死代码等情况（见 6.4.4.3）
Test coverage analysis is a two step process involving requirements-based coverage analysis and structural coverage analysis. The first step analyzes the test cases in relation to the software requirements to confirm that the selected test cases satisfy the specified criteria. The second step confirms that the requirements-based test procedures exercised the code structure to the applicable coverage criteria. If the structural coverage analysis showed the applicable coverage was not met, additional activities are identified for resolution of such situations as dead code (see 6.4.4.3)
测试覆盖率分析的目标是：The objectives for test coverage analysis are:
a. 实现了高级需求的测试覆盖率。Test coverage of high-level requirements is achieved.
b. 实现了低级需求的测试覆盖率。Test coverage of low-level requirements is achieved.
c. 实现软件结构测试覆盖率达到适当的覆盖率标准。Test coverage of software structure to the appropriate coverage criteria is achieved.
d. 实现了软件结构的数据耦合和控制耦合的测试覆盖。Test coverage of software structure, both data coupling and control coupling, is achieved.
6.4.4.1 基于需求的测试覆盖率分析 Requirements-Based Test Coverage Analysis
此分析是为了确定基于需求的测试验证软件需求的实现的情况。 该分析可能揭示对额外的基于需求的测试用例的需求。 活动包括：This analysis is to determine how well the requirements-based testing verified the implementation of the software requirements. This analysis may reveal the need for additional requirements-based test cases. Activities include:
a. 使用关联的跟踪数据进行分析，以确认每个软件需求都存在测试用例。Analysis, using the associated Trace Data, to confirm that test cases exist for each software requirement.
b. 进行分析以确认测试用例满足第 6.4.2 节中定义的正常测试和健壮性测试的标准。Analysis to confirm that test cases satisfy the criteria of normal and robustness testing as defined in section 6.4.2.
c. 解决分析中发现的所有缺陷。 可能的解决方案是添加或增强测试用例。Resolution of any deficiencies identified in the analysis. Possible solutions are adding or enhancing test cases.
d. 进行分析以确认用于实现结构覆盖的所有测试用例以及所有测试程序都可追溯至需求。Analysis to confirm that all the test cases, and thus all the test procedures, used to achieve structural coverage, are traceable to requirements.
6.4.4.2 结构覆盖分析 Structural Coverage Analysis
该分析确定哪些代码结构（包括组件之间的接口）未被基于需求的测试过程执行。 基于需求的测试用例可能没有完全运用包括接口在内的代码结构，因此需要进行结构覆盖分析并产生额外的验证以提供结构覆盖。 活动包括：This analysis determines which code structure, including interfaces between components, was not exercised by the requirements-based test procedures. The requirements-based test cases may not have completely exercised the code structure, including interfaces, so structural coverage analysis is performed and additional verification produced to provide structural coverage. Activities include:
a. 分析基于需求的测试过程中收集的结构覆盖信息，以确认结构覆盖程度适合软件级别。Analysis of the structural coverage information collected during requirements-based testing to confirm that the degree of structural coverage is appropriate to the software level.
b. 结构覆盖分析可以在源代码、目标代码或可执行目标码上执行。 与执行结构覆盖分析的代码形式无关，如果软件级别为 A，并且编译器、链接器或其他方式生成了无法直接追溯到源代码语句的附加代码，则应执行附加验证来确定 这种生成的代码序列的正确性。Structural coverage analysis may be performed on the Source Code, object code, or Executable Object Code. Independent of the code form on which the structural coverage analysis is performed, if the software level is A and a compiler, linker, or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences.
注意：“无法直接追溯到源代码语句的附加代码”是指引入在源代码级别不会立即显现的分支或副作用的代码。 这意味着，例如，出于结构覆盖分析的目的，编译器生成的数组绑定检查不被认为可以直接追溯到源代码语句，而应接受额外的验证。
Note: “Additional code that is not directly traceable to Source Code statements” is code that introduces branches or side effects that are not immediately apparent at the Source Code level. This means that compiler-generated array-bound checks, for example, are not considered to be directly traceable to Source Code statements for the purposes of structural coverage analysis, and should be subjected to additional verification.
c. 进行分析以确认基于需求的测试已经实现了代码组件之间的数据和控制耦合。Analysis to confirm that the requirements-based testing has exercised the data and control coupling between code components.
d. 结构覆盖分析分辨率（见6.4.4.3）。Structural coverage analysis resolution (see 6.4.4.3).
6.4.4.3 结构覆盖分析分辨率 Structural Coverage Analysis Resolution
结构覆盖分析可以揭示代码结构，包括测试期间未使用的接口。 解决方案将需要额外的软件验证过程活动。 未执行的代码结构（包括接口）以及解决这些问题的相关活动的原因包括：Structural coverage analysis may reveal code structure including interfaces that were not exercised during testing. Resolution will require additional software verification process activity. Causes of unexecuted code structure including interfaces, and associated activities to resolve them include:
a. 基于需求的测试用例或过程的缺点：应增加测试用例或更改测试过程以提供缺失的覆盖范围。 用于执行基于需求的覆盖率分析的方法可能需要进行审查。Shortcomings in requirements-based test cases or procedures: The test cases should be augmented or test procedures changed to provide the missing coverage. The method(s) used to perform the requirements-based coverage analysis may need to be reviewed.
b. 软件需求的不足：应修改软件需求并开发附加测试用例并执行测试程序。Inadequacies in software requirements: The software requirements should be modified and additional test cases developed and test procedures executed.
c. 无关代码，包括无效代码：应删除代码并进行分析以评估效果和重新验证的必要性。 如果在源代码或目标码级别发现无关代码，则仅当分析表明可执行目标码中不存在该代码时才允许保留该代码（例如，由于智能编译、链接或某些其他机制）， 并已制定程序以防止包含在未来的构建中。Extraneous code, including dead code: The code should be removed and an analysis performed to assess the effect and the need for reverification. If extraneous code is found at the Source Code or object code level, it may be allowed to remain only if analysis shows it does not exist in the Executable Object Code (for example, due to smart compiling, linking, or some other mechanism), and procedures are in place to prevent inclusion in future builds.
d. 停用的代码：停用的代码应以两种方式之一进行处理，具体取决于其定义的类别：Deactivated code: Deactivated code should be handled in one of two ways, depending upon its defined category:
1. 第一类：停用的代码，不打算在任何认证产品中使用的任何当前配置中执行。 对于这一类别，分析和测试的结合应该表明可以防止、隔离或消除可能无意中执行停用代码的方式。 对一类停用代码的软件级别的任何重新分配都应通过系统安全评估过程来证明合理，并记录在软件方面的认证计划中。 同样，对一类停用代码的软件验证过程的任何减轻都应由软件开发过程证明是合理的，并记录在软件方面的认证计划中。Category One: Deactivated code that is not intended to be executed in any current configuration used within any certified product. For this category, a combination of analysis and testing should show that the means by which the deactivated code could be inadvertently executed are prevented, isolated, or eliminated. Any reassignment of the software level for Category One deactivated code should be justified by the system safety assessment process and documented in the Plan for Software Aspects of Certification. Similarly, any alleviation of the software verification process for Category One deactivated code should be justified by the software development processes and documented in the Plan for Software Aspects of Certification.
2. 第二类：仅在目标计算机环境的某些批准配置中执行的停用代码。 应建立正常执行此代码所需的操作配置，并开发额外的测试用例和测试过程以满足所需的覆盖目标。Category Two: Deactivated code that is only executed in certain approved configurations of the target computer environment. The operational configuration needed for normal execution of this code should be established and additional test cases and test procedures developed to satisfy the required coverage objectives.
6.4.5 测试用例、过程和结果的审查和分析Reviews and Analyses of Test Cases, Procedures, and Results
这些审查和分析活动确认软件测试满足以下目标：These review and analysis activities confirm that the software testing satisfies these objectives:
a. 测试用例：第 6.4.4.a 和 6.4.4.b 节介绍了与测试用例验证相关的目标。Test cases: The objectives related to verification of test cases are presented in sections 6.4.4.a and 6.4.4.b.
b. 测试程序：目的是验证测试用例（包括预期结果）是否已正确开发为测试程序。Test procedures: The objective is to verify that the test cases, including expected results, were correctly developed into test procedures.
c. 测试结果：目的是确保测试结果正确，并解释实际结果与预期结果之间的差异。Test results: The objective is to ensure that the test results are correct and that discrepancies between actual and expected results are explained.
6.5 软件验证过程的可追溯性 Software Verification Process Traceability
软件验证过程可追溯活动包括：Software verification process traceability activities include:
a. 开发了跟踪数据，显示软件需求和测试用例之间的双向关联。 此跟踪数据支持基于需求的测试覆盖率分析。Trace Data, showing the bi-directional association between software requirements and test cases, is developed. This Trace Data supports the requirements-based test coverage analysis.
b. 开发了显示软件需求和测试用例之间双向关联的追踪数据。 该追踪数据支持基于需求的测试覆盖率分析。Trace Data, showing the bi-directional association between test cases and test procedures, is developed. This Trace Data enables verification that the complete set of test cases has been developed into test procedures.
c. 开发了显示测试过程和测试结果之间双向关联的跟踪数据。 该跟踪数据能够验证整套测试程序是否已执行。Trace Data, showing the bi-directional association between test procedures and test results, is developed. This Trace Data enables verification that the complete set of test procedures has been executed.
6.6 参数数据项的验证 Verification of Parameter Data Items
如果满足以下所有条件，则参数数据项的验证可以与可执行目标码的验证分开进行：
Verification of a parameter data item can be conducted separately from the verification of the Executable Object Code if all of the following apply:
• 可执行目标码已通过正常范围测试进行开发和验证，以正确处理符合其定义的结构和属性的所有参数数据项文件。The Executable Object Code has been developed and verified by normal range testing to correctly handle all Parameter Data Item Files that comply with their defined structure and attributes.
• 可执行目标码在参数数据项文件结构和属性方面是健壮的。The Executable Object Code is robust with respect to Parameter Data Item Files structures and attributes.
• 由参数数据项文件的内容产生的可执行目标码的所有行为都可以被验证。All behavior of the Executable Object Code resulting from the contents of the Parameter Data Item File can be verified.
• 生命周期数据的结构允许对参数数据项进行单独管理。The structure of the life cycle data allows the parameter data item to be managed separately.
除非满足上述所有条件，否则参数数据项不应与软件的其余部分分开进行验证。 在这种情况下，可执行目标码和参数数据项文件应一起验证。Unless all conditions above are met, parameter data items should not be verified separately from the rest of the software. In this case, the Executable Object Code and the Parameter Data Item Files should be verified together.
对于可以与可执行目标码的验证分开验证的参数数据项，适用以下确定的目标。 以下目标可以通过测试、分析和评审的结合来实现。For parameter data items that can be verified separately from verification of the Executable Object Code, the objectives identified below apply. The objectives below may be achieved by a combination of tests, analyses, and reviews.
a. 应验证参数数据项文件是否符合高级需求定义的结构； 该验证包括确保参数数据项文件不包含高级需求未定义的任何元素。 参数数据项文件中的每个数据元素还应显示为具有正确的值，与其他数据元素一致，并符合高级需求定义的其属性。The Parameter Data Item File should be verified to comply with its structure as defined by the high-level requirements; this verification includes ensuring that the Parameter Data Item File does not contain any elements not defined by the high-level requirements. Each data element in the Parameter Data Item File should also be shown to have the correct value, to be consistent with other data elements, and to comply with its attributes as defined by the high-level requirements.
注意：对于某些数据元素，它们的属性可能是唯一需要验证的方面。 在其他情况下，数据元素的值可能需要验证。
Note: For certain data elements, their attributes may be the only aspect that needs to be verified. In other cases, the value of the data element may need to be verified.
b. 验证过程中已涵盖参数数据项文件的所有元素。All elements of the Parameter Data Item File have been covered during verification.
如果参数数据项的结构或属性发生改变，则应分析是否需要修改和重新验证可执行目标码。If changes are made to the structure or attributes of the parameter data item, then the need for modification and reverification of the Executable Object Code should be analyzed.
1113
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
