Automatic test case intelligent repair method, system and equipment

Abstract

The invention discloses an automatic test case intelligent repairing method, system and device. The method specifically comprises the steps that a target automatic test case set is screened out according to repairing task configuration parameters; based on the target automatic test case set, detecting boundary condition coverage vulnerabilities through a symbolic execution technology, and identifying uninitialized variable risk points in combination with a data flow analysis technology to obtain a defect identification result; the defect recognition result is input into an AI repair engine, and a repair scheme is generated; inputting the repair scheme into a repair confidence scoring model and a repair influence evaluation model, and performing risk evaluation and screening on the repair scheme to obtain a recommended repair scheme; and verifying the test case repaired by executing the recommended repair scheme in the isolation environment, and if the verification is passed, outputting a repair report. According to the method, intelligent repair of the automatic test case is realized, the repair efficiency and accuracy are improved, and meanwhile, the flexibility of the repair process is enhanced.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an automated test case intelligent repair method, system and device. Background Technology

[0002] In the field of software development and testing, as software systems become increasingly large-scale and complex, automated test cases are playing an increasingly crucial role in software quality assurance systems. Automated test cases can simulate user operations, performing rapid and repetitive tests on various software functions, effectively improving testing efficiency, reducing manual testing costs, and providing strong assurance for stable software quality.

[0003] However, in actual operation, automated test cases face numerous problems, leading to frequent test failures. On one hand, code errors are a significant factor causing test case failures. Various code defects are inevitable during software development, such as boundary condition coverage vulnerabilities. These vulnerabilities can cause abnormal behavior when handling boundary values, leading to the failure of test cases that rely on boundary value judgments. The risk of uninitialized variables is equally significant; when variables are not correctly initialized before use, the program's execution result will be unpredictable, severely impacting the normal execution of test cases. On the other hand, environmental changes also have a significant impact on automated test cases. The dynamic nature of the software operating environment, including operating system version updates, changes in dependency library versions, and differences in hardware configurations, can cause compatibility issues for test cases that previously functioned correctly in new environments, leading to test failures.

[0004] Existing methods for maintaining and fixing test cases primarily rely on manual operation, which has several limitations. First, they are extremely inefficient. Manually checking and fixing automated test cases is time-consuming. Testers need to review code line by line, analyze the reasons for test failures, and manually write fixes—a tedious and time-consuming process that cannot keep pace with the rapid iteration of software development. Second, accuracy is difficult to guarantee. Manual operation is susceptible to subjective factors, and omissions and errors are common. For example, testers may fail to fully identify all potential code defects or introduce new errors during the fixing process, leading to incomplete or failed fixes, thus affecting software quality. Third, they lack intelligent tools. Existing methods cannot leverage intelligent technologies to automatically analyze the reasons for test case failures and generate fixes, failing to fully utilize the advantages of computers in data processing and pattern recognition, thus limiting further improvements in efficiency and accuracy. Finally, they lack flexibility. It is difficult to set scheduled tasks to automatically trigger the test case fixing process according to different user needs; it is also difficult to accurately select specific test cases for fixing, failing to meet diverse testing scenarios and personalized user requirements. Summary of the Invention

[0005] The purpose of this invention is to provide an automated test case intelligent repair method, system, and device, which realizes automated test case intelligent repair, improves repair efficiency and accuracy, enhances the flexibility of the repair process, meets the diverse needs of different users, and provides strong support for software quality assurance, thereby solving at least one of the aforementioned problems in the prior art.

[0006] In a first aspect, the present invention provides an intelligent repair method for automated test cases, the method specifically comprising: Receive the repair task configuration parameters and filter the target set of automated test cases based on the repair task configuration parameters; Based on the target automated test case set, symbolic execution technology is used to detect boundary condition coverage vulnerabilities, and data flow analysis technology is used to identify uninitialized variable risk points to obtain defect identification results; The defect identification results are input into the AI ​​repair engine to generate a repair plan; The remediation plans are input into the remediation confidence scoring model and the remediation impact assessment model to conduct risk assessment and screening of the remediation plans and obtain recommended remediation plans. In an isolated environment, test cases after implementing the recommended remediation plan are verified. If the verification passes, a remediation report is output.

[0007] Secondly, the present invention provides an automated test case intelligent repair system, the system specifically comprising: The test case filtering module is used to receive the configuration parameters of the repair task and filter out the target set of automated test cases based on the configuration parameters of the repair task. The defect identification module is used to detect boundary condition coverage vulnerabilities based on the target automated test case set, and to identify uninitialized variable risk points by combining data flow analysis technology to obtain defect identification results. The repair solution module is used to input the defect identification results into the AI ​​repair engine to generate a repair solution; The scheme screening module is used to input remediation schemes into the remediation confidence scoring model and the remediation impact assessment model, conduct risk assessment and screening of remediation schemes, and obtain recommended remediation schemes. The solution verification module is used to verify the test cases after the recommended repair solution is implemented in an isolated environment. If the verification is successful, a repair report will be output.

[0008] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the automated test case intelligent repair method as described in any of the above methods.

[0009] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the automated test case intelligent repair method as described in any of the above methods.

[0010] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention realizes intelligent repair of automated test cases, improves repair efficiency and accuracy, enhances the flexibility of the repair process, meets the diverse needs of different users, and provides strong support for software quality assurance.

[0011] 2. This invention accurately filters out target automated test cases and their related files by parsing the configuration parameters input by the user, and binds them to the execution strategy, providing an accurate target set for subsequent targeted repairs.

[0012] 3. This invention utilizes symbolic execution and data flow analysis techniques to comprehensively detect boundary condition coverage vulnerabilities and uninitialized variable risk points, accurately obtain defect information, and lay the foundation for generating effective remediation solutions.

[0013] 4. This invention extracts contextual code fragments based on defect information and assembles structured hints, which are then input into an AI repair model to generate multiple candidate repair solutions, providing a wealth of options for selecting the optimal repair solution.

[0014] 5. This invention extracts multiple features of the repair scheme to score confidence, analyzes code dependencies to assess impact risks, and combines decision rules to screen recommended schemes, thus ensuring the quality and feasibility of the repair scheme.

[0015] 6. This invention performs comprehensive verification of the repaired test cases in an isolated environment, determines whether the repair passes based on multiple verification results and outputs a report, ensuring the reliability of the quality of the repaired test cases.

[0016] 7. This invention achieves continuous optimization of the repair engine and evaluation model by constructing reinforcement learning experience tuples and storing reward values ​​in an experience replay pool, sampling data to train the policy network and fine-tuning the evaluation model.

[0017] 8. This invention constructs a knowledge graph by identifying non-code errors, and when a new error occurs, it performs reasoning to generate a root cause list and suggestions, and updates the weights based on the verification results, thereby improving the ability to handle non-code errors. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating an automated test case intelligent repair method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an automated test case intelligent repair system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating an embodiment of the intelligent repair method for automated test cases disclosed in this invention is shown below, detailed in the following description: S101: Receive the repair task configuration parameters and filter the target automated test case set according to the repair task configuration parameters.

[0027] In this embodiment, a user interface is built, which provides a variety of parameter input options to facilitate users in setting the configuration parameters of the repair task according to their actual needs. These parameter options include, but are not limited to, the software module to which the test case belongs, the priority of the test case, the creation time range of the test case, the execution status of the test case (such as success, failure, not executed, etc.), and the functional characteristics involved in the test case.

[0028] Users input configuration parameters for the repair task through this interactive interface. For example, if a user wants to repair automated test cases in a specific software module that have high priority and are in a failed execution state, the user can select or enter the software module name, the high priority option, and the failed execution state option in the corresponding input boxes.

[0029] After the user completes the parameter input and submits it, the system's backend parameter parsing module will parse the user-inputted repair task configuration parameters. The parsing process transforms the various parameter information entered by the user into internal data structures that the system can recognize and process. For example, it maps the software module name selected by the user to the software module identifier stored internally by the system, and converts priority options into corresponding priority values.

[0030] Next, the system accesses the database storing automated test cases based on the parsed repair task configuration parameters. The database stores detailed information about all automated test cases, including the software module to which the test case belongs, its priority, creation time, execution status, and the functional characteristics involved.

[0031] The system uses the parsed parameters as filtering criteria to perform queries in the database. For example, if the parsed parameters require filtering high-priority test cases within a specific software module, the system will search the database for all automated test case records that meet both conditions.

[0032] Finally, the system extracts the automated test cases that meet the configuration parameters of the repair task and forms a target automated test case set. These test cases will then be used as the objects of subsequent repair processes, performing operations such as defect identification and repair solution generation.

[0033] S102, based on the target automated test case set, uses symbolic execution technology to detect boundary condition coverage vulnerabilities and combines data flow analysis technology to identify uninitialized variable risk points, thus obtaining defect identification results.

[0034] In this embodiment, the first step is to set up a symbolic execution environment. An independent symbolic execution instance is created for each test case in the selected set of target automated test cases. The symbolic execution environment needs to be configured with symbolic variables related to the runtime environment of the software system corresponding to the test case. These symbolic variables are used to simulate various input values ​​that the software may receive during operation. For example, if a test case involves a calculation function that accepts integer input, then corresponding integer-type symbolic variables are defined in the symbolic execution environment to represent the possible inputs.

[0035] Next, symbolic execution technology is used to detect boundary condition coverage vulnerabilities. For each symbolic execution instance of a test case, boundary values ​​are selected from the domain of the symbolic variable as input for symbolic execution. Taking a function that accepts integer inputs ranging from 1 to 100 as an example, 1 and 100 are selected as boundary value inputs during symbolic execution. During execution, the symbolic execution engine traces the program's execution path and analyzes the logic when the program processes these boundary values. If an abnormal branch (such as jumping to an error handling code block) or an unexpected result is found when the program processes boundary values, the test case is marked as potentially having a boundary condition coverage vulnerability. Simultaneously, the problematic boundary value and its corresponding execution path information are recorded as preliminary identification results of the boundary condition coverage vulnerability.

[0036] Next, data flow analysis is performed to identify risks associated with uninitialized variables. Based on symbolic execution, data flow analysis is conducted on the code of each test case. The data flow analysis tool tracks the definition and usage of variables in the program. Starting from the program's entry point, the definition location of each variable (i.e., where the variable is assigned a value) is recorded. During subsequent code execution, the usage locations of variables are checked. If a variable is not correctly defined (i.e., uninitialized) before a certain usage location, it is marked as having an uninitialized risk. For example, in a function, if a variable is used in the conditional evaluation of an if statement, but no value is assigned to it before entering the if statement, then this variable is considered to have an uninitialized risk. Simultaneously, information such as the name of the uninitialized variable, its line of code, and the execution path it may affect is recorded.

[0037] Finally, the preliminary identification results of boundary condition coverage vulnerabilities and the identification results of uninitialized variable risks are summarized to form a complete defect identification result. This defect identification result will list in detail the relevant information of boundary condition coverage vulnerabilities and uninitialized variable risks in each target automated test case, providing a basis for subsequent remediation work.

[0038] S103 inputs the defect identification results into the AI ​​repair engine to generate a repair solution.

[0039] In this embodiment, the defect identification results are first preprocessed and organized into a standardized format that the AI ​​remediation engine can recognize. For example, information related to the boundary conditions and vulnerabilities, such as the function name involved, specific boundary values, and the line number of the code where the vulnerability occurs, is arranged according to a specific field order and format. For uninitialized variable risk points, information such as the variable name, the code block in which it is located, and the functional modules that may be affected is also standardized and organized. At the same time, each defect identification result is assigned a unique identifier for subsequent tracking and management.

[0040] Next, the preprocessed defect identification results are input into the input interface of the AI ​​remediation engine. Upon receiving the data, the AI ​​remediation engine activates its internal feature extraction module. This module performs in-depth analysis of the input defect identification results and extracts key features. For boundary condition coverage vulnerabilities, the feature extraction module focuses on code logic features related to boundary value handling, such as the structure of conditional statements and the comparison methods for boundary values. For uninitialized variable risk points, it extracts code structure features related to variable definition and usage, such as the scope of variables and the location of assignment statements.

[0041] Then, the AI-powered remediation engine uses its pre-trained models to generate remediation solutions. These models are trained on a large amount of historical test case defect data and corresponding remediation solutions. Based on extracted features, the model searches the knowledge base for similar defect cases and their remediation methods. For example, if the current boundary condition coverage vulnerability is found to be similar in characteristics to a vulnerability in a historical case, the model will refer to the remediation method of that historical case, combined with the specific code structure and business logic of the current software, to generate a remediation solution suitable for the current situation. For uninitialized variable risks, the model will recommend appropriate initialization methods based on the variable's usage scenario and scope, such as adding assignment statements in suitable code locations.

[0042] Finally, the AI-powered repair engine performs initial optimization on the generated repair solutions. It checks whether the solutions conform to coding standards and syntax requirements, avoiding the generation of code with syntax errors. Simultaneously, it considers the impact of the repair solutions on other parts of the software, striving to ensure that the solutions do not introduce new problems. After optimization, the final repair solution is output, which includes detailed code modification suggestions, such as the lines of code to be modified and the modified code content.

[0043] S104. Input the remediation plan into the remediation confidence scoring model and the remediation impact assessment model to conduct risk assessment and screening of the remediation plan and obtain the recommended remediation plan.

[0044] In this embodiment, the input repair plan is preprocessed. Key information in the repair plan, such as code modifications and involved functional modules, is organized and extracted according to the format required by the repair confidence scoring model and the repair impact assessment model. For example, for code modifications, the number of lines modified and the code content before and after modification are recorded in detail; for involved functional modules, their business domain and hierarchical relationship in the software system are identified. Simultaneously, each repair plan is assigned a unique identifier for subsequent tracking and management.

[0045] The pre-processed remediation plans are input into the remediation confidence scoring model and the remediation impact assessment model, respectively. Upon receiving a remediation plan, the remediation confidence scoring model initiates its internal evaluation mechanism. This model, built upon extensive historical remediation data and expert experience, analyzes the rationality and logic of code modifications within the remediation plan, as well as its similarity to known successful remediation cases. For example, the model checks whether the code modifications conform to software coding standards, whether the modified code can correctly handle various boundary conditions, and how similar it is in code structure and logic to previously successful remediation plans for similar defects. Through these analyses, the model provides a remediation confidence score, reflecting the likelihood that the remediation plan will successfully resolve the defect.

[0046] Simultaneously, the remediation impact assessment model begins evaluating the remediation plan. This model primarily focuses on the impact of the remediation plan on other parts of the software system. It analyzes whether the code modifications involved in the remediation plan will introduce new dependencies and affect the normal operation of other functions. For example, if the remediation plan modifies a global variable, the model will check the usage of that variable in other modules and assess whether the modification will cause anomalies in other modules. Based on these analysis results, the remediation impact assessment model will assign a remediation impact assessment score, which represents the degree of impact of the remediation plan on the overall stability of the software system.

[0047] Then, the evaluation results of the two models are combined. A comprehensive evaluation rule is set, for example, the repair confidence score and the repair impact assessment score are weighted and summed according to certain weights to obtain a comprehensive evaluation score. The weights can be adjusted according to actual needs. If more emphasis is placed on the success rate of the repair solution, the weight of the repair confidence score can be set higher; if more emphasis is placed on the impact on the software system, the weight of the repair impact assessment score can be increased.

[0048] Finally, the remediation plans are screened based on the overall evaluation score. A threshold for the overall evaluation score is set; only remediation plans with scores above this threshold are selected as recommended remediation plans. Remediation plans with scores below the threshold can be fed back to relevant personnel for further analysis and optimization, or a new remediation plan can be generated. In this way, recommended remediation plans that have a high probability of successfully resolving the defect while having a minimal impact on the software system can be selected.

[0049] S105: Verify the test cases after implementing the recommended remediation plan in an isolated environment. If the verification passes, output a remediation report.

[0050] In this embodiment, an isolated environment is constructed that is as similar as possible to the actual production environment but is also independent of it, based on the software runtime environment requirements upon which the target automated test cases depend. This isolated environment encompasses aspects such as the operating system, dependent libraries, and hardware configuration. For example, if the target test cases run on a specific version of the Linux operating system and depend on certain specific versions of open-source libraries, then the same version of the Linux operating system and the corresponding open-source library versions are installed in the isolated environment. Simultaneously, independent hardware resources, such as a dedicated server or virtual machine, are allocated to the isolated environment to ensure that its operation is not interfered with by other external factors and can realistically simulate the runtime scenarios of the test cases.

[0051] Automated test cases that have executed the recommended remediation plan were deployed to the established isolated environment. During deployment, the deployment specifications for the test cases were strictly followed to ensure that all components and dependencies were correctly installed and configured. For example, for test cases requiring specific configuration files, the contents of the configuration files were ensured to be accurate and placed in the correct directory. Simultaneously, all parameters and operational steps during the deployment process were recorded for future traceability and troubleshooting in case of problems.

[0052] In the isolated environment, launch the repaired automated test cases and execute them according to the preset test flow and test case steps. During the test, record the execution status of the test cases in detail, including the input data, output results, and execution time of each step. For example, for a test case simulating user login, record the username and password entered by the user, as well as the login result (success or failure) and response time returned by the system. At the same time, monitor various system performance indicators such as CPU utilization and memory usage during the execution of the test cases to ensure that the system runs stably during the test.

[0053] Based on the expected results of the test cases, the actual execution results are analyzed and judged. If the actual execution results are consistent with the expected results, it means that the fixed test cases can run normally in the isolated environment, and the verification is passed; if the actual execution results are inconsistent with the expected results, it means that the fixed test cases still have problems, and the verification fails. For example, for the test cases of the simulated user login function mentioned above, if the expected result is that the user can successfully log in after entering the correct username and password, but the actual execution result is that the login fails, then the verification fails. For cases where the verification fails, further analysis of the reasons for the failure is needed. It may be due to problems with the repair solution, or it may be due to differences between the isolated environment and the actual environment.

[0054] If verification passes, a detailed remediation report is generated. The report includes a description of the test case failures before the remediation, the specific details of the recommended remediation plan, the verification process and results in the isolated environment, and performance metrics of the test cases after the remediation. For example, the report details the specific circumstances under which test cases failed due to boundary condition coverage vulnerabilities before the remediation, how the recommended remediation plan modified the code to address the vulnerability, the number of times the test cases were executed in the isolated environment, the results of each execution, and performance data such as the average response time of the test cases after the remediation. The remediation report is presented in a clear and standardized format for easy review and understanding by relevant personnel.

[0055] In some embodiments, step S101 above, which involves receiving repair task configuration parameters and filtering the target automated test case set based on the repair task configuration parameters, specifically includes: Receive the repair task configuration parameters input by the user through the configuration interface, and parse and extract the target scope definition rules and task execution strategy from the repair task configuration parameters; Based on the rules defined by the target scope, the identifiers of the target automated test cases and their corresponding source code files are filtered out by querying the test case management database; The target automated test case identifier and its corresponding source code file are bound to the task execution strategy to generate a set of target automated test cases.

[0056] In this embodiment, a configuration interface is established through which users input configuration parameters for the repair task. For example, users can set target scope definition rules on the interface, such as specifying the module or function category to which the test cases to be repaired belong. For instance, if a user wants to repair automated test cases related to the user login module, they can explicitly specify the module in the target scope definition rules. Simultaneously, users can also set task execution strategies, such as setting the execution time of the repair task—whether it should be executed immediately or at a specific time—or setting the priority of the repair task.

[0057] After receiving the repair task configuration parameters input by the user through the configuration interface, the system parses and extracts these parameters. The system has a dedicated parameter parsing module that can identify and extract the target scope definition rules and task execution strategies. For example, from the complex parameter information input by the user, it accurately separates descriptive information about the target test case scope, as well as relevant strategy information about how the task should be executed.

[0058] Next, based on the extracted target scope definition rules, the system filters target automated test cases by querying the test case management database. The test case management database stores a large amount of information related to automated test cases, including test case identifiers, their respective modules, functional descriptions, and corresponding source code files. The system performs precise queries in the database according to the target scope definition rules. For example, if the target scope definition rule specifies a particular functional module, the system filters the database to retrieve the identifiers of all automated test cases under that module and simultaneously obtains the corresponding source code files for these test cases.

[0059] Finally, the system binds the identifiers of the selected target automated test cases and their corresponding source code files to the previously extracted task execution strategies. This binding ensures that each target test case executes according to the user-defined strategy during subsequent repair processes. For example, if the task execution strategy specifies that the repair task will be executed at 10 PM, then these target test cases will be repaired according to this schedule. Through this binding operation, the system generates a set of target automated test cases, which contains the test cases that need to be repaired and their corresponding execution strategy information, providing clear target objects and execution basis for subsequent repair work.

[0060] In some embodiments, step S102 above, which involves detecting boundary condition coverage vulnerabilities using symbolic execution technology based on the target automated test case set and identifying uninitialized variable risk points using data flow analysis technology to obtain defect identification results, specifically includes: Based on the target automated test case set, a symbolic execution path tree of the source code file is constructed. By marking the program input as symbolic values ​​and collecting path constraints, the boundary condition values ​​not covered in the original test cases are derived using the constraint solver, and boundary condition coverage vulnerability information is generated. Based on the target automated test case set, a control flow graph of the source code file is constructed. By analyzing the definition and usage states of variables in the control flow graph, a definition-use chain is established, and code locations where variables are not defined before use are identified in at least one path, generating information on uninitialized variable risk points. The system integrates boundary condition coverage vulnerability information with uninitialized variable risk point information to output defect identification results.

[0061] In this embodiment, a source code file is selected from the target automated test case set as the analysis object. This source code file is preprocessed to ensure it meets the input requirements of the symbolic execution tool. Then, the symbolic execution tool analyzes the source code file, marking program inputs as symbolic values ​​during the analysis. These symbolic values ​​are not specific numerical values, but rather represent a class of input values ​​with a specific range of values. As the program code executes, path constraints are collected for each execution path. These path constraints describe the conditions that the input symbolic values ​​must satisfy when the program executes on that path. Next, a constraint solver is used to solve the collected path constraints. The constraint solver can deduce boundary condition values ​​not covered in the original test cases based on these constraints. For example, for a function that processes numerical input, the original test cases may only test values ​​within the normal range, while the constraint solver can deduce boundary values ​​that exceed the normal range but conform to the program logic, such as maximum values, minimum values, and special values ​​that just cause overflow. The derived boundary condition values ​​are organized and recorded to generate boundary condition coverage vulnerability information, which details the location of the boundary condition coverage vulnerability in the source code file and the corresponding boundary condition value.

[0062] Similarly, source code files are selected from the target automated test case set, and specialized tools or algorithms are used to analyze these files to generate their control flow graphs. A control flow graph is a graphical representation of program control flow, consisting of nodes and edges. Nodes represent basic blocks in the program (a continuous block of code with only one entry and one exit point), and edges represent control transfers during program execution. After constructing the control flow graph, the variables within it are analyzed. Specifically, the definition and usage states of each variable are analyzed. The definition state refers to the location where the variable is assigned a value in the program, while the usage state refers to the location where the variable is referenced in the program. By analyzing these definition and usage states, definition-use chains are established. Definition-use chains clearly show the path information from when a variable is defined to when it is used. After establishing the definition-use chains, each path is checked to identify code locations where at least one path contains a variable that was not defined before use. For example, in a function, a variable might be used in a conditional branch, but if this variable is not defined on any path leading to that branch, this indicates a risk point of uninitialized variables at that location. The code locations containing these uninitialized variable risk points are recorded, and uninitialized variable risk point information is generated. This information details the specific location of the uninitialized variable risk points in the source code file and the information of the related variables.

[0063] The defect identification results are output by integrating boundary condition coverage vulnerability information and uninitialized variable risk point information. The previously generated boundary condition coverage vulnerability information and uninitialized variable risk point information can be integrated and stored and managed using a unified data structure or format. For example, this information can be stored in a table, with each row recording one defect, including the defect type (boundary condition coverage vulnerability or uninitialized variable risk point), the file name of the defect, the function name, the line number of the code, and a detailed description. By integrating and organizing this information, a complete defect identification result is formed. This result can comprehensively and accurately reflect the various defects existing in the source code files corresponding to the target automated test case set, providing detailed basis for subsequent remediation work.

[0064] In one possible implementation, taking projects of different sizes as examples, for small projects, the number of source code files is relatively small and the code structure is relatively simple. First, all source code files in the target automated test case set of the small project are analyzed sequentially. For each source code file, a symbolic execution path tree is constructed according to the steps in Example 1. Due to the small project size, the symbolic execution tool can quickly complete the symbolic execution analysis of each file, collect path constraints, and derive boundary condition values ​​using a constraint solver. Constructing the control flow graph is also quick, and due to the simple code structure, the establishment and analysis of the definition-use chain is relatively easy, enabling rapid identification of uninitialized variable risk points. The boundary condition coverage vulnerability information and uninitialized variable risk point information generated for each file are integrated. Due to the small number of files, the integration process is simple and fast, ultimately outputting the defect identification results for the entire small project. The entire process can be completed in a short time, and due to the small project size, there are fewer complex logic and difficult-to-analyze situations, ensuring a good level of accuracy and completeness in defect identification.

[0065] For large projects, the number of source code files is numerous, the code structure is complex, and it may contain multiple modules and subsystems. First, based on the project's module division or functional characteristics, the target automated test case set is grouped, with each group corresponding to a relatively independent module or subsystem. Then, for each group, the steps in Example 1 are followed. When constructing the symbolic execution path tree, due to the large amount of code, symbolic execution tools may require a long analysis time and may encounter some complex logic and loop structures, requiring optimization strategies, such as appropriate loop unrolling or abstraction, to improve analysis efficiency. Similarly, constructing the control flow graph and establishing the definition-use chain also faces the problem of high code complexity, potentially requiring more powerful tools or algorithms to accurately analyze variable definitions and usage. For the boundary condition coverage vulnerability information and uninitialized variable risk point information generated for each group, preliminary integration is performed within the group, and then the integration results of all groups are fully merged to form the defect identification results for the entire large project. Due to the complexity of large projects, some manual auxiliary checks and adjustments may be needed during the integration process to ensure the accuracy and completeness of the defect identification results. Meanwhile, to improve efficiency, parallel processing can be used to analyze and process multiple groups simultaneously, making full use of computing resources.

[0066] In some embodiments, step S103 above, which involves inputting the defect identification result into the AI ​​repair engine to generate a repair solution, specifically includes: Based on the defect identification results, the defect type, defect location, and defect description information are extracted. Extract the context code snippet containing the defect from the source code file based on the defect location; The defect type, defect description information, and context code snippets are assembled into a structured prompt for the AI ​​repair model according to a preset template. The structured prompts are input into the AI ​​repair model for inference, resulting in multiple candidate repair solutions for the defects; Each candidate repair solution is parsed and formatted, and the specific code modifications and natural language descriptions corresponding to each candidate repair solution are extracted to generate a set of repair solutions.

[0067] In this embodiment, after obtaining the defect identification results, a specially designed information extraction algorithm or tool is used to sort out the key information in the results. For example, for defects such as boundary condition coverage vulnerabilities, the defect type is accurately located from the identification results as "boundary condition coverage vulnerability," and its specific location in the source code file is determined, such as a specific line of code in a function. At the same time, a detailed description of the defect is extracted, such as "when processing input values ​​as the maximum boundary value, the program did not make a correct judgment, resulting in an exception." For uninitialized variable risk points, its defect type is also clearly identified as "uninitialized variable risk point," the code location where the variable is not initialized is found, and the possible impact of the risk point is described, such as "the variable is not initialized before use, which may lead to unpredictable program execution results."

[0068] Next, contextual code snippets are extracted from the source code file based on the identified defect location. Using code editing tools or the features provided by the development environment, the specific line of code containing the defect is located. Then, using this defect as the center, a certain range of lines of code are extended upwards and downwards to extract the contextual code snippets containing the defect. For example, if the defect is located in the middle of a function, the complete code from beginning to end of the function is extracted, or, depending on the specific situation, several lines of code closely related to the defect logic are extracted. The purpose of this is to provide sufficient contextual information for the subsequent AI repair model, enabling it to more accurately understand the background and cause of the defect.

[0069] The parsed defect types, defect descriptions, and extracted context code snippets are assembled into structured hints for the AI-based repair model according to a pre-designed template. The pre-designed template is carefully crafted to present information in a clear and standardized manner. For example, the template might specify listing the defect type first, followed by a detailed defect description, and finally the context code snippet. During the assembly process, the completeness and accuracy of the information are ensured to avoid omissions or formatting errors. For example, the structured hint might appear as: "Defect Type: Boundary Condition Coverage Vulnerability; Defect Description: When processing input values ​​that are at maximum boundary values, the program failed to make a correct judgment, resulting in an exception; Context Code Snippet: [Extracted code content here]".

[0070] The assembled structured hints are input into the AI ​​fix model for reasoning. This AI fix model, trained on a large amount of data, possesses the ability to analyze and process code defects and generate fixes. Upon receiving the structured hints, the model analyzes and understands the defect based on its learned knowledge and patterns, and uses its reasoning ability to generate multiple candidate fixes for that defect. These candidate fixes may be different code modifications aimed at resolving the same defect.

[0071] Specialized analysis tools or algorithms are used to analyze each candidate repair solution generated by the AI ​​repair model. The specific code modifications corresponding to each candidate repair solution are extracted; for example, whether it's modifying an assignment statement for a variable or adding a new conditional statement. Simultaneously, natural language descriptions corresponding to the code modifications are extracted, explaining the purpose and effect of the modification. For example, the natural language description might be "set the initial value of this variable to 0 to avoid exceptions caused by uninitialization." The specific code modifications and natural language descriptions of all candidate repair solutions are compiled to generate a set of repair solutions, providing a foundation for subsequent repair solution evaluation and selection.

[0072] Furthermore, the training process of the AI-based repair model involves constructing a large-scale, high-quality multimodal training dataset, combining multi-stage transfer learning strategies and adversarial training mechanisms to gradually optimize the model's ability to repair defects in automated test cases. Specifically, automated test case data covering various software types (such as web applications, mobile applications, and embedded systems) is collected, including test script code, historical defect reports, repair records, and test environment configuration information. For example, for test cases of web applications, test code containing JavaScript / Python scripts is collected, defect reports recording "array out of bounds" or "null pointer exception" errors are recorded, and code snippets of boundary condition checks added during repair are collected. Simultaneously, code change records related to test case repair are extracted from open-source code repositories (such as GitHub), and each change is labeled with its corresponding defect type (such as boundary condition vulnerability, uninitialized variable), repair location (such as lines 15 to 20), and repair strategy (such as adding conditional judgments, initializing variables). In addition, natural language description data is introduced, associating the text descriptions in defect reports (such as "when the user inputs a negative number, the calculation result is abnormal") with the code repair content to form a triplet data of "defect text - code defect - repair code".

[0073] Select a code understanding model (such as CodeBERT) pre-trained on a general programming language dataset (such as CodeSearchNet) as the basic framework. This model already has a preliminary understanding of code syntax structures, variable naming patterns, and basic logic. For example, when the input code snippet is "if(x>0){y=x;}else{y=0;}", the model can identify the boundary condition judgment logic of variable x. On this basis, for the test case repair scenario, further conduct secondary pre-training on a mixed dataset containing test script code and defect repair records. Specifically, splice the test script code and the corresponding repair code into an input sequence, and train the model to predict the key modified parts in the repair code (such as the added "else{y=0;}" branch). In this stage, strengthen the model's understanding of code context relevance through the Masked Language Modeling task. For example, when the model sees a defect description like "uninitialized variable z", it can associate with the context in the code where "z is used directly without being assigned a value".

[0074] Connect the pre-trained model to a multi-task learning framework and optimize three sub-tasks simultaneously: defect type classification, repair location localization, and repair code generation. In the defect type classification task, given a defect description text (such as "array index out of range") and a code snippet, the model needs to determine whether the defect type belongs to boundary condition vulnerabilities, uninitialized variables, or other categories; in the repair location localization task, the model needs to mark the line number range that needs to be modified in the code snippet (such as lines 3 to 5); in the repair code generation task, the model needs to generate the complete repair code according to the defect type and the context code (such as adding the "if(index<array.length)" judgment). During training, use a joint loss function to combine the loss values of the three tasks (such as the cross-entropy loss for the classification task, the IoU loss for the localization task, and the sequence-to-sequence loss for the generation task), and synchronously update the model parameters through backpropagation. For example, when the model generates "z=0;" to repair the uninitialized variable z in the repair code generation task, if the localization task mismarks the repair location, the joint loss will amplify this error, forcing the model to optimize both the location judgment and the code generation capabilities simultaneously.

[0075] In some embodiments, in the above step S104, the inputting the repair solution into the repair confidence scoring model and the repair impact assessment model to perform risk assessment and screening on the repair solution to obtain a recommended repair solution specifically includes: Extract the semantic consistency feature, historical pattern matching feature, and code change simplicity feature of each repair solution, and input the semantic consistency feature, historical pattern matching feature, and code change simplicity feature into the pre-trained repair confidence scoring model to obtain the repair confidence score corresponding to each repair solution; By analyzing the dependencies of the modified code contained in each remediation plan through a pre-trained remediation impact assessment model, constructing a code change impact propagation graph and identifying affected internal related use cases and external common components, and generating a remediation impact risk rating for each remediation plan by combining the impact breadth and risk level; Based on preset decision-making rules, multiple remediation options are filtered and ranked by combining remediation confidence scores and remediation impact risk ratings to obtain recommended remediation options.

[0076] In this embodiment, for each remediation scheme, semantic consistency features, historical pattern matching features, and code change simplicity features are extracted. Semantic consistency features primarily consider the degree of semantic fit between the remediation scheme and the original code and the overall software functionality. For example, whether the remediated code logic is semantically consistent with the expected function, and whether there are any semantic ambiguities. Historical pattern matching features analyze past remediation patterns for similar code defects to determine whether the current remediation scheme matches successful historical remediation patterns. For example, whether the current remediation scheme uses similar and effective processing logic for past remediation methods for specific types of boundary condition coverage vulnerabilities. Code change simplicity features focus on the degree and simplicity of code modification by the remediation scheme. Remediation schemes with fewer lines of modified code and simpler logical structures usually perform better in this feature. These three extracted features are input into a pre-trained remediation confidence scoring model. This model, trained on a large amount of data with known remediation effects, can score each remediation scheme based on the input features, thereby obtaining a remediation confidence score for each scheme. A higher score indicates a more reliable remediation scheme in terms of confidence.

[0077] A pre-trained remediation impact assessment model is used to analyze the dependencies of the modified code included in each remediation plan. Code in software is often not isolated; various dependencies exist between different parts of the code, such as function call relationships and data transfer relationships. By analyzing these dependencies, a code change impact propagation diagram is constructed, which visually shows other parts that may be affected after code modification. Based on this propagation diagram, affected internal related test cases and external common components are identified. Internal related test cases refer to other test cases that have functional connections with the currently remediated test cases within the software, while external common components are common parts such as external libraries or modules that the software depends on. Taking into account the breadth of impact—the number and scope of affected internal related test cases and external common components—and the risk level—such as the importance of affected components to the overall functionality of the software—a remediation impact risk rating is generated for each remediation plan. A higher rating indicates a greater potential impact and risk from the remediation plan.

[0078] Based on pre-defined decision rules, multiple remediation options are filtered and ranked using the previously obtained remediation confidence scores and remediation impact risk ratings. The decision rules can be set to prioritize options with higher remediation confidence scores while filtering out options with excessively high remediation impact risk ratings. For example, a threshold for the remediation confidence score can be set, retaining only options with scores above that threshold. These options are then ranked from lowest to highest according to their remediation impact risk ratings. The top-ranked options are the recommended remediation options, as they offer both high remediation reliability and minimize the impact and risk of the remediation.

[0079] Furthermore, the pre-training process for the confidence scoring model involves collecting a large amount of data related to repaired automated test cases. This data covers repair cases under various software types, functional modules, and code defect scenarios. Data sources include past test case repair records within the enterprise, repair history in open-source software projects, and publicly available test case repair datasets. For each repair case, detailed records are kept of the test case code before repair, test failure information, repair solution code, and test results after repair. Next, feature extraction is performed on the collected data. For each repair solution, semantic consistency features, historical pattern matching features, and code change simplicity features are extracted. The data with extracted features is divided into training and test sets according to a certain ratio. The training set data is input into a selected model (such as a multilayer perceptron or convolutional neural network), using the repair effect of the repair solution (such as whether the test passes after repair) as a label, allowing the model to learn the relationship between features and repair effects. During training, appropriate optimization algorithms, such as stochastic gradient descent, are used to adjust model parameters to minimize the model's loss function and improve the model's accuracy and generalization ability. Through multiple iterations of training, the model gradually converges, achieving better performance.

[0080] Furthermore, the pre-training process for the remediation impact assessment model includes collecting a large number of automated test case remediation cases. These cases should contain rich software environment information and remediation code information. Software environment information includes operating system version, dependency library version, hardware configuration, etc., while remediation code information includes the modified code content, modification location, involved functions and variables, etc. Simultaneously, the impact of each remediation plan on the software is recorded, such as whether it causes other test cases to fail, whether it affects software performance, and whether it introduces new functional defects. Data sources can include internal software test remediation records, publicly available cases from software testing communities, and data provided by professional software testing research institutions. Next, feature extraction is performed. For each remediation plan, the dependencies of the modified code are analyzed as one of the important features. By analyzing the call relationships and data transfer relationships between functions in the code, other parts affected by the modified code are determined. A code change impact propagation diagram is constructed to visually display the propagation path and scope of the code modification. Simultaneously, affected internal related test cases and external common components are identified. Internal related test cases refer to other test cases that have functional relationships with the currently remediated test case within the software, while external common components are external libraries or modules that the software depends on. Furthermore, considering the breadth of impact—the number and scope of affected internal related use cases and external common components—and the risk level—such as the importance of affected components to the overall software functionality and the probability of failure—this information is extracted as features. The data with extracted features is divided into training and test sets according to a certain ratio, ensuring the diversity and representativeness of the data in both sets, covering various software environments and remediation scenarios. For example, stratified sampling can be performed based on factors such as software type and operating system version, ensuring that each category has a reasonable proportion in both the training and test sets. A graph neural network model can be chosen as the model architecture because the code change impact propagation graph has graph structure characteristics, and graph neural networks can better handle this structured data and capture the complex relationships between nodes. The dataset is input into the selected graph neural network model, using the actual impact risk rating of the remediation solution (e.g., low, medium, high) as labels, allowing the model to learn the relationship between features and impact risk. During training, appropriate optimization algorithms are used to adjust model parameters; for example, backpropagation can be used for graph neural network models to improve the model's evaluation accuracy. Through multiple iterations of training, the model gradually converges, enabling it to accurately predict the impact risk of the remediation solution.

[0081] In some embodiments, step S105 above, which involves verifying the test cases after implementing the recommended remediation scheme in an isolated environment, and outputting a remediation report if the verification passes, specifically includes: Based on the recommended repair scheme, the source code files of the target automated test case set are repaired to obtain the repaired test cases; Execute the repaired test cases in an isolated environment, monitor the execution process and results, and obtain verification results, including test assertion results, execution integrity results, and environmental side effect check results. The verification results determine whether the repair has passed verification; if it has, a repair report is output.

[0082] In this embodiment, the location of the source code files corresponding to the target automated test case set is clearly defined. These source code files are typically stored in a specific project code repository, and the source code files that need to be fixed can be accurately located through pre-defined file path rules or version control system identification information.

[0083] Using text processing tools or the code editing functions provided by an Integrated Development Environment (IDE), modify the source code files according to the recommended remediation plan. For example, if the recommended remediation plan indicates that a certain section of code has a boundary condition coverage vulnerability and the boundary value judgment logic needs to be modified, then find the corresponding code segment in the source code and adjust the judgment conditions according to the suggestions in the plan, such as changing the original "less than or equal to" judgment to "less than" that value. For the remediation of uninitialized variable risks, if the plan suggests initializing the variables, add appropriate initialization statements before the variable is used for the first time, such as initializing uninitialized integer variables to 0. During the modification process, ensure the accuracy and completeness of the modifications to avoid introducing new code errors. After completing the modifications, save the source code file to obtain the remediated test cases.

[0084] To ensure the accuracy of the verification process and prevent interference from other factors, an isolated environment needs to be built. This isolated environment can be a standalone virtual machine or a containerized environment, and its configuration should be as consistent as possible with the actual operating environment of the software, including the operating system version, dependency library versions, and hardware configuration.

[0085] The repaired test cases are deployed to an isolated environment, and then the test cases are executed. During execution, multiple monitoring methods are used to obtain comprehensive verification results.

[0086] For monitoring test assertion results, test cases typically contain a series of assertion statements to determine whether the software's functionality meets expectations. A dedicated testing framework or a custom monitoring script can capture the execution results of these assertion statements in real time. For example, if an assertion states that a function's return value should be a specific value, after the function completes execution, the monitoring script will check whether the actual return value matches the expected value and record whether the assertion passed.

[0087] For monitoring the completeness of test case execution, it's crucial to ensure the execution flow of the test cases is complete, identifying any unexecuted code paths or premature termination. This can be achieved by inserting log entries into the code to record the execution status of each critical step. For example, adding log statements at the function's entry and exit points will record the corresponding logs as the function executes. By analyzing these logs, it's possible to determine whether the test cases executed completely according to the expected flow.

[0088] Monitoring environmental side effects involves checking whether the execution of test cases has caused unexpected side effects on the isolated environment, such as modifying system files or changing the configuration of dependent libraries. These side effects can be discovered by comparing the state of the isolated environment before and after the test cases are executed. For example, before executing test cases, critical files and configurations in the isolated environment can be backed up. After execution, the current state can be compared with the backup state, and any differences can be recorded as environmental side effects check results.

[0089] By combining the above three monitoring methods, verification results are obtained, including test assertion results, execution integrity results, and environmental side effect check results.

[0090] In some embodiments, in steps S101 to S105 above, the method further includes: Acquire repair process data, and construct reinforcement learning experience tuples based on the defect characteristics of the repair process data, the characteristics of the adopted repair scheme, and the model evaluation score and validation results; The reward value is calculated based on the verification results and the attributes of the repair plan. The reinforcement learning experience tuple and the reward value are stored in the experience replay pool. Data is sampled from the experience replay pool, and the policy network in the AI ​​repair engine is trained using the policy gradient algorithm to optimize the decision parameters of the policy network. The validated remediation cases in the experience replay pool are used as labeled samples to supervise and fine-tune the remediation confidence scoring model and the remediation impact assessment model.

[0091] In this embodiment, during the remediation of automated test cases, remediation process data is continuously collected. This data covers several key aspects. First, defect characteristics, which record in detail the various code defects detected in the target automated test case set. For example, for boundary condition coverage vulnerabilities, this includes which code modules they appear in, which boundary value judgment logic they involve, and for uninitialized variable risk points, the type of uninitialized variables, the function they reside in, and their call relationships. Second, the characteristics of the adopted remediation scheme, including the specific remediation measures taken for each defect. For example, for boundary condition coverage vulnerabilities, whether the judgment conditions were modified or boundary value handling logic was added; for uninitialized variable risk points, whether variable initialization was performed or the order of variable usage was adjusted. The complexity of the remediation scheme and the number of lines of code involved are also recorded. Finally, model evaluation scores and verification results are included. The model evaluation score comes from the remediation confidence scoring model and the remediation impact assessment model, reflecting the credibility of the remediation scheme and its potential impact. The verification results are obtained by verifying the test cases after implementing the recommended remediation scheme in an isolated environment, including whether the test passed and the specific details of the test assertions.

[0092] The defect features, adopted repair scheme features, model evaluation scores, and validation results from the aforementioned repair process data are organized and encapsulated according to the structure of reinforcement learning experience tuples. Reinforcement learning experience tuples typically contain information such as state, action, reward, and next state. In this scenario, defect features can be considered the current state, adopted repair scheme features can be considered the actions taken, the subsequently calculated reward value can be considered the reward information, and the state changes of the repaired test cases during the validation process can be abstracted as the next state (although in practice this may not strictly correspond to the traditional reinforcement learning concept of the next state, data organization follows this logic). In this way, reinforcement learning experience tuples are constructed, providing a data foundation for subsequent reinforcement learning training.

[0093] The reward value is calculated based on the verification results and the attributes of the remediation plan. The verification results are one of the key factors in determining the reward value. If the remediated test case passes verification in the isolated environment, it means that the remediation plan effectively solves the defect in the test case, and a higher base reward value will be given. Conversely, if the verification fails, a lower base reward value or even a negative reward value will be given to penalize the failure to effectively fix the problem.

[0094] In addition to the verification results, the attributes of the repair solution also affect the reward value. For example, a repair solution with low complexity, minimal code changes, and minimal impact on other software functions will receive an additional reward on top of the base reward value to encourage the generation of higher-quality and simpler repair solutions. Conversely, if the repair solution is highly complex, involves a large range of changes, or may have a potential impact on other software functions, the reward value will be reduced accordingly.

[0095] After calculating the reward value, the reinforcement learning experience tuples are associated with the reward value, and they are stored as a complete data record in the experience replay pool. The experience replay pool is a data structure used to store historical experience data. It breaks the temporal correlation between data, allowing for more efficient use of historical data in subsequent training processes, thereby improving the stability and effectiveness of training.

[0096] Data is sampled from the experience replay pool according to a certain sampling strategy. The sampling strategy can be random sampling or sampling based on data priority, such as prioritizing the sampling of experience tuples with higher or lower reward values ​​(those with greater learning value).

[0097] The sampled data is input into the policy network of the AI ​​repair engine. The policy network is a neural network model used to generate repair solutions. It outputs corresponding repair solutions (actions) based on the input defect features (i.e., the current state). During training, the policy gradient algorithm is used to optimize the decision parameters of the policy network. The basic idea of ​​the policy gradient algorithm is to calculate the gradient of the reward value with respect to the policy network parameters, and then update the parameters along the direction of the gradient, increasing the probability that the policy network generates repair solutions that can obtain higher reward values. Specifically, for each sampled empirical tuple, its corresponding gradient information is calculated, and then the parameters of the policy network are fine-tuned based on the gradient information. By continuously sampling data from the empirical replay pool and training, the decision parameters of the policy network are gradually optimized, enabling it to generate higher-quality and more effective repair solutions.

[0098] Validated repair cases from the experience replay pool are used as annotation samples. These validated repair cases contain rich information, including the original defect characteristics, the actual repair solutions used, the evaluation scores of the repair solutions, and the final validation results.

[0099] These labeled samples were used to perform supervised fine-tuning of the repair confidence scoring model and the repair impact assessment model. Supervised fine-tuning is a supervised learning method that involves inputting labeled samples into the model, calculating the error between the model's output and the true labels, and then adjusting the model's parameters using the error backpropagation algorithm to make the model's output closer to the true labels. For the repair confidence scoring model, the actual effects of the repair solutions (validation results) were used as true labels to adjust the model's ability to assess the confidence of the repair solutions; for the repair impact assessment model, the actual impact of the repair solutions on other functions of the software was used as true labels to optimize the model's accuracy in assessing the impact of the repair solutions. By continuously using labeled samples from the experience replay pool for supervised fine-tuning, the performance of these two models was improved, thereby providing a more reliable basis for subsequent repair solution selection.

[0100] In some embodiments, in steps S101 to S105 above, the method further includes: Identify non-code error phenomena and their environmental context characteristics during the repair process, and encode them as structured error events; Based on structured error events and historical operation and maintenance knowledge, an environmental problem knowledge graph is constructed, which includes error phenomenon nodes, potential root cause nodes, and solution nodes. When a new non-code error occurs, matching and multi-step reasoning are performed in the environmental problem knowledge graph to generate a list of potential root causes and corresponding solution suggestions. Based on the verification and confirmation results of each potential root cause in the potential root cause list, the confidence weights of the relevant relationship edges in the environmental problem knowledge graph are updated.

[0101] In this embodiment, during the repair process of automated test cases, a dedicated monitoring module is arranged to monitor the test runtime environment in real time. This monitoring module continuously collects various environmental information related to the test, including operating system version information, dependency library version information, hardware configuration parameters (such as CPU model, memory size, disk space, etc.), network connection status (such as network latency, bandwidth, etc.), and system resource usage during test runtime (such as CPU utilization, memory utilization, etc.).

[0102] When a test case fails and it is initially determined that the failure is not due to a code error, record the specific phenomena observed when the error occurred. For example, the test case may suddenly stop responding after a certain operation step or a specific error message may appear. Simultaneously, extract the environmental context features related to the error phenomenon, i.e., the various environmental information collected above.

[0103] Recorded non-code errors and extracted environmental context features are encoded using a predefined structured template. This template includes fields for error description, operating system version, dependency library version, hardware configuration, network status, and system resource usage. This encoding method transforms non-code errors and their environmental context features into structured error events, facilitating subsequent processing and analysis. For example, if a test case fails due to dependency library version incompatibility, the structured error event will explicitly record the error as "dependency library compatibility error," and will also detail the current dependency library version number, operating system version number, hardware configuration information, and network and system resource usage.

[0104] Collect historical operational knowledge, including non-code error cases encountered during past testing, corresponding root cause analyses, and the final solutions adopted. This historical operational knowledge can be obtained by reviewing test logs, operational record documents, and communicating with operations personnel.

[0105] Based on structured error events and combined with historical operational knowledge, a knowledge graph of environmental issues is being constructed. Within this knowledge graph, non-code error phenomena within each structured error event are designated as error phenomenon nodes. For example, "dependency library compatibility error" and "network connection timeout error" are treated as distinct error phenomenon nodes.

[0106] For each error phenomenon node, its potential root causes are analyzed based on historical operation and maintenance knowledge, and these potential root causes are established as potential root cause nodes and associated with the corresponding error phenomenon nodes. For example, for "dependency library compatibility error", potential root causes may include outdated dependency library versions, conflicts between dependency libraries and other software, etc. These potential root causes are respectively linked as nodes to the "dependency library compatibility error" node.

[0107] Simultaneously, for each potential root cause node, a corresponding solution is determined based on historical operational knowledge, and this solution is linked to the corresponding potential root cause node as a solution node. For example, for the potential root cause "dependency library version is too low," the solution might be to upgrade the dependency library version, thus linking "upgrade dependency library version" as a solution node to the "dependency library version is too low" node. In this way, an environmental problem knowledge graph is constructed, containing error phenomenon nodes, potential root cause nodes, and solution nodes, providing knowledge support for subsequent error reasoning and resolution.

[0108] When a new non-code error occurs, the error phenomenon and its environmental context features are first encoded into a new structured error event. Then, the error phenomenon in the new structured error event is matched with error phenomenon nodes in the environmental problem knowledge graph. If a perfectly matching error phenomenon node exists, the potential root cause node and solution node associated with that node are directly obtained; if no perfectly matching node exists, error phenomenon nodes with high similarity are searched. Similarity can be determined based on keyword matching of the error phenomenon description, similarity calculation of environmental context features, etc.

[0109] After identifying the associated potential root cause nodes, multi-step reasoning is performed. Multi-step reasoning means not only considering potential root causes directly associated with the error phenomenon node, but also further considering other potential root causes that these potential root causes may trigger. For example, if a potential root cause is "insufficient network bandwidth," further reasoning might consider that "insufficient network bandwidth may be due to network equipment failure or excessive network traffic." Through this multi-step reasoning, a comprehensive list of potential root causes is generated.

[0110] For each potential root cause in the potential root cause list, a corresponding solution node is retrieved from the environmental problem knowledge graph to generate a solution suggestion. The potential root cause list and its corresponding solution suggestions are then compiled and provided to operations or testing personnel for further analysis and processing.

[0111] Operations or testing personnel will verify and confirm each potential root cause based on the generated list of potential root causes and suggested solutions. Verification methods may include actually troubleshooting environmental issues and conducting relevant tests. For example, for the potential root cause of "outdated dependency library version," verification can be performed by checking the actual version of the dependency library and comparing it with the required version; for the potential root cause of "insufficient network bandwidth," verification can be performed by using network testing tools to conduct bandwidth tests.

[0112] Based on the verification results, the confidence weights of relevant relationship edges in the environmental problem knowledge graph are updated. If a potential root cause is verified as the true cause of a new non-code error, the confidence weight of the relationship edge between the potential root cause node and the corresponding error phenomenon node is increased. Simultaneously, if the potential root cause has a corresponding solution and the solution is effective, the confidence weight of the relationship edge between the solution node and the potential root cause node is increased. Conversely, if a potential root cause is verified as not being the true cause, the confidence weight of the relationship edge between the potential root cause node and the corresponding error phenomenon node is decreased. In this way, the environmental problem knowledge graph is continuously optimized, improving its accuracy and reliability in subsequent error reasoning and resolution.

[0113] Reference Figure 2An embodiment of the present invention provides an automated test case intelligent repair system 2, wherein the system 2 specifically includes: The test case filtering module 201 is used to receive the repair task configuration parameters and filter the target automated test case set according to the repair task configuration parameters. The defect identification module 202 is used to detect boundary condition coverage vulnerabilities based on the target automated test case set, and to identify uninitialized variable risk points by combining data flow analysis technology, thereby obtaining defect identification results. The repair solution module 203 is used to input the defect identification results into the AI ​​repair engine to generate a repair solution. The scheme screening module 204 is used to input the remediation schemes into the remediation confidence scoring model and the remediation impact assessment model, conduct risk assessment and screening of the remediation schemes, and obtain recommended remediation schemes. The solution verification module 205 is used to verify the test cases after the recommended repair solution is implemented in an isolated environment. If the verification is successful, a repair report will be output.

[0114] It is understandable that, such as Figure 1 The content of the automated test case intelligent repair method embodiment shown is applicable to the automated test case intelligent repair system embodiment. The specific functions implemented by the automated test case intelligent repair system embodiment are the same as those shown. Figure 1 The automated test case intelligent repair method shown in the embodiment is the same, and the beneficial effects achieved are the same as those shown. Figure 1 The beneficial effects achieved by the intelligent repair method for automated test cases shown in the embodiment are also the same.

[0115] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0117] Reference Figure 3 The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the automated test case intelligent repair method as described in any of the above methods.

[0118] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0119] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0120] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0121] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the automated test case intelligent repair method as described in any of the above methods.

[0122] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0123] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0124] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0125] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0126] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. An automated test case intelligent repair method, characterized in that, The method specifically includes: Receive the repair task configuration parameters and filter the target set of automated test cases based on the repair task configuration parameters; Based on the target automated test case set, symbolic execution technology is used to detect boundary condition coverage vulnerabilities, and data flow analysis technology is used to identify uninitialized variable risk points to obtain defect identification results; The defect identification results are input into the AI ​​repair engine to generate a repair plan; The remediation plans are input into the remediation confidence scoring model and the remediation impact assessment model to conduct risk assessment and screening of the remediation plans and obtain recommended remediation plans. In an isolated environment, test cases after implementing the recommended remediation plan are verified. If the verification passes, a remediation report is output.

2. The method according to claim 1, characterized in that, The process of receiving repair task configuration parameters and filtering the target automated test case set based on these parameters specifically includes: Receive the repair task configuration parameters input by the user through the configuration interface, and parse and extract the target scope definition rules and task execution strategy from the repair task configuration parameters; Based on the rules defined by the target scope, the identifiers of the target automated test cases and their corresponding source code files are filtered out by querying the test case management database; The target automated test case identifier and its corresponding source code file are bound to the task execution strategy to generate a set of target automated test cases.

3. The method according to claim 1, characterized in that, The target-based automated test case set utilizes symbolic execution technology to detect boundary condition coverage vulnerabilities and combines data flow analysis technology to identify uninitialized variable risk points, obtaining defect identification results, specifically including: Based on the target automated test case set, a symbolic execution path tree of the source code file is constructed. By marking the program input as symbolic values ​​and collecting path constraints, the boundary condition values ​​not covered in the original test cases are derived using the constraint solver, and boundary condition coverage vulnerability information is generated. Based on the target automated test case set, a control flow graph of the source code file is constructed. By analyzing the definition and usage states of variables in the control flow graph, a definition-use chain is established, and code locations where variables are not defined before use are identified in at least one path, generating information on uninitialized variable risk points. The system integrates boundary condition coverage vulnerability information with uninitialized variable risk point information to output defect identification results.

4. The method according to claim 1, characterized in that, The step of inputting the defect identification results into the AI ​​repair engine to generate a repair plan specifically includes: Based on the defect identification results, the defect type, defect location, and defect description information are extracted. Extract the context code snippet containing the defect from the source code file based on the defect location; The defect type, defect description information, and context code snippets are assembled into a structured prompt for the AI ​​repair model according to a preset template. The structured prompts are input into the AI ​​repair model for inference, resulting in multiple candidate repair solutions for the defects; Each candidate repair solution is parsed and formatted, and the specific code modifications and natural language descriptions corresponding to each candidate repair solution are extracted to generate a set of repair solutions.

5. The method according to claim 1, characterized in that, The process of inputting remediation plans into the remediation confidence scoring model and the remediation impact assessment model to conduct risk assessment and screening of the remediation plans and obtain recommended remediation plans specifically includes: Extract the semantic consistency features, historical pattern matching features, and code change simplicity features of each remediation scheme. Input the semantic consistency features, historical pattern matching features, and code change simplicity features into the pre-trained remediation confidence scoring model to obtain the remediation confidence score corresponding to each remediation scheme. By analyzing the dependencies of the modified code contained in each remediation plan through a pre-trained remediation impact assessment model, constructing a code change impact propagation graph and identifying affected internal related use cases and external common components, and generating a remediation impact risk rating for each remediation plan by combining the impact breadth and risk level; Based on preset decision-making rules, multiple remediation options are filtered and ranked by combining remediation confidence scores and remediation impact risk ratings to obtain recommended remediation options.

6. The method according to claim 1, characterized in that, The process involves verifying the test cases after implementing the recommended remediation plan in an isolated environment. If the verification passes, a remediation report is output, which includes: Based on the recommended repair scheme, the source code files of the target automated test case set are repaired to obtain the repaired test cases; Execute the repaired test cases in an isolated environment, monitor the execution process and results, and obtain verification results, including test assertion results, execution integrity results, and environmental side effect check results. The verification results determine whether the repair has passed verification; if it has, a repair report is output.

7. The method according to claim 6, characterized in that, The method further includes: Acquire repair process data, and construct reinforcement learning experience tuples based on the defect characteristics of the repair process data, the characteristics of the adopted repair scheme, and the model evaluation score and validation results; The reward value is calculated based on the verification results and the attributes of the repair plan. The reinforcement learning experience tuple and the reward value are stored in the experience replay pool. Data is sampled from the experience replay pool, and the policy network in the AI ​​repair engine is trained using the policy gradient algorithm to optimize the decision parameters of the policy network. The validated remediation cases in the experience replay pool are used as labeled samples to supervise and fine-tune the remediation confidence scoring model and the remediation impact assessment model.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Identify non-code error phenomena and their environmental context characteristics during the repair process, and encode them as structured error events; Based on structured error events and historical operation and maintenance knowledge, an environmental problem knowledge graph is constructed, which includes error phenomenon nodes, potential root cause nodes, and solution nodes. When a new non-code error occurs, matching and multi-step reasoning are performed in the environmental problem knowledge graph to generate a list of potential root causes and corresponding solution suggestions. Based on the verification and confirmation results of each potential root cause in the potential root cause list, the confidence weights of the relevant relationship edges in the environmental problem knowledge graph are updated.

9. An automated test case intelligent repair system, characterized in that, The system specifically includes: The test case filtering module is used to receive the configuration parameters of the repair task and filter out the target set of automated test cases based on the configuration parameters of the repair task. The defect identification module is used to detect boundary condition coverage vulnerabilities based on the target automated test case set, and to identify uninitialized variable risk points by combining data flow analysis technology to obtain defect identification results. The repair solution module is used to input the defect identification results into the AI ​​repair engine to generate a repair solution; The scheme screening module is used to input remediation schemes into the remediation confidence scoring model and the remediation impact assessment model, conduct risk assessment and screening of remediation schemes, and obtain recommended remediation schemes. The solution verification module is used to verify the test cases after the recommended repair solution is implemented in an isolated environment. If the verification is successful, a repair report will be output.

10. A computer device, characterized in that, include: A memory and a processor, and a computer program stored in the memory, which, when executed on the processor, implements the automated test case intelligent repair method as described in any one of claims 1 to 8.

Images