A self-optimizing security testing method, system, and computer-readable storage medium

Abstract

As various systems evolve towards autonomous self-evolution, self-optimization capability has become a crucial characteristic of modern systems. Systems need to be able to propose improvement suggestions and automatically modify their own code or configuration based on operational data, user feedback, or external instructions. However, existing technologies suffer from deficiencies such as a lack of secure testing mechanisms, data corruption during testing, a stateless branching concept, a lack of conflict handling mechanisms, and insufficient rollback capabilities. This application provides a secure testing method, system, and computer-readable storage medium for system self-optimization, aiming to enable the target system to test improvement suggestions in an isolated environment, independently store state changes generated during testing, intelligently merge them into the main system after successful testing, safely discard them upon test failure, and support precise rollback, ensuring the system maintains stability and data integrity while autonomously evolving.

Description

Technical Field

[0001] This application relates to the fields of system security and software testing technology, and more specifically, to a system self-optimizing security testing method, system, and computer-readable storage medium. Background Technology

[0002] With the rapid development of information technology, various systems, such as software systems, industrial control systems, robotic systems, and vehicle systems, are gradually acquiring autonomous evolution capabilities. They can generate improvement suggestions based on operational data, user feedback, or external commands and attempt to automatically modify their own code or configuration. However, existing technologies have significant shortcomings in achieving system self-optimization. First, there is a lack of effective security testing mechanisms. Directly implementing code or configuration modifications on the main system may lead to system crashes, data corruption, or service interruptions because the absence of an isolated environment to verify the improvement effects results in a very high risk of irreversible errors. Second, data management issues are prominent during testing: the interaction between the system and the external environment inevitably generates new state data, such as user operation logs, sensor readings, or internal state changes. Directly writing this data to the main storage system will pollute production data, while completely discarding it wastes valuable operational information. Third, existing systems do not introduce the concept of state branches, making it impossible to isolate and store state changes in the test environment from the main system state, resulting in the inability to intelligently merge valid data after the test is passed. Fourth, when the state records generated during testing overlap in timestamps or conflict in content with existing records in the main system, there is a lack of reasonable conflict detection and handling mechanisms, which can easily lead to data chaos. Finally, the rollback capability is severely inadequate: once self-optimization fails, the system struggles to accurately restore itself to its pre-modification state. Rollback operations on complex state data are often incomplete or unreliable, increasing the risk of system instability. These issues collectively constrain the security and reliability of the system's autonomous evolution.

[0003] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0004] The purpose of this application is to provide a security testing method, system, and computer-readable storage medium for system self-optimization, which has the advantages of significantly reducing the risk of crashes, data corruption, and service interruptions during the system self-optimization process by isolating the test environment and intelligent data management, thereby improving security and reliability.

[0005] Firstly, this application discloses a security testing method for system self-optimization, the technical solution of which is as follows: A security testing method for system self-optimization includes the following steps: Receive improvement suggestions for the target system; In response to triggering conditions, a test environment isolated from the target system is created. The test environment contains a copy of the target system's code and state data. Apply the improvement recommendations in the test environment; Run automated tests in a test environment to verify the effectiveness of the improvements; State changes that occur during the test environment's operation are recorded in the state data copy; The decision on whether to merge the records and code copies in the state data copy into the target system will be based on the test results.

[0006] Furthermore, this application also proposes that the triggering conditions include at least one of user approval, automatic system triggering, or external event triggering.

[0007] Furthermore, this application also proposes that the isolation between the test environment and the target system includes, but is not limited to, at least one of process isolation, file isolation, or data isolation.

[0008] Furthermore, this application also proposes to determine whether to merge based on test results: If the test passes, the records in the status data copy will be merged into the status data of the target system according to preset rules, and the code copy will be merged into the code library of the target system. If the test fails, discard the state data copy and the code copy.

[0009] Furthermore, this application also proposes that merging according to preset rules includes: detecting whether there is a timestamp conflict between the record and the target system status data, and merging according to the conflict handling strategy.

[0010] Furthermore, this application proposes that conflict resolution strategies include, but are not limited to, retaining target system data, overwriting target system data, or inserting data after adjusting timestamps.

[0011] Furthermore, this application also proposes that automated testing includes, but is not limited to, at least one of unit testing, integration testing, performance testing, or security testing.

[0012] Furthermore, this application also proposes to include creating a complete snapshot of the target system prior to the merger, the snapshot including code version and state data backups.

[0013] Furthermore, this application also proposes to include support for rolling back to a snapshot to restore the code and state data of the target system.

[0014] Secondly, this application also discloses a security testing system for self-optimization of software systems, comprising: The suggestion receiving module is used to receive improvement suggestions for the target system; The test environment creation module is used to create a test environment isolated from the target system in response to triggering conditions. The test environment contains a copy of the target system's code and a copy of its state data. Improve the application module to apply improvement suggestions in the test environment; The test module is used to run automated tests in the test environment; The state management module is used to record state changes that occur during the operation of the test environment in a state data copy; The merge decision module is used to determine whether to merge the records and code copies in the state data copy into the target system based on the test results.

[0015] Furthermore, this application also proposes to include a version control module for creating a complete snapshot of the target system prior to merging and supporting rollback.

[0016] Furthermore, this application also proposes that the test environment creation module be configured to implement at least one of process isolation, file isolation, or data isolation.

[0017] Thirdly, this application also discloses a computer-readable storage medium having a computer program stored thereon, which implements the above-described method when executed by a processor.

[0018] As can be seen from the above, the security testing method, system, and computer-readable storage medium for system self-optimization provided in this application solve the problems of lack of security testing mechanism and data management defects in the prior art by creating an isolated test environment, applying improvement suggestions, running automated tests, recording state changes, and deciding on merging based on the results. It has the advantages of improving the security and reliability of the system self-optimization process. Attached Figure Description

[0019] Several embodiments of this application are described below with reference to the accompanying drawings. It should be noted that the specific structures, modules, steps, parameters, and connections shown in the drawings are preferred embodiments of this application and not limitations on the scope of protection of this application. Those skilled in the art can make various modifications, substitutions, or combinations to the specific details shown in the drawings based on the teachings of this application, and these modified embodiments should still be considered to fall within the scope of protection of this application.

[0020] Figure 1 This application provides a system architecture diagram. The diagram is an example of the system architecture of this application. The module division and connection relationship are only illustrative and do not limit the scope of protection of the claims.

[0021] Figure 2This application provides a flowchart for creating and improving a test environment. The flowchart shows an example of the process for creating and improving a test environment. The specific order of steps can be adjusted according to actual needs and does not constitute a limitation on the claims.

[0022] Figure 3 This application provides a state branch merging decision-making flowchart. The flowchart shown is an example of the merging decision-making process of this application. The specific decision-making logic can be configured according to actual needs and does not constitute a limitation on the claims.

[0023] Figure 4 This diagram illustrates how branch records are inserted into the main system status data, and is intended to serve as a reference for merging status data by timestamp. The diagram is merely an example and does not constitute a limitation on the claims. Detailed Implementation

[0024] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. Other technologies that may be mentioned in the embodiments can be implemented using existing technology or other patent applications filed by the applicant on the same day, and will not be repeated here. It should be particularly noted that the specific module divisions, process steps, data flow directions, status names, time values, etc., shown in the accompanying drawings are merely illustrative examples and should not constitute a limitation on the scope of protection of the claims of this application. The scope of protection of the claims is determined solely by their wording and should be interpreted in accordance with the overall content of the specification.

[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] During the system's self-optimization process, existing technologies lack secure testing mechanisms, which can lead to irreversible errors or even system boot failures if the main system code or configuration is directly modified. Specifically, writing state data generated during system interaction with the external environment directly to main storage during testing can cause data corruption, while discarding it completely wastes valuable runtime information. Furthermore, the stateless branching concept makes it impossible to isolate test state changes from the main system state during storage; the lack of conflict handling mechanisms leads to data corruption during merging; and insufficient rollback capabilities make it difficult to accurately restore the system to its pre-optimization state. These issues affect system stability and data integrity, exposing the system to high risks during its autonomous evolution.

[0027] For example, in a self-optimization scenario of an intelligent agent system, after the agent generates improvement suggestions based on user feedback, if the modifications are directly applied to the main system, user interaction logs and internal state changes during testing are recorded in the main storage. When the test runs, the newly generated state records overlap with existing records in the main system. Due to the lack of a conflict detection mechanism, data is overwritten or lost, leading to inconsistent system states. Furthermore, residual test data cannot be completely cleared after a test failure, affecting subsequent user interactions and system decision-making processes. In this scenario, the state data contamination problem renders historical behavior analysis ineffective, and the system cannot be restored to a reliable state.

[0028] If these issues are not addressed, system stability will be severely impacted. Critical business operations may be interrupted due to test failures, and recovery to a reliable state may be impossible. Data contamination will reduce system reliability, render historical state analysis ineffective, and increase system maintenance complexity. Furthermore, the lack of a conflict resolution mechanism leads to data chaos during state merging, and insufficient rollback capabilities make it difficult for the system to cope with optimization failure scenarios, ultimately affecting the system's long-term evolution capabilities.

[0029] To address this, this application proposes a security testing method for system self-optimization, comprising the following steps: Receive improvement suggestions for the target system; In response to triggering conditions, a test environment isolated from the target system is created. The test environment contains a copy of the target system's code and state data. Apply the improvement recommendations in the test environment; Run automated tests in a test environment to verify the effectiveness of the improvements; State changes that occur during the test environment's operation are recorded in the state data copy; The decision on whether to merge the records and code copies in the state data copy into the target system will be based on the test results.

[0030] For ease of understanding, the following explains some key terms in this embodiment: A target system refers to any software or hardware system that requires self-optimization, updates, or configuration changes. This system can be a standalone application, a complex distributed system, an embedded device, or a cloud service, etc.

[0031] Improvement suggestions refer to proposed modifications to a target system aimed at enhancing its functionality, performance, security, or stability. These suggestions can include code-level modifications, adjustments to configuration parameters, or optimizations to data structures.

[0032] A trigger condition refers to a specific event or state that initiates the system's self-optimization security testing process. This condition can be an external command, an anomaly detected internally by the system, or a preset time point, etc.

[0033] A test environment is a runtime environment specifically created to verify improvement recommendations, completely isolated from the target system. This environment is designed to simulate the real-world operating conditions of the target system, but its operation will not have any direct impact on the target system.

[0034] A code copy refers to a complete replica of the target system's currently running codebase. This copy is modified and executed in a test environment to validate improvement recommendations.

[0035] A state data copy refers to a complete replica of the target system's current operational state data. This copy records all data changes caused by improvement suggestions or during testing within the test environment, and is independent of the target system's actual state data.

[0036] Automated testing refers to a set of pre-written test cases that can be executed automatically to verify the functionality, performance, or security of a system. These tests aim to objectively evaluate the effectiveness of improvement suggestions and detect potential problems.

[0037] Merging refers to the process of integrating the valid records from the modified code copy and state data copy in the test environment into the target system after the improvement proposal has been verified through testing.

[0038] The security testing method for system self-optimization proposed in this application is characterized by ensuring that the system can be verified in a secure and isolated environment during self-optimization through a series of steps, and intelligently handling the resulting changes based on the verification results.

[0039] Specifically, the method first receives improvement suggestions for the target system. These suggestions can be a text file detailing the necessary modifications to the target system, such as changing the logic of a function or adjusting a configuration parameter. Alternatively, the suggestions can be input via a simple command-line tool, where the user specifies the file path and the specific modifications to be made.

[0040] Subsequently, in response to a trigger condition, the system creates a test environment isolated from the target system. This trigger condition can be a manually issued test start command. Upon receiving this command, the system copies all program files and configuration files of the target system within a separate storage area, creating a code copy. Simultaneously, the system also copies the database files or critical data storage directories currently used by the target system, creating a state data copy. This test environment is configured as an independent process or execution instance, and its operation does not directly access or modify the actual resources of the target system.

[0041] In the aforementioned test environment, the system application receives improvement suggestions. Specifically, a pre-defined script runs in the test environment, modifying corresponding files in the code copy based on the improvement suggestions, such as replacing specific lines of code or updating parameter values ​​in configuration files.

[0042] Next, run automated tests in the test environment to verify the effectiveness of the improvements. These automated tests can be a set of pre-defined functional test scripts that simulate user interactions with the system and check whether the system behavior meets expectations. For example, for a web service, automated tests can simulate user login, data querying, and submission, and verify the correctness of these operations after applying the improvement suggestions.

[0043] During the test environment, all state changes are recorded in a copy of the state data. This means that during testing, whether it's an internal system state update, a new log entry, or a modification to the database, it will only be written to the previously created copy of the state data and will not affect the actual running state of the target system.

[0044] Finally, based on the results of the automated tests, the system decides whether to merge the records in the state data copy and the code copy into the target system. For example, if the automated test report shows that all test cases passed successfully and no errors or exceptions were detected, the system will mark the test as successful. In this case, the system will prepare to integrate the modified code copy from the test environment into the target system's codebase and integrate the valid data changes recorded in the state data copy into the actual state data of the target system. Conversely, if the test results show that there are failed test cases or new problems are detected, the system will mark the test as failed and safely discard the test environment and all its copies without performing any merge operations.

[0045] The following example will provide a more detailed explanation of the above technical solution: Suppose a smart home control system (the target system) needs to optimize its device linkage logic to improve response speed. Traditional optimization methods might directly modify the main system's code, which carries the risk of introducing new errors and causing system instability.

[0046] To address this, this application proposes a security testing method for system self-optimization. First, a developer (User A) submits an improvement suggestion detailing an optimization scheme for a device linkage algorithm within the smart home control system, such as adjusting the priority of sensor data processing.

[0047] Subsequently, when a test start command is received by the system, the system responds to this trigger condition by creating a dedicated virtualized execution space as the test environment on an independent computing resource. This virtualized execution space contains all the program files (code copies) currently running in the smart home control system, as well as a complete backup of the device status database (status data copy), such as the on / off status of each device, sensor readings, etc.

[0048] Next, the algorithm optimizations specified in the improvement recommendations are automatically applied to the code copy within that virtualized execution space. For example, a script might modify the module in the code copy responsible for processing sensor data, adjusting its processing logic.

[0049] Then, a series of automated test cases are executed within this virtualized execution space. These test cases simulate various scenarios in a smart home environment, such as simulating a user leaving home, returning home, or entering night mode, and verify whether the optimized device linkage logic can respond faster and more accurately. For example, the test cases might simulate a "user leaving home" scenario and check whether devices such as lights and air conditioners turn off within a preset time.

[0050] During automated test execution, any device state changes, system logs, or internal configuration updates generated by the new algorithm are recorded in a state data copy within this virtualized execution space, completely isolated from the actual device state database of the main system. For example, simulated device switching actions and sensor data changes during testing only affect the state data copy.

[0051] After automated testing is completed, the system generates a detailed test report. If the report shows that the new algorithm improves response speed without introducing any errors or abnormal behavior, the system decides to merge the optimized code and valid state data generated during the test into the main system. For example, the optimized code will be deployed to the main system, and the device state changes simulated during the test and verified as correct (such as states generated by new linkage rules) will also be integrated into the main system's device state database. Conversely, if the test results are unsatisfactory, such as discovering that new linkage logic causes device malfunctions, the virtualized execution space and all its contents will be safely destroyed without affecting the main system.

[0052] As can be seen from the above examples, the security testing method for system self-optimization proposed in this application demonstrates a significant technical contribution in addressing the lack of a security testing mechanism in the system self-optimization process of existing technologies. Traditional methods often involve direct modifications to the main system, which can lead to system crashes or data corruption if problems occur, lacking effective isolation and rollback mechanisms. In contrast, this application ensures the operational security of the main system by creating a test environment isolated from the target system and performing code modifications and automated testing within this environment. Even if tests fail, the test environment can be safely discarded, avoiding any negative impact on the main system.

[0053] Furthermore, addressing the issues of data contamination during testing and the lack of a stateful branch concept in existing technologies, this application effectively solves these challenges by introducing state data copies. In the testing environment, all data changes caused by improvement suggestions or generated during testing are independently recorded in the state data copy, forming a temporary "state branch." This contrasts with the traditional practice of directly writing test data into the main system or discarding it entirely. This application's solution avoids the risk of main system data contamination while retaining valuable state data generated during testing, providing a foundation for subsequent intelligent merging.

[0054] Therefore, the method in this application forms a complete and efficient closed loop for system self-optimization security testing through a series of interconnected steps: receiving improvement suggestions, creating an isolated test environment, applying the improvement suggestions, running automated tests, recording state changes to a copy, and deciding whether to merge based on the test results. This holistic technical concept not only improves the security and reliability of system self-optimization but also optimizes the efficiency and accuracy of data management, providing a solid guarantee for the system to maintain stability and data integrity during autonomous evolution.

[0055] In some of the solutions mentioned above in this application, triggering conditions are proposed to create isolated test environments. However, in their implementation, the triggering conditions lack specific implementation methods and cannot adapt to various application scenarios, such as user approval, automatic system triggering, or external event triggering, resulting in inflexible and inefficient test environment creation.

[0056] In this regard, this application further proposes that the triggering conditions include at least one of user approval, automatic system triggering, or external event triggering.

[0057] User approval refers to a mechanism where system administrators, developers, or other authorized users actively initiate or confirm the test environment creation process. This can be achieved by providing an explicit "Approve" button or command through a graphical user interface or command-line interface. After the user clicks or enters the command, the system receives the approval signal and triggers subsequent operations. Alternatively, it can be integrated into an existing workflow management system or version control system. After an improvement suggestion is submitted and undergoes code review, the reviewer conducts final approval, and the approval result is notified to the testing system via API or message queue. Automatic system triggering refers to a mechanism where the system automatically initiates the test environment creation process without manual intervention based on preset rules, internal state changes, or periodic tasks. This can be achieved by setting a time scheduler to automatically check for improvement suggestions to be tested at specific times and trigger testing. Alternatively, it can be triggered based on system monitoring metrics (such as CPU utilization, memory usage, and error rate reaching thresholds) or data changes (such as new improvement suggestions being added to the database). When these metrics meet preset conditions, the system automatically starts the testing process. External event triggering refers to a mechanism where the system responds to specific signals or messages from external systems or environments, thereby initiating the test environment creation process. This can be achieved by receiving event notifications from other services or modules via a message queue. For example, when an external continuous integration / continuous deployment (CI / CD) pipeline completes code building, it sends a "build complete" event, which the test system receives and triggers tests. Alternatively, it can be configured to listen for specific HTTP requests or webhook callbacks. When a specific event occurs on an external system, it sends an HTTP POST request to the test system, which then triggers tests upon receiving it.

[0058] This application's solution provides multiple flexible trigger conditions, enabling the system to intelligently initiate the creation of isolated test environments based on different application scenarios and requirements. When the system receives improvement suggestions for the target system and meets preset trigger conditions, whether through user approval, internal intelligent judgment, or external event-driven mechanisms, the system responds to these trigger signals and creates a test environment isolated from the target system. This test environment includes a code copy and a state data copy of the target system, ensuring the independence and security of the testing process. Within the test environment, the system can apply the improvement suggestions and run automated tests to verify the improvement effects. State changes generated during the test environment's operation are recorded in the state data copy, preventing contamination of the main system's data. Finally, based on the results of the automated tests, the system decides whether to merge the records in the state data copy and the code copy into the target system. This mechanism allows the system to select the most appropriate start time based on actual conditions during self-optimization, thereby avoiding test delays or resource waste caused by a single trigger method and significantly improving the intelligence, flexibility, and efficiency of the testing process. By specifying the triggering conditions as at least one of user approval, automatic system triggering, or external event triggering, this solution further enhances the adaptability and automation of the basic isolation testing framework, ensuring the stability and data integrity of the system during its autonomous evolution process.

[0059] As a specific implementation method, the triggering conditions can be implemented as follows. For example, in one scenario, when the system receives an improvement suggestion for the target system, it can send an email containing details of the improvement suggestion and an approval link to the system administrator's email address. After the system administrator clicks the approval link in the email and confirms approval on a web interface, the system receives a user approval signal, thereby triggering the creation of the test environment. In another scenario, the system can be configured with a background service that checks every hour for new improvement suggestions submitted to the code repository. Once a new improvement suggestion is detected and passes preliminary static code analysis, the system will automatically trigger the creation of the test environment without manual intervention. Furthermore, external event triggering can also be achieved through integrated message queues. For example, when a continuous integration / continuous deployment (CI / CD) pipeline successfully builds a module and generates a new executable file, the CI / CD system can send a "build successful" message to a preset message queue. The test system subscribes to this message queue, and upon receiving this message, it triggers the creation of the test environment and tests the newly built executable file as part of the improvement suggestion. These different triggering mechanisms can be flexibly configured according to the characteristics of the target system and the operation and maintenance strategy. Multiple triggering methods can even be enabled at the same time to meet complex and ever-changing application needs.

[0060] Through the above technical solutions, this application effectively solves the problem of inflexible and inefficient test environment creation due to the lack of specific implementation methods for triggering conditions, which cannot adapt to various application scenarios. Specifically, a user approval mechanism is introduced to ensure that key improvement suggestions are manually confirmed before testing, improving the security and controllability of testing and preventing unauthorized or immature modifications from directly entering the testing process. The system's automatic triggering mechanism enables the system to autonomously start testing based on preset rules or internal state changes, greatly improving the test response speed and automation level, especially suitable for periodic checks or performance indicator-based optimization scenarios. The external event triggering mechanism allows the system to flexibly respond to signals from other systems or environments, enabling seamless integration into a wider range of automated workflows and adapting to diverse deployment and operation environments. The introduction of these triggering conditions makes the test environment creation process more intelligent and adaptable, avoiding test delays or resource waste that may result from a single triggering method, thereby ensuring that the system can run efficiently and reliably during self-optimization testing, significantly improving the flexibility and efficiency of the entire self-optimization process.

[0061] In some of the embodiments described above in this application, isolation between the test environment and the target system is proposed to ensure the security and independence of the test process. However, in its implementation, the isolation method may not be comprehensive or specific enough, which may lead to unexpected interference between the test environment and the main system at the process, file or data level, thereby causing data pollution, system conflict or resource contention problems, affecting the reliability of the test results and the stability of the main system.

[0062] In this regard, this application further proposes that the isolation between the test environment and the target system includes, but is not limited to, at least one of process isolation, file isolation, or data isolation.

[0063] Process isolation refers to the physical separation of the execution processes in the test environment from the processes of the target system at the operating system level. This can be achieved in several ways. For example, by using container technologies provided by the operating system (such as Docker and LXC), an independent process namespace and resource groups (cgroups) can be created for the test environment, preventing processes in the test environment from directly accessing or interfering with processes in the target system. Another approach is to deploy the test environment in a separate virtual machine (VM). The VM provides a completely independent operating system instance and process space, thus achieving more thorough process isolation.

[0064] File isolation ensures that the test environment can only access its own copies of files, and cannot directly modify or overwrite the original files on the target system. This can be achieved using copy-on-write (CoW) file system technology. When the test environment attempts to modify a file, the system first copies the file for modification, while the original file remains unchanged. Alternatively, this can be achieved by mounting a separate, temporary file system volume for the test environment, or by using the chroot mechanism to restrict the root directory of its file system to a specific sandbox directory, thus preventing test operations from polluting the target system's file system.

[0065] Data isolation refers to storing all state data generated during the test environment's operation in a separate copy, preventing it from being mixed with the target system's production data. This can be achieved by configuring a separate database instance, a separate database tablespace, or a separate storage path for the test environment, ensuring that all data is written to its dedicated area. For example, for relational databases, a separate database schema or a completely new database instance can be created for the test environment; for file storage, a separate directory or bucket can be specified to store test data.

[0066] The phrase "at least one" provides flexibility in implementation. This means that in practical applications, one, two, or all of the above isolation methods can be selected based on the characteristics of the target system, the sensitivity of the test, and the available computing resources. For example, for tests involving only computational logic without file or data interaction, only process isolation may be required; while for tests involving comprehensive system behavior verification, process, file, and data isolation may need to be implemented simultaneously to ensure the comprehensiveness and security of the test.

[0067] The solution proposed in this application constructs a highly independent and secure test sandbox by preferably implementing at least one of the following when creating the test environment: process isolation, file isolation, or data isolation. When the system receives improvement suggestions for the target system and creates a test environment in response to triggering conditions, the test environment creation module actively configures these isolation mechanisms. Specifically, process isolation ensures that all execution processes in the test environment are physically separated from the production processes of the target system when applying improvement suggestions and running automated tests, avoiding the impact of resource contention, unexpected termination, or memory leaks on the stability of the target system. File isolation ensures that operations such as modifying code copies, generating log files, or creating temporary files in the test environment are strictly limited to their own file copies, without touching or polluting the original codebase and file system of the target system. Simultaneously, data isolation ensures that state changes generated during the operation of the test environment, such as new data generated or modified data by automated tests, are only recorded in the state data copy, completely separated from the production state data of the target system, thereby effectively avoiding data pollution and data inconsistency problems. Through this multi-layered, selectable isolation mechanism, the method of this application ensures that any operation performed in the testing environment—whether code modification, functional verification, or data generation—can be conducted in a fully controlled and side-effect-free environment. This greatly improves the reliability of test results and guarantees the stability and data integrity of the target system during its self-optimization process. This explicit isolation strategy makes the "test environment isolated from the target system" more robust and secure, effectively solving various interference problems that may occur during testing.

[0068] As a specific implementation, a microservices-based software system can be considered. When this system needs to perform self-optimization, such as introducing a new recommendation algorithm module or fixing a critical vulnerability, a test environment is created. To achieve isolation between the test environment and the target system, the following measures can be taken: First, regarding process isolation, the test environment can be deployed as one or a group of Docker containers. Each container has an independent process namespace, network interface, and file system view, ensuring that the microservice instances running in the test environment (e.g., beta versions of recommendation services, user authentication services, etc.) are completely isolated from their corresponding services in the production environment at the operating system level. Even if the test service crashes or runs out of resources, it will not affect the normal operation of the production service. Second, regarding file isolation, when the test environment creation module copies a copy of the target system's code, Docker's copy-on-write storage driver (such as OverlayFS) can be used to manage the container's file system. This means that when the container starts, there is a read-only layer pointing to the target system's codebase, while all modifications to the code copy (e.g., application improvement suggestions) are written to a separate, writable container layer. In this way, file operations in the test environment will not directly modify the original code files of the target system. Finally, regarding data isolation, the test environment can be configured to connect to a separate test database instance, or use a separate database schema on a shared database server. For example, if the target system uses a PostgreSQL database, the test environment can connect to a database named `test_db`, while the production environment connects to `prod_db`. All state changes generated during the execution of automated tests in the test environment, such as user behavior logs, recommendation results, and system configuration updates, will be recorded in `test_db`, not written to `prod_db`, thus ensuring the purity of production data. Through the above technical means, this embodiment fully demonstrates how process isolation, file isolation, and data isolation can be achieved through specific container technologies, file system management, and database configuration, thereby providing a safe and independent test environment for system self-optimization.

[0069] The above technical solutions clarify the isolation methods between the test environment and the target system, effectively solving the problem of unintended interference that may occur between the test environment and the main system in traditional testing. Specifically, process isolation avoids resource contention and potential crashes of test processes on main system processes, ensuring the operational stability of the main system; file isolation ensures that operations on the file system by the test environment do not pollute or damage the code and configuration of the main system, maintaining the integrity of the file system; data isolation prevents data generated during testing from mixing with main system data, avoiding data pollution and ensuring the purity and consistency of main system data. This multi-layered and selectable isolation mechanism allows the application of improvement suggestions and the running of automated tests in the test environment to be carried out in a highly controlled and side-effect-free environment, thereby significantly improving the reliability of test results and providing a solid foundation for the secure self-optimization of the target system.

[0070] In some of the embodiments described above in this application, a method is proposed to decide whether to merge data based on test results to achieve post-test security decisions. However, in the implementation process, the lack of specific operating rules may lead to timestamp conflicts or inconsistencies in content when merging state data. The handling of discarding copies when the test fails is not clearly defined, which may cause data chaos or waste of resources and affect the integrity of system data and operational stability.

[0071] In this regard, this application further proposes to determine whether to merge based on test results, including: If the test passes, the records in the state data copy will be merged into the state data of the target system according to preset rules, and the code copy will be merged into the code library of the target system. If the test fails, discard the state data copy and the code copy.

[0072] This technical feature refers to the system's decision-making process after completing automated testing. It determines whether to integrate improvements (including code and state data) generated in the test environment into the target main system based on the final test results. This decision-making mechanism ensures that only verified and expected improvements are adopted, thus avoiding potential risks to the main system from unverified modifications. Specifically, this decision can be based on the analysis of automated test reports. For example, the system automatically parses test reports to determine if there are failed test cases, error logs, or unmet performance metrics. If all key metrics pass, the test is considered passed; otherwise, it is considered a failure. Alternatively, the decision can be based on preset pass rates, error rates, performance metric thresholds, etc. For example, if the test case pass rate reaches 95% or higher and there are no serious security vulnerabilities, the test is considered passed. When the automated test results show that the improvement suggestions work well in the test environment and achieve the expected results, the system records all state changes generated in the state data copy during the test and integrates them securely and systematically into the actual running state data of the target main system according to predefined rules. This aims to retain valuable running data generated during the testing process and avoid data waste. For example, a timestamp-based sequential merging strategy can be used to append or insert records from the state data copy into the target system's state data according to their generated timestamps, ensuring the time-series integrity of the data. Alternatively, merging can be based on data type and business logic. Specific merging strategies can be used for different types of data (such as logs, configurations, and user behavior data). For example, log data can be directly appended, configuration data can be merged using difference merging, and user behavior data can be deduplicated and aggregated. Once the test passes, the system integrates the verified and modified code copy from the test environment into the target main system's code repository. This signifies that the code modifications in the improvement suggestions have been formally adopted by the main system and become a new component. For example, version control tools such as Git and SVN can be used to merge the tested code copy as a new commit into the target system's main branch and record the merge history. Alternatively, file synchronization tools or scripts can be used to overwrite or update code files in the test environment to the corresponding code directories in the target system, ensuring code consistency. When the automated test results fail to meet the preset pass criteria, the system completely deletes the state data copy and code copy created in the test environment and does not integrate them into the target main system. This measure aims to prevent substandard improvements that may introduce problems or errors from contaminating the main system, ensuring its stability and data integrity. For example, a resource reclamation mechanism can be employed: temporary storage space is allocated during test environment creation, and upon test failure, the system automatically triggers the resource reclamation mechanism, deleting the corresponding state data copy files, database tables, or container volumes, as well as the temporary directory containing the code copy.For certain distributed or persistent storage copies, the system can mark them as "discarded" or "to be deleted" and clean them up periodically in the background to avoid the data recovery difficulties that may result from immediate deletion.

[0073] This application's solution addresses the issues of data corruption and resource waste that can result from a lack of specific operational rules during system self-optimization by running automated tests in an isolated test environment and then making explicit decisions based on the test results. Specifically, when the system receives improvement suggestions for the target system and responds to triggering conditions, it creates an isolated test environment containing copies of the target system's code and state data. The improvement suggestions are then applied and automated tests are run within this environment. Furthermore, this application introduces an intelligent decision-making mechanism: once the automated tests are complete, the system evaluates the test results according to preset pass / fail criteria. If the evaluation result indicates a pass, the improvement suggestions are considered valid and safe. In this case, the system securely integrates the records from the state data copies generated in the test environment into the target system's state data according to preset merging rules, and simultaneously merges the verified code copies into the target system's codebase, thus achieving formal deployment of the improvements. Conversely, if the evaluation result indicates a test failure, it means the improvement suggestions may have defects or introduce new problems. To protect the stability and data integrity of the main system, the system immediately discards the state data copies and code copies generated in the test environment, ensuring that these unqualified modifications do not affect the main system. This mechanism, closely integrated with the steps of creating isolated test environments and running automated tests, forms a closed-loop security optimization process, ensuring that the system maintains high stability and data integrity while evolving itself.

[0074] The following is a concrete example, using an intelligent recommendation system as an example. This system generates improvement suggestions based on user behavior data, such as optimizing a parameter of the recommendation algorithm or modifying data processing logic. Upon receiving the improvement suggestions and meeting the triggering conditions, the system creates an isolated test environment containing copies of the current recommendation system's code and state data such as user behavior data and recommendation results. The improvement suggestions are applied to the code copy in the test environment, and a series of automated tests are run, including unit tests, integration tests, and performance tests, to verify the new algorithm's recommendation accuracy, response speed, and resource consumption. As a specific implementation, if the automated test results show that the new algorithm's recommendation accuracy has improved by 5%, the response time is within an acceptable range, and all test cases pass, the system determines that the test has passed. At this point, the system merges the records in the newly generated user behavior logs, recommendation result caches, and other state data copies in the test environment into the main recommendation system's database in timestamp order, ensuring that the main system can utilize this new and effective data. Simultaneously, the optimized recommendation algorithm code copy is merged into the main recommendation system's codebase, completing the formal algorithm upgrade. However, if automated testing results show that the new algorithm leads to a decrease in recommendation accuracy, or in certain extreme cases, system crashes, the system determines the test to have failed. In this case, the system immediately discards all copies of state data (e.g., temporary database tables or log files) and code (e.g., temporary code directories) generated in the test environment to ensure that these unqualified modifications do not have any negative impact on the running main recommendation system, thereby avoiding data pollution and resource waste.

[0075] Through the above technical solution, this application provides an optimized and intelligent decision-making mechanism that solves the problem of timestamp conflicts or content inconsistencies that may occur when merging state data due to the lack of specific operational rules in traditional solutions. By merging records and code copies in the state data copy according to preset rules when the test passes, it ensures that verified and effective improvements can be safely and orderly integrated into the main system, thereby preserving valuable data generated during testing, avoiding data waste, and ensuring the consistency and integrity of the main system code and state data. Simultaneously, when the test fails, it preferentially discards the state data copy and code copy, effectively preventing unqualified modifications that may introduce problems from polluting the main system, avoiding data chaos and resource waste, and greatly improving the security, reliability, and stability of the system's self-optimization process. This mechanism provides the system with an intelligent and secure "quality gate," ensuring that while the system continues to evolve, its core functions and data remain in a controlled and stable state.

[0076] In some of the embodiments described above in this application, a method is proposed to merge state data copies into the target system state data according to preset rules after the test is passed. However, in its implementation, when there is a timestamp conflict between the state records generated during the test and the target system state data, there is a lack of an effective processing mechanism, which may lead to data inconsistency or incorrect merging.

[0077] In response, this application further proposes to merge data according to preset rules, including: detecting whether there is a timestamp conflict between the detection record and the target system status data, and merging them according to the conflict handling strategy.

[0078] The detection of timestamp conflicts between records and target system state data refers to the system proactively identifying any temporal overlap or conflict between records in the state data copy generated in the test environment and the existing state data of the target system before merging them into the target system state data. This can be achieved in several ways. For example, the system can iterate through each record in the state data copy and compare its timestamp with the timestamps of all records in the target system state data one by one; alternatively, the system can pre-index or hash the timestamps of the target system state data to quickly find and compare potential conflicts. Furthermore, the detection efficiency can be improved by sorting the state data copy and the target system state data by timestamp before performing a linear scan comparison.

[0079] Merging based on conflict resolution strategies refers to the system resolving timestamp conflicts according to pre-defined rules after they are detected, ensuring the accuracy and consistency of the data merge. These strategies may include, but are not limited to: prioritizing the preservation of existing data in the target system (i.e., records in the test environment do not overwrite records in the target system when conflicts occur); or prioritizing the overwriting of existing data in the target system (i.e., records in the test environment replace conflicting records in the target system); or adjusting the timestamps of the test environment records before inserting them into the target system's state data to avoid complete timestamp overlap. Furthermore, more complex strategies can be set, such as determining how to handle conflicts based on data priority, source, or type. In some cases, the system can even pause the merging process and prompt the administrator for manual decision-making.

[0080] This application's solution effectively addresses potential confusion and inconsistencies during data merging by introducing a timestamp conflict detection mechanism before merging the validated state data copy from the test environment into the target system's state data. Specifically, after the automated testing in the test environment verifies the improved performance, the system prepares to merge records from the state data copy into the target system according to preset rules. Before this merge operation, the system first compares the timestamps of each record to be merged in the state data copy with existing records in the target system's state data. If two records are found to have the same timestamp, a timestamp conflict is considered to exist. Therefore, the system does not blindly merge but intelligently resolves these conflicts based on preset conflict handling strategies. For example, if the strategy is set to "retain target system data," conflicting test records will be ignored; if the strategy is set to "overwrite target system data," test records will replace old records in the target system; if the strategy is set to "adjust timestamps before insertion," the system will assign a new, non-conflicting timestamp to the test record and insert it. This mechanism ensures that even if data with timestamps overlapping with the main system is generated in the test environment, it can be properly handled through intelligent decision-making, avoiding data pollution and potential system errors, thereby guaranteeing the data integrity and stability of the target system during the self-optimization process.

[0081] The following example illustrates this. Assume the target system is a smart home device, whose status data includes device operation logs, sensor readings, and user operation records, all with precise timestamps. After receiving improvement suggestions and verifying them in an isolated test environment, a copy of the status data is generated in the test environment, containing some new logs and sensor data. Before merging this data into the target system, the system first performs timestamp conflict detection. For example, if a log record in the test environment has a timestamp of "2023-10-26 10:00:05", and the target system's status data also contains a log record with a timestamp of "2023-10-26 10:00:05", the system will identify this as a timestamp conflict. At this point, the system will handle the conflict according to a preset conflict resolution strategy. As a specific implementation, if the conflict resolution strategy is set to "preserve target system data", the conflicting log record in the test environment will be discarded, and the original record in the target system will remain unchanged. If the strategy is set to "overwrite target system data", the log record in the test environment will replace the original record in the target system. For example, if the policy is set to "adjust timestamp before insertion", the system may fine-tune the timestamp of the log record in the test environment to "2023-10-26 10:00:05.001" and insert it into the target system status data, thereby avoiding complete overlap while retaining two records.

[0082] Through the above technical solution, this application effectively solves the problem of timestamp conflicts that may occur when merging test environment and target system state data during system self-optimization. By proactively detecting whether there are timestamp conflicts between the records and the target system state data before merging, and intelligently merging according to a preset conflict handling strategy, data chaos, overwriting errors, or data loss caused by timestamp overlap are avoided. This not only ensures the accuracy and consistency of state data merging after the test is passed, but also significantly improves the data integrity and stability of the target system during its autonomous evolution process, reduces the risk of system failure caused by data conflicts, and enables the system to perform self-optimization more safely and reliably.

[0083] In some of the embodiments described above in this application, a conflict handling strategy is proposed to handle timestamp conflicts in state data merging. However, in its implementation, there is a lack of specific strategies to handle conflicts, resulting in data corruption or loss.

[0084] In response, this application further proposes conflict handling strategies including, but not limited to, retaining target system data, overwriting target system data, or inserting data after adjusting timestamps.

[0085] Conflict handling strategies refer to a series of methods used by the system to resolve conflicts between different data sources during the data merging process, based on preset rules or algorithms. The aim is to ensure the consistency, integrity, and logical correctness of the merged data, avoiding data loss or the introduction of errors. This strategy can be a configurable module, allowing system administrators to choose appropriate handling methods based on business needs; or it can be a decision-making mechanism embedded in the merging logic, automatically selecting a solution based on the type of conflict and data priority. The strategy of preserving target system data means that when a timestamp conflict occurs, the existing state data in the target system (i.e., the main system) is prioritized. Its purpose is to maintain the stability and authority of the main system, preventing data in the test environment from accidentally overwriting or damaging important information in the main system. For example, when an event in the test environment has the same timestamp as a critical operation in the main system, the system will choose to retain the critical operation record in the main system while ignoring or recording the conflicting record in the test environment. The strategy of overwriting target system data means that when a timestamp conflict is detected, the corresponding record in the target system is replaced or updated with the record in the state data copy in the test environment. This method is suitable when the data in the test environment is considered more accurate, optimized, or represents the new state expected by the system. For example, if the test environment successfully validates an optimized value for a configuration parameter, and that optimized value needs to take effect immediately, an overriding strategy can be used to ensure that the main system adopts these validated improvements in a timely manner. The strategy of adjusting timestamps before insertion aims to resolve conflicts by modifying the timestamps of conflict records, thereby allowing all relevant data from both the test environment and the target system to be retained and inserted in chronological order. Its purpose is to avoid data loss while maintaining the temporal logic of the data. For example, when an event in the test environment has the same timestamp as an event in the target system, but their contents differ and both have retention value, the system can automatically fine-tune the timestamp of the event in the test environment (e.g., add a very small time unit) and then insert it into the state data of the target system, thereby ensuring that all events are recorded and in the correct temporal order.

[0086] This application's solution addresses the timestamp conflict issue in state data merging by providing specific conflict handling strategies, ensuring the intelligence and reliability of data merging. In the aforementioned method, after the system runs automated tests in an isolated test environment and generates state change records in a state data copy, if the test passes, the records in the state data copy need to be merged into the target system's state data according to preset rules. During this merging process, if a timestamp conflict is detected between a record and the target system's state data, the conflict handling strategy provided by this solution will be activated. Specifically, this strategy offers several processing options: It can choose to retain the target system data, ensuring priority is given to maintaining the stability of the main system's data in case of conflict, avoiding errors introduced by overwriting; it can also choose to overwrite the target system data, allowing direct updates to the main system when the test environment data is more reliable, achieving timely data optimization; or it can choose to adjust the timestamp before insertion, eliminating conflicts and maintaining the correct temporal sequence of data by modifying the timestamp, preventing data corruption. The introduction of these strategies enables flexible handling of various timestamp conflict scenarios when merging validated improvement data from the test environment back into the main system, avoiding data corruption or loss problems that may occur in traditional methods. In this way, even in complex concurrent operations or asynchronous update scenarios, the system can intelligently manage the merging of state data, thereby ensuring data integrity and reliability during the system's self-optimization process.

[0087] The following is a concrete example. Suppose an intelligent recommendation system is undergoing self-optimization, and its improvement suggestions have been verified in an isolated test environment, generating new user behavior logs (state data copies). When these logs need to be merged back into the main system's user behavior database, the system detects that some log entries in the test environment have the same timestamps as existing log entries in the main system. As one specific implementation, if the conflicting log entries pertain to a user's "click" event on a recommended item, while the main system records a "browse" event for that item, and the system considers the "browse" event to have higher priority or occurred earlier in the main system, then a "preserve target system data" strategy can be adopted, i.e., retaining the "browse" record in the main system while ignoring the "click" record in the test environment. As another specific implementation, if the log entries in the test environment pertain to a user's "feedback rating" of the new recommendation algorithm, and this rating has been rigorously tested and verified, and the system wants to immediately update the user rating data in the main system, then a "overwrite target system data" strategy can be adopted, overwriting the old rating record in the main system with the new rating record from the test environment. As another specific implementation, if the conflicting log entries are a "add to cart" event for a product in the test environment and a "favorite" event for another product in the main system, and the two entries have different content but the same timestamp, and both have retention value, the system can adopt a "adjust timestamp before insertion" strategy. For example, the system can automatically fine-tune the timestamp of the "add to cart" event in the test environment (e.g., increase it by 1 millisecond) and then insert it into the user behavior database of the main system, thereby ensuring that both events are fully recorded and maintain a reasonable time sequence.

[0088] Through the above technical solution, this application effectively solves the problem of data corruption or loss caused by timestamp conflicts during state data merging. By providing multiple flexible conflict handling strategies, such as retaining target system data, overwriting target system data, or inserting data after adjusting timestamps, the system can intelligently select the most suitable merging method according to the actual situation, thereby ensuring the accuracy and reliability of state data merging. This greatly enhances the system's ability to handle complex data changes during self-optimization, ensures data integrity, and reduces the risk of system errors caused by data conflicts, enabling the system to evolve more safely and stably.

[0089] Traditional automated testing of existing system self-optimization may result in incomplete test coverage if it does not cover diverse test types. This may prevent a comprehensive assessment of the potential impact of improvements on functionality, performance, security, and other dimensions, thereby increasing the risk of undetected issues appearing after system optimization.

[0090] In this regard, this application further proposes automated testing, including but not limited to at least one of unit testing, integration testing, performance testing, or security testing.

[0091] Automated testing refers to the process of using specialized software tools or scripts to execute pre-defined test cases without human intervention and automatically evaluate the test results. Its purpose is to improve testing efficiency, repeatability, and accuracy, while reducing the cost and errors of manual testing. This process can involve writing test scripts using scripting languages ​​(such as Python and JavaScript) combined with testing frameworks (such as Selenium, Appium, JUnit, and TestNG) and configuring continuous integration / continuous deployment (CI / CD) tools (such as Jenkins and GitLab CI) to automatically trigger execution. Alternatively, commercial automated testing platforms or tools (such as UFT and TestComplete) can be used to design, execute, and manage test cases; these tools typically offer graphical interfaces and richer functionality. Unit testing is testing performed on the smallest testable units (such as functions, methods, and classes) of a program, aiming to verify that these independent units function as expected. It ensures local correctness of code and is the foundation for building high-quality software. In implementation, unit testing frameworks specific to programming languages ​​can be used, such as JUnit for Java, unittest or pytest for Python, NUnit for C#, and Jest or Mocha for JavaScript, to write test cases to verify the input, output, and internal logic of each independent code module. Simultaneously, mocking or stubbing techniques can be used to isolate the external dependencies of the unit under test, ensuring the independence and repeatability of the tests. Integration testing, following unit testing, combines multiple tested units to test the correctness of their interfaces and interactions. It aims to discover potential problems in inter-module collaboration, ensuring that all parts of the system can work together. This can be achieved by building a test environment, deploying multiple interdependent modules, and then writing test cases to simulate user operations or inter-system communication, verifying the smoothness of data flow and function calls. Alternatively, top-down, bottom-up, or sandwich integration strategies can be used to gradually integrate and test modules to systematically discover integration problems. Performance testing aims to evaluate the system's response speed, stability, resource utilization, and other performance metrics under specific loads. It helps to identify system bottlenecks and ensure that the system meets expected performance requirements. This can be achieved by using load testing tools (such as JMeter, LoadRunner, and k6) to simulate a large number of concurrent users or requests, monitoring the system's resource consumption such as CPU, memory, and network bandwidth, and recording metrics such as response time and throughput. Furthermore, stress testing and capacity testing can be used to gradually increase the system load until the system crashes or reaches its performance limits, in order to assess the system's maximum capacity and stability. Security testing aims to discover security vulnerabilities and weaknesses in the system, preventing security threats such as unauthorized access, data breaches, and denial-of-service attacks.It ensures that the system maintains its integrity, confidentiality, and availability in the face of malicious attacks. This can be achieved by using Static Application Security Testing (SAST) tools to scan the source code and identify potential security flaws; or by using Dynamic Application Security Testing (DAST) tools to simulate attacks at runtime and discover vulnerabilities. Alternatively, penetration testing can simulate hacker behavior, attempting to bypass security controls and uncover deeper security risks in the system.

[0092] This application's solution ensures comprehensive verification of improvement suggestions for the target system by running diverse automated tests in an isolated test environment. Specifically, upon receiving improvement suggestions for the target system, the system responds to trigger conditions and creates a test environment isolated from the target system. This environment contains copies of the target system's code and state data. The improvement suggestions are then applied to the code copy within this test environment. Based on this, automated tests are run to comprehensively evaluate the improvement effects. These automated tests can include, but are not limited to, at least one of unit tests, integration tests, performance tests, or security tests. Introducing unit tests ensures that the improvement suggestions do not introduce errors into the functionality of individual modules within the target system, guaranteeing local correctness of the code. Integration tests further verify whether the interfaces and interactions between the improved modules and with existing modules are normal, avoiding system failures caused by inter-module collaboration issues. Performance tests assess the impact of the improvement suggestions on system resource consumption, response speed, and stability, ensuring that optimization does not lead to new performance bottlenecks or degradation. Security tests focus on detecting whether the improvements introduce new security vulnerabilities, thereby ensuring the overall security of the system. During testing, all state changes are recorded in a state data copy, completely isolated from the target system's master state data. This isolation mechanism, combined with diverse automated testing, allows for thorough verification of improvement suggestions across multiple dimensions, including functionality, performance, and security, without affecting the target system's stable operation. Ultimately, based on the combined results of these automated tests, the system decides whether to merge the records in the state data copy and the code copy into the target system. This mechanism not only solves the problem of incomplete test coverage in traditional testing but also significantly reduces the risk of undetected issues after system optimization by conducting multi-dimensional testing in an isolated environment, thereby improving the safety and reliability of the system's self-optimization.

[0093] As a specific implementation, suppose an intelligent recommendation system needs to optimize its recommendation algorithm. Upon receiving a new suggestion to improve the recommendation algorithm, the system creates an isolated test environment containing a copy of the current recommendation system's code and a copy of user behavior data. After the improvement suggestion is applied to the code copy in the test environment, the system initiates a series of automated tests. First, unit testing can be performed to verify each independent function in the new recommendation algorithm (e.g., the user preference calculation function, the item similarity calculation function), ensuring that each function produces the expected output given the input. For example, simulated historical user behavior data can be provided to the user preference calculation function to verify whether it can correctly generate user preference vectors. Second, integration testing can be performed to integrate the new recommendation algorithm module with existing user interface modules, database interaction modules, etc., to test whether the entire recommendation process is smooth. For example, simulating user browsing, clicking, and purchasing behaviors can verify whether the recommendation list can be displayed correctly and whether user behavior data can be correctly recorded and processed. Next, performance testing can be performed, using tools to simulate a large number of concurrent user requests to evaluate the new algorithm's response time, throughput, and CPU and memory usage under different loads. For example, when simulating 10,000 concurrent user requests, monitor whether the average response time of the recommendation interface is within an acceptable range and whether the server resource utilization is reasonable. Finally, security testing can be conducted to try to discover potential security vulnerabilities introduced by the new algorithm. For example, by inputting abnormal data or constructing malicious requests, test whether the system has vulnerabilities such as SQL injection, cross-site scripting (XSS), or the risk of data leakage. During these automated tests, all user interaction logs, recommendation results, and other state changes generated during the test environment's operation are recorded in a state data copy. If all tests pass, it indicates that the new recommendation algorithm meets the requirements in terms of functionality, performance, and security, and the system can decide to merge it into the target system. Conversely, if any test fails, the improvement can be discarded to avoid introducing problematic code into the production environment.

[0094] Through the above technical solution, this application effectively addresses the problem of incomplete test coverage that may exist in traditional automated testing. During the system self-optimization process, by running diverse automated tests, including unit tests, integration tests, performance tests, and security tests, in an isolated environment, comprehensive and multi-dimensional verification of improvement suggestions is ensured. Specifically, unit tests guarantee the correctness of local code logic, integration tests ensure the smooth collaboration between modules, performance tests evaluate the system's stability and efficiency under load, and security tests effectively identify and mitigate potential security risks. This comprehensive testing strategy significantly improves the accuracy and reliability of improvement effect evaluation, thereby greatly reducing the risk of undetected problems after system optimization and ensuring the stability and security of the target system during continuous evolution. Simultaneously, combined with the isolated testing environment and state data replication mechanism, even during such comprehensive testing, there will be no impact on the target system's production environment or data contamination, further enhancing the security of system self-optimization.

[0095] In some of the solutions described above in this application, a merge decision is proposed to determine whether to merge the state data copy and the code copy into the target system. However, in the process of its implementation, if the merge operation fails or an error is introduced, the system may not be able to recover to the previous safe state, resulting in risks to data integrity and system stability.

[0096] In this regard, this application further proposes that the above method also includes creating a complete snapshot of the target system before merging, the snapshot including code version and state data backup.

[0097] In this approach, "creating a complete snapshot of the target system before merging" aims to provide a comprehensive, point-in-time consistent save of the target system's current code and state data before merging the code and state data copies from the test environment into the target system. Its core function is to provide a reliable recovery point for potential merge failures or introduced errors, ensuring the system can be safely rolled back to its pre-merge state. One implementation method is to leverage the snapshot functionality provided by the operating system or virtualization platform. For example, for a target system running in a virtual machine or container, an application programming interface (API) provided by a hypervisor or container orchestration tool can be used to take a snapshot of the entire virtual machine instance or container state before the merge operation. Another implementation method is to use file system-level snapshot technologies, such as ZFS or Btrfs file systems, to take a snapshot of the data volume containing the target system. Furthermore, a script can be triggered at the start of the merge operation to package and store all critical files and directories of the target system (including code repositories, configuration files, data files, etc.) to a specified backup location.

[0098] The statement that "the snapshot includes code version and state data backups" clarifies the comprehensiveness of the snapshot content, ensuring that when a rollback is needed, not only can the correct code logic be restored, but also the runtime data state that matches that code logic. This completeness is key to achieving accurate system rollback, avoiding system inconsistencies or functional abnormalities caused by code-data mismatches. As one implementation method, code version backup can identify and record the current code repository state using tags or specific commit identifiers from version control systems (such as Git or SVN), or it can directly copy the target system's current code directory completely to the backup storage. As another implementation method, state data backup can be a logical backup of the database used by the target system (such as exporting SQL scripts, using the database's built-in backup tools for full or incremental backups), or it can be a copy and archive of critical data files (such as log files, configuration data, user data, etc.) in persistent storage.

[0099] In the aforementioned security testing method for system self-optimization, when deciding whether to merge the records and code copies in the state data copy of the test environment into the target system based on the results of automated testing, this application further proposes to take a comprehensive snapshot of the target system before performing the merge operation to mitigate potential risks. This snapshot not only covers the current code version of the target system but also includes backups of all its state data. In this way, the system has a complete and consistent recovery point before the merge operation begins. If any unexpected event occurs during the merge process, such as merge failure, introduction of new errors, or system instability, the system can use this snapshot to precisely roll back to the state before the merge, thereby effectively avoiding data loss or system crashes caused by merge operation errors, and greatly improving the security and reliability of the system self-optimization process. This mechanism of establishing a recovery point before critical operations, together with the isolated test environment, constructs a multi-layered security guarantee, ensuring that the system can maintain high stability and data integrity while continuously evolving.

[0100] As a specific implementation method, during the self-optimization of the agent system, before merging the state data copies (such as experience pools and relationship graphs) and code copies generated during testing into the main system after the improvement suggestions in the test environment have passed automated testing, the system can automatically create a complete snapshot of the main system. This snapshot can include backups of all code files, configuration files, and core state data (such as current experience pool data, learning model parameters, user preference settings, etc.) of the current agent system. For example, code versioning can be achieved by tagging a Git repository with a timestamp and version number, while state data backup can be accomplished by exporting key tables from the database to SQL files or performing database-level logical backups. In this way, even if the subsequent merge operation causes abnormal agent behavior or data corruption, the system can quickly roll back to the stable state before the merge, ensuring the continuity of agent services and the security of user data.

[0101] Through the above technical solution, during the system self-optimization process, especially before merging the improvements from the test environment into the target system, a complete snapshot of the target system is pre-created. This snapshot includes backups of code versions and state data. This provides the system with a reliable recovery point when the merge operation faces potential risks. If the merge fails or introduces errors, the system can precisely roll back to the safe state before the merge, effectively avoiding data loss, system crashes, or irreversible errors caused by merge operation mistakes. This greatly enhances the robustness and security of the system's self-optimization process, ensuring the system's data integrity and stability.

[0102] In some of the solutions mentioned above in this application, testing and merging mechanisms are proposed for the safe testing and improvement of the system. However, in this process, if problems occur in the merged system, there is a lack of effective means to restore it to the state before optimization, which leads to damage to system stability and risks to data integrity.

[0103] This application further proposes to include support for rolling back to the snapshot, restoring the code and state data of the target system. "Supporting rollback to the snapshot" means that the system has the ability to restore itself to a pre-saved complete state. The snapshot is a complete copy of the code, configuration, and state data captured by the system at a specific point in time. This rollback capability can be achieved in various ways. For example, version control systems can be used for fine-grained code management, combined with file system-level snapshot technology (such as ZFS or Btrfs) or virtual machine snapshot functionality provided by virtualization platforms to achieve the preservation and restoration of the overall system state. Alternatively, database transaction logs or incremental backup mechanisms can be used in conjunction with file system backups to build a unified snapshot management and recovery process. "Restoring the code and state data of the target system" means reloading the code and state data saved in the snapshot into the target system, returning it to the running state at the time the snapshot was created. Specifically, for code recovery, the version control system can be used to detect the code version corresponding to a specific snapshot; for state data recovery, database recovery tools or file system recovery tools can be used to load the backup data back into the main storage. In containerized or virtualized deployment scenarios, the overall restoration of code and state data can also be achieved by directly replacing or launching the container image or virtual machine image corresponding to the snapshot.

[0104] This application's solution introduces a rollback mechanism, providing crucial fault recovery capabilities for the system's self-optimization process. After the system receives improvement suggestions and verifies them in an isolated test environment, if the test results show that the improvement is effective, a complete snapshot of the target system is first created before merging the improved code and state data copies from the test environment into the target system. This snapshot comprehensively records the target system's code version and state data backup before the merge. This is intended to provide a reliable recovery point for subsequent operations. Once the code and state data copies are merged into the target system, if any unforeseen problems or failures occur in the target system during actual operation, such as system crashes, sharp performance degradation, or data anomalies, the system can use the pre-created snapshot to perform a rollback operation. During the rollback, the system will accurately restore the target system's code and state data to the state recorded in the snapshot. This means that not only is the target system's program logic restored to the version before the merge, but its runtime context information is also synchronously restored to the state before the merge, thereby ensuring the integrity and consistency of system recovery. This mechanism effectively avoids persistent failures caused by merge errors, eliminates the risk of code and data inconsistencies, and fully restores system functionality. By combining the creation of a complete snapshot before merging with support for rolling back to that snapshot and restoring code and state data, the solution proposed in this application constructs a robust safety net, enabling the system to effectively address potential risks while evolving autonomously, and greatly enhancing the system's fault tolerance and data protection level.

[0105] The following is a concrete example, using an agent system as an example. Suppose an agent system generates a new learning algorithm as an improvement suggestion based on user feedback. After verification in an isolated test environment and confirmation that the new algorithm performs well in the test environment, the system prepares to merge it into the main agent system. Before performing the merge operation, the system first creates a complete snapshot of the main agent system. This snapshot contains the current code version of the main agent system (i.e., the old learning algorithm) and a backup of all its state data, such as the experience pool and knowledge graph. Subsequently, the new learning algorithm code and the updated experience pool data in the test environment are merged into the main agent system. However, after the main agent system has been running for a period of time, due to some complex user interactions or unforeseen environmental factors, the agent system begins to exhibit unstable behavior, such as a significant increase in the decision error rate or excessively long response times. At this point, the system administrator or automated monitoring system can trigger a rollback operation. The agent system will use the previously created snapshot to restore the main agent system's code to the old learning algorithm version and restore its experience pool, knowledge graph, and other state data to their state before the merge. In this way, the intelligent agent system can quickly and safely return to its stable operating state before the merger, avoiding the long-term impact of problems introduced by the new algorithm on the system.

[0106] Through the above technical solution, this application provides a reliable fault recovery mechanism. During the system self-optimization process, even if unforeseen problems occur in the target system after testing and merging improvements, the code and state data of the target system can be accurately restored by rolling back to a pre-created complete snapshot. This significantly reduces the system instability and data integrity risks that may arise from merging improvements, ensuring high availability and robustness of the system during its autonomous evolution. This solution provides a crucial security guarantee for the system, enabling it to more confidently perform self-optimization and iterative updates.

[0107] In some of the solutions mentioned above in this application, a system self-optimization security testing method is proposed to solve the problems of lack of isolated testing environment, data pollution and insufficient rollback capability. However, in this process, the specific system types to which the method can be applied are not clearly defined, which leads to limited universality of the method and unclear actual deployment scope. It may not be able to effectively cover diverse application scenarios such as embedded devices or distributed systems, thereby affecting the wide applicability and implementation efficiency of the solution.

[0108] The solution proposed in this application can also be applied to self-optimizing systems, including but not limited to software systems, industrial control systems, robot systems, vehicle systems, smart home devices, data center servers, or edge computing node systems.

[0109] The term "applied to" refers to deploying, integrating, or adapting the system's self-optimized security testing methods to specific types of systems, enabling them to perform their functions on those systems. This includes, but is not limited to, running corresponding software modules on the system's hardware platform or interfaced with the system's existing architecture to manage, test, and merge the system's code and state data. The "software system" can refer to purely software-level systems such as desktop applications, mobile applications, web services, and operating systems, implemented as independent services or integrated into existing software as a library. The "industrial control system," such as programmable logic controllers (PLCs), distributed control systems (DCS), and supervisory control and data acquisition systems (SCADA), typically involves embedded systems with high real-time requirements and tight hardware coupling; its implementation may involve testing firmware updates and configuration changes. The "robot system," including industrial robots and service robots, involves complex software and hardware interactions such as motion control, perception, and decision-making; its implementation may involve testing motion planning algorithms and sensor fusion algorithms. The "vehicle-mounted systems," such as autonomous driving domain controllers, infotainment systems, and body control modules, are typically embedded systems with high real-time requirements. Their implementation may involve OTA updates and functional safety testing. The "smart home devices," such as smart speakers, smart lighting, and smart locks, are typically resource-constrained embedded devices. Their implementation may involve firmware upgrades and configuration update testing. The "data center servers," including physical servers, virtual machines, and containers, run various services and applications. Their implementation may involve operating system updates, application deployment, and configuration change testing. The "edge computing node systems," computing devices deployed at the network edge, typically have limited resources and require remote management and updates. Their implementation may involve remote firmware updates and application deployment testing.

[0110] The proposed solution clarifies that the aforementioned system self-optimization security testing method can be widely applied to various system types, enabling the security testing, state branch management, and intelligent merging mechanisms provided by this method to transcend different technical fields and deployment environments. The core of this method lies in providing a universal framework: creating a test environment isolated from the target system, containing copies of code and state data. Improvement suggestions are applied and automated tests are run within this environment. Based on the test results, a decision is made on whether to merge the records in the state data copy and the code copy into the target system. This universality allows it to adapt to the specific forms of "code" and "state data" in different systems. Whether it's the firmware and I / O states of an industrial control system or the configuration files and performance metrics of a data center server, all can be abstracted and incorporated into this testing process. Therefore, this method, combined with the basic solution, not only solves the problems of lack of security testing, data contamination, and insufficient rollback capabilities during self-optimization, but also further addresses the challenges of limited universality and unclear deployment scope that the solution may face in practical applications, ensuring the universality and implementation efficiency of the solution.

[0111] The following is a concrete example. Taking an industrial control system as an example, when it is necessary to upgrade the firmware of a programmable logic controller (PLC) or optimize the parameters of a control loop, the system first receives the corresponding improvement suggestions. In response to the engineer's user approval trigger, the system creates a simulation or virtualization environment completely isolated from the actual production line. This test environment contains a copy of the PLC's currently running firmware version as a code copy, and real-time operating data such as current I / O states, register values, and process parameters as a status data copy. Subsequently, the new PLC firmware or modified DCS control parameters are loaded into the simulation environment. Next, the system runs a preset automated test script in this test environment to simulate various operating conditions in the production process, such as start-up, stop, load changes, and abnormal situations, to verify the stability, real-time performance, and control accuracy of the new firmware or parameters. During this test, any intermediate variables, alarm records, historical trend data, or other state changes generated in the simulation environment are accurately recorded in the status data copy, completely isolated from the main system's data. Based on the results of the automated test, if the test passes, the system will merge the valid records (such as optimized parameters and new operation log formats) from the status data copy into the status data of the main system according to preset rules, and deploy the new firmware or control program to the actual industrial control system. Conversely, if the test fails, the entire test environment will be safely discarded to ensure that it will not have any impact on the production system.

[0112] Through the above technical solution, this application clarifies that the system self-optimization security testing method can be widely applied to, but is not limited to, software systems, industrial control systems, robot systems, vehicle systems, smart home devices, data center servers, or edge computing node systems, thereby significantly improving the method's versatility and practical deployment scope. This enables the security testing, state branch management, and intelligent merging mechanisms provided by this method to effectively cover diverse application scenarios, solving the problems of insufficient versatility and unclear practical deployment scope in existing technologies, thus improving the solution's broad applicability and implementation efficiency.

[0113] Traditional existing systems lack effective security testing mechanisms when performing self-optimization. Directly modifying the main system code may lead to irreversible errors or even system crashes. If the state data generated by the interaction with the external environment during testing is directly written to the main storage, it will cause data pollution. If it is completely discarded, it will waste valuable runtime data. At the same time, existing technologies do not have the concept of state branches, cannot isolate storage test state changes, and lack conflict handling and precise rollback capabilities, making it difficult for the system to balance innovation and stability during autonomous evolution.

[0114] To address this issue, this application proposes a self-optimizing security testing system for software systems, comprising a suggestion receiving module, a test environment creation module, an improvement application module, a testing module, a state management module, and a merge decision module. The suggestion receiving module receives improvement suggestions for the target system; the test environment creation module creates a test environment isolated from the target system in response to triggering conditions, the test environment containing a copy of the target system's code and a copy of its state data; the improvement application module applies the improvement suggestions within the test environment; the testing module runs automated tests within the test environment; the state management module records state changes generated during the test environment's operation in the state data copy; and the merge decision module determines whether to merge the records in the state data copy and the code copy into the target system based on the test results.

[0115] The core innovation of this embodiment lies in combining the test environment creation module and the state management module to isolate state data. This allows state changes to be independently stored in a state data copy during testing, preventing data contamination of the main system. Simultaneously, the merge decision module intelligently processes the state data copy based on test results, implementing a decision-making mechanism that merges valid data when the test passes and safely discards it when the test fails, thus solving the problems of missing conflict handling mechanisms and insufficient rollback capabilities. Specifically, the isolated environment built by the test environment creation module ensures that code modifications and state changes occur within the copy, keeping the main system in a safe state at all times. The state management module records all state changes generated by interactions during testing in the state data copy, forming temporary state branches, preventing data contamination while retaining valid runtime data. The merge decision module executes intelligent decisions based on automated test results. When the test passes, it merges the records in the state data copy and the code copy into the target system; when the test fails, it discards the copy, thereby ensuring system security while achieving complete data retention and accurate rollback.

[0116] Through the above technical solution, the system can verify improvement suggestions without affecting the operation of the main system. State data generated during testing is strictly isolated and stored in a state data copy, preventing data contamination of the main system. In case of test failure, the entire test environment can be safely discarded, achieving a lossless rollback. After a test passes, valid data is intelligently merged to ensure timing correctness and data integrity. For example, when optimizing device linkage logic in a smart home control system, the test environment creation module generates an isolated environment containing code and state data copies. The state management module records simulated device on / off state changes during testing in the state data copy. The merging decision module decides whether to merge the optimized code and verified state data into the main system based on the automated test results, thereby improving response speed while eliminating the risk of system crashes. Overall, this solution significantly improves the security, data integrity, and recoverability of the system's self-optimization process by constructing a complete secure testing closed loop.

[0117] While traditional systems can verify improvements through isolated testing environments during self-optimization, they still suffer from insufficient rollback capabilities after merging the tested improvements into the main system. This means that if the merging operation introduces new, unforeseen problems, the system will struggle to accurately revert to its pre-optimization state, potentially leading to system crashes or data loss, thus hindering the security and reliability of the system's self-optimization.

[0118] In this regard, this application further proposes that the system also includes a version control module for creating a complete snapshot of the target system before merging and supporting rollback.

[0119] The version control module is used to manage and track historical versions of system code, configuration, and state data. It records every change and allows the system to revert to any historical version when needed. This module can be integrated and customized based on existing mature version control systems (such as Git and SVN), or it can be implemented independently through file system snapshots, database transaction log management, etc. Creating a complete snapshot of the target system means capturing all code, configuration, and state data of the target system at a specific point in time and saving it as a recoverable baseline before performing critical operations on the target system (such as merging code and state data copies from the test environment into the target system). For code, this can be achieved by copying the current codebase and tagging it with a version number, or by utilizing the branching / tag functionality of the version control system. For state data, this can be achieved by performing logical backups of the database (such as exporting SQL scripts), physical backups (such as copying data files), or by utilizing the snapshot functionality of the storage system. For configuration, it involves copying the current set of configuration files. Support for rollback means that when problems arise after system improvements are implemented, or when it is necessary to undo a merge operation, the target system's code, configuration, and state data can be restored to the state at the time of the snapshot using the previously created snapshot. Code rollback can be achieved using the recovery commands provided by the version control system; rollback of state data can be accomplished by importing backup data, restoring database snapshots, or rolling back database transaction logs; and rollback of configuration is achieved by replacing the current configuration file with the configuration file in the snapshot.

[0120] Building upon the aforementioned system self-optimization security testing method, this application further introduces a version control module. This module works closely with the merge decision module. Before the merge decision module decides to merge the validated code and state data copies from the test environment into the target system, the version control module proactively intervenes to create a complete snapshot of the target system. This snapshot includes not only the current code version of the target system but also all its state data backups and configuration information. In this way, the system has a reliable recovery point before the actual merge operation is executed. Once the merge operation is complete, regardless of any potential problems subsequently discovered, such as unexpected errors introduced by new features, performance degradation, or data inconsistency breaches, the system can utilize the rollback function provided by the version control module to precisely restore the target system's code, configuration, and state data to the snapshot state before the merge. This gives the entire self-optimization process strong fault tolerance, providing a security barrier in the production environment even if not all problems are fully discovered in the isolated test environment, ensuring that the system's stability and data integrity are not compromised as it continues to evolve.

[0121] The following is a concrete example. In a data center server system, when the merge decision module decides to merge the validated configuration changes and state data from the test environment into the main server system based on test results, the version control module is activated first. For example, the version control module can trigger an automated script that calls the virtualization platform's snapshot function to create a complete snapshot of the entire server virtual machine, or perform a full backup of the server's critical database, and copy the currently running application code and configuration files to a separate backup storage area, while recording the snapshot creation timestamp and version identifier. Subsequently, the merge decision module performs the actual merge operation, applying the new configuration to the main server and merging the state data generated in the test environment into the main database. If, after this, the server's monitoring system detects a significant increase in service response time or abnormal errors, the system administrator can immediately roll back the previously created snapshot through the interface provided by the version control module. The system will automatically restore the code, configuration, and state data to the state at the time of the snapshot, thereby quickly eliminating the problem and restoring normal service operation.

[0122] Through the above technical solution, this application effectively solves the problem of insufficient rollback capability in existing technologies. During the system's self-optimization process, even after isolation testing, unforeseen problems may still arise after merging into the main system. The version control module creates a complete snapshot before merging, providing the system with a reliable recovery point. This allows the system to accurately and quickly roll back to its stable state before optimization should any problems arise during the merge operation, avoiding system crashes, data loss, or prolonged downtime due to optimization errors. This greatly enhances the security, reliability, and controllability of the system's self-optimization process, reduces the risk of continuous system evolution, and ensures that the system maintains stable operation and data integrity while autonomously evolving.

[0123] In some of the solutions mentioned above in this application, a test environment creation module is proposed to create a test environment isolated from the target system. However, in this process, the lack of specific isolation mechanism may lead to insufficient isolation effect, which may not effectively prevent data pollution or resource conflicts during the test, thereby affecting system security and data integrity.

[0124] To address this, this application further proposes a test environment creation module configured to implement at least one of the following: process isolation, file isolation, or data isolation. This module is responsible for dynamically constructing a test space completely separated from the target system's main runtime environment based on preset trigger conditions. Its core function is to replicate the target system's critical components and place them in a controlled, independent runtime domain to ensure that testing activities do not interfere with or affect the main system. This module can be implemented using container technology, virtual machine technology, or through an operating system-level sandbox mechanism. Process isolation ensures that application processes running in the test environment are independent of processes running in the target system's main environment, without affecting each other. This means that test processes have independent memory space, CPU time slice allocation, and system resource access permissions; even if a test process crashes or malfunctions, it will not affect the normal operation of the main system processes. Methods for implementing process isolation include, but are not limited to: utilizing the process sandbox mechanism provided by the operating system, such as Linux's cgroups and namespaces; running the test environment in a separate virtual machine; or providing an independent runtime environment for the test processes through container technology. File isolation refers to providing a separate file system view for the test environment, ensuring that file operations in the test environment do not directly affect files in the target system's main file system. This is typically achieved by copying copies of the target system's code and configuration to a separate storage space in the test environment, or by using copy-on-write technology, so that modifications to files in the test environment only affect their own copies and do not modify the original files. File isolation prevents accidental modifications to code or configuration during testing from polluting the main system, ensuring the integrity of the main system's file data. Data isolation refers to ensuring that state data generated or modified in the test environment is separated from the target system's main state data storage. This means that user operation logs, internal system state changes, database records, and other data generated during testing will be written to a separate "state data copy," and will not be directly written to or modified in the main system's database, cache, or other persistent storage. Methods for achieving data isolation include, but are not limited to: configuring a separate database instance or database schema for the test environment; using a separate storage volume or file directory to store the state data copy; or providing a logically independent data view for the test environment through data virtualization technology. "At least one" indicates that in actual deployment, any one or more of the above isolation mechanisms can be flexibly selected and combined according to specific system characteristics, security requirements, resource constraints, and testing needs.For example, for resource-sensitive systems, process isolation might be prioritized to reduce overhead; for systems with extremely high data integrity requirements, both file isolation and data isolation might be used simultaneously; and for systems requiring comprehensive security, process isolation, file isolation, and data isolation might be implemented simultaneously to achieve the most thorough isolation effect. This flexibility allows this solution to adapt to a variety of complex application scenarios.

[0125] When an improvement suggestion for the target system is received and the triggering conditions are met, the test environment creation module starts an independent test environment. During the construction of this test environment, it ensures a clear boundary between all operations within the test environment and the main system, based on a preset isolation strategy. Specifically, if process isolation is selected, the test environment creation module allocates an independent process space for the test task, confining the execution of test code, resource usage, and any potential abnormal behavior to this independent process, preventing direct impact on other processes in the main system. If file isolation is selected, the module provides an independent file system view for the test environment, meaning any modifications to code or configuration copies during testing will only affect the test environment and will not touch or contaminate the original files in the main system. If data isolation is selected, the test environment creation module ensures that all state changes generated during testing, such as new log entries, database updates, or internal state data, are stored in a separate copy of state data, completely separated from the state data of the main system. Through this flexible combination of isolation mechanisms, the test environment creation module ensures that the entire process of applying improvement suggestions, running automated tests, and recording state changes in the test environment is conducted in a safe, controlled environment that is undisturbed by the main system. This complete isolation ensures that even if the test fails, it will not have any negative impact on the stability, data integrity, or normal operation of the target system, thus providing a solid security guarantee for the system's self-optimization.

[0126] For example, consider a containerization-based implementation. When the system receives improvement suggestions and meets triggering conditions, the test environment creation module can use container orchestration tools to dynamically create one or more new container instances as the test environment. Specifically, for process isolation, each test container runs in an independent Linux namespace, with its own process tree, network interface, and mount point, ensuring complete isolation between processes in the test environment and those in the host system or other containers. Even if a process within a test container crashes, it will not affect other services on the host machine or the main system. For file isolation, the test environment creation module can use Docker's copy-on-write file system layer. When a test container is created, copies of the target system's code and configuration are mounted as read-only layers, while any modifications made to these files by the test container are written to a separate, writable container layer. This way, file operations in the test environment do not modify the original code or configuration, and this writable layer can be easily discarded after the test, achieving rapid cleanup and isolation of the file system. For data isolation, the test environment creation module can dynamically allocate an independent database instance or database schema to each test container. For example, if the target system uses a PostgreSQL database, the test environment creation module can create a new database on the main database server, or start a lightweight database service inside the test container and store a copy of the state data in this separate database. The connection string between the test container and the external database is configured to point to this separate test database, ensuring that all state data generated during testing is completely separated from the main system's production data. Through this containerized implementation, the test environment creation module can efficiently and flexibly implement process isolation, file isolation, and data isolation, providing a highly isolated and easily managed runtime environment for system self-optimization security testing.

[0127] Through the above technical solutions, the test environment creation module can flexibly select and implement at least one of process isolation, file isolation, or data isolation according to actual needs. This refined isolation mechanism completely solves the data pollution and resource conflict problems caused by insufficient isolation in traditional solutions. Specifically, process isolation ensures the independent operation of test tasks, avoiding interference with the stability of the main system; file isolation ensures the integrity of the main system code and configuration, preventing accidental modifications during testing; and data isolation effectively prevents data generated during testing from polluting the main system's state data, maintaining data consistency. The introduction of these isolation methods enables the application of improvement suggestions and the running of automated tests to be carried out in a highly secure, reliable, and side-effect-free environment, greatly improving the security, stability, and data integrity of the system's self-optimization process, thereby ensuring the system can continue to operate stably while autonomously evolving.

[0128] In some of the solutions mentioned above in this application, a system self-optimization security testing method is proposed to solve problems such as the lack of security testing mechanism, data pollution during testing, stateless branch concept, lack of conflict handling mechanism and insufficient rollback capability. However, when implementing these methods, there is a lack of a standardized and automatically executable program form, which leads to the method execution relying on manual operation, low efficiency, limited deployment flexibility, and difficulty in rapid promotion and application in different hardware environments.

[0129] In this regard, this application further proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method.

[0130] Computer-readable storage media refers to a physical carrier capable of storing computer programs or data from which a processor can read instructions and data. Its function is to provide the foundation for persistent storage, distribution, and cross-platform deployment of computer programs. As one possible implementation, this medium can be non-volatile memory, such as hard disk drives, solid-state drives, flash drives, or various types of read-only memory. As another possible implementation, the medium can also be optical disc storage media, such as CD-ROMs, DVD-ROMs, or Blu-ray discs, or remote storage systems accessed via network protocols. A computer program refers to a set of encoded instructions designed to cause the processor to perform specific tasks or operations. Its function is to translate abstract, self-optimizing security testing methods into concrete steps that can be understood and executed by a computer. As one possible implementation, the program can be a compiled binary executable file, such as an .exe file or an ELF file that runs under a specific operating system environment. As another possible implementation, the program can be an interpreted script file, such as a Python script or JavaScript file, or a bytecode file, such as a Java .class file. When the program is executed by the processor, the method is implemented. This means that the processor (e.g., a central processing unit, graphics processing unit, microcontroller, etc.) reads and interprets the instructions in the computer program, thereby executing operations according to a predetermined logical sequence, and ultimately completing all the steps of the aforementioned system self-optimization security testing method. Its function is to transform the logic carried by the computer program into actual computational behavior, realizing the automated operation of the method. As one possible implementation, the processor can directly load and execute program instructions from the storage medium; for example, in embedded systems, the microcontroller directly reads and runs firmware instructions from flash memory. As another possible implementation, the operating system can load the program into memory and schedule the processor to execute the program's instructions; for example, in general-purpose computer systems, the operating system manages program execution and resource allocation.

[0131] The proposed solution achieves automation, efficiency, and broad applicability by encoding a system-self-optimizing security testing method into a computer program, storing it on a computer-readable storage medium, and then executing it via a processor. Specifically, the computer-readable storage medium, as the physical carrier, provides stable and persistent storage space for the computer program and supports convenient distribution and deployment, freeing the method from limitations of a single hardware environment and enabling cross-platform application. The computer program transforms the complex logic of the aforementioned system-self-optimizing security testing method—including receiving improvement suggestions, creating an isolated test environment, applying improvements, running automated tests, recording state changes, and deciding whether to merge based on test results—into precise and unambiguous machine instructions. When the processor executes the computer program, it automatically completes all the aforementioned testing and optimization steps strictly according to the preset logical sequence and operating procedures. This collaborative working mechanism transforms a testing process that might otherwise require manual intervention, be time-consuming, and prone to errors, into a standardized, repeatable, and automated process driven autonomously by the computer system. In this way, this application not only solves the problems of method execution relying on manual operation, low efficiency, and limited deployment flexibility, but more importantly, it ensures that the core advantages designed by the above-mentioned security testing method, such as isolation, data integrity, intelligent merging, and rollback, can be stably, efficiently, and on a large scale, thereby effectively guaranteeing the stability and data integrity of the system during the autonomous evolution process.

[0132] The following is a specific example. As a particular implementation, the computer-readable storage medium can be a solid-state drive (SSD), which features high-speed read / write capabilities and good shock resistance, making it suitable for server environments. The computer program can be an executable binary file written and compiled in Go, containing all the logic and instructions for implementing the aforementioned system self-optimization security testing method. This includes functions such as parsing improvement suggestions, calling containerization technology to create a test environment, executing automated test scripts, managing the reading and writing of state data copies, and triggering merge or discard operations based on test results. This executable binary file is deployed on a server running a Linux operating system. When preset triggering conditions are met (e.g., receiving new improvement suggestions and obtaining user approval), the server's central processing unit loads and executes the binary program. After startup, the program automatically coordinates system resources and completes the entire security testing and optimization process according to the steps described above, without manual intervention.

[0133] Through the above technical solutions, this application can significantly improve the implementation efficiency and reliability of the system self-optimization security testing method. First, by encoding the method into a computer program and executing it via a processor, the testing process is fully automated, greatly reducing manual operations, thus avoiding human error and significantly improving the speed of testing and optimization. Second, using a computer-readable storage medium as the program carrier allows the method to be stored, distributed, and deployed in a standardized form, solving the problem of limited deployment flexibility and enabling its rapid promotion and application in different hardware environments (such as servers, edge devices, or cloud platforms). Furthermore, this programmatic implementation ensures that core technical means such as isolation testing, state branch management, intelligent merging, and rollback in the above method are executed consistently and reliably, thereby fully leveraging the advantages of these technical means in ensuring system security and data integrity. Ultimately, this allows the system to maintain high stability and reliability while autonomously evolving.

[0134] Other application scenarios The following simplified embodiments illustrate the application of the present invention in other fields. Specific implementations of these embodiments can be found in the examples described in the detailed embodiments above, and will not be repeated here.

[0135] Simplified Example 1: Upgrading the Motion Planning Algorithm of a Robot System In robotic systems, upgrading motion planning algorithms can impact motion accuracy and safety. This invention creates code and state copies (joint positions, velocities, torques) of the robot controller in a simulation environment. The new algorithm is run in a test environment, simulating various motion trajectories and load conditions to verify its stability and accuracy. Trajectory data and energy consumption data generated during testing are recorded in state branches. If the test passes, the state branches are merged into the main system, and the new algorithm is deployed; if the test fails, they are discarded. A snapshot of the robot system is created before merging, supporting rollback. This embodiment ensures the operational safety of the robot system.

[0136] Simplified Example 2: OTA Upgrade of In-Vehicle System In intelligent vehicles, in-vehicle systems (such as autonomous driving domain controllers and infotainment systems) require software updates via OTA (Over-The-Air). This invention creates code and state copies (vehicle status, sensor data, user settings) of the in-vehicle system in an isolated environment. The new version is run in a test environment to simulate various driving scenarios and road conditions, verifying the upgrade effect. State changes generated during testing (such as new feature trigger records and interaction logs) are recorded in state branches. After successful testing, the state branches are merged into the main system, and the new version is officially deployed; if the test fails, the branches are discarded. A system snapshot is created before merging, supporting rollback. This embodiment ensures the reliability of in-vehicle system upgrades and avoids driving safety risks.

[0137] Simplified Example 3: Configuration Changes for Data Center Servers In data centers, configuration changes to server clusters (such as database parameter adjustments and load balancing strategy updates) can impact service quality. This invention creates configuration copies and runtime state copies (CPU load, memory usage, and connection count) of servers in an isolated environment. The new configuration is applied in a test environment to simulate normal and peak loads, verifying the effect of the configuration change. Performance data generated during testing is recorded in a state branch. If the test passes, the state branch is merged into the main system, and the new configuration is officially applied; if the test fails, it is discarded. A server snapshot is created before merging, supporting rapid rollback. This embodiment ensures the stability of data center services.

[0138] Simplified Example 4: Software Update of Edge Computing Nodes In edge computing scenarios, nodes are widely distributed, making on-site recovery difficult after update failures. This invention creates code and state copies (local data, network status) of edge nodes in an isolated environment. The new version is run in a test environment to simulate normal workloads and verify the update effect. If the test passes, the state branch is merged into the main system and the new version is deployed; if the test fails, it is discarded. A node snapshot is created before merging, supporting remote rollback. This embodiment ensures the reliability of edge node updates.

[0139] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0140] This solution is applicable not only to local devices but can also be deployed on cloud servers. Those skilled in the art should understand that the technical solution of this invention is not limited to a specific deployment environment, and any implementation based on the technical concept of this application should be considered to fall within the protection scope of this invention.

Claims

1. A security testing method for system self-optimization, characterized in that, Includes the following steps: Receive improvement suggestions for the target system; In response to a triggering condition, a test environment isolated from the target system is created, the test environment containing a code copy and a state data copy of the target system; Apply the improvement recommendations in the test environment; Run automated tests in the test environment to verify the effectiveness of the improvements; The state changes that occur during the operation of the test environment are recorded in the state data copy; Based on the test results, a decision will be made on whether to merge the records in the state data copy and the code copy into the target system.

2. The method according to claim 1, characterized in that, The triggering conditions include at least one of user approval, automatic system triggering, or external event triggering.

3. The method according to claim 1, characterized in that, The isolation between the test environment and the target system includes, but is not limited to, at least one of process isolation, file isolation, or data isolation.

4. The method according to claim 1, characterized in that, The decision on whether to merge based on test results includes: If the test passes, the records in the state data copy will be merged into the state data of the target system according to preset rules, and the code copy will be merged into the code library of the target system. If the test fails, discard the state data copy and the code copy.

5. The method according to claim 4, characterized in that, The merging according to preset rules includes: detecting whether there is a timestamp conflict between the record and the target system status data, and merging them according to the conflict handling strategy.

6. The method according to claim 5, characterized in that, The conflict handling strategy includes, but is not limited to, at least one of the following: retaining the target system data, overwriting the target system data, or inserting the data after adjusting the timestamp.

7. The method according to claim 1, characterized in that, The automated testing includes, but is not limited to, at least one of unit testing, integration testing, performance testing, or security testing.

8. The method according to claim 1, characterized in that, It also includes creating a complete snapshot of the target system prior to the merger, the snapshot including code version and state data backups.

9. The method according to claim 8, characterized in that, It also includes support for rolling back to the snapshot, restoring the code and state data of the target system.

10. A security testing system for self-optimization of software systems, characterized in that, include: The suggestion receiving module is used to receive improvement suggestions for the target system; The test environment creation module is used to create a test environment isolated from the target system in response to a triggering condition. The test environment includes a code copy and a state data copy of the target system. An improved application module is used to apply the improvement recommendations in the test environment. The test module is used to run automated tests in the test environment; The state management module is used to record the state changes that occur during the operation of the test environment in the state data copy; The merge decision module is used to decide whether to merge the records in the state data copy and the code copy into the target system based on the test results.

11. The system according to claim 10, characterized in that, It also includes a version control module for creating a complete snapshot of the target system before merging and for supporting rollback.

12. The system according to claim 10, characterized in that, The test environment creation module is configured to include, but is not limited to, at least one of process isolation, file isolation, or data isolation.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 9.

Images