An automated simulation testing system and method for AUTOSAR AP platform middleware

Abstract

The application provides an automatic simulation test system and method for AUTOSAR AP platform middleware, relates to the technical field of middleware simulation testing, and comprises a test framework library, a project storage library, a task executor and a test platform. The test framework library is used for storing a test operation packaging tool set. The project storage library is used for storing test project resources. The task executor is used for pulling the test project resources associated with a target test task configured by a tester through a test platform and full-pulling the test operation packaging tool set to form a resource set. A corresponding docker container is created based on the actual deployment environment of the middleware on a target board card, a middleware execution environment is built in combination with the resource set, the middleware execution environment is mapped into the docker container, the target test task is executed in the docker container environment, test data collection, result analysis and test report generation are completed, and the test report is returned to the test platform. The environment is highly close to a real scene, complex hardware topology simulation is supported, and the test efficiency is significantly improved.

Description

Technical Field

[0001] This invention relates to the field of middleware simulation testing technology, and in particular to an automated simulation testing system and method for AUTOSAR AP platform middleware. Background Technology

[0002] AUTOSAR (Automotive Open System Architecture), as the core standardized architecture for automotive electronic software development, plays a crucial role in the development of software-defined vehicles. By defining unified interface specifications and standardized software modules, it effectively simplifies the development process of automotive electronic systems, enhances the independence, portability, and reusability of software components, and enables flexible migration and integration of software products from different manufacturers and between different ECUs (Electronic Control Units). This provides effective support for addressing the challenges of rapid iteration in automotive electronic technology and the market's demand for personalized functionalities.

[0003] With the continuous increase in the complexity of automotive electronic systems, the middleware based on the AUTOSAR Adaptive Platform (AP), as the core support layer of in-vehicle software, directly determines the operational safety of the entire vehicle's electronic systems through its functional reliability. However, the current testing process for AUTOSAR AP platform middleware still faces many severe challenges, becoming a major bottleneck restricting project iteration efficiency: First, building a test environment is difficult and costly. The AUTOSAR AP platform middleware relies on a specific hardware operating environment and complex deployment configuration. Traditional testing requires building a test environment based on real target boards, which not only involves a large investment of hardware resources, but also requires a precise environment building process with highly coupled links. This places extremely high demands on the professional skills and operational attention to detail of the testers. Any slight oversight may lead to distortion of the test environment, thereby affecting the accuracy of the test results.

[0004] Secondly, automated testing capabilities are insufficient, and processes are severely fragmented. Currently, most common testing methods in the industry rely on manually written scripts or isolated tools with limited functionality, covering only specific interfaces or simple functional scenarios of a single middleware component. They lack the capability for automated simulation testing of large-scale, multi-node ECU interaction scenarios. Furthermore, key testing aspects such as test case management, simulation environment deployment, test case execution, test data collection, result analysis, and report generation lack effective integration, resulting in multiple process breakpoints and preventing the achievement of fully automated closed-loop management.

[0005] Furthermore, testing efficiency is low and resources are wasted. Fragmented testing and verification methods not only fail to guarantee comprehensive test coverage and repeatability of test results, but also require significant manpower for repetitive tasks such as environment setup, test case execution, and result analysis, which significantly prolongs the testing cycle, increases project development costs, and cannot meet the rapidly iterative development needs of the automotive electronics industry.

[0006] In summary, the industry urgently needs an efficient and reliable automated simulation testing solution for AUTOSAR AP platform middleware to address issues such as complex environment construction, low automation, and fragmented processes in existing testing methods. This solution would enable fully automated integration of the testing process, flexible configuration and rapid deployment of the testing environment, and improved testing efficiency and reliability while reducing reliance on real hardware, thus ensuring the functional safety of middleware in complex automotive scenarios. Summary of the Invention

[0007] To address the problems existing in the prior art, this invention provides an automated simulation testing system for AUTOSAR AP platform middleware, comprising: The test framework library stores a set of test operation encapsulation tools adapted to the AUTOSAR AP platform middleware; A project repository is used to store test project resources adapted to the AUTOSAR AP platform middleware; A task executor, connected to the test framework library, the project repository, and the test platform, comprises: The resource retrieval module is used to retrieve the associated test project resources based on the target test task configured by the tester through the test platform, and to retrieve the entire test operation encapsulation toolset to form a resource set; The task execution module is used to create a corresponding Docker container based on the actual deployment environment of the middleware on the target board, and at the same time build a middleware execution environment in combination with the resource set, and map the middleware execution environment into the Docker container to execute the target test task in the Docker container environment, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

[0008] Preferably, the testing platform provides a front-end interactive interface for the testers to configure a single test item or a test set containing multiple test items as the target test task.

[0009] Preferably, the task execution module includes: The environment deployment unit is used to execute the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources; The environment preparation unit, connected to the environment deployment unit, is used to execute the execution environment preparation script in the test operation encapsulation toolset in the middleware development environment, so as to call the sh tool package and build the middleware execution environment based on the test project, and create a blank test machine instance in the middleware execution environment. The test execution unit, connected to the environment preparation unit, is used to execute the test execution script in the test operation encapsulation toolset to create the Docker container and map the middleware execution environment into the Docker container to execute the target test task in the Docker container environment.

[0010] Preferably, the environment preparation unit includes: The integration subunit is used to call the standardized arxml integration command in the sh toolkit to integrate the user arxml model in the test project with the public arxml model in the test operation encapsulation toolkit to obtain the integrated arxml model; The merging subunit is used to merge the user test code in the test project with the framework code in the test operation encapsulation toolkit to obtain a C++ test project; The compilation subunit is used to call the standardized compilation instructions in the sh toolkit to compile the C++ test project and generate an executable file; The update subunit is used to call the standardized update instructions in the sh toolkit to load the executable file and the integrated arxml model into the test machine to build the middleware execution environment.

[0011] Preferably, the test execution unit includes: Create a subunit to create the corresponding Docker container based on the actual deployment environment of the middleware on the target board and the ECU topology configuration in the test project resources; The mapping subunit is used to map the middleware execution environment containing the test machine into the Docker container; The execution subunit is used to start the test machine in the Docker container to execute the target test task, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

[0012] Preferably, the Docker container corresponds one-to-one with the ECU.

[0013] Preferably, the task executor further includes a task cleanup module, which is used to execute the environment cleanup script in the test operation encapsulation toolset after the test report is returned to the test platform, and to stop and delete all Docker containers associated with the deployed target test tasks.

[0014] Preferably, the test report includes the execution results of each test case included in the target test task; The testing platform includes a result analysis module, which is used to perform preliminary analysis on the test cases that fail to execute, in order to identify the failure points and indicate possible causes.

[0015] This invention also provides an automated simulation testing method for AUTOSAR AP platform middleware, applied to the aforementioned automated simulation testing system, the automated simulation testing method comprising: Step S1: The automated simulation test system retrieves the associated test project resources from the project repository according to the target test task configured by the tester through the test platform, and retrieves the test operation encapsulation toolset from the test framework library to form a resource set. Step S2: The automated simulation testing system creates a corresponding Docker container based on the actual deployment environment of the middleware on the target board. At the same time, it builds a middleware execution environment in conjunction with the resource set and maps the middleware execution environment to the Docker container to execute the target test task in the Docker container environment, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

[0016] Preferably, step S2 includes: Step S21: The automated simulation test system executes the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources. Step S22: The automated simulation test system executes the execution environment preparation script in the test operation encapsulation toolset in the middleware development environment to call the sh toolkit and build the middleware execution environment based on the test project, and create a blank test machine instance in the middleware execution environment. Step S23: The automated simulation test system executes the test execution script in the test operation encapsulation toolset to create the Docker container, and maps the middleware execution environment into the Docker container to execute the target test task in the Docker container environment.

[0017] The above technical solution has the following advantages or beneficial effects: Based on the collaborative architecture of a test framework library, a project repository, and a task executor, this invention effectively solves the problems of complex configuration, cumbersome processes, long processing times, and high error rates in existing automotive middleware testing environments. Testers only need to configure simple target test tasks through the test platform to quickly deploy a test system that closely resembles the real operating environment, efficiently execute test tasks, and automatically generate comprehensive and detailed standardized test reports, significantly improving the automation level and reliability of automotive middleware testing, as detailed below: 1) The environment closely resembles real-world scenarios: When building the middleware execution environment, the task executor constructs a Docker image based on the actual deployment environment of the middleware on the target board. It strictly follows the environment baseline configuration of the target board middleware in the test framework library, ensuring that the core attributes of the middleware execution environment in the Docker container are completely consistent with the deployment environment of the real vehicle ECU. This fundamentally avoids the test distortion problem caused by the difference between the traditional simulation environment and the real environment, enabling the test results to truly reflect the running status of the middleware in the vehicle scenario and greatly improving the credibility of the test results. 2) Supports complex hardware topology simulation: For complex scenarios of multiple ECUs working together in an in-vehicle system, the task executor can flexibly adjust the number of Docker containers created according to the test project requirements, so as to flexibly build complex test scenarios of multiple ECUs working together; at the same time, different containers can load different images to accurately reproduce the customer's real use environment; 3) Significantly improves testing efficiency: From automatically pulling test framework library resources and test project resources after the test task is triggered, to automatically building the middleware execution environment and deploying the Docker container cluster, and then to automatically executing test cases, collecting test data, generating test reports and sending them back to the test platform, the entire process requires no manual intervention, achieving full automation and eliminating repetitive operations in manual regression testing; at the same time, test tasks support one-click triggering and concurrent execution of multiple tasks, greatly shortening the test cycle; 4) Effectively reduce testing costs: By building a simulated test environment through Docker container virtualization technology, when physical test board resources are insufficient, all test cases can be executed in the simulated environment. Each module only needs to perform necessary compatibility verification on the real board, which greatly reduces the dependence on scarce physical board resources, avoids test blocking due to hardware resource bottlenecks, and saves hardware and manpower costs. 5) Significantly improves test accuracy: Traditional manual testing requires processing a large number of models and C++ projects simultaneously, and manually analyzing execution logs, machine logs, coredumps and packet capture data, which is prone to misjudgment due to operational oversights; This invention completely avoids the risks of human operation through fully automated testing, ensuring stable and reliable test results; 6) Simplify problem localization costs: The system automatically collects comprehensive test data and presents it in a structured manner in the test report, enabling intuitive presentation and rapid traceability of test data. Testers can directly obtain detailed execution information of each test case through the test report, quickly locate the data flow and log fragments corresponding to test anomalies, and eliminate the need to manually filter and organize massive amounts of raw data, significantly reducing the difficulty and time cost of troubleshooting and improving problem-solving efficiency. Attached Figure Description

[0018] Figure 1 A schematic diagram of the structure of an automated simulation testing system for an AUTOSAR AP platform middleware, as a preferred embodiment of the present invention; Figure 2 This is a schematic diagram of the overall process of automated simulation testing in a preferred embodiment of the present invention. Figure 3 This is a flowchart illustrating the task execution process in a preferred embodiment of the present invention. Figure 4 A flowchart illustrating an automated simulation testing method for an AUTOSAR AP platform middleware, as a preferred embodiment of the present invention. Figure 5 This is a schematic diagram of the sub-process of step S2 in a preferred embodiment of the present invention. Detailed Implementation

[0019] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0020] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, an automated simulation testing system for AUTOSARAP platform middleware is provided, such as... Figures 1 to 3 As shown, it includes: Test Framework Library 100 is used to store a set of test operation encapsulation tools adapted to the AUTOSAR AP platform middleware; Project repository 200 is used to store test project resources adapted to the AUTOSAR AP platform middleware; Task executor 300 is connected to test framework library 100, project repository 200, and test platform 400, respectively. Task executor 300 includes: Resource retrieval module 1 is used to retrieve the associated test project resources based on the target test task configured by the tester through the test platform, and to retrieve the test operation encapsulation toolset in its entirety to form a resource set; Task execution module 2 is used to create a corresponding Docker container based on the actual deployment environment of the middleware on the target board. At the same time, it combines the resource set to build the middleware execution environment and maps the middleware execution environment to the Docker container to execute the target test task in the Docker container environment, complete the test data collection, result analysis and test report generation, and send the test report back to the test platform 400.

[0021] Specifically, in this embodiment, the aforementioned testing platform 400 preferably provides a front-end interactive interface and back-end services, supporting test task configuration, test set management, report viewing, and historical data tracing. The front-end interactive interface 401 is developed based on HTML+jQuery+CSS, realizing task configuration and result visualization. The back-end service adopts a Python+Django architecture, interacts with GitLab through the python-gitlab library, uses Allure to generate standardized test reports, uses Memcache to implement view caching, and uses SQLite3 as the database to store test task, result, and report data.

[0022] Among them, the front-end interactive interface 401 provided by the test platform 400 allows testers to configure a single test project or a test set containing multiple test projects as the target test task. Subsequently, the back-end service sends the task instruction to GitLab, triggering the GitLab-Runner / Jenkins to start the CICD process.

[0023] The aforementioned test framework library 100 stores a set of test operation encapsulation tools that encapsulate common operations into Python functions and Shell scripts, achieving standardization and reusability of the test process. It preferentially uses Python tools for environment building, container management, and data acquisition, generating Shell scripts as the process glue. It also employs Docker to build a virtual test environment, using CMake as the default compilation tool, and utilizes Tcpdump, Pyshark, and Scapy for network packet capture. It relies on common libraries such as JSON, YAML, and regular expressions for data parsing and configuration management.

[0024] The test operation encapsulation toolkit includes a development environment preparation script (init.py script), an execution environment preparation script (build.sh script), a test execution script (run.sh script), and an environment cleanup script (clean_env.sh script), which together form a complete test execution chain.

[0025] The aforementioned project repository 200 preferably stores scenario-based test project resources in the form of a Git repository. Each test project contains the user's arxml model, C++ test project (.cpp test code), yaml configuration file, and Shell test script, corresponding to an independent test scenario.

[0026] The aforementioned task executor 300 preferably uses GitLab-Runner / Jenkins as the CICD execution carrier, and includes a resource retrieval module 1 and a task execution module 2, which are responsible for the full-process automation of resource retrieval, environment building, test execution and result feedback.

[0027] In a preferred embodiment of the present invention, the task execution module 2 includes: Environment deployment unit 21 is used to execute the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources; Environment preparation unit 22 is connected to environment deployment unit and is used to execute the execution environment preparation script in the test operation encapsulation toolset in the middleware development environment, so as to call the sh tool package and build the middleware execution environment based on the test project, and create a blank test machine instance in the middleware execution environment. The test execution unit 23 and the connection environment preparation unit 22 are used to execute test execution scripts in the test operation encapsulation toolset to create Docker containers and map the middleware execution environment into the Docker containers so as to execute the target test tasks in the Docker container environment.

[0028] Specifically, in this embodiment, the `init.py` script is executed to install the target board middleware SDK, ARA runtime, and compilation toolchain to deploy the middleware development environment. Subsequently, the `build.sh` script is executed within the middleware development environment to call the `sh` toolkit to complete model integration, code merging, compilation and installation, and test machine updates, generating the `sh` toolkit and downloading the test project, providing dependencies and tool support for subsequent environment construction. The environment preparation unit 22 includes: Integration subunit 221 is used to call the standardized arxml integration command in the sh toolkit to integrate the user arxml model in the test project with the public arxml model in the test operation encapsulation toolkit to obtain the integrated arxml model; Merging subunit 222 is used to merge the user test code in the test project with the framework code in the test operation encapsulation toolkit to obtain a C++ test project; Compilation subunit 223 is used to call the standardized compilation instructions in the sh toolkit to compile the C++ test project and generate an executable file; The update subunit 224 is used to call the standardized update instructions in the sh toolkit to load the executable file and the integrated arxml model into the test machine in order to build the middleware execution environment.

[0029] Specifically, by integrating the user's arxml model with the public arxml model, a complete configuration adapted to the test machine is generated; by merging the user's test code and the framework code, a complete C++ test project is generated; by compiling the C++ test project, an executable file that can run on the test machine is generated; and by using the ara_cmd tool, the executable file and the integrated arxml model are loaded into a blank test machine to generate a middleware execution environment containing test logic.

[0030] Subsequently, the virtual environment deployment and test execution are completed by executing the run.sh script. Test execution unit 23 includes: Create subunit 231 to create a corresponding Docker container based on the actual deployment environment of the middleware on the target board and the ECU topology configuration in the test project resources; Mapping subunit 232 is used to map the middleware execution environment containing the test machine into a Docker container; Execution subunit 233 is used to start the test machine inside the Docker container to execute the target test task, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

[0031] In this configuration, each Docker container corresponds one-to-one with an ECU, meaning each container simulates one ECU. By mapping the middleware execution environment containing the test machine to the Docker container, core consistency between the virtual environment and the real deployment environment is achieved. The test machine within the Docker container then executes the various test cases included in the target test task. During execution, this includes switching functional group states, triggering communication interactions, collecting packet capture data to achieve test data acquisition, completing test result assertions, generating an Allure test report, and sending it back to the test platform 400. Further preferably, the execution subunit 233 is also used to accurately associate the test case ID with the execution log, SOME / IP packet capture data, machine operation log, and core dump file during test data acquisition, ensuring subsequent traceability.

[0032] In a preferred embodiment of the present invention, the task executor 300 further includes a task cleanup module 3, which is used to execute an environment cleanup script in the test operation encapsulation toolkit after the test report is sent back to the test platform 400, and to stop and delete the Docker containers associated with all deployed target test tasks.

[0033] Specifically, in this embodiment, the clean_env.sh script is executed after the test is completed to stop and delete the Docker container, clean up temporary files and log cache, and release execution node resources.

[0034] In a preferred embodiment of the present invention, the test report includes the execution results of each test case included in the target test task; The test platform 400 includes a result analysis module 402, which is used to perform preliminary analysis on test cases that fail to execute, in order to identify the failure points and indicate possible causes.

[0035] Specifically, in this embodiment, failed test cases are preferably associated and mapped with corresponding test logs, packet capture data, and machine operation logs. This allows for a structured presentation of anomalies and associated data links in the test report, clearly identifying failure points and indicating possible causes, all displayed through a front-end interactive interface. Furthermore, testers can directly click on failed test cases in the report to view associated data streams and log fragments, eliminating the need to manually sift through massive amounts of raw data. This significantly reduces the difficulty and time cost of troubleshooting, and improves problem-solving efficiency.

[0036] This invention also provides an automated simulation testing method for AUTOSAR AP platform middleware, applied to the aforementioned automated simulation testing system, such as... Figure 4 As shown, automated simulation testing methods include: Step S1: The automated simulation test system retrieves the associated test project resources from the project repository based on the target test task configured by the tester through the test platform, and fully retrieves the test operation encapsulation toolset from the test framework library to form a resource set. Step S2: The automated simulation testing system creates a corresponding Docker container based on the actual deployment environment of the middleware on the target board. At the same time, it builds a middleware execution environment in conjunction with the resource set and maps the middleware execution environment into the Docker container to execute the target test task in the Docker container environment, complete the test data collection, result analysis and test report generation, and send the test report back to the test platform.

[0037] In a preferred embodiment of the present invention, such as Figure 5 As shown, step S2 includes: Step S21: The automated simulation test system executes the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources. Step S22: The automated simulation test system executes the execution environment preparation script in the test operation encapsulation toolset within the middleware development environment to call the sh toolkit and build the middleware execution environment based on the test project, and creates a blank test machine instance in the middleware execution environment. Step S23: The automated simulation test system executes the test execution scripts in the test operation encapsulation toolset to create a Docker container and maps the middleware execution environment into the Docker container to execute the target test task in the Docker container environment.

[0038] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. An automated simulation testing system for AUTOSAR AP platform middleware, characterized in that, include: The test framework library stores a set of test operation encapsulation tools adapted to the AUTOSAR AP platform middleware; A project repository is used to store test project resources adapted to the AUTOSAR AP platform middleware; A task executor, connected to the test framework library, the project repository, and the test platform, comprises: The resource retrieval module is used to retrieve the associated test project resources based on the target test task configured by the tester through the test platform, and to retrieve the entire test operation encapsulation toolset to form a resource set; The task execution module is used to create a corresponding Docker container based on the actual deployment environment of the middleware on the target board, and at the same time build a middleware execution environment in combination with the resource set, and map the middleware execution environment into the Docker container to execute the target test task in the Docker container environment, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

2. The automated simulation testing system according to claim 1, characterized in that, The testing platform provides a front-end interactive interface for testers to configure a single test item or a test set containing multiple test items as the target test task.

3. The automated simulation testing system according to claim 1, characterized in that, The task execution module includes: The environment deployment unit is used to execute the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources; The environment preparation unit, connected to the environment deployment unit, is used to execute the execution environment preparation script in the test operation encapsulation toolset in the middleware development environment, so as to call the sh tool package and build the middleware execution environment based on the test project, and create a blank test machine instance in the middleware execution environment. The test execution unit, connected to the environment preparation unit, is used to execute the test execution script in the test operation encapsulation toolset to create the Docker container and map the middleware execution environment into the Docker container to execute the target test task in the Docker container environment.

4. The automated simulation testing system according to claim 3, characterized in that, The environment preparation unit includes: The integration subunit is used to call the standardized arxml integration command in the sh toolkit to integrate the user arxml model in the test project with the public arxml model in the test operation encapsulation toolkit to obtain the integrated arxml model; The merging subunit is used to merge the user test code in the test project with the framework code in the test operation encapsulation toolkit to obtain a C++ test project; The compilation subunit is used to call the standardized compilation instructions in the sh toolkit to compile the C++ test project and generate an executable file; The update subunit is used to call the standardized update instructions in the sh toolkit to load the executable file and the integrated arxml model into the test machine to build the middleware execution environment.

5. The automated simulation testing system according to claim 4, characterized in that, The test execution unit includes: Create a subunit to create the corresponding Docker container based on the actual deployment environment of the middleware on the target board and the ECU topology configuration in the test project resources; The mapping subunit is used to map the middleware execution environment containing the test machine into the Docker container; The execution subunit is used to start the test machine in the Docker container to execute the target test task, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

6. The automated simulation testing system according to claim 1, characterized in that, Each Docker container corresponds one-to-one with each ECU.

7. The automated simulation testing system according to claim 1, characterized in that, The task executor also includes a task cleanup module, which is used to execute the environment cleanup script in the test operation encapsulation toolset after the test report is sent back to the test platform, and to stop and delete all Docker containers associated with the deployed target test tasks.

8. The automated simulation testing system according to claim 1, characterized in that, The test report contains the execution results of each test case included in the target test task; The testing platform includes a result analysis module, which is used to perform preliminary analysis on the test cases that fail to execute, in order to identify the failure points and indicate possible causes.

9. An automated simulation testing method for AUTOSAR AP platform middleware, characterized in that, The automated simulation testing method, applied to the automated simulation testing system as described in any one of claims 1-8, comprises: Step S1: The automated simulation test system retrieves the associated test project resources from the project repository according to the target test task configured by the tester through the test platform, and retrieves the test operation encapsulation toolset from the test framework library to form a resource set. Step S2: The automated simulation testing system creates a corresponding Docker container based on the actual deployment environment of the middleware on the target board. At the same time, it builds a middleware execution environment in conjunction with the resource set and maps the middleware execution environment to the Docker container to execute the target test task in the Docker container environment, complete test data collection, result analysis and test report generation, and send the test report back to the test platform.

10. The automated simulation testing method according to claim 9, characterized in that, Step S2 includes: Step S21: The automated simulation test system executes the development environment preparation script in the test operation encapsulation toolset to deploy the middleware development environment, generate the sh tool package, and download the relevant test project from the pulled test project resources. Step S22: The automated simulation test system executes the execution environment preparation script in the test operation encapsulation toolset in the middleware development environment to call the sh toolkit and build the middleware execution environment based on the test project, and create a blank test machine instance in the middleware execution environment. Step S23: The automated simulation test system executes the test execution script in the test operation encapsulation toolset to create the Docker container, and maps the middleware execution environment into the Docker container to execute the target test task in the Docker container environment.

Images