Automatic testing method and device for airborne controller, computer equipment and medium

Abstract

The embodiment of the invention provides an automatic testing method and device for an airborne controller, computer equipment and a medium, and the method comprises the following steps: creating and starting a Docker container instance based on a Docker mirror image, deploying a container instance, and constructing an automatic testing environment through the Docker container instance; analyzing the test configuration file through the test management component, obtaining a test case list from the test configuration file, generating a test program execution file and starting an automatic test environment; and executing all the test cases through the test management component until all the test cases are executed, and generating a test result report and a structure coverage rate verification report according to the test type of the test configuration file and the generated result file set. According to the scheme, the test management component, the virtual target board component, the target board test agent and the test control protocol stack are integrated into the single container instance, so that one-key deployment of the test environment is realized.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and in particular to an automated testing method, apparatus, computer equipment, and medium for airborne controllers. Background Technology

[0002] As a core component of the aircraft control system, the correctness and reliability of the airborne controller software directly affect flight safety, thus requiring extensive testing to ensure safety and reliability. With the increasing complexity and scale of airborne software functions, the workload of software testing has increased dramatically, placing higher demands on automated software testing frameworks. More importantly, the development process of aircraft airborne software must adhere to airworthiness standards such as DO-178C. This standard requires establishing a traceable chain from software requirements and test cases to test results, and completing source code coverage and object code coverage analysis to demonstrate the adequacy of software verification.

[0003] Traditional automated testing frameworks generally employ a host machine plus a physical target board or simulation board testing architecture, which has the following inherent drawbacks: First, the test environment deployment is rigid, with severely insufficient resource scalability and flexibility. Test execution heavily relies on specific physical target board hardware or simulation boards, requiring cumbersome physical connections and manual configuration for deployment, resulting in long preparation cycles. More significantly, a single physical environment typically only supports a single target board model, causing the test system to be "hardware-bound" and making it difficult to quickly adapt to multiple test scenarios. Furthermore, the scale of automated testing is limited by the expensive and limited number of physical boards, and multiple test tasks are prone to resource contention, leading to test queue congestion and poor overall system scalability.

[0004] Secondly, the testing iteration process is lengthy and inefficient. In terms of testing methodologies, existing technologies typically require compiling the test program along with the onboard system software and then embedding it into the target board image. This means that any minor modification to a test case must undergo a complete process of "modifying code -> recompiling the entire system image -> re-flashing -> restarting the environment," with iteration cycles often lasting several hours. This is unsuitable for the pace of rapid development and verification, significantly slowing down software delivery.

[0005] Third, the testing process suffers from low automation and reliability. The host machine and target board are typically connected via peripherals such as serial ports or JTAG. These physical links are susceptible to interference, have low transmission rates, and poor stability. When transmitting large amounts of test data or executing long-term tests, the risk of communication interruption is high, severely impacting the efficiency and reliability of automated testing. Furthermore, the lack of a comprehensive automated solution covering test deployment, test case distribution, execution monitoring, and result collection means that significant manual intervention is required during the testing process, making it difficult to establish a standardized management loop.

[0006] Fourth, the lack of native support for aviation airworthiness standards makes the generation of certification materials difficult. Existing testing tools, including some virtualization solutions, generally lack native automated support for the core verification requirements of the DO-178C standard (such as requirement traceability chains and coverage analysis). The traceability relationship between test cases and software requirements usually relies on manually maintained documents or tables, which are prone to errors and difficult to maintain. At the same time, it is impossible to automatically generate compliant source code coverage and target code coverage reports. This part of the work often requires manual completion using additional, non-integrated tools, which is cumbersome and makes it difficult to guarantee the credibility and consistency of evidence, becoming one of the main bottlenecks in the certification of airborne software.

[0007] In summary, existing technical solutions, whether traditional physical test architectures or emerging virtualization solutions, are simply combinations of general-purpose tools, lacking in-depth integration and systematic solutions to address the specific testing needs of airborne controllers in terms of architectural diversity, real-time performance, high reliability, and airworthiness compliance. Therefore, there is an urgent need for an innovative solution to overcome the fundamental bottlenecks of traditional test architectures in terms of efficiency, cost, flexibility, and compliance. Summary of the Invention

[0008] In view of this, embodiments of the present invention provide an automated testing method for airborne controllers to address the technical problem of the lack of in-depth integration and systematic solutions for the special testing requirements of airborne controllers in terms of architectural diversity, real-time performance, high reliability, and airworthiness compliance in the prior art. The method includes: Build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated testing environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. The test management component parses the test configuration file, obtains the test case list from the test configuration file, generates the test program executable file, and starts the automated test environment. The test management component executes all test cases in the test case list sequentially until all test cases have been executed, generating a set of test case result files. Based on the test type in the test configuration file and the set of result files, a test result report and a structure coverage verification report are generated.

[0009] This invention also provides an automated testing device for airborne controllers, addressing the technical problem of the lack of in-depth integration and systematic solutions for the specific testing requirements of airborne controllers in terms of architectural diversity, real-time performance, high reliability, and airworthiness compliance in existing technologies. The device includes: A test environment building module is used to build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated test environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. The automated testing module is used to parse the test configuration file through the test management component, obtain the test case list from the test configuration file, generate the test program executable file, and start the automated testing environment. The report generation module is used to execute all test cases in the test case list sequentially through the test management component until all test cases have been executed, generate a set of test case result files, and generate a test result report and a structure coverage verification report based on the test type in the test configuration file and the set of result files.

[0010] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned automated testing methods for airborne controllers, thereby solving the technical problem in the prior art of lacking in-depth integration and systematic solutions to the special testing requirements of airborne controllers in terms of architectural diversity, real-time performance, high reliability, and airworthiness compliance.

[0011] This invention also provides a computer-readable storage medium storing a computer program that executes any of the above-described automated testing methods for airborne controllers, in order to solve the technical problem in the prior art of lacking in-depth integration and systematic solutions to the special testing requirements of airborne controllers in terms of architectural diversity, real-time performance, high reliability, and airworthiness compliance.

[0012] Compared with the prior art, the beneficial effects that at least one technical solution adopted in the embodiments of this specification can achieve include at least: It enables one-click deployment of the test environment, dynamic loading and isolated execution of test programs, and automated testing through the communication protocol stack of the test control protocol stack. It can automatically generate coverage analysis reports and solve the technical bottlenecks of traditional test frameworks in terms of deployment efficiency, test iteration, communication reliability and compliance verification. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of an automated testing method for airborne controllers provided in an embodiment of the present invention; Figure 2 This is a functional framework diagram of an embodiment of the automated testing method for airborne controllers provided by the present invention; Figure 3 This is a flowchart illustrating an automated testing method for airborne controllers provided in an embodiment of the present invention; Figure 4 This is a structural block diagram of a computer device provided in an embodiment of the present invention; Figure 5 This is a structural block diagram of an automated testing device for airborne controllers provided in an embodiment of the present invention. Detailed Implementation

[0015] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0016] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] The terminology is defined as follows: DO-178C, the Aircraft Software Airworthiness Certification Standard, is officially titled "Software Considerations in the Certification of Airborne Systems and Equipment".

[0018] QEMU is an open-source processor emulator capable of emulating various processor architectures.

[0019] Docker, a containerization technology, enables applications and their dependencies to be packaged into a portable container.

[0020] Addressing the core issues of existing testing frameworks, such as their inability to quickly deploy with a single click, their inability to dynamically load and isolate test programs, their lack of dedicated test communication mechanisms, and their lack of built-in automatic generation capabilities for airworthiness certification evidence, this paper provides a highly integrated, efficient, flexible, and natively DO-178C compliance verification-enabled automated testing framework and method for airborne controllers. Figure 2 As shown, this framework integrates four core modules into a single Docker container, enabling not only one-click deployment of the test environment in seconds and dynamic loading and isolated execution of test programs, but also full automation of reliable transmission of test programs, precise control of instructions, and real-time feedback of results through a dedicated communication protocol stack. Furthermore, it has built-in capabilities for automatically generating requirement traceability chains and coverage analysis reports, thus solving the technical bottlenecks of traditional test frameworks in terms of deployment efficiency, test iteration, communication reliability, and compliance verification.

[0021] In this embodiment of the invention, an automated testing method for airborne controllers is provided, such as... Figure 1 and Figure 3 As shown, the method includes: Step S101: Build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated testing environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. Step S102: The test management component parses the test configuration file, obtains the test case list from the test configuration file, generates the test program executable file, and starts the automated test environment; Step S103: Through the test management component, execute all test cases in the test case list in sequence until all test cases have been executed, generate a result file set of test cases, and generate a test result report and a structure coverage verification report according to the test type of the test configuration file and the result file set.

[0022] In practice, the following steps are used to build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated testing environment using the Docker container instance: Select a cross-compilation toolchain for the architecture type of the virtual target board; integrate the pre-configured QEMU emulator, Python runtime environment, coverage data collection dynamic library, the cross-compilation toolchain, the configuration file of the virtual target board, and the base image into a Docker image; create and start the Docker container instance based on the Docker image, and obtain the test management component, the target board test agent, the test configuration file, and the test control protocol stack of the test management component from a remote repository; deploy the test management component, the target board test agent, the test configuration file, and the test control protocol stack into the Docker container instance.

[0023] In specific implementation, the following steps are used to parse the test configuration file through the test management component, obtain the test case list from the test configuration file, generate the test program executable file, and start the automated test environment: The test management component parses the test configuration file to obtain the target board model, test case list, software under test information, and test type for this test. Based on the test case list, it downloads the corresponding test program source code and the software under test image from a remote repository. According to the target board model, it selects the corresponding cross-compilation toolchain and compiles it to generate the test program executable file for the current virtual target board. Finally, it starts the test control protocol stack service of the test management component, listening on the specified port.

[0024] In practice, the following steps are used to execute all test cases in the test case list sequentially through the test management component, generating a set of test result files: The test cases in the test case list are executed sequentially until all test cases have been executed. A Ping message is sent to the target board test agent via the test control protocol stack. If no response message is received within a set time, the communication link is not connected, execution is terminated, and an error is reported. If a response message is received, the test program execution file is transmitted in chunks to the target board test agent via a Data message. The target board test agent stores the data blocks of the test program execution file in the memory area of ​​the virtual target board. If any Data message transmission fails, execution is terminated and an error is reported. After the test program execution file is uploaded, the test management component sends an instruction message to notify the test agent to execute the test program execution file. The target board test agent loads the received test program execution file into a text segment, dynamically loading the test program execution file through the text segment. If an abnormal situation occurs, execution is terminated and an error is reported. After the test program execution file is completed, the target board test agent sends the information of the memory area to the test management component via a Text message. After receiving the Text message, the test management component records the test results in a test result file set.

[0025] In practice, the following steps are used to generate a test result report and a structure coverage verification report based on the test type in the test configuration file and the result file set: Based on the integrated result file set, the test management component automatically generates a test result report, which includes a mapping relationship between requirements and test cases, test results, and a requirement traceability matrix. The requirement traceability matrix is ​​used to characterize the coverage of requirements. A dynamic library instruction address record file is generated through coverage collection. The test management component constructs a structural coverage verification report that meets aviation airworthiness standards, which includes a target code coverage verification report and a source code coverage verification report. Instruction address data in the instruction address record file is read. When the test type is target code coverage testing, based on the instruction address data and the memory mapping file of the software under test, the coverage of each CPU instruction of the software under test is analyzed, the target code coverage is calculated, and a target code coverage verification report is generated according to the target code coverage verification standard. When the test type is source code coverage testing, based on the instruction address data and the mapping relationship between the instruction address data and the source code, the execution status of each source code instruction is analyzed, the source code coverage is calculated, and a source code coverage verification report is generated according to the source code coverage verification standard.

[0026] In practice, the following steps are used to collect instruction address log files from dynamic libraries based on coverage: During test execution, the CPU instruction execution status of the software under test is monitored by the dynamic library through the coverage, and the instruction address data of each executed CPU instruction is recorded; the instruction address data is saved to the instruction address record file of the Docker container instance.

[0027] In practice, the following steps are used to build a requirement coverage verification standard that meets aviation airworthiness standards through the test management component: The test management component generates a requirement traceability matrix that meets aviation airworthiness standards. This requirement traceability matrix is ​​used as a requirement coverage verification standard. The requirement traceability matrix is ​​used to store the complete mapping relationship between software requirements and test cases. During test execution, the test management component records the verification results of each test case and its corresponding software requirements, and updates the requirement traceability matrix with the verification results.

[0028] Specifically, this embodiment of the invention integrates and deploys four core components—the test management component, the virtual target board component, the target board test agent, and the test control protocol stack—within the same Docker container instance. These components communicate efficiently through the container's internal network, forming a complete and portable test unit. Through the deep integration and collaborative work of these four core components, this framework constructs a complete airborne controller virtualization test environment, achieving second-level deployment of the test environment, dynamic loading of test programs, dedicated and reliable test communication, and automated airworthiness compliance verification. The composition and functions of the four core components are as follows: 1. Test Management Component: Serving as the central control center of the framework, this component manages test cases and test program files, compiles and generates test program executables, launches the virtual target board and loads the software under test, communicates with the target board test agent via the test control protocol stack, distributes test program executables to the virtual target board, sends test control commands to execute the test program, and receives and parses test results. Building upon this foundation, this module deeply integrates the core requirements of the DO-178C airworthiness standard. Through its built-in requirement traceability management function, it generates a requirement traceability matrix compliant with the DO-178C standard and automatically establishes and maintains a complete mapping relationship between software requirements and test cases. During test execution, the module automatically records the verification results of each test case and its corresponding requirement, achieving automatic statistics on requirement coverage and automatic generation of traceability chains. Simultaneously, this module integrates coverage analysis tools, which can automatically generate source code coverage verification reports and target code coverage verification reports compliant with the DO-178C standard based on the collected coverage data, completely resolving the technical bottlenecks of traditional testing tools in the preparation of airworthiness certification materials.

[0029] 2. Virtual Target Board Component: Based on the QEMU emulator, this module rapidly instantiates a controller simulation instance identical to the real hardware environment using a pre-built airborne controller base image. The key to this module is its precise replacement of physical hardware. Its core capability is the ability to simulate various typical airborne processor architectures such as PowerPC, ARM, and DSP, thus providing a highly simulated operating environment for the software under test. Through this module, the framework achieves lightweight, second-level generation, and on-demand destruction of the target under test, completely solving the bottleneck problem of test environment deployment. Simultaneously, this invention also developed a coverage collection dynamic library, which can be selectively loaded according to test requirements when the virtual target board starts. This coverage collection dynamic library monitors the CPU instruction execution of the software under test, records the address data of each executed CPU instruction, and stores the address data in a coverage data file in a designated directory of the container. After the test is completed, the test management component will automatically generate a target code coverage verification report based on the instruction address data in the file and the memory mapping file of the software under test. Through the mapping relationship between instruction addresses and source code, a source code coverage verification report can also be generated, providing a complete chain of coverage evidence for DO-178C compliance verification.

[0030] 3. Target Board Test Agent: As a resident service program, it runs in each simulation controller environment created by the virtual target board component. Its core function is to listen for and receive test program executable files and test control commands through the test control protocol stack, and to realize the dynamic loading and execution of test programs. That is, without restarting the virtual target board, it can load the received test program executable file into memory and run it, execute test control commands, monitor the test process, collect result data, and send the test results back to the test management component through the test control protocol stack.

[0031] 4. Test Control Protocol Stack: This embodiment of the invention defines a lightweight and reliable application-layer communication protocol that runs on the container's internal network. The protocol stack adopts a bidirectional communication architecture, constructing a dedicated test communication mechanism to achieve reliable transmission of test program files, precise control of test commands, and structured feedback of test results. The message frame structure of this protocol stack includes: message header (8 bits), message type (8 bits), message payload (variable length), CRC checksum (32 bits), and message trailer (8 bits). The protocol stack mainly defines five message types: Ping messages for network status detection; command messages for sending commands to the target controller to execute specific operations, such as setting running parameters or running test programs; data messages for transmitting test program executable files; text messages for transmitting test results; and response messages for responding to other messages (ACK for normal response, NACK for abnormal response). This protocol stack is specifically customized for the test process, constructing a dedicated test communication mechanism to achieve reliable transmission of test program files, precise control of test commands, and structured feedback of test results. The protocol stack consists of two distinct implementations: the test management component-side protocol stack, used by the test management component to send network status detection messages, command messages, and executable test programs to the target board, while also receiving response messages and test results from the target board; and the target board-side protocol stack, used by the test agent to listen on the port, receive network status detection messages, command messages, and executable test program files, while also sending response messages and test results to the test management component.

[0032] Specifically, the coverage data collection dynamic library is a dynamic link library used in this embodiment of the invention for collecting code execution coverage data.

[0033] Specifically, the test control protocol stack is a custom communication protocol defined in this embodiment of the invention, used for test control and data transmission between the host machine and the target board.

[0034] Specifically, the automated testing method for airborne controllers includes the following steps: Step 1: Docker instance deployment and environment preparation.

[0035] On the server, a Docker instance is created and started based on a pre-built dedicated Docker image. This dedicated image integrates all the core dependencies of this testing framework, including: a pre-configured QEMU emulator, a Python runtime environment, a coverage collection dynamic library, cross-compilation toolchains for different target board architectures, configuration files for various virtual target boards, and base images. After the instance starts, it automatically pulls the test management component (including coverage analysis tools), the source code and test configuration files of the target board test agent module, and the pre-compiled communication protocol stack (test control protocol stack) software of the test management component from a remote repository and deploys them in a specific working directory within the container. Through this step, one-click environment preparation and isolated deployment of the testing framework are achieved. Step 2: Parse the test configuration file.

[0036] The test management component parses the test configuration file, which specifies the target board model, test case list, software under test information, and test type. After parsing, it downloads the corresponding test program source code and software under test image from the remote repository based on the test case list. It dynamically selects the appropriate cross-compilation toolchain based on the target board model, compiles and generates the test program executable file for that target board, and simultaneously compiles and generates the target board test proxy module executable file that matches the target board architecture. Finally, it starts the communication protocol stack service on the test management component side, listening on the specified port.

[0037] Step 3: Start the virtual environment and load the components.

[0038] Based on the test configuration, the test management component selects the corresponding virtual target board configuration file and drives the QEMU emulator to instantiate a simulation environment for the specific airborne controller model. The base image, the software under test (DUT), and the compiled executable file of the target board test agent module are loaded into the simulation environment. This test agent module embeds a communication protocol stack serving the target board. Upon startup, it automatically loads the communication protocol stack service and listens on the specified port to establish a communication connection with the test management component. When the test configuration file specifies coverage analysis as the test type, the virtual target board will automatically load a coverage collection dynamic library during startup. This library is used to collect DUT instruction execution data in real time during test execution for subsequent coverage analysis. This step enables rapid adaptation to multiple target board models, solving the "hardware binding" problem of traditional solutions.

[0039] Step 4: Test case execution and result collection.

[0040] The test management component executes all test cases in the test list sequentially, as follows: Step 4.1: Communication link detection.

[0041] Before executing each test case, a Ping message is first sent to the target board test agent via the test control protocol stack to check the communication link connectivity. If no response message is received within the set time, it is determined that there is a network connection error, the test case execution fails and exits.

[0042] Step 4.2: Test program transmission.

[0043] Once the communication link is established, the test program execution file is transmitted in chunks to the target board test agent via Data messages. The target board test agent stores the received data blocks in a pre-allocated memory area on the virtual target board. Each Data message transmission requires an acknowledgment response to ensure transmission reliability. If a transmission failure occurs, the process is immediately terminated and an error is reported.

[0044] Step 4.3: Dynamically load and execute.

[0045] After the test program is uploaded, a command message is sent to notify the test agent to execute the program. The test agent loads the received test program executable file into the text segment (code area) and dynamically loads and executes it by directly jumping to the code segment entry address, without needing to restart the simulation system or re-flash the image. During the execution of the test program, execution information and result data are written to a pre-allocated memory area on the target board in real time. After the program completes execution, the test agent reads the complete execution information and result data from this memory area and sends it to the test management component via a Text message. The test agent monitors the system status in real time during execution, and if any abnormality occurs, it immediately reports the test execution exception to the test management component via a NACK message.

[0046] Step 4.4: Execution result collection and test result recording.

[0047] Upon receiving a Text message, the test management component records the test results in a separate test result file according to a predefined format. Each test case corresponds to a test result file, containing the test case name, requirement number, module under test, function under test, execution result, expected output information, and actual output information. This structured recording mechanism is deeply integrated with the DO-178C requirement traceability function built into the test management component: the recorded requirement number serves as the core index, directly driving the automated construction of the requirement traceability matrix; based on this traceability matrix, the system can accurately establish a complete mapping relationship between each test case and its corresponding software requirement item; detailed execution results provide direct evidence for the automatic determination of requirement verification status, supporting accurate statistics of requirement coverage; and complete comparison information between expected and actual outputs provides an auditable and reproducible objective chain of evidence for the verification conclusions of each requirement, fully meeting the DO-178C requirements for objective evidence in the verification process.

[0048] Repeat the above process until all test cases have been executed. This rigorous closed-loop test execution and result recording mechanism not only technically ensures the controllability of each test case execution process and the reliability of the results, but more importantly, it systematically constructs the complete set of underlying data required to generate final compliance evidence. These structured and standardized record files directly serve as input for the test management component to automatically generate comprehensive test verification and requirement coverage reports, ensuring seamless integration and high automation from initial test execution to final compliance document output. This completely solves the bottleneck problems of traditional methods that rely on manual processing, are prone to errors, and are inefficient in this stage.

[0049] This step addresses the problems of unreliable traditional communication links and low testing iteration efficiency by using a dedicated communication protocol stack and dynamic loading technology.

[0050] Step 5: Generate and upload the test report.

[0051] Step 5.1: Integrate test results.

[0052] The management module reads the test result files of all test cases, uses the previously recorded requirement numbers as the core index, and organizes them hierarchically according to the requirement numbers. Lower-level requirements belonging to the same high-level requirement are categorized and integrated, and the execution status of corresponding test cases under the same lower-level requirement is summarized. Based on the exact mapping relationship between test cases and requirement items, a complete DO-178C requirement hierarchy verification structure is constructed.

[0053] Step 5.2: Test verification and requirements coverage integration (test result report) generation.

[0054] Based on the integrated test data and leveraging the built-in requirement traceability management function of the test management module, a comprehensive report is automatically generated, containing a complete mapping relationship between requirements and test cases, as well as detailed test results. This report not only fully presents the execution results of all test cases but also clearly demonstrates requirement coverage through a requirement traceability matrix. The report includes core information such as the module under test, the function under test, the test case name, the high-level requirement number, the low-level requirement number, and the execution result, systematically linking test verification results with requirement coverage status. For test cases that fail to execute, additional comparison information between expected and actual output is recorded. Combined with the complete verification evidence chain collected in the early stages, a comprehensive test verification and requirement coverage report that meets airworthiness review requirements is formed. Finally, the complete report is output as an HTML file.

[0055] Step 5.3: Generate the structural coverage report.

[0056] Based on the test type in the test configuration file, perform the corresponding coverage analysis: When the test type is target code coverage test, the coverage analysis and processing function is invoked to read the instruction address record file generated by the coverage collection dynamic library, and combined with the memory mapping file of the software under test, the coverage of each CPU instruction of the software under test is analyzed, the target code coverage is automatically calculated, and a detailed coverage analysis table is generated according to the DO-178C target code coverage verification standard and output as an HTML report.

[0057] When the test type is source code coverage test, the coverage analysis and processing function is invoked. Based on the coverage rate, the instruction address data recorded by the dynamic library is collected. Through the mapping relationship between instruction address and source code, the execution status of each source code is accurately analyzed, the source code coverage rate is automatically calculated, and a detailed coverage analysis table is generated according to the DO-178C source code coverage verification standard and output as an HTML report.

[0058] Step 5.4, Report Upload and Display.

[0059] All generated test report files (including requirements traceability reports and coverage reports) are automatically uploaded to the designated server and provided to testers in web page format. Testers can directly access the test results through a browser, enabling instant sharing and visualization of the test results.

[0060] This step automates the organization, analysis, and report generation of test results, ensuring the complete traceability of the testing process. It solves the problems of traditional solutions lacking native support for airworthiness standards and difficulties in generating certification materials, while providing testers with an intuitive and convenient way to view results.

[0061] In this embodiment, a computer device is provided, such as... Figure 4 As shown, it includes a memory 401, a processor 402, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described automated testing methods for airborne controllers.

[0062] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0063] In this embodiment, a computer-readable storage medium is provided, which stores a computer program that executes any of the above-described automated testing methods for airborne controllers.

[0064] Specifically, computer-readable storage media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media do not include transient media, such as modulated data signals and carrier waves.

[0065] Based on the same inventive concept, this invention also provides an automated testing apparatus for airborne controllers, as described in the following embodiments. Since the principle behind the problem-solving of the automated testing apparatus for airborne controllers is similar to that of the automated testing method for airborne controllers, the implementation of the automated testing apparatus for airborne controllers can refer to the implementation of the automated testing method for airborne controllers, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0066] Figure 5 This is a structural block diagram of an automated testing device for airborne controllers according to an embodiment of the present invention, such as... Figure 5 As shown, it includes: a test environment building module 501, an automated test execution module 502, and a report generation module 503. The structure is described below.

[0067] The test environment building module 501 is used to build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated test environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. The automated testing module 502 is used to parse the test configuration file through the test management component, obtain the test case list from the test configuration file, generate the test program executable file, and start the automated testing environment. The report generation module 503 is used to execute all test cases in the test case list sequentially through the test management component until all test cases have been executed, generate a set of test case result files, and generate a test result report and a structure coverage verification report according to the test type of the test configuration file and the set of result files.

[0068] In one embodiment, building a test environment module includes: The Docker image integration unit is used to integrate the pre-configured QEMU emulator, Python runtime environment, coverage data collection dynamic library, cross-compilation toolchain, configuration file of the virtual target board and base image into a Docker image; The component unit is used to create and start the Docker container instance based on the Docker image, and to obtain the test management component, the target board test agent, the test configuration file, and the test control protocol stack of the test management component from the remote repository. The container deployment unit is used to deploy the test management component, the target board test agent, the test configuration file, and the test control protocol stack to the Docker container instance.

[0069] In one embodiment, executing an automated testing module includes: The configuration file parsing unit is used to parse the test configuration file through the test management component and obtain the target board model, test case list, software information to be tested and test type from the test configuration file. The file download unit is used to download the corresponding test program source code and the software image to be tested from the remote repository according to the test case list; The executable file generation unit is used to select the corresponding cross-compilation toolchain according to the target board model and compile and generate the test program executable file for the current virtual target board; The startup protocol stack unit is used to start the service of the test control protocol stack of the test management component and listen on the specified port.

[0070] In one embodiment, the report generation module includes: The loop unit is used to execute the test cases in the test case list sequentially until all test cases have been executed: The communication link detection unit is used to send a Ping message to the target board test agent through the test control protocol stack. If no response message is received within a set time, the communication link is not connected, the execution is terminated and an error is reported. An execution file storage unit is used to transmit the test program execution file in chunks to the target board test agent via a Data message if a response message is received. The target board test agent stores the data blocks of the test program execution file in the memory area of ​​the virtual target board. The error reporting unit is used to terminate execution and report an error if any of the Data messages fails to be transmitted. The file upload unit is used so that after the test program execution file is uploaded, the test management component sends an instruction message to notify the test agent to execute the test program execution file. The execution file loading unit is used by the target board test agent to load the received test program execution file into the text segment, dynamically load the test program execution file through the text segment, and terminate execution and report errors if an abnormal situation occurs. The message sending unit is used so that after the test program execution file is completed, the target board test agent sends the information of the memory area to the test management component via a Text message; The test result recording unit is used by the test management component to record the test results to the test result file set after receiving the Text message.

[0071] In one embodiment, the report generation module further includes: The test result generation unit is used to automatically generate a test result report based on the integrated result file set through the test management component. The test result report includes the mapping relationship between requirements and test cases, test results, and a requirement traceability matrix. The requirement traceability matrix is ​​used to characterize the coverage of requirements. The instruction address record generation unit is used to generate instruction address record files by collecting dynamic libraries through coverage. A coverage verification standard unit is set up to construct a structural coverage verification report that meets aviation airworthiness standards through the test management component. The structural coverage verification report includes an object code coverage verification report and a source code coverage verification report. The address read unit is used to read instruction address data from the instruction address record file; The target code coverage analysis unit is used to analyze the coverage of each CPU instruction of the software under test based on the instruction address data and the memory mapping file of the software under test when the test type is target code coverage test, calculate the target code coverage rate, and generate a target code coverage rate verification report according to the target code coverage verification standard. The source code coverage analysis unit is used to analyze the execution status of each source code based on the instruction address data and the mapping relationship between the instruction address data and the source code when the test type is source code coverage test, calculate the source code coverage rate, and generate a source code coverage verification report according to the source code coverage verification standard.

[0072] In one embodiment, the instruction address recording unit is further configured to, during test execution, collect the coverage data to monitor the CPU instruction execution of the software under test through the dynamic library, and record the instruction address data of each executed CPU instruction; and save the instruction address data to the instruction address recording file of the Docker container instance.

[0073] In one embodiment, the report generation module further includes: The requirement coverage verification unit is used to generate a requirement traceability matrix that meets aviation airworthiness requirements through the test management component, and to use the requirement traceability matrix as the coverage verification standard. The requirement traceability matrix is ​​used to store the complete mapping relationship between software requirements and test cases. During test execution, the test management component records the verification results of each test case and the corresponding software requirements, and updates the requirement traceability matrix with the verification results.

[0074] The embodiments of the present invention achieve the following technical effects: This invention simplifies a complex testing system into a standard Docker container, enabling out-of-the-box deployment. The complete testing environment can be copied and deployed in seconds on any Docker-supported platform, completely solving the problems of complex and time-consuming deployment in traditional testing environments, achieving ultimate portability and efficient deployment. Through a dynamic loading mechanism, this invention eliminates time-consuming repetitive compilation and flashing, shortening the test iteration cycle from hours to minutes, greatly accelerating the development and verification cycle and improving testing efficiency. This invention supports the rapid creation of simulation controllers of different models and architectures, easily achieving parallel testing of multiple models and elastic scheduling of test resources, breaking free from the "one board, one use" limitation, and possessing high flexibility and scalability. This invention achieves a fully automated closed-loop process through a dedicated protocol stack, reducing manual intervention, and ensures stable and efficient communication through the container's internal network, improving the reliability and consistency of test results, and providing complete automation and reliability assurance. Through built-in automated requirements tracing and coverage analysis functions, this invention directly generates key certification evidence required by airworthiness standards such as DO-178C, solving core pain points in the airborne software certification process and providing strong compliance support for airworthiness. This invention replaces most of the physical board requirements with software simulation, significantly reducing hardware procurement and maintenance costs as well as R&D risks caused by board damage, thus significantly optimizing costs. The custom test control protocol stack ensures the reliability of test program file transmission, command control, and result feedback, providing a reliable communication mechanism and overcoming the instability of traditional physical links.

[0075] Obviously, those skilled in the art should understand that the modules or steps of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

[0076] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An automated testing method for airborne controllers, characterized in that, include: Build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated testing environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. The test management component parses the test configuration file, obtains the test case list from the test configuration file, generates the test program executable file, and starts the automated test environment. The test management component executes all test cases in the test case list sequentially until all test cases have been executed, generating a set of test case result files. Based on the test type in the test configuration file and the set of result files, a test result report and a structure coverage verification report are generated.

2. The automated testing method for airborne controllers as described in claim 1, characterized in that, Build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated testing environment using the Docker container instance, including: The pre-configured QEMU emulator, Python runtime environment, coverage data collection dynamic library, cross-compilation toolchain, configuration file of the virtual target board, and base image are integrated into the Docker image; Based on the Docker image, create and start the Docker container instance, and obtain the test management component, the target board test agent, the test configuration file, and the test control protocol stack of the test management component from the remote repository; The test management component, the target board test agent, the test configuration file, and the test control protocol stack are deployed to the Docker container instance.

3. The automated testing method for airborne controllers as described in claim 1, characterized in that, The test management component parses the test configuration file, retrieves the test case list from the test configuration file, generates the test program executable file, and starts the automated test environment, including: The test management component parses the test configuration file to obtain the target board model, test case list, software information to be tested, and test type for this test. Download the corresponding test program source code and the software image to be tested from the remote repository according to the test case list; Select the corresponding cross-compilation toolchain according to the target board model, and compile to generate the test program executable file for the current virtual target board; Start the test control protocol stack service of the test management component and listen on the specified port.

4. The automated testing method for airborne controllers as described in claim 1, wherein the test management component executes all test cases in the test case list sequentially to generate a test result file set, including: Execute the test cases in the test case list sequentially until all test cases have been executed: The test control protocol stack sends a Ping message to the target board test agent. If no response message is received within a set time, the communication link is not connected, execution is terminated, and an error is reported. If a response message is received, the test program execution file is transmitted in chunks to the target board test agent via a Data message. The target board test agent stores the data blocks of the test program execution file in the memory area of ​​the virtual target board. If any of the Data messages fails to be transmitted, execution is terminated and an error is reported. After the test program executable file is uploaded, the test management component sends an instruction message to notify the test agent to execute the test program executable file; The target board test agent loads the received test program execution file into the text segment, dynamically loads the test program execution file through the text segment, and terminates execution and reports an error if an abnormal situation occurs. After the test program executable file is completed, the target board test agent sends the information of the memory region to the test management component via a Text message; After receiving the Text message, the test management component records the test results to the test result file set.

5. The automated testing method for airborne controllers as described in any one of claims 1 to 4, characterized in that, Based on the test type in the test configuration file and the result file set, generate a test result report and a structure coverage verification report, including: Based on the integrated result file set, a test result report is automatically generated by the test management component. The test result report includes the mapping relationship between requirements and test cases, test results, and a requirement traceability matrix, which is used to characterize the coverage of requirements. The instruction address record file is generated by collecting dynamic library data based on coverage. The test management component is used to build a structural coverage verification report that meets aviation airworthiness standards. The structural coverage verification report includes an object code coverage verification report and a source code coverage verification report. Read instruction address data from the instruction address record file; When the test type is target code coverage test, based on the instruction address data and the memory mapping file of the software under test, the coverage of each CPU instruction of the software under test is analyzed, the target code coverage rate is calculated, and a target code coverage rate verification report is generated according to the target code coverage verification standard. When the test type is source code coverage test, based on the instruction address data, the execution status of each source code is analyzed through the mapping relationship between the instruction address data and the source code, the source code coverage rate is calculated, and a source code coverage verification report is generated according to the source code coverage verification standard.

6. The automated testing method for airborne controllers as described in claim 5, characterized in that, The dynamic library instruction address log file is generated by collecting coverage data, including: During the test execution, the CPU instruction execution status of the software under test is monitored by the dynamic library through the coverage, and the instruction address data of each executed CPU instruction is recorded. The instruction address data is saved to the instruction address record file of the Docker container instance.

7. The automated testing method for airborne controllers as described in claim 5, characterized in that, Also includes: The test management component generates a requirement traceability matrix that meets aviation airworthiness requirements standards, and uses the requirement traceability matrix as a coverage verification standard. The requirement traceability matrix is ​​used to store the complete mapping relationship between software requirements and test cases. During test execution, the test management component records the verification results of each test case and the corresponding software requirements, and updates the verification results to the requirement traceability matrix.

8. An automated testing device for airborne controllers, characterized in that, include: A test environment building module is used to build a Docker image, create and start a Docker container instance based on the Docker image, deploy the Docker container instance, and build an automated test environment through the Docker container instance. The Docker container instance includes a test management component, a virtual target board component, a target board test agent, and a test control protocol stack. The automated testing module is used to parse the test configuration file through the test management component, obtain the test case list from the test configuration file, generate the test program executable file, and start the automated testing environment. The report generation module is used to execute all test cases in the test case list sequentially through the test management component until all test cases have been executed, generate a set of test case result files, and generate a test result report and a structure coverage verification report based on the test type in the test configuration file and the set of result files.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the automated testing method for airborne controllers as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the automated testing method for airborne controllers according to any one of claims 1 to 7.

Images