Virtual-real combined embedded software remote testing system and method

Abstract

The invention discloses a virtuality and reality combined embedded software testing system and a virtuality and reality combined embedded software testing method in the technical field of embedded software testing. The test system comprises a plurality of clients, a server and a plurality of test units, the server is used for providing WEB service for a user, managing the user and controlling the authority of the user, and is also used for providing virtual equipment and physical equipment management, managing the virtual equipment and a test unit and completing test task reservation and test task execution of the user; the test unit is used for providing a physical test environment and comprises a test device and a tested device, the test device is a computer or a special device containing an adaptive interface and computing processing capability, and the tested device is a target board card or device operated by embedded software; and the client is used for accessing the WEB service of the server through a network. The testing system supports resource sharing and collaborative testing in different places, and before the physical target is in place, the virtual target is used for starting testing as soon as possible, and testing left shifting is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded software testing, and in particular to a virtual-real combined embedded software remote testing system and method. Background Art

[0002] Embedded software testing faces more difficulties and challenges than traditional software testing, mainly due to the complexity of embedded systems, hardware dependence and resource-constrained environment.

[0003] Normally, embedded software can only be tested after the target hardware or system is determined. Most embedded system organizations suffer from a shortage of target systems and have to wait in line to obtain equipment. As a result, the use of pure software to simulate experimental equipment has emerged. Testers only need to run virtual simulation software to conduct virtual experiments. However, due to the limitations of the operating environment, hardware simulators have obvious deficiencies in concurrent testing and process testing. There is still a big difference between software simulation devices and actual physical devices, especially when it comes to the timing part of hardware devices. It is difficult for virtual devices to simulate the full performance of real devices. Embedded software testing based on physical devices will also encounter problems such as difficulty in hardware sharing, complex test environment configuration, hardware environment contamination after the test is completed, difficulty in automated testing, and difficulty in remote interactive testing.

[0004] Drivers for embedded systems usually directly control hardware devices, and testing these low-level codes is extremely complex. Driver errors may cause system crashes, deadlocks, or other difficult-to-debug faults. At the same time, differences between different hardware platforms may cause compatibility issues, which increases the complexity of test coverage. In embedded systems, automated testing is even more difficult to implement. On the one hand, automated testing requires interaction with hardware, and the interfaces and environments of different devices are different, making it difficult for test scripts to be universal; on the other hand, building an automated testing framework that simulates the actual physical environment is very complex, and usually requires building a dedicated hardware environment or using a hardware-in-the-loop (HIL) test platform, which is costly and technically demanding. Summary of the invention

[0005] In order to solve or at least partially solve the above problems, the present application provides a virtual-real combination embedded software testing system and method. Through this testing system and method, before the physical hardware is developed, the operation of the hardware can be simulated by software simulation to test the embedded software and accelerate the R&D cycle; after the physical hardware is determined, complex and comprehensive tests can be performed on the physical hardware to address the shortcomings of pure software simulation testing; at the same time, the network can be used to achieve sharing of test equipment in different regions and remote interactive testing.

[0006] The embodiment of the present application provides a virtual-real combined embedded software testing system, including: a number of clients, a server and a number of testing units; The server includes a Web test portal, which is used to provide WEB services to users, manage users and control permissions. The server is also used to provide unified virtual device and physical device management, manage the virtual device and the test unit, and complete the user's test task reservation and test task execution; The client is used to access the WEB service of the server through the network, access the remote test unit through the network reservation, and perform embedded software testing on the device under test; The test unit is used to provide a physical test environment, including a test device and a device under test. The test device is a computer or special device including an adapter interface and computing processing capabilities, and the device under test is a target board or device running embedded software.

[0007] Based on the above embodiments, the present application can be further improved as follows: In one embodiment of the present application, the test unit also includes a test gateway and a timing device. The test gateway is used to complete the conversion of the protocol of the device under test to the TCP / IP protocol, and the timing device is used to provide high-precision clock services; the connection channel between the client and the device under test is: client-server-test gateway-test device-device under test; the test device can be shared with multiple clients in a time-sharing manner.

[0008] In one of the embodiments of the present application, the Web test portal includes a user management module, a permission management module, a test task management module, and a test data management module; the server is used to reproduce the hardware's operating mechanism, interface, and behavior in a virtual environment through software simulation before the device under test is developed, thereby supporting software development, testing, and verification; the server includes a number of containers, in which test tools and configuration environments are installed. When performing physical device testing, the containers are transferred to the device under test for operation, thereby achieving rapid deployment of the test environment and quickly restoring the device under test to its initial state after the test is completed.

[0009] In one of the embodiments of the present application, the client is used to access the WEB service of the test server through the network to complete operations such as user login, test task reservation, test task management, test software transmission, test task execution, and test data analysis.

[0010] In one of the embodiments of the present application, the embedded software testing system is based on the Internet network and B / S architecture, adopts a star network topology connection, and is based on a TCP / IP custom application layer protocol.

[0011] The testing method of the embedded software testing system includes the following processes: Step 1: Test task reservation: The user logs in to the WEB test portal of the server through the client, reserves a remote test task, and selects a simulation test or a physical test; for the simulation test, the server generates a simulator-based test environment and generates a test task; for the physical test, the server dynamically pairs the client and the test unit, returns the test time according to the idle state of the device under test, and records it in the database, and establishes a point-to-point connection before the test starts; Step 2: Remote configuration: During remote testing, the user downloads the embedded software program to be tested to a simulated test environment or a physical device under test, and configures the test environment; The WEB test portal of the server provides a configuration management module, in which the user sets parameters, and the server generates a configuration file and transmits it to the simulated test environment or physical test equipment to complete the test environment configuration; For the physical test, a test tool is installed in the container, and a test environment is configured based on the container. The container is downloaded to the device under test, and a software program is run in the container environment, thereby realizing rapid configuration of the test environment; Step 3: Remote interactive test: The user executes the remote test task in the test task management module of the WEB test portal of the server, and performs operations such as starting the test, stopping the test, and single-step testing. The status of the simulator or the device under test is displayed in a graphical form on the WEB page; Step 4: View and analyze test data: After the test is completed, view the test process data and defect data in the data management module of the WEB test portal of the server, and analyze indicators such as the execution rate and pass rate of the test cases.

[0012] The embodiment of the present application also provides a virtual simulation test method for embedded software. Before the physical target is in place, the hardware operating mechanism, interface and behavior are reproduced in a virtual environment through a hardware simulator using a virtual target, thereby supporting software testing and verification. The simulator's operating environment is based on QEMU virtualization deployment, and QEMU's ability to flexibly adjust the simulator's operating environment is utilized to meet the requirements of different test scenarios. Based on the aforementioned embedded software testing system, the virtual simulation test method includes the following steps: Step 1: The user reserves a test task through the client and selects the required hardware simulator; Step 2: After receiving the test reservation, the server generates a simulator operating environment based on QEMU and delivers it to the user; Step 3: The user establishes a connection with the simulator, performs test environment configuration, and transmits the embedded software program; Step 4: The user performs remote interactive testing on the WEB testing portal of the server.

[0013] In one of the embodiments of the present application, multiple virtual environments running the same simulator are generated based on QEMU, and the embedded software program is transmitted to each simulator at the same time. Different simulators execute different test contents in parallel to improve the test efficiency. For objects that are not easy to construct or obtain, the unit test process that requires all internal or external dependencies to be stable, or the scene where the interface automation test needs to call a third-party interface, the mock method is used to simulate the object, external dependency or interface return data.

[0014] In one of the embodiments of the present application, the test task management module is used to scan, build, test, and deploy an automated workflow for embedded software. According to the test process, simulators for multiple different physical conditions are generated in the test process, and the test process is orchestrated using a process orchestration tool to implement the continuous integration / delivery (CI / CD) process of embedded software. At the same time, the simulator environment provides a third-party interface for integrating more simulators, and new virtual targets can be accessed by accessing the GUI, CLI, and API.

[0015] The embodiment of the present application further provides a container-based embedded software physical testing method. Based on the aforementioned embedded software testing system, the embedded software physical testing method includes the following steps: Deploy CI tools and auxiliary testing tools in the test equipment of the test unit; The device under test performs adaptation of the container operating environment; The test tool is installed in the container and the test parameters are configured, and the embedded software program is deployed into the container; The container runs on the device under test to complete the test task. Specifically: the test task and environment are run based on the container, the container runs in multiple devices under test at the same time, and the container orchestration tool is used to arrange the test tasks in a specific order, and the test process is transmitted in a pipeline to achieve automation and process-based testing.

[0016] Use container orchestration tools or scripts to create, configure, and start containers for development and test environments in one click. Testers can customize container configurations such as environment variables, network settings, and mounted volumes as needed. After the test is completed, destroy the container to release resources and ensure that the operating environment of the device under test is not contaminated.

[0017] In one embodiment of the present application, the test tasks are distributed to different test devices to execute test cases in parallel, and software compatibility tests are performed in parallel based on the characteristics of container isolation and rapid environment cleanup. Containers are combined with DevOps to unify the development, testing, and operation and maintenance environments, and realize full process automation from development to testing.

[0018] Containers are used to simulate the external environment required for test execution, typical test scenarios are containerized, images are stored in image repositories, and test scenarios are deployed in a microservices manner through container combination tools to achieve test scenario reuse.

[0019] Run kernel-related applications in the container, decouple the application from the kernel features, and port part of the code corresponding to the kernel module to the application.

[0020] In case the hardware device number changes due to restart of the device under test and the hardware device needs to be loaded dynamically, modify the mobile device configuration file and dynamically load the new device number through the underlying characteristics.

[0021] The LTP test suite uses serial execution by default. Starting multiple containers to concurrently execute kernel function tests increases CPU load and reduces test execution time. For test cases that require dynamic link libraries, the necessary dynamic libraries are integrated into the container image.

[0022] In one of the embodiments of the present application, for hardware driver testing, the device cgroup feature of the kernel is used to implement the device pass-through function, and the device under test is mapped into a container for hardware driver testing.

[0023] In one of the embodiments of the present application, for long-term stable stress testing, the file system in the container is used to support the operation of the stress program to avoid the problem of system crash caused by the stress program. When the stress program has a memory leak, the container attempts to use more than the limited memory, which will trigger OOM (Out Of Memory). After setting the restart rules, the resources occupied by the container are cleared, and the container will quickly restart and continue to stress.

[0024] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. This virtual-real embedded software remote testing system and method has the ability of networked collaborative test management and operation control, supports remote sharing of test resources, and supports remote collaborative testing. Before the physical target is in place, use the virtual target to start testing as early as possible to achieve test left shift. Through the unified WEB test management service, it is helpful to share physical and virtual targets, and only one target needs to be reserved for testing.

[0025] 2. Based on the embedded software remote testing system, the container-based embedded software physical testing method uses virtual targets through hardware simulators to reproduce the hardware's operating mechanism, interface and behavior in a virtual environment before the physical target is in place, thereby supporting software testing and verification. The simulator executes different test contents in parallel to improve test efficiency. The process orchestration tool is used to orchestrate the test process to realize the continuous integration / delivery (CI / CD) process of embedded software. The container-based embedded software physical testing method uses container orchestration tools or scripts to create, configure and start containers for development and test environments in one click. Testers can customize the configuration of containers as needed, such as environment variables, network settings and mounted volumes. After the test is completed, the container is destroyed to release resources to ensure that the operating environment of the device under test is not polluted. The test tasks are distributed to different test devices to execute test cases in parallel, and software compatibility tests are performed in parallel based on the characteristics of container isolation and rapid environment cleanup. Containers and DevOps are combined to unify the development, testing, and operation and maintenance environments to achieve full process automation from development to testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for the specific embodiments or the description of the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn according to the actual scale.

[0027] Figure 1 A schematic diagram of a virtual-real embedded software remote testing system in an embodiment of the present application; Figure 2 This is a block diagram of a virtual-real embedded software remote testing system in an embodiment of the present application; Figure 3 A flowchart of the steps of the testing method of the embedded software testing system in the embodiment of the present application; Figure 4 This is a timing diagram of the interaction between the client and the device under test in an embodiment of the present application; Figure 5 This is a schematic diagram of a process-based concurrent test based on a container in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The present invention is further explained below in conjunction with specific implementation methods. It should be understood that these implementation methods are only used to illustrate the present invention and are not used to limit the scope of the present invention. After reading the present invention, various equivalent forms of modifications to the present invention by those skilled in the art all fall within the scope defined by the claims attached to this application.

[0029] The present invention aims at the problems existing in embedded software testing, and provides an embedded software remote testing system and method that utilizes a software simulator and a physical device to combine virtual and real. With the help of the Internet and its server, a unified management system-level sharable physical testing unit of virtual and physical testing devices is provided to remote client users. The virtual simulation testing method can complete the rapid testing of software before the physical device is in place. The container-based physical device testing method can quickly build a test environment and complete the test task.

[0030] like Figure 1 As shown, a virtual-real remote embedded software testing system is based on the Internet network and B / S architecture, and consists of multiple clients, test servers and multiple test units. The system adopts a star network topology connection and is based on a TCP / IP custom application layer protocol. The client can access the remote test unit through a network appointment and perform embedded software testing on the device under test. The test equipment of the remote test unit can be shared with multiple clients in a time-sharing manner. The connection channel between the client and the remote device under test is: client-server-test gateway-test equipment-device under test. The test equipment is a computer or special equipment that includes an adapter interface and computing processing capabilities, and the device under test is a target board or device for embedded software operation.

[0031] like Figure 2 As shown, the specific components of the system include: The client is used to access the WEB service of the test server through the network to complete operations such as user login, test task reservation, test task management, test software transmission, test task execution, and test data analysis.

[0032] The server is used to provide WEB services to users, manage users and control permissions, provide a unified virtual device and physical device management interface, manage simulators and test units, and complete user test task reservations and test task execution. The server deploys a hardware simulator. Before the development of the device under test is completed, the hardware's operating mechanism, interface, and behavior are reproduced in a virtual environment through software simulation, thereby supporting software development, testing, and verification. At the same time, the server provides a test container image, and the test tools and configuration environment are installed in the container. When performing physical device testing, the container is transferred to the device under test for operation, thereby achieving rapid deployment of the test environment and quickly restoring the device under test to its initial state after the test is completed.

[0033] The test unit is used to provide a physical test environment, including a test gateway, test equipment, a device under test, and a timing device. The test equipment provides various interfaces and interface drivers and can connect multiple devices under test. The test gateway completes the conversion of the device under test protocol to the TCP / IP protocol and can connect multiple test devices. The timing device provides high-precision clock services.

[0034] like Figure 3 As shown, the testing method of the virtual-real remote embedded software testing system includes the following processes: S101: Test task reservation: The client logs in to the WEB test portal, makes a reservation for a remote test task, and selects a simulation test or a physical test; for a simulation test, the server generates a simulator-based test environment and generates a test task; for a physical test, the server dynamically pairs the client and the test unit, returns the test time based on the idle state of the device under test, and records it in the database, and establishes a point-to-point connection before the test starts.

[0035] S102: Remote configuration: During remote testing, the user downloads the embedded software program to be tested to a simulated test environment or a physical device under test, and configures the test environment.

[0036] Furthermore, the server WEB test portal provides a configuration management module, in which the user sets parameters, and the server generates a configuration file and transmits it to the simulated test environment or physical test equipment to complete the test environment configuration.

[0037] Furthermore, for physical testing, the test tool is installed in the container, and the test environment is configured based on the container. The container is downloaded to the device under test, and the software program runs in the container environment content, thereby realizing rapid configuration of the test environment.

[0038] S103: Remote interactive test: The user executes remote test tasks in the test task management module of the server WEB test portal, and performs operations such as starting test, stopping test, and single-step test. The status of the simulator or the device under test is displayed graphically on the WEB page. The interaction sequence between the client and the device is as follows: Figure 4 .

[0039] S104: View and analyze test data: After the test is completed, view the test process data and defect data in the test data management module of the server WEB test portal, and analyze indicators such as the execution rate and pass rate of the test cases.

[0040] A virtual simulation test method for embedded software: Before the physical target is in place, the hardware operating mechanism, interface and behavior are reproduced in a virtual environment through a hardware simulator using a virtual target, thereby supporting software testing and verification. The simulator's operating environment is based on QEMU virtualization deployment, and QEMU's ability to flexibly adjust the simulator's operating environment is used to meet the requirements of different test scenarios. Based on the above system, the method includes the following steps: Step 1: The user schedules a test task and selects the required hardware simulator; Step 2: After receiving the test reservation, the server generates a simulator operating environment based on QEMU and delivers it to the user; Step 3: The user establishes a connection with the simulator, configures the test environment, and transfers the embedded software program; Step 4: The user performs remote interactive testing on the server WEB portal.

[0041] Furthermore, multiple virtual environments running the same simulator are generated based on QEMU, and the embedded software programs are transferred to each simulator at the same time. Different simulators execute different test contents in parallel to improve the test efficiency. For objects that are not easy to construct or obtain, the unit test process requires all internal or external dependencies to be stable, or in scenarios where interface automation testing requires calling third-party interfaces, the mock method is used to simulate objects, external dependencies, or interface return data.

[0042] Furthermore, the test task management module is used to scan, build, test, and deploy the automated workflow of embedded software. According to the test process, simulators for multiple different physical conditions are generated in the test process, and the process orchestration tool is used to orchestrate the test process to realize the continuous integration / delivery (CI / CD) process of embedded software, such as Figure 5 At the same time, the simulator environment provides a third-party interface for integrating more simulators, and new virtual targets can be accessed by accessing the GUI, CLI, and API.

[0043] A container-based embedded software physical testing method includes the following contents: CI tools and auxiliary testing tools are deployed in the test equipment of the test unit. The device under test is adapted to the container operating environment. The test tools are installed in the container and test parameters are configured. The embedded software program is deployed into the container. The container runs on the device under test to complete the test task.

[0044] Use container orchestration tools or scripts to create, configure, and start containers for development and test environments in one click. Testers can customize container configurations such as environment variables, network settings, and mounted volumes as needed. After the test is completed, destroy the container to release resources and ensure that the operating environment of the device under test is not contaminated.

[0045] The distributed approach is used to distribute test tasks to different test devices to execute test cases in parallel. Based on the isolation and rapid environment cleanup characteristics of containers, software compatibility tests are performed in parallel. The combination of containers and DevOps unifies the development, testing, and operation and maintenance environments, and realizes full process automation from development to testing.

[0046] Containers are used to simulate the external environment required for test execution, typical test scenarios are containerized, images are stored in image repositories, and test scenarios are deployed in a microservices manner through container combination tools to achieve test scenario reuse.

[0047] Run kernel-related applications in the container, decouple the application from the kernel features, and port part of the code corresponding to the kernel module to the application.

[0048] The execution steps of automated testing based on Docker containers include: Step 1: Build a Docker image. Define the configuration and dependencies of the test environment in the container file Dockerfile according to the requirements of the test environment. Then use the Docker command to build the Docker image.

[0049] Step 2: Write test scripts. Use various automated testing frameworks to write test scripts and define test cases and test steps.

[0050] Step 3: Run the test using a Docker container. Run the test script using a Docker container to ensure consistency and isolation of the test environment. Use container orchestration tools to orchestrate multiple containers to implement complex integration testing.

[0051] Step 4: Integrate automation into the continuous integration process. Integrate automated testing into the continuous integration process to ensure that tests are automatically run after each code submission. Use CI / CD tools to trigger automated tests and generate reports.

[0052] Furthermore, in case the hardware device number changes due to the restart of the device under test and the hardware device needs to be loaded dynamically, modify the / etc / udev / rules.d / 70-persistent-net.rules configuration file of the device under test and dynamically load the new device number through the underlying characteristics.

[0053] The implementation based on Docker container is as follows: Step 1: Use the udevadm info / dev / bus / usb001 / 011 command to obtain the device ID and major and minor numbers (X, Y). Step 2: Start the container: docker run -ti -device= / dev / bus / usb / 001 / 011 ${test_image} ${test_command} .

[0054] Step 3: After the device restarts, use the udevadm info command to find the new device number major and minor (X, Y) of the hardware device. Step 4: Enter the cgroup directory corresponding to the container: / sys / fs / cgroup / devices / docker / ${containerid}; You can find c X, Z rwm in the devices.list file.

[0055] By echo "c X,Y rwm" >> devices.allow; Modify the device cgroup file to open the device to the container. Step 5: Execute inside the container: mknod / dev / bus / usb / 001 / 012 c X, Y; Allows the container to directly access the device under test.

[0056] Furthermore, the memory test is containerized as follows: Multi-container concurrent testing. The test cases in the LTP test suite are executed serially by default. You can start multiple containers to concurrently execute kernel function tests to increase the CPU load and reduce the test execution time. Build a kernel test environment in the container. The test case source code in the LTP test suite is dynamically compiled by default, and its operation requires a dynamic link library, which causes some kernel test cases to fail to execute. Integrate the necessary dynamic libraries into the container image to ensure the smooth execution of the test cases and avoid environmental pollution caused by directly installing library files in the host. Use containers to build kernel integration test scenarios. As the underlying technology, it is difficult to find integration test scenarios that can include multiple kernel features. In the Docker environment, the following Docker commands can be used to build integration test scenarios for kernel features such as namespace, cgroup, capability, and seccomp, reducing the integration test design time.

[0057] $ docker run --memory 20m --cap-add sys_admin --security-opt seccomp=unconfined --userns-remap default ubuntu:14.04 bash .

[0058] Furthermore, for hardware driver testing, the kernel's device cgroup feature is used to implement device passthrough, mapping the device under test into the container for hardware driver testing. The test environment will not pollute the host environment, facilitating parallel testing of device drivers; the host file system lacks the library files required for testing, and the tools in the container's file system are used to assist testing.

[0059] Furthermore, for long-term and stable stress testing, using the file system in the container to support the operation of the stress program can standardize the operation of long-term and stable tests and integrate the testing capabilities of multiple test groups. Containerization of the test environment can avoid the problem of system crashes caused by stress programs. When the stress program has a memory leak, the container will trigger OOM (Out Of Memory) when it attempts to use more than the limited memory. After setting the restart rule, the resources occupied by the container will be cleared, and the container will quickly restart and continue to stress.

[0060] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A virtual-real combination embedded software testing system, characterized in that: include: Several clients, servers and several test units; The server includes a Web test portal, which is used to provide WEB services to users, manage users and control permissions. The server is also used to provide virtual device and physical device management, manage the virtual device and the test unit, and complete the user's test task reservation and test task execution; The test unit is used to provide a physical test environment, including a test device and a device under test. The test device is a computer or a dedicated device including an adapter interface and computing processing capabilities, and the device under test is a target board or device running embedded software; The client is used to access the WEB service of the server through the network, access the test unit through network reservation, and perform the embedded software test on the device under test.

2. The embedded software testing system according to claim 1, characterized in that: The test unit also includes a test gateway and a timing device. The test gateway is used to complete the conversion of the protocol of the device under test to the TCP / IP protocol, and the timing device is used to provide high-precision clock services. The connection channel between the client and the device under test is: client-server-test gateway-test device-device under test; the test device can be shared with multiple clients in a time-sharing manner.

3. The embedded software testing system according to claim 1, characterized in that: The Web test portal includes a user management module, a permission management module, a test task management module, and a test data management module; the server is used to reproduce the hardware's operating mechanism, interface, and behavior in a virtual environment through software simulation before the device under test is developed, thereby supporting software development, testing, and verification; the server includes a number of containers, in which test tools and configuration environments are installed. When performing physical device testing, the containers are transferred to the device under test for operation, thereby achieving rapid deployment of the test environment and quickly restoring the device under test to its initial state after the test is completed.

4. An embedded software testing method, characterized in that: The embedded software testing system according to any one of claims 1 to 3 comprises the following steps: Step 1: Test task reservation: The user logs in to the WEB test portal of the server through the client, reserves a remote test task, and selects a simulation test or a physical test; for the simulation test, the server generates a simulator-based test environment and generates a test task; for the physical test, the server dynamically pairs the client and the test unit, returns the test time according to the idle state of the device under test, and records it in the database, and establishes a point-to-point connection before the test starts; Step 2: Remote configuration: During remote testing, the user downloads the embedded software program to be tested to a simulated test environment or a device under test, and configures the test environment; The WEB test portal of the server provides a configuration management module, in which the user sets parameters, and the server generates a configuration file and transmits it to the simulated test environment or test equipment to complete the test environment configuration; For the physical test, a test tool is installed in a container, and a test environment is configured based on the container. The container is downloaded to the device under test, and a software program is run in the container environment, thereby realizing rapid configuration of the test environment; Step 3: Remote interactive test: The user executes the remote test task in the test task management module of the WEB test portal of the server, and performs the start test, stop test, and single-step test operations; Step 4: View and analyze test data: After the test is completed, view the test process data and defect data in the data management module of the WEB test portal of the server, and analyze the execution rate and pass rate indicators of the test cases.

5. A virtual simulation test method for embedded software, characterized in that: The embedded software testing system according to any one of claims 1 to 3 comprises the following steps: Step 1: The user reserves a test task through the client and selects the required simulator; Step 2: After receiving the test reservation, the server generates a simulator operating environment based on QEMU and delivers it to the user; Step 3: The user establishes a connection with the simulator, configures the test environment, and transmits the embedded software program; Step 4: The user performs remote interactive testing on the WEB testing portal of the server.

6. The virtual simulation test method according to claim 5, characterized in that: The server generates multiple virtual environments running the same simulator based on QEMU, and transmits the embedded software program to each simulator at the same time, and different simulators execute different test contents in parallel.

7. The virtual simulation test method according to claim 5, characterized in that: Utilize the data management module of the WEB test portal of the server to scan, build, test, and deploy the automated workflow of embedded software, generate simulators for multiple different physical conditions in the test process according to the test process, and use the process orchestration tool to orchestrate the test process to realize the continuous integration / delivery process of embedded software; The simulator environment provides a third-party interface for integrating more simulators, and new virtual targets can be accessed by accessing the GUI, CLI, and API.

8. A container-based embedded software physical testing method, characterized in that: The embedded software testing system according to any one of claims 1 to 3 comprises the following steps: S1: deploy CI tools and auxiliary testing tools in the test equipment of the test unit; S2: The device under test performs container operating environment adaptation; S3: installing a test tool in the container and configuring test parameters, and deploying the embedded software program into the container; S4: The container runs on the device under test to complete the test task. Specifically, the test task and environment are run based on the container, and the container runs in multiple devices under test at the same time. The container orchestration tool is used to arrange the test tasks in a specific order, and the test process is transmitted in a pipeline to achieve automation and process-based testing.

9. The embedded software physical testing method according to claim 8, characterized in that: The test tasks are sent to different test devices in a distributed manner to execute test cases in parallel and to perform software compatibility tests in parallel.

10. The embedded software physical testing method according to claim 8, characterized in that: For hardware driver testing, the device cgroup feature of the kernel is used to implement device pass-through, and the device under test is mapped into the container for hardware driver testing.

Images