Code testing method based on environmental virtualization and distributed behavior simulation drive

Abstract

The invention relates to software development, in particular to a code testing method based on environmental virtualization and distributed behavior simulation driving, and the method comprises the steps: a demand obtaining and modeling stage: converting a user demand into an executable semantic model and a design scheme; in the multi-dimensional environment virtualization and simulation stage, a multi-platform and multi-scene environment is simulated, and a reliable operation environment is provided for code testing and function verification; in the automatic testing stage, code testing and function verification are achieved through an automatic tool; in the feedback and optimization stage, code design is continuously optimized by analyzing a test result, and closed-loop improvement is completed; a deployment and maintenance stage: performing automatic deployment of codes and continuous maintenance of the system; according to the technical scheme, the defects that in the prior art, a multi-platform environment is difficult to support, static analysis and testing are not comprehensive enough, and an effective feedback mechanism is lacked can be effectively overcome.

Description

Technical Field

[0001] The present invention relates to software development, and in particular to a code testing method based on environment virtualization and distributed behavior simulation driving. Background Art

[0002] In the process of software development, code generation, testing and optimization are key links. Traditional software development methods often require developers to manually write code, and then test and optimize it manually or semi-automatically. This method is inefficient and prone to errors. With the continuous development of technologies such as cloud computing and big data, software development has entered a new era of automation and intelligence.

[0003] Among the existing technical solutions, the closest existing technical solution is the practice of continuous integration (CI) and continuous deployment (CD). This practice emphasizes frequent integration of code into the main branch during the software development process, and quickly discovers and fixes errors through automated building and testing to ensure software quality. At the same time, continuous deployment enables new versions of the software to be delivered to users faster.

[0004] Specifically, the steps of this practice usually include: developers submit code to the version control system; trigger the continuous integration server to build and test; if the build and test are successful, the code is merged into the main branch; if the build and test fail, the developer needs to fix the error and then resubmit the code. This practice can improve the quality and efficiency of software development to a certain extent, but in a multi-platform development environment, it has the following disadvantages:

[0005] 1) Lack of consideration for multi-platform environments: Traditional continuous integration and continuous deployment practices mainly focus on the construction and testing of a single platform, and lack support for multi-platform environments, which may lead to compatibility or performance issues in the generated code on some platforms;

[0006] 2) Insufficient static analysis and testing: Usually, the focus is on code construction and unit testing, but insufficient attention is paid to static analysis and integration testing of the code. This may cause some syntax errors and logic errors to be ignored in the early stages and not discovered until the later stages, increasing the difficulty and cost of repair;

[0007] 3) Lack of effective feedback mechanism: Although the results of build and test can be collected, there is often no clear guidance on how to use these results for feedback and optimization. This may result in problems in the software development process not being discovered and resolved in a timely manner, affecting the quality of the software and the reliability of deployment. Summary of the invention

[0008] 1. Technical issues to be resolved

[0009] In view of the above-mentioned shortcomings of the prior art, the present invention provides a code testing method based on environment virtualization and distributed behavior simulation drive, which can effectively overcome the defects of the prior art in supporting multi-platform environments, incomplete static analysis and testing, and lack of an effective feedback mechanism.

[0010] (II) Technical solution

[0011] To achieve the above objectives, the present invention is implemented through the following technical solutions:

[0012] The code testing method based on environment virtualization and distributed behavior simulation driving includes the following steps:

[0013] S1, Requirements acquisition and modeling phase: converting user requirements into executable semantic models and design solutions;

[0014] S2, Multi-dimensional environment virtualization and simulation stage: simulate multi-platform and multi-scenario environments to provide a reliable operating environment for code testing and function verification;

[0015] S3, Automated testing phase: Use automated tools to implement code testing and functional verification;

[0016] S4, Feedback and Optimization Phase: Continuously optimize code design by analyzing test results to complete closed-loop improvement;

[0017] S5, Deployment and maintenance phase: automatic code deployment and continuous system maintenance.

[0018] Preferably, the requirements acquisition and modeling phase in S1: converting user requirements into executable semantic models and design solutions, including:

[0019] S11. Natural language analysis: Use natural language processing technology to analyze user input requirements;

[0020] S12, demand semantic modeling: build a three-layer semantic model and use the domain knowledge graph to complete the mapping from demand to design solution;

[0021] S13, demand verification and confirmation: automatically generate a demand confirmation form for the user to confirm. If the user confirms, enter S2, otherwise return to S11, the user modifies the demand, and regenerates the demand confirmation form for the user to confirm;

[0022] Among them, the word segmentation tools NLTK, Spacy and the entity recognition algorithm NER are combined to parse user input needs.

[0023] Preferably, the demand semantic modeling in S12: constructing a three-layer semantic model, using the domain knowledge graph to complete the mapping from demand to design solution, including:

[0024] S121. Construct a three-layer semantic model:

[0025] Functional layer, extracting functional points from requirements;

[0026] Business layer, defines the business logic relationship between function points;

[0027] The technical layer determines the technical implementation details;

[0028] S122. Use the domain knowledge graph to complete the mapping from requirements to design solutions.

[0029] Preferably, the multi-dimensional environment virtualization and simulation stage in S2: simulates multi-platform and multi-scenario environments to provide a reliable operating environment for code testing and function verification, including:

[0030] S21. Virtualization environment construction: Build containerized images adapted to different platforms and dynamically load platform-related dependencies;

[0031] S22, Multi-dimensional scenario simulation: Configure virtual environment parameters, use distributed simulation tools to define different scenarios based on behavior scripts to simulate user behavior, and use container image stacking mechanism to build high-fidelity environment images;

[0032] S23, Dynamic environment scheduling: Use the scheduler Kubernetes to automatically allocate computing resources, support multi-environment concurrent testing, dynamically allocate computing resources when resources are limited, ensure the scheduling efficiency of simulation tasks, provide an environment status monitoring interface, and monitor the simulation effect in real time;

[0033] In the construction of the virtualized environment, Docker, Kubernetes and OpenStack are used to build containerized images adapted to different platforms, and platform-related dependencies are dynamically loaded;

[0034] In the multi-dimensional scenario simulation, the distributed simulation tools Apache JMeter and Locust are used to define different scenarios based on behavior scripts to simulate user behavior.

[0035] Preferably, the multi-dimensional scenario simulation in S22: using the container image stacking mechanism to build a high-fidelity environment image, including:

[0036] S221, build a universal basic image;

[0037] S222, adding specific configurations for different operating systems;

[0038] S223, dynamically loading a configuration file for a specific user requirement;

[0039] The construction process of the high-fidelity environment image is expressed as follows:

[0040]

[0041] In the above formula, M base As the base image, C i is the i-th environment configuration layer, n is the number of environment configuration layers, M final Mirror the environment for high fidelity.

[0042] Preferably, the dynamic environment scheduling in S23: dynamically allocating computing resources to ensure the scheduling efficiency of simulation tasks under resource constraints, including:

[0043] S231, dynamically allocate computing resources using the scheduler Kubernetes according to container resource requests and node resource conditions;

[0044] S232, introduce a task priority queue and adjust the priority according to the importance of the task;

[0045] The computing resource allocation formula of the scheduler Kubernetes based on resource constraints is as follows:

[0046]

[0047] In the above formula, R available (N i ) is node N i Available computing resources, R required (T k ) is task T k The computing resource requirements of R alloc (N i ) is assigned to node N i computing resources.

[0048] Preferably, in the automated testing phase of S3, code testing and functional verification are implemented using automated tools, including:

[0049] S31. Code quality analysis: Scan the code to check for syntax errors, potential vulnerabilities, and non-standard code;

[0050] S32, Unit test: Generate unit test scripts based on the requirements semantic modeling results, covering all relevant functions;

[0051] S33, Integration test: simulate the real system operating environment and test the interfaces and dependencies between modules;

[0052] S34, Distributed Behavior Simulation: Simulate user behavior in a distributed environment, generate real loads of high concurrency and complex scenarios, and ensure the consistency and synchronization of behavior scripts in different containers;

[0053] S35. Result collection: Collect the test results of unit testing and integration testing, and automatically generate test reports for developers’ reference;

[0054] In the code quality analysis, code formatting tools Prettier and Black and static analysis tool SonarQube are combined to perform code scanning to check syntax errors, potential vulnerabilities and non-standard codes;

[0055] In unit testing, JUnit, PyTest, and Mocha frameworks are used to generate unit test scripts based on the results of semantic modeling of requirements, covering all relevant functions;

[0056] In integration testing, Postman is used for interface testing and Cypress is used for front-end integration testing.

[0057] Preferably, the distributed behavior simulation in S34: simulating user behavior in a distributed environment to generate a real load of high concurrency and complex scenarios, including:

[0058] 1) Use an event-based user behavior model to simulate user behavior in a distributed environment, generate real loads in high-concurrency and complex scenarios, and synchronize events between distributed nodes through message queues;

[0059] Among them, the user behavior model is modeled as a discrete event sequence B:

[0060] B={(t1,a1),(t2,a2),…,(t m ,a m )};

[0061] In the above formula, t m is the trigger time of the mth event, a m is the behavior type of the mth event, and m is the number of events;

[0062] 2) Introduce reinforcement learning models to optimize behavior scripts: Use historical load data sets to train reinforcement learning models to generate new behavior scripts to adapt to dynamic changes in scenarios.

[0063] Preferably, in the feedback and optimization phase of S4: by analyzing the test results, continuously optimizing the code design and completing closed-loop improvements, including:

[0064] S41, Data Collection: Collect data including static analysis results, test logs and system performance indicators;

[0065] S42, Data analysis and problem location: Use analysis algorithms to locate the root cause of the problem, and automatically generate a problem report, annotate the problem module and optimization suggestions;

[0066] S43, Closed-loop optimization: adjust the requirements semantic modeling and code generation rules according to the problem report, and automatically trigger code generation and retesting;

[0067] In data collection, the log collection tool ELK Stack is used to collect data including static analysis results, test logs, and system performance indicators;

[0068] In data analysis and problem location, cluster analysis and anomaly detection are used to locate the root cause of the problem.

[0069] Preferably, the deployment and maintenance phase in S5: automatic deployment of code and continuous maintenance of the system, including:

[0070] S51, Automated deployment: Automatically generate deployment scripts and configure the operating environment;

[0071] S52, operation status monitoring: real-time monitoring of system operation status, collection of performance data and user behavior data;

[0072] S53, Continuous Update and Maintenance: Based on user feedback and system operation status data, a new round of optimization is initiated, and new versions are automatically iterated and deployed;

[0073] In automated deployment, deployment tools Ansible and Terraform are used to automatically generate deployment scripts and configure the operating environment.

[0074] In operation status monitoring, monitoring tools Prometheus and Grafana are used to monitor the system operation status in real time and collect performance data and user behavior data.

[0075] (III) Beneficial effects

[0076] Compared with the prior art, the code testing method based on environment virtualization and distributed behavior simulation drive provided by the present invention has the following beneficial effects:

[0077] 1) Support for multi-platform environments: Through containerization technology, the present invention can simulate different platform environments, verify the correctness and performance of the generated code on each platform, and ensure the accuracy and availability of the code;

[0078] 2) Comprehensive static analysis and testing: The present invention integrates code formatting tools and static analysis tools, which can automatically check and correct syntax errors and logical errors in the code. At the same time, by automatically running unit tests and configuring automated integration tests, the correctness of the code functions can be fully verified;

[0079] 3) Effective feedback mechanism: The present invention can collect data such as static analysis results, test logs, and system performance indicators, and improve the quality of software and the reliability of deployment through feedback loops and continuous improvement. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0081] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0082] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0083] Code testing methods driven by environment virtualization and distributed behavior simulation, such as Figure 1 As shown in S1, demand acquisition and modeling phase: converting user requirements into executable semantic models and design solutions, including:

[0084] S11. Natural language analysis: Use natural language processing technology to analyze user input requirements (including function descriptions, performance requirements, platform restrictions, etc.);

[0085] S12, demand semantic modeling: build a three-layer semantic model and use the domain knowledge graph to complete the mapping from demand to design solution;

[0086] S13, demand verification and confirmation: automatically generate a demand confirmation form for the user to confirm. If the user confirms, enter S2, otherwise return to S11, the user modifies the demand, and regenerates the demand confirmation form for the user to confirm;

[0087] Among them, the word segmentation tools NLTK, Spacy and the entity recognition algorithm NER are combined to parse user input needs.

[0088] Specifically, demand semantic modeling in S12: construct a three-layer semantic model and use the domain knowledge graph to complete the mapping from demand to design solution, including:

[0089] S121. Construct a three-layer semantic model:

[0090] Functional layer, extracting functional points in requirements (such as login, payment);

[0091] The business layer defines the business logic relationship between function points (e.g. payment depends on order generation);

[0092] The technical layer determines the technical implementation details (such as database call methods);

[0093] S122. Use the domain knowledge graph to complete the mapping from requirements to design solutions.

[0094] S2, Multi-dimensional environment virtualization and simulation stage: simulate multi-platform and multi-scenario environments to provide a reliable operating environment for code testing and function verification, including:

[0095] S21. Virtualization environment construction: Build containerized images adapted to different platforms (such as Linux, Windows, macOS), and dynamically load platform-related dependencies (such as library files and operating environment);

[0096] S22, Multi-dimensional scenario simulation: Configure virtual environment parameters (including network bandwidth, latency, and storage space, etc.), use distributed simulation tools to define different scenarios (such as high concurrency, network disconnection) based on behavior scripts to simulate user behavior, and use the container image stacking mechanism to build a high-fidelity environment image;

[0097] S23, Dynamic environment scheduling: Use the scheduler Kubernetes to automatically allocate computing resources, support multi-environment concurrent testing, dynamically allocate computing resources (such as CPU, memory) when resources are limited, ensure the scheduling efficiency of simulation tasks, provide an environment status monitoring interface, and monitor the simulation effect in real time;

[0098] In the construction of the virtualized environment, Docker, Kubernetes and OpenStack are used to build containerized images adapted to different platforms, and platform-related dependencies are dynamically loaded;

[0099] In the multi-dimensional scenario simulation, the distributed simulation tools Apache JMeter and Locust are used to define different scenarios based on behavior scripts to simulate user behavior.

[0100] 1) Multi-dimensional scenario simulation in S22: Use the container image stacking mechanism to build a high-fidelity environment image, including:

[0101] S221. Build a general base image (including commonly used dependent libraries);

[0102] S222. Adding specific configurations for different operating systems (e.g., adding .NET environment to Windows images);

[0103] S223, dynamically loading configuration files for specific user needs (such as network settings, resource restrictions);

[0104] The construction process of the high-fidelity environment image is expressed as follows:

[0105]

[0106] In the above formula, M base As the base image, C i is the i-th environment configuration layer, n is the number of environment configuration layers, M final Mirror the environment for high fidelity.

[0107] 2) Dynamic environment scheduling in S23: Dynamically allocate computing resources to ensure the scheduling efficiency of simulation tasks when resources are limited, including:

[0108] S231, dynamically allocate computing resources using the scheduler Kubernetes according to container resource requests and node resource conditions;

[0109] S232, introduce a task priority queue (Priority Queue) to adjust the priority according to the importance of the task (such as real-time requirements);

[0110] The computing resource allocation formula of the scheduler Kubernetes based on resource constraints is as follows:

[0111]

[0112] In the above formula, R available (N i ) is node N i Available computing resources, R required (T k ) is task T k The computing resource requirements of R alloc (N i ) is assigned to node N i computing resources.

[0113] S3, Automated testing phase: Use automated tools to implement code testing and functional verification, including:

[0114] S31. Code quality analysis: Scan the code to check for syntax errors, potential vulnerabilities, and non-standard code;

[0115] S32, Unit test: Generate unit test scripts based on the requirements semantic modeling results, covering all relevant functions;

[0116] S33, Integration test: simulate the real system operating environment and test the interfaces and dependencies between modules;

[0117] S34, Distributed Behavior Simulation: Simulate user behavior in a distributed environment, generate real loads of high concurrency and complex scenarios, and ensure the consistency and synchronization of behavior scripts in different containers;

[0118] S35, Result Collection: Collect the test results of unit testing and integration testing (including pass rate, error logs and performance indicators, etc.), and automatically generate test reports for developers' reference;

[0119] In the code quality analysis, code formatting tools Prettier and Black and static analysis tool SonarQube are combined to perform code scanning to check syntax errors, potential vulnerabilities and non-standard codes;

[0120] In unit testing, JUnit, PyTest, and Mocha frameworks are used to generate unit test scripts based on the results of semantic modeling of requirements, covering all relevant functions;

[0121] In integration testing, Postman is used for interface testing and Cypress is used for front-end integration testing.

[0122] Specifically, S34's distributed behavior simulation simulates user behavior in a distributed environment and generates realistic loads in high-concurrency and complex scenarios, including:

[0123] 1) Use an event-based user behavior model to simulate user behavior in a distributed environment, generate real loads in high-concurrency and complex scenarios, and synchronize events between distributed nodes through message queues;

[0124] Among them, the user behavior model is modeled as a discrete event sequence B:

[0125] B={(t1,a1),(t2,a2),...,(t m ,a m )};

[0126] In the above formula, t m is the trigger time of the mth event, a m is the behavior type of the mth event (e.g., login, browsing), and m is the number of events;

[0127] 2) Introduce reinforcement learning models to optimize behavior scripts: Use historical load data sets to train reinforcement learning models to generate new behavior scripts to adapt to dynamic changes in scenarios.

[0128] S4, Feedback and Optimization Phase: By analyzing the test results, continuously optimize the code design and complete the closed-loop improvement, including:

[0129] S41, Data Collection: Collect data including static analysis results, test logs and system performance indicators;

[0130] S42, Data analysis and problem location: Use analysis algorithms to locate the root cause of the problem, and automatically generate a problem report, annotate the problem module and optimization suggestions;

[0131] S43, Closed-loop optimization: adjust the requirements semantic modeling and code generation rules according to the problem report, and automatically trigger code generation and retesting;

[0132] In data collection, the log collection tool ELK Stack (Elasticsearch, Logstash, Kibana) is used to collect data including static analysis results, test logs and system performance indicators;

[0133] In data analysis and problem location, cluster analysis and anomaly detection are used to locate the root cause of the problem.

[0134] S5, Deployment and Maintenance Phase: Automated code deployment and continuous system maintenance, including:

[0135] S51. Automated deployment: Automatically generate deployment scripts and configure the operating environment (such as cloud servers and container clusters);

[0136] S52, operation status monitoring: real-time monitoring of system operation status, collection of performance data and user behavior data;

[0137] S53, Continuous Update and Maintenance: Based on user feedback and system operation status data, a new round of optimization is initiated, and new versions are automatically iterated and deployed;

[0138] In automated deployment, deployment tools Ansible and Terraform are used to automatically generate deployment scripts and configure the operating environment.

[0139] In operation status monitoring, monitoring tools Prometheus and Grafana are used to monitor the system operation status in real time and collect performance data and user behavior data.

[0140] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A code testing method based on environment virtualization and distributed behavior simulation drive, characterized in that: The following steps are involved: S1, Requirements acquisition and modeling phase: converting user requirements into executable semantic models and design solutions; S2, Multi-dimensional environment virtualization and simulation stage: simulate multi-platform and multi-scenario environments to provide a reliable operating environment for code testing and function verification; S3, Automated testing phase: Use automated tools to implement code testing and functional verification; S4, Feedback and Optimization Phase: Continuously optimize code design by analyzing test results to complete closed-loop improvement; S5, Deployment and maintenance phase: automatic code deployment and continuous system maintenance.

2. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 1 is characterized in that: Requirements acquisition and modeling phase in S1: Convert user requirements into executable semantic models and design solutions, including: S11. Natural language analysis: Use natural language processing technology to analyze user input requirements; S12, demand semantic modeling: build a three-layer semantic model and use the domain knowledge graph to complete the mapping from demand to design solution; S13, demand verification and confirmation: automatically generate a demand confirmation form for the user to confirm. If the user confirms, then go to S2, otherwise return to S11, the user modifies the demand, and regenerates the demand confirmation form for the user to confirm; Among them, the word segmentation tools NLTK, Spacy and the entity recognition algorithm NER are combined to parse user input needs.

3. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 2 is characterized in that: Semantic modeling of requirements in S12: Build a three-layer semantic model and use the domain knowledge graph to complete the mapping from requirements to design solutions, including: S121. Construct a three-layer semantic model: Functional layer, extracting functional points from requirements; Business layer, defines the business logic relationship between function points; The technical layer determines the technical implementation details; S122. Use the domain knowledge graph to complete the mapping from requirements to design solutions.

4. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 2 is characterized in that: Multi-dimensional environment virtualization and simulation stage in S2: simulate multi-platform and multi-scenario environments to provide a reliable operating environment for code testing and function verification, including: S21. Virtualization environment construction: Build containerized images adapted to different platforms and dynamically load platform-related dependencies; S22, Multi-dimensional scenario simulation: Configure virtual environment parameters, use distributed simulation tools to define different scenarios based on behavior scripts to simulate user behavior, and use container image stacking mechanism to build high-fidelity environment images; S23, Dynamic environment scheduling: Use the scheduler Kubernetes to automatically allocate computing resources, support multi-environment concurrent testing, dynamically allocate computing resources when resources are limited, ensure the scheduling efficiency of simulation tasks, provide an environment status monitoring interface, and monitor the simulation effect in real time; In the construction of the virtualized environment, Docker, Kubernetes and OpenStack are used to build containerized images adapted to different platforms, and platform-related dependencies are dynamically loaded; In the multi-dimensional scenario simulation, the distributed simulation tools Apache JMeter and Locust are used to define different scenarios based on behavior scripts to simulate user behavior.

5. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 4 is characterized in that: Multi-dimensional scenario simulation in S22: Use the container image stacking mechanism to build a high-fidelity environment image, including: S221, build a universal basic image; S222, adding specific configurations for different operating systems; S223, dynamically loading a configuration file for a specific user requirement; The construction process of the high-fidelity environment image is expressed as follows: In the above formula, M base As the base image, C i is the i-th environment configuration layer, n is the number of environment configuration layers, M final Mirror the environment for high fidelity.

6. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 4 is characterized in that: Dynamic environment scheduling in S23: Dynamically allocate computing resources to ensure the scheduling efficiency of simulation tasks when resources are limited, including: S231, dynamically allocate computing resources using the scheduler Kubernetes according to container resource requests and node resource conditions; S232, introduce a task priority queue and adjust the priority according to the importance of the task; The computing resource allocation formula of the scheduler Kubernetes based on resource constraints is as follows: In the above formula, R available (N i ) is node N i Available computing resources, R required (T k ) is task T k The computing resource requirements of R alloc (N i ) is assigned to node N i computing resources.

7. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 4 is characterized in that: Automated testing phase in S3: Use automated tools to implement code testing and functional verification, including: S31. Code quality analysis: Scan the code to check for syntax errors, potential vulnerabilities, and non-standard code; S32, Unit test: Generate unit test scripts based on the requirements semantic modeling results, covering all relevant functions; S33, Integration test: simulate the real system operating environment and test the interfaces and dependencies between modules; S34, Distributed Behavior Simulation: Simulate user behavior in a distributed environment, generate real loads of high concurrency and complex scenarios, and ensure the consistency and synchronization of behavior scripts in different containers; S35. Result collection: Collect the test results of unit testing and integration testing, and automatically generate test reports for developers’ reference; In the code quality analysis, code formatting tools Prettier and Black and static analysis tool SonarQube are combined to perform code scanning to check syntax errors, potential vulnerabilities and non-standard codes; In unit testing, JUnit, PyTest, and Mocha frameworks are used to generate unit test scripts based on the results of semantic modeling of requirements, covering all relevant functions; In integration testing, Postman is used for interface testing and Cypress is used for front-end integration testing.

8. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 7 is characterized in that: Distributed behavior simulation in S34: simulates user behavior in a distributed environment and generates realistic loads in high-concurrency and complex scenarios, including: 1) Use an event-based user behavior model to simulate user behavior in a distributed environment, generate real loads in high-concurrency and complex scenarios, and synchronize events between distributed nodes through message queues; Among them, the user behavior model is modeled as a discrete event sequence B: B={(t1,a1),(t2,a2),...,(t m ,a m )}; In the above formula, t m is the trigger time of the mth event, a m is the behavior type of the mth event, and m is the number of events; 2) Introduce reinforcement learning models to optimize behavior scripts: Use historical load data sets to train reinforcement learning models to generate new behavior scripts to adapt to dynamic changes in scenarios.

9. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 7 is characterized in that: Feedback and optimization phase in S4: By analyzing the test results, the code design is continuously optimized to complete closed-loop improvements, including: S41, Data Collection: Collect data including static analysis results, test logs and system performance indicators; S42, Data analysis and problem location: Use analysis algorithms to locate the root cause of the problem, and automatically generate a problem report, annotate the problem module and optimization suggestions; S43, Closed-loop optimization: adjust the requirements semantic modeling and code generation rules according to the problem report, and automatically trigger code generation and retesting; In data collection, the log collection tool ELK Stack is used to collect data including static analysis results, test logs, and system performance indicators; In data analysis and problem location, cluster analysis and anomaly detection are used to locate the root cause of the problem.

10. The code testing method based on environment virtualization and distributed behavior simulation drive according to claim 9, characterized in that: Deployment and maintenance phase in S5: Automated code deployment and continuous system maintenance, including: S51, Automated deployment: Automatically generate deployment scripts and configure the operating environment; S52, operation status monitoring: real-time monitoring of system operation status, collection of performance data and user behavior data; S53, Continuous Update and Maintenance: Based on user feedback and system operation status data, a new round of optimization is initiated, and new versions are automatically iterated and deployed; In automated deployment, deployment tools Ansible and Terraform are used to automatically generate deployment scripts and configure the operating environment. In operation status monitoring, monitoring tools Prometheus and Grafana are used to monitor the system operation status in real time and collect performance data and user behavior data.

Images