An automatic program repair method combining executable invariants and differential signals

Abstract

This invention relates to the field of program repair technology, and provides an automatic program repair method combining executable invariants and differential signals. The method includes: receiving the program to be repaired and a test set; generating multiple candidate patches by calling a large language model; forming an itemized list of behavioral specifications based on the repair intent description; generating several executable invariant assertions and injecting them into the target function or call point, generating an invariant assertion injection record table; generating test cases covering boundary conditions and abnormal scenarios based on the large language model; collecting execution signals while running the candidate patches; converting patch differences into semantic editing features and calculating an editing stability index; calculating the overall semantic consistency score of the candidate patches based on the support of the specification clauses; calculating the overall comprehensive score of the candidate patches; and outputting the optimal patch based on the overall comprehensive score of the candidate patches. This invention can effectively reduce the proportion of overfitted patches, improve the accuracy of repair patches, and has strong interpretability and good versatility.

Description

Technical Field

[0001] This invention relates to the field of large language models and automatic program repair technology, specifically to an automatic program repair method that combines executable invariants and differential signals. Background Technology

[0002] With the widespread application of Large Language Models (LLMs) in code generation and program repair, automatic program repair methods based on LLMs have gradually become a research hotspot. Existing techniques typically generate candidate patches by calling the large language model and then verify them using existing test sets. However, these methods have the following shortcomings: some candidate patches can pass test set verification but do not actually fix program defects, causing them to fail in real-world scenarios; some existing methods mainly rely on static analysis, symbolic reasoning, or coverage detection, making it difficult to capture erroneous behavior of patches under boundary conditions or abnormal inputs; although large language models can output natural language descriptions, reasoning steps, or repair reasons, current technologies lack technical solutions to transform this information into executable verification mechanisms; some methods rely on model fine-tuning or the generation of a large number of verification samples, making low-cost application in practical engineering difficult. Therefore, how to fully utilize the interpretable byproducts of large language models and combine them with executable signals to identify and screen patches has become an urgent technical problem to be solved. Summary of the Invention

[0003] To address the technical problems existing in the prior art, this invention proposes an automatic program repair method that combines executable invariants and differential signals. By introducing repair intent descriptions, executable invariants, and test cases generated by a large language model, these are transformed into executable or alignable verification signals. Furthermore, by combining coverage differentials, anomaly distributions, and return value distributions, candidate patches are comprehensively screened and ranked from multiple dimensions, thereby improving the correctness and reliability of repair patches. This solves the technical problems of high overfitting patch ratios, limited verification methods, and lack of interpretability in existing automatic program repair methods.

[0004] The first objective of this invention is to provide an automatic program repair method that combines executable invariants with differential signals.

[0005] A second objective of this invention is to provide a computer device.

[0006] A third objective of this invention is to provide a storage medium.

[0007] The first objective of this invention can be achieved by adopting the following technical solution:

[0008] An automatic program repair method combining executable invariants and differential signals, the method comprising:

[0009] S1. Receive the program to be repaired and the test set, and call the large language model to generate multiple candidate patches;

[0010] S2. Generate a repair intent description using a large language model, and form an itemized list of behavioral norms based on the repair intent description;

[0011] S3. Based on the large language model, generate several executable invariant assertions and inject them into the target function or call point, and generate an invariant assertion injection record table;

[0012] S4. Based on the examples and boundary handling requirements in the repair intent description, generate test cases covering boundary conditions and abnormal scenarios based on the large language model.

[0013] S5. Based on the invariant assertion injection record table and test cases, collect execution signals when running the candidate patch. The execution signals include coverage difference, anomaly distribution, invariant assertion triggering status and return value distribution.

[0014] S6. Align the itemized behavior specification list with the differences and operation logs of candidate patches for semantic consistency, convert the patch differences into semantic editing features and calculate the editing stability index, and calculate the overall semantic consistency score of candidate patches based on the support of specification clauses.

[0015] S7. Calculate the overall comprehensive score of candidate patches based on execution signals, editing stability index, and overall semantic consistency score, and output the optimal patch based on the overall comprehensive score of candidate patches.

[0016] Specifically, step S1 includes:

[0017] S11. Receive the software engineering information to be repaired, parse the software engineering information to generate engineering metadata; when failure test cases or stack traces are provided, organize them into failure contexts.

[0018] S12. Combining the first throw position of the failure context with the baseline coverage, determine the suspected file set and its corresponding modification range, and write the suspected file set and its corresponding modification range into the generation constraints.

[0019] S13. The large model generates several candidate patches at once. Each candidate patch is output in a uniform difference format or minimum change block. The candidate patches are deduplicated.

[0020] S14. Perform a pre-check on candidate patches without changing the business logic, and mark candidate patches as uncompileable and compileable.

[0021] Specifically, step S2 includes:

[0022] S21. Utilize the large language model to output a structured list of repair intent descriptions. The structured list includes: a summary of the repair intent description, preconditions, postconditions, exception and boundary handling, non-destructive items, and examples.

[0023] S22. Convert the natural language entries of the preconditions and postconditions in the structured list into computable conditional predicates to obtain an itemized list. Assign a specification number and version number to each itemized list to form an itemized behavior specification list.

[0024] Specifically, step S3 includes:

[0025] S31. Generate several executable invariant assertions based on the large language model. The invariant assertions include: entry invariant assertions, exit invariant assertions, and in-process invariant assertions.

[0026] S32. Based on the input constraints, output constraints, and internal logic requirements in the repair intent description, inject the corresponding entry invariant assertions and exit invariant assertions into the call point or target function.

[0027] S33. During invariant assertion injection, each invariant assertion is assigned an assertion number and a semantic label. After the invariant assertion injection is completed, an invariant assertion injection record table is formed.

[0028] Specifically, step S4, based on the examples and boundary handling requirements in the repair intent description, generates test cases covering boundary conditions and abnormal scenarios based on a large language model, including:

[0029] S41. Generate a test intent list based on the examples and boundary handling requirements in the repair intent description, and generate compilable test cases based on the test intent list;

[0030] S42. Determine the range and boundary points of the input parameters based on the preconditions and postconditions extracted from the repair intent description, and set an upper limit on the number of test cases based on the range and boundary points of the input parameters to form input data construction constraints.

[0031] Specifically, step S5 includes:

[0032] S51. Execute candidate patches on the original test set and test cases respectively in an isolated environment, and set the execution timeout and the total duration of the entire test set for each test case;

[0033] S52. When running candidate patches, collect coverage difference data, and collect the improvement in class coverage, method coverage, line coverage, and branch coverage respectively; calculate the coverage difference vector before and after the patch under the same test conditions, and calculate the line coverage difference, branch coverage difference, and neighborhood coverage improvement respectively.

[0034] S53. Calculate the assertion violation rate and exception rate respectively, parse the test output and error flow, statistically analyze the distribution of exception types, the location of the first exception, the proportion of newly added exceptions and calculate the exception rate; statistically analyze the number of times the injected assertions pass / fail, the triggering location and proportion, and correspond them one by one with the assertion number to form an assertion overview table and calculate the assertion violation rate.

[0035] S54. Collect sample values ​​of key variables under different test cases, calculate the numerical characteristics of key variables, perform statistical analysis on the values ​​of key variable numerical characteristics to obtain the distribution of key variables, and calculate the return value consistency score between the distribution of key variables and the expected relationship of the repair intention description through the return value consistency scoring function.

[0036] Specifically, step S6 includes:

[0037] S61. Semantic feature generation of patch differences: Patch differences are transformed into semantic editing features, risk labels are added to each edit, and editing stability indicators are calculated.

[0038] S62. Alignment of key points of the specification with operational facts: Using the postconditions / anomaly handling items of the itemized behavioral specification list as query items, align the specification items with the operational facts one by one, calculate the computational support of each specification item, and calculate the overall semantic consistency score of the candidate patch based on the support of each specification item.

[0039] Specifically, step S7 includes:

[0040] S71. Based on coverage difference, assertion violation rate, anomaly rate, consistency score and editing stability index, calculate the overall comprehensive score of candidate patches according to their respective weights;

[0041] S72. Constraints and tie-breaking: Candidate patches with the same overall score are determined by the principle of minimum change and compilation / execution time. If the assertion violation rate is greater than 0 and the assertion is true on the critical assertion, or if the anomaly rate exceeds the threshold, the candidate patch is removed and does not enter the ranking.

[0042] S73, outputs the patch with the highest overall score, providing score breakdown and evidence citation.

[0043] The second objective of this invention can be achieved by adopting the following technical solution:

[0044] A computer device includes a processor and a memory for storing a processor-executable program, wherein when the processor executes the program stored in the memory, it implements the above-described automatic program repair method combining executable invariants and differential signals.

[0045] The third objective of this invention can be achieved by adopting the following technical solution:

[0046] A storage medium storing a program that, when executed by a processor, implements the above-described automatic program repair method combining executable invariants and differential signals.

[0047] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0048] This invention proposes an automatic program repair method that combines executable invariants and differential signals. By introducing repair intent descriptions generated by a large language model, executable invariants, and adversarial tests, these are transformed into executable or alignable verification signals. Furthermore, by combining coverage differentials, anomaly distributions, and return value distributions, candidate patches are comprehensively screened and ranked from multiple dimensions, thereby improving the correctness and reliability of repair patches. This solves the technical problems of high overfitting patch ratios, limited verification methods, and lack of interpretability in existing automatic program repair methods.

[0049] By utilizing the byproducts of large language models as verification criteria, this approach not only generates patches but also extracts repair intentions, invariants, and test cases. These natural language or pseudocode products are then transformed into executable verification signals, achieving an organic combination of the interpretability of large language model LLMs and program verification. By introducing differential execution signals, differences in coverage, exception triggering, and assertion results among different patches are compared, providing a new dimension for measuring patch correctness and overcoming the shortcomings of traditional verification methods that rely solely on test sets. Through its lightweight design, it eliminates the need for training or fine-tuning large language models, relying only on existing models and general-purpose tools, enabling low-cost integration into existing automated program repair frameworks.

[0050] This invention reduces the generation of overfitted patches, increases the proportion of correct patches in the candidate set, and ensures the interpretability and universality of the screening process. This method is applicable to different programming languages ​​and various defect scenarios, and can also be combined with various existing patch generation methods, demonstrating good potential for practical application. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating the steps of an automatic program repair method combining executable invariants and differential signals in an embodiment of the present invention.

[0053] Figure 2This is a schematic diagram of the logic flow of the automatic program repair method in an embodiment of the present invention;

[0054] Figure 3 This is an internal structural diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0055] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments, and the implementation of the present invention is not limited thereto. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Example 1:

[0057] This embodiment provides an automatic program repair method that combines executable invariants and differential signals. Without training or fine-tuning a large language model, it introduces repair intent descriptions, executable invariants, and test cases generated by the large language model, transforming them into measurable execution signals. These signals, along with differential coverage and other information, are used for screening and ranking candidate patches to improve the hit rate of correct repairs and reduce the overfitting ratio. This method effectively reduces the proportion of overfitted patches, improves the accuracy of repair patches, and has the advantages of low cost, strong interpretability, and good versatility, making it suitable for automatic repair scenarios involving various programming languages ​​and multiple types of defects.

[0058] like Figure 1 As shown, the automatic program repair method combining executable invariants and differential signals according to the present invention includes:

[0059] S1: Receive the program to be repaired and the test set, and call the large language model to generate multiple candidate patches.

[0060] S11. Receive the software engineering information to be repaired, parse the software engineering information to generate engineering metadata; when failure test cases or stack traces are provided, organize them into failure context.

[0061] The system first receives information about the software project to be repaired. This information includes the project's root directory, source code files, test case directory, build tool information (such as Maven or Gradle), target module identifier (which can be a class name, method name, or line number range), and language version (such as Java 8). For example, if the input software project is a configuration parsing module and the test set contains failed test cases due to null pointer exceptions, the system parses the build script (such as pom.xml) to obtain the project metadata. Then, it calls the large language model to generate multiple candidate patches for the specified method location at once. Each patch is output in either a "uniform diff format" or "minimum change block" format. The system further performs syntax checks and duplicate filtering on the candidate patches to obtain a set of compilable candidate patches. The optimal number of candidates is 10-20 to balance diversity and execution cost.

[0062] In this example, the system parses the build script pom.xml or build.gradle to generate project metadata, including (1) a list of source files (including absolute path, package name, class name, and file fingerprint); (2) a list of test files; and (3) a list of dependencies. When a failed test case or stack trace is provided, it is organized into a failure context, which includes: the name of the failed test case, the exception type, and the class and line number of the first location where the exception was thrown.

[0063] In this embodiment, taking the integer clipping function in the general-purpose tool library as an example, the business intent of this function is: return 0 when the input is less than 0, return 100 when the input is greater than 100, and return the original value otherwise. Due to improper historical maintenance, the current implementation has boundary handling errors that need to be automatically corrected. The system receives the project root directory, test directory, build script, and language version, parses it to obtain the source code manifest, test manifest, and dependency manifest, and locates the `clip` method as the suspected modification area from failed test cases and stack traces.

[0064] S12. Combining the first throw position of the failure context with the baseline coverage, determine the suspected file set and its corresponding modification range, and write the suspected file set and its corresponding modification range into the generation constraints.

[0065] S121. When the input software engineering information does not explicitly specify the target class or method, combine the first throw location of the failure context in S11 with the baseline coverage to determine the suspected file set and its corresponding modification range, and obtain the defect range location result.

[0066] Specifically, when the target class or method is not explicitly given, it means that the input software engineering information does not directly specify the specific defect location. For example, only failed test cases, exception stacks, or test logs are provided, without explicitly indicating the source file or function name that should be modified. In this case, this invention automatically locates potentially defective files and methods by comprehensively analyzing the failure context information. Specifically, it first extracts the first throw position within the project namespace in the failure stack to identify initially suspicious files; then, combined with baseline coverage information, it increases the weight of files or methods covered by failed test cases; simultaneously, it matches relevant variable names and call statements in the source code based on exception type and keywords, and uses static analysis to determine the upstream and downstream call relationships at this location. After comprehensive calculation of multi-source signals, a set of suspected files and their corresponding modification ranges are formed. When the positioning accuracy reaches the method level, the range is represented in the form of "class name + method signature"; if only files or line blocks can be located, it is represented in the form of a line-level neighborhood of several lines above and below the first throw position (usually 3 to 7 lines).

[0067] S122. Write the defect range location results into the generation constraints to limit the allowed range and modification rules of patch generation. Perform constraint verification on the patch. If out-of-bounds or prohibited modifications are detected, the patch will be automatically rejected.

[0068] To prevent the large language model from generating modifications that exceed the target scope or affect the system structure, this invention incorporates the aforementioned location results into "generation constraints." Generation constraints are structured control information that limits the allowed scope and modification rules for patch generation. These constraints include the range of files, methods, or line numbers that can be modified, and prohibited modifications such as public interface signatures, cross-file call relationships, external dependency references, and exception swallowing. Parameters such as modification granularity, maximum number of patch blocks, and maximum number of lines changed per block are also set to ensure the scale of generated patches is controllable. Generation constraints are entered along with prompts when calling the large language model, explicitly instructing the model to only modify within the specified scope and follow established rules. After generation, the patch undergoes constraint validation; if out-of-bounds or prohibited modifications are detected, the patch is automatically rejected. For example, the scope is written as: { "Allow modification": "Foo.bar(int)", "Prohibit": ["Public interface signature", "Cross-file call relationship"]}. Subsequent prompts must reference this constraint to prevent excessive modification. In this way, the present invention can effectively limit the scope of modification without reducing the flexibility of repair, ensuring that the patch has the characteristics of being minimized, compilable and verifiable.

[0069] S13. The large model generates several candidate patches at once. Each patch is output in a uniform difference format or as a minimum change block. The candidate patches are deduplicated.

[0070] In this embodiment, the large model generates 10-20 candidate patches at once, and each patch is output in a uniform diff format or a minimal change block (JSON). The uniform diff format includes a file header, line number blocks, and added / deleted line markers. The minimal change block consists of fields for [file path, start line, end line, replacement content, and context fingerprint].

[0071] The deduplication process for candidate patches includes: first, normalizing whitespace and comments, then calculating hashes based on the syntax tree editing script (insertion / replacement / deletion, target node type) to achieve deduplication. A patch number is generated for each candidate, and generation metadata (model name, sampling parameters, timestamp, suggested version, etc.) is recorded.

[0072] S14. Perform a pre-check on candidate patches without changing the business logic, and mark candidate patches as uncompileable and compileable.

[0073] Perform a rapid preflight check without altering the business logic: ① Syntax check (e.g., using a tool equivalent to javac); ② Skip-test build run (using the "skip test" parameter supported by Maven / Gradle); ③ Basic style check. Candidates that fail the preflight check are marked as "uncompileable" but retained for statistical purposes; candidates that pass the preflight check proceed to the S5 runtime phase. Generation time increases linearly with the number of candidates; the number of candidates is typically 10–20 to avoid excessive subsequent execution costs.

[0074] S2. Use a large language model to generate a description of the repair intent and form a list of itemized behavioral norms.

[0075] S21. Utilize the large language model to output a structured list of repair intent descriptions. The structured list includes: a summary of the repair intent description, preconditions, postconditions, exception and boundary handling, non-destructive items, and examples.

[0076] Specifically, the large model is required to output a structured list (YAML or JSON) containing: 1) a summary of the repair intent: a one-sentence description of the repair objective; 2) preconditions: a list of conditions that the input and state must satisfy; 3) postconditions: observable behaviors and properties after repair; 4) anomaly and boundary handling: expected handling strategies under different boundary / anomaly inputs; 5) non-destructive terms: existing behaviors that should not regress; 6) examples: several "input-expected output" pairs, at least covering boundary examples.

[0077] If the list is not fully standardized, the system will perform weak fault-tolerant parsing (such as parentheses completion and synonym name unification) and verify that "summary and postconditions" are required fields.

[0078] S22. Convert the natural language entries of the preconditions and postconditions in the structured list into computable conditional predicates to obtain an itemized list. Assign a specification number and version number to each itemized list to form an itemized behavior specification list.

[0079] Specifically, the natural language entries of "preconditions / postconditions" are converted into computable conditional predicates: such as input range (e.g., x ≥ 0), return value relationship (e.g., return 0 when x < 0), and state invariance (e.g., "the size of the set does not decrease"). Each predicate is stored in an internal representation containing "left term, operator, right term, and scope (method level / object level)" for use by the invariant generation of S3 and the consistency alignment of S6.

[0080] Assign a specification number and version number to each specification list, and record the source model and a summary of the prompts. If the specifications are subsequently merged or corrected, retain a change log.

[0081] In this embodiment, for the aforementioned software engineering defects, the model may provide a description of the remediation intent: "Ensure that when the configuration item object is null, the default value 0 is returned without throwing an exception." This natural language description is converted into an itemized list, for example: [Precondition] The configuration item object is not null; [Postcondition] Return 0 when the configuration item object is null; [Non-disruptive item] Normal configuration parsing logic is not affected. The above list is assigned a unique number to support subsequent traceability.

[0082] S3. Generate several executable invariant assertions based on the large language model, inject the executable invariant assertions into the target function or call point, and generate an injection record table by attaching an assertion number and semantic label to each executable invariant assertion.

[0083] S31. Generate several executable invariant assertions based on the large language model. The executable invariant assertions include: entry invariant assertions, exit invariant assertions, and in-process invariant assertions.

[0084] The invention employs several invariant assertions: entry invariant assertions check whether the input parameters and initial state satisfy the preconditions described in the repair intent before the method call; exit invariant assertions verify whether the return value and output state meet the postconditions before the method returns; and in-process invariant assertions perform intermediate checks on critical loop bodies, conditional branches, or state update statements during method execution to ensure that the program maintains the expected relationships throughout the execution path. For example, when the repair intent description includes entries such as "the list length should not decrease during the loop" or "the accumulated variable should remain non-negative," in-process invariant assertions are automatically injected near the loop or critical statement. For general input / output functions, in-process invariants can be enabled or omitted depending on complexity; however, for functions containing loops or state-dependent logic, enabling in-process assertions helps to capture logical deviations in advance, thereby improving the coverage depth and reliability of verification. Therefore, this invention supports in-process invariant assertions as one of the invariant types to enhance the system's adaptability and scalability to complex program structures.

[0085] Map the preconditions of step S2 to entry assertions and the postconditions to exit assertions; complex relationships can be broken down into multiple basic assertions. To control overhead, the number of invariant assertions should not exceed a preset upper limit, preferably 3–5.

[0086] S32. Based on the input constraints, output constraints, and internal logic requirements involved in the repair intent description, inject the corresponding entry invariant assertions and exit invariant assertions into the call point or target function.

[0087] Specifically, the target function or call point refers to the location where the invariant injection operation is performed. Here, the "target function" refers to the function body itself identified as the target of the fix, i.e., the code block that the patch might modify; the "call point" refers to the upper-level location that calls the target function, used to monitor whether the call behavior conforms to the fix intent or does not violate the original constraints. For example, when the fix intent requires "parameters cannot be empty before the call" or "the return value must be non-negative after the call," entry assertions can be injected at the call point to check the validity of the input parameters or the call result; when the fix target involves the internal logic of the function, corresponding entry and exit assertions are inserted inside the target function. The purpose of this setup is to perform executable verification of the target function's execution process without changing the external interface and calling relationships, achieving full-process constraints on input, output, and intermediate states.

[0088] The target function is the core object to be repaired; while the call point is a node used for auxiliary monitoring of the function's call location. The choice between the two can be flexible depending on the repair intent: when the defect is concentrated within the function, the focus is on injecting assertions within the target function; when the problem originates from call parameters or return value passing, injection is performed at the call point. This design ensures the accuracy of verification while avoiding damage to the program structure, thus achieving a low-intrusion, executable invariant verification mechanism.

[0089] In this embodiment, the executable invariant can be implemented in multiple ways, which can be flexibly selected according to the characteristics of the programming language and the runtime environment. The assertion can adopt three invariant assertion forms:

[0090] 1) Runtime assertions (assert condition: "assertion number and prompt message", runtime assertions must be enabled).

[0091] 2) Unit test assertions (using JUnit assertion functions in test code);

[0092] 3) Contractual checks (such as non-empty checks and parameter validity checks).

[0093] Specifically, runtime assertions enable real-time verification of input and output states during program execution; unit test assertions allow for automated verification during the testing phase in conjunction with adversarial test sets; and contractual checks constrain the legality of parameters and return values ​​at function entry and exit points through a contractual framework. This design ensures that the invariant verification mechanism can be embedded in production code or run independently of the testing framework, thereby improving the method's versatility and engineering feasibility. With the support of multiple assertion mechanisms, this invention can achieve unified executable verification logic across different programming languages ​​and execution environments, providing a reliable foundation for subsequent execution signal acquisition and semantic consistency alignment, further enhancing the interpretability and technical adaptability of patch selection results.

[0094] S33. During invariant assertion injection, each invariant assertion is assigned an assertion number and a semantic label. After the invariant assertion injection is completed, an invariant assertion injection record table is formed.

[0095] In this embodiment, based on the large language model, the preconditions in the repair intent description are mapped to entry assertions, and the postconditions are mapped to exit assertions. Specifically, the following requirements are met when injecting invariant assertions: ① The method signature and type parameters are not changed; ② The assertion expression must not produce side effects; ③ The same type of exception is thrown uniformly when assertions fail, which is convenient for statistics. Each assertion is assigned a number, and the number of invariant entries does not exceed a preset limit. After injection, an injection record table is formed, which includes: file, method, line number, assertion expression, and source, so as to facilitate runtime verification and one-click rollback afterward. Each assertion is attached with an assertion number and semantic tag, which is convenient for S5 to statistically trigger and locate the entry assertion, which can be expressed as "If the input object is empty, trigger the check", and the exit assertion can be expressed as "When the input is empty, the return value must be equal to 0". The assertion injection does not change the method signature, does not introduce side effects, and assigns a number to each assertion for subsequent detection. To control runtime overhead, the number of invariant assertion entries does not exceed a preset limit, preferably 3 to 5.

[0096] S4. Based on the examples and boundary handling requirements in the repair intent description, generate test cases covering boundary conditions and abnormal scenarios using a large language model. Automatic coverage of boundary conditions and abnormal scenarios significantly improves the completeness and robustness of patch verification, effectively reducing the risk of overfitting caused by relying solely on the original test set.

[0097] In this invention, boundary conditions refer to situations where a program approaches its functional limits in terms of input data or runtime state, such as minimum value, maximum value, zero value, null value, empty string, extremely long input, or the boundary before and after numerical overflow. When a program processes such input, it is often prone to exposing hidden logical errors or conditional judgment defects. Therefore, boundary condition testing is used to verify the stability and correctness of the program under extreme input conditions. Abnormal scenarios refer to situations that may trigger abnormal or unexpected behavior during program execution, including but not limited to: invalid input type, empty parameters, division by zero, index out of bounds, file non-existence, network interruption, or data format errors. Abnormal scenario testing is used to verify the robustness and error handling capabilities of the program under abnormal input or runtime states, ensuring that the repaired code can safely exit or return as expected under abnormal conditions.

[0098] S41. Generate a test intent list based on the examples and boundary handling requirements in the remediation intent description, and generate compilable test cases based on the test intent list. This enables the conversion of test intents into executable units, and achieves a compile-level mapping from semantic-level test intents to actual runnable verification scripts. It is a key step in implementing the remediation intent description into an automated verification mechanism.

[0099] Specifically, a test case is the smallest unit of execution used to verify a specific function or behavior of a program, typically consisting of input data, expected output, and execution steps. Each test case corresponds to an executable unit test function that can run independently and output a pass or fail result. In this invention, test cases are automatically generated by a large language model based on the repair intent description, covering three categories of input: normal input, boundary condition input, and abnormal scenario input. For example, in the scenario of repairing the configuration parsing module, in addition to generating tests for normal configuration item parsing, the system automatically generates test cases for situations such as "configuration item is empty," "key is missing," and "value is in an invalid format," to comprehensively verify the behavior of the repair patch under various input conditions.

[0100] Specifically, the large language model first generates a structured "test intent list" based on the examples, preconditions, postconditions, and exception and boundary handling entries in the repair intent description. This list describes the semantic content of each test objective in a machine-parseable form (such as JSON or YAML), including: test name, combination of input parameters, execution target function, expected output or desired behavior (e.g., returning a specific value or throwing a specific exception), and whether it belongs to a boundary or exception category.

[0101] The system then performs "executable unit conversion" on the list, mapping each intent item to a compileable and runnable unit test function based on different languages ​​and testing framework templates. This process not only achieves semantic and syntactic conversion from natural language to program code, but also automatically completes structured elements such as initialization, assertions, and resource release, ensuring the integrity and runnability of the test code.

[0102] For example, in a Java environment, the system converts the test intent list into test code conforming to the JUnit specification: creating a `@Test` method for each test intent, filling the target function call with input parameters, and converting the expected result into assertion statements (such as `assertEquals()`, `assertThrows()`, etc.), while automatically inserting necessary initialization and cleanup logic; in a Python environment, it converts it into test functions conforming to the PyTest specification, using `assert` or `pytest.raises()` statements to verify the expectation. For tests that need to cover boundary or exceptional scenarios, the conversion module also automatically generates auxiliary input data (such as null values, negative numbers, maximum values, or illegal formats) and indicates the expected behavior in the test function (e.g., "should not throw an exception" or "should return the default value").

[0103] Therefore, the so-called "conversion of executable units" essentially refers to the process of transforming test intents from the semantic description stage into test case code units with complete input, execution, and verification logic. This process ensures that each test intent can be executed independently, run repeatedly, and produce clear pass / fail results, thereby achieving a closed-loop mapping from natural language repair descriptions to automated verification code. This mechanism eliminates the need for manual coding in the test case generation process, significantly improving the system's automation level, verification coverage, and traceability, and providing a reliable and operable foundation for subsequent execution signal acquisition and semantic consistency alignment.

[0104] Based on the "Example" and "Exception and Boundary Handling" entries in step S2, the system generates a test intent list: {Test Case Name, Input Category, Expected Result}. Subsequently, the system generates compilable unit tests using a unified template, employing a consistent naming convention for test classes and methods, and distinguishing between different equivalence classes such as normal, boundary, exception, and negative examples. Expected results are primarily derived from the machine-defined expression of postconditions; if "no exceptions are thrown" is required, then "no exceptions assertions" or equivalent structures are used to ensure that test cases of different categories correctly reflect the expected behavior described in the repair intent statement.

[0105] S42. Determine the range and boundary points of the input parameters based on the preconditions and postconditions extracted from the repair intent description, and set an upper limit on the number of test cases based on the range and boundary points of the input parameters to form input data construction constraints.

[0106] Specifically, based on the preconditions and postconditions extracted from the repair intent description, the system first derives the value range and critical points of each input parameter, including typical boundaries such as minimum, maximum, zero, null, NaN, and extreme length. Then, it automatically generates several representative values ​​for each type of input, forming an input sample set. For multi-parameter scenarios, the system introduces constraints when generating combinations to avoid invalid or duplicate parameter combinations, thus preventing combination explosion caused by an excessive number of test cases. To improve test reproducibility, the system fixes the random seed during the data generation phase and records generation metadata (including timestamps and version information). In scenarios involving external dependencies (such as files, networks, or system time), the system uses stubs or simulation mechanisms to simulate external interactions using virtual data or local substitutions, avoiding the influence of non-deterministic factors on test results. Finally, the system sets an upper limit on the number of test cases for each method, preferably 5-10, covering normal, boundary, and abnormal input cases. The system maps these input data and expected outputs to executable unit test functions (test cases), ensuring that the tests cover critical boundaries while maintaining high execution efficiency and stable results. It realizes the automated construction of input constraints into specific test data, ensuring that the verification process is representative, controllable and repeatable, and provides a reliable input basis for subsequent execution signal acquisition (S5).

[0107] When automatically generating test cases, the syntax rules, directory structure, and build configuration are standardized to ensure syntactic and build constraints, guaranteeing that the test code can be correctly compiled and recognized and executed by the project build system. Specifically, the test framework and syntax format supported by the target project are used uniformly when generating test cases. For example, JUnit annotations and standard assertion statements are used in Java projects, and PyTest function structures and assertion expressions are used in Python projects. This ensures that the generated test classes are syntactically correct and can be executed directly.

[0108] Test class files are organized according to the path corresponding to the image of the class under test, meaning the test classes and the class under test maintain the same package name or module structure, facilitating automatic association and execution by the build tool. Simultaneously, the system explicitly prohibits modifying production code to meet testing requirements, ensuring that repair verification does not affect the original logic. The only permitted exception is invariant assertion injection in S3, which is used to verify the effectiveness of repairs without altering functional behavior. Regarding build configuration, the test engine and result output functions are automatically enabled, for example, by adding corresponding test plugins and report paths to the Maven or Gradle build scripts. Through these constraints, it is ensured that the automatically generated test files conform to project specifications in terms of syntax, paths, and build process, enabling stable operation and output of verification results, providing a reliable foundation for subsequent execution signal collection.

[0109] S5. Based on the invariant assertion injection record table in step S3 and the test cases generated in step S4, execution signals are collected when the candidate patch is run. The execution signals include coverage difference, anomaly distribution, invariant assertion triggering status and return value distribution.

[0110] S51. In an isolated environment, execute the candidate patch on the original test set and the test cases generated in step S4 respectively. Set the execution timeout and the total duration of the entire test for each test case.

[0111] Specifically, all execution is performed in an isolated environment. The system executes candidate patches on both the original test set and the extended test set (original + adversarial test cases). The timeout for a single test case is preferably set to around 5 seconds, and the total test duration is preferably no more than 10 minutes, while limiting memory and concurrency. A coverage acquisition agent is enabled during execution. Each execution generates a run number and records the patch number, timestamp, and resource usage. During execution, the following signals are collected: ① Coverage difference, including the improvement in class coverage, method coverage, line coverage, and branch coverage; ② Anomaly distribution, including anomaly type and location; ③ Invariant assertion triggering, including the number of triggers and pass rate; ④ Return value distribution, such as mean, variance, and hit rate. For example, if a candidate patch does not trigger an anomaly and returns 0 in the "configuration item is empty" test, the assertion pass rate is 100%.

[0112] S52. When running candidate patches, collect coverage difference data, and collect the improvement of class coverage, method coverage, line coverage and branch coverage respectively; calculate the coverage difference vector before and after the patch under the same test conditions, and calculate the line coverage difference, branch coverage difference and neighborhood coverage improvement respectively.

[0113] The system runs under both the "original test set" and the "extended test set (original + adversarial)," parsing coverage reports to obtain coverage at four levels: class, method, line, and branch. A coverage report is a statistical file automatically generated by a coverage collection tool when test cases are executed, recording the proportion of code at different levels in the source code that are actually executed. Coverage reflects the extent to which tests reach the four levels of class, method, line, and branch, and is an important basis for measuring the impact of patch modifications on the program's execution scope. Specifically, the system runs the program versions before and after the patch under both the "original test set" and the "extended test set (original + adversarial)," calling existing coverage tools (such as JaCoCo for Java, Coverage.py for Python, and gcov for C) to generate coverage reports. These reports are typically output in XML, CSV, or JSON format, and include the execution count and coverage proportion for each class, method, and its corresponding lines of code and conditional branches.

[0114] The generated report is parsed to extract coverage data at four levels: class coverage, which represents the proportion of executed classes to the total number of classes; method coverage, which represents the proportion of called methods to the total number of methods; line coverage, which represents the proportion of executed lines of code to the total number of executable lines; and branch coverage, which represents the proportion of triggered conditional branches to the total number of branches.

[0115] Using the coverage results of "unpatched + original test set" as the baseline, the system calculates the coverage difference vector before and after the patch under the same test conditions. The coverage difference vector includes row coverage difference, branch coverage difference, and neighborhood coverage improvement. Among them, row coverage difference is the difference between row-level coverage before and after the patch, and branch coverage difference is the difference between branch-level coverage. At the same time, to measure the local impact range of the patch, "neighborhood coverage improvement" is calculated, which is the change in coverage of the region N rows (preferably 3-7 rows) above and below the patched row.

[0116] Specifically, the covering difference vector is calculated as follows:

[0117] Calculate the row coverage difference: Delta_line(c) = row coverage (after patch) - row coverage (before patch).

[0118] Calculate branch coverage difference: Delta_branch(c) = Branch coverage (after patch) - Branch coverage (before patch).

[0119] Calculate the neighborhood coverage improvement: Delta_cov_near(c) = Neighborhood coverage (after patch) - Neighborhood coverage (before patch).

[0120] Through this step, the present invention can quantify the changes in the execution behavior of candidate patches, especially the coverage improvement within the patch's neighborhood, thereby providing a reliable basis for judging the correctness, scope of influence, and stability of patches.

[0121] In this embodiment, patches A / B / C are used as examples for illustration:

[0122] Coverage difference: Calculates row / branch coverage changes and coverage improvement in changed neighborhoods. A and B both show significant improvement in changed neighborhoods, while C is close to A.

[0123] Anomaly distribution: Patch A has no new anomalies; Patch B has no anomalies; Patch C throws a runtime anomaly when inputting 101, increasing the anomaly rate.

[0124] Invariant assertions: A. All pass; B. Violates "NEG>0" when inputting 0; C. Violates the "no exception thrown" related entry and triggers assertion statistics exception when inputting 101.

[0125] Return value distribution: Patch A returns {0, 0, 100} for {-1, 0, 101}, consistent with expectations; Patch B, by changing "≤0" to "<0", takes the subsequent branch and ultimately returns 0 when 0 is input, which appears numerically correct, but does not follow the intended path of "non-positive numbers should be directly returned to zero", thus incurring a deduction in the semantic alignment stage; Patch C throws an exception without returning a value when 101 is input. The above statistics are uniformly stored as row-based data (run number, patch number, coverage difference, exception statistics, assertion pass / fail count, return value statistics, time consumed, exit code, etc.) for subsequent automatic calculation.

[0126] S53. Calculate the assertion violation rate and the anomaly rate respectively, parse the test output and error flow, statistically analyze the distribution of anomaly types, the location of the first anomaly, the proportion of newly added anomalies, and calculate the anomaly rate; statistically analyze the number of times the injected assertions pass / fail, the triggering location and proportion, and correspond them one by one with the assertion number to calculate the assertion violation rate.

[0127] In this invention, assertion violation rate and anomaly rate are used to measure the stability and correctness of candidate patches during execution and are important components of the execution signal. Assertion violation rate reflects the proportion of invariant assertions injected by step S3 that fail to trigger during execution, and is used to evaluate whether the patch violates the behavioral constraints specified in the repair intent statement; anomaly rate statistically analyzes runtime anomalies or timeouts that occur during test execution, and is used to reflect the robustness of the patch under abnormal input or boundary conditions.

[0128] Specifically, the assertion violation rate and anomaly rate are calculated as follows:

[0129] assertion violation rate of candidate patch c: viol(c) = number of violations / total number of checks

[0130] The anomaly rate of candidate patch c: exc(c) = (total anomalies + timeout penalty weight) (Number of timeouts) / Total number of test cases

[0131] The recommended weight for timeout penalty is 2; if a critical assertion fails or a new fatal exception is added, the patch should be removed.

[0132] In the overall process, the assertion violation rate and anomaly rate, along with other execution signals from step S5 (such as coverage difference and return value distribution), constitute a quantitative vector of patch performance and participate in semantic consistency alignment in step S6. When the remediation intent description includes items such as "no exceptions should be thrown" or "all assertions should pass," the system matches these semantic requirements with the corresponding assertion violation rate and anomaly rate to determine whether the patch behavior conforms to the remediation intent. In the final step S7, these two indicators serve as negative features in the comprehensive scoring model, directly affecting the patch ranking results: patches with high violation or anomaly rates will be judged as unstable or erroneous patches; if a critical assertion fails or a new fatal anomaly is added, the patch will be directly rejected by the system and will not enter the final screening stage.

[0133] By introducing measures of assertion violation rate and anomaly rate, this invention can transform runtime behavioral anomalies and logical errors into quantifiable judgment signals, achieving fine-grained distinction from "passed the test" to "correct behavior", thereby significantly reducing the proportion of overfitted patches and improving the accuracy and reliability of repair screening.

[0134] S54. Collect sample values ​​of key variables under different test cases, calculate the numerical characteristics of key variables, perform statistical analysis on the values ​​of key variable numerical characteristics to obtain the distribution of key variables, and calculate the return value consistency score between the distribution of key variables and the expected relationship of the repair intention description through the return value consistency scoring function.

[0135] Specifically, key variables refer to variables that directly or indirectly reflect the repair intent, such as the main calculation results of a function, intermediate state variables, loop counters, or flag bits. When executing candidate patches, the system collects return value samples, gathering sample values ​​of these variables under different test cases through lightweight instrumentation or logging, and calculating their numerical characteristics (such as mean, variance, extreme values, or distribution patterns). Key variable distribution refers to the statistical analysis of the values ​​of key variables during program execution to reflect the impact of the patch on program behavior.

[0136] The key variable distribution is used to perform a "weak match" with the expected relationship stated in the repair intent description in step S2, that is, to determine whether the changing trend or output characteristics of the key variables meet the repair target. For example, if the repair intent requires "the result should be non-negative" or "the counter should monotonically increase," the system can verify whether the patch satisfies such properties through the key variable distribution. Through statistical analysis of the key variable distribution, this invention can determine the rationality and stability of the patch from a behavioral perspective without relying on specific output values.

[0137] In this embodiment, for targets labeled as "pure functions" or whose output can be directly observed, return value samples are collected, and classification distributions or numerical statistics (mean, variance, extreme values) are calculated. These are then compared with the expected relationship described in the repair intent statement in step S2 (e.g., the hit rate of "returning 0 when the input is less than 0"). If necessary, minimal instrumentation (printing or probing) is performed at key locations to ensure that business behavior is not altered.

[0138] Specifically, the return value consistency scoring function :

[0139] ;

[0140] The distance function can be any distance metric (such as KS distance or Jensen-Shannon distance), and the result is mapped to [0,1]; a higher value indicates a better match to expectations. (Symbols) This represents the return value consistency scoring function for candidate patch c. It measures the degree of match between the observed return value distribution during patch execution and the expected distribution specified in the repair intent statement in step S2. A score closer to 1 indicates that the patch's return behavior is more in line with expectations; a lower score indicates a greater deviation from the repair objective. Therefore, It serves as a semantic consistency signal in the system, used for the alignment of repair intentions in step S6 and the comprehensive patch scoring in step S7, and is one of the important indicators for evaluating the semantic correctness of patches.

[0141] In this embodiment, the execution signal recording format is a line-based JSON record of the execution signals generated in each execution. The values ​​are normalized or standardized as needed for direct use in subsequent steps. The fields of the execution signals include: run number, patch number, test suite identifier, coverage difference, exception statistics, assertion summary, return value statistics, timeout, out-of-memory status, exit code, etc.

[0142] Example of line-based JSON: { "Run ID":"run_...","Patch ID":"patch_...", "Test Suite":"Original|Extended", "Coverage Difference":{"Line":..., "Branch":..., "Neighborhood":...}, "Exception Statistics":{"Total Exceptions":...,"Timeout":..., "Type Distribution":{...}}, "Assertion Summary":[{"Assertion ID":"inv_1","Pass":x,"Fail":y},...], "Return Value Statistics":{"Hit Rate":{"Returns 0 when x<0":0.93}, "Mean":..., "Variance":...}, "Timeout in milliseconds":..., "Timeout":false, "Exit Code":0}

[0143] S6. Align the differences between the repair intent description and the candidate patches and the runtime logs for semantic consistency, convert the patch differences into semantic editing features and calculate the editing stability index, and calculate the overall semantic consistency score of the candidate patches based on the support of the specification clauses.

[0144] The system aligns each specification entry in the repair intent with the execution signal. For example, the entry "Return 0 when configuration object is empty" will be aligned to the result "Hit rate = 100%" in the return value distribution; the entry "Does not break normal logic" will be aligned to the result "Pass rate = 100%" in the assertion check. The alignment result is calculated as a support score, with uncovered entries treated as 0.5 and entries covered by adversarial use cases given higher weights, ultimately aggregated into a consistency score.

[0145] S61. Convert patch differences into semantic editing features, assign a risk label to each edit, and calculate the editing stability index.

[0146] Convert patch differences into semantic editing features: for example, which interface calls were modified, how conditional expressions changed (e.g., "≥" changed to ">"), whether abnormal paths were added / removed, and whether boundary branches were added. Label each edit with a risk tag (e.g., "condition negation" or "may introduce null pointer short circuit") and calculate edit stability metrics.

[0147] Specifically, stability indicators It can be represented as:

[0148] ;

[0149] The normalized risk score represents the normalization within the current defect instance, with the result in [0,1]. The stability indicator function is denoted as... It is a linear synthesis of the normalized risk score r(c) and the editing dispersion d(c): ,in As an empirical coefficient, r(c) is a comprehensive score of risk labels such as 'condition negation, abnormal path addition, cross-module reference, etc.' and normalized within the current defect instance. d(c) reflects whether the modification is concentrated in the neighborhood of the change and the granularity of the change is the smallest.

[0150] S62. Alignment of specification points to operational facts: Using the postconditions / anomaly handling items in step S2 as "query items", align each specification item with the operational facts, calculate the computational support of each specification item, and calculate the overall semantic consistency score of the candidate patch based on the support of each specification item.

[0151] Specifically, the operational facts of step S5 are aligned one by one, and the coverage difference, anomaly distribution, assertion triggering status, and return value distribution collected in step S5 are mapped one by one to the specification entries in step S2, determining whether each specification is satisfied, violated, or irrelevant. This includes aligning to the hit rate / violation rate of return value statistics, aligning to anomaly type and frequency statistics, and aligning to the pass / fail count in assertion overview, which can be expressed as:

[0152] Input-output relationship → Align to the hit rate / violation rate statistics of the return value;

[0153] Anomaly Strategy → Align with anomaly type and frequency statistics;

[0154] State unchanged → Align with pass / fail count in assertion profile.

[0155] Alignment employs a two-stage process: "rules + keyword mapping" (including a list of terms and parameters) and "string approximate matching." If necessary, a small sentence vector model can be used to evaluate short sentence similarity, but without any training or fine-tuning.

[0156] Specifically, for each specification item Calculate the support score, and then calculate the overall semantic consistency score based on the support score.

[0157] Calculate each specification entry Calculate support: ∈ [0,1];

[0158] For each canonical predicate, a support score (0–1, higher values ​​indicate stronger consistency) is calculated, and the scores are aggregated by weight to obtain a semantic consistency score. Functional postconditions have a higher weight than descriptive entries; entries covered by adversarial tests have appropriately increased weights. Negative evidence (newly added unexpected anomalies, key assertion failures) is penalized. The final consistency score of 0–1 is obtained, and together with the coverage difference of S5, anomaly and assertion metrics, it constitutes the feature vector of this patch.

[0159] Calculate the overall semantic consistency score: ;

[0160] Where 'c' represents a candidate patch. This represents the total number of entries. If an entry is not reached, it is treated with a neutral value of 0.5; if an entry is covered by adversarial tests, its weight is increased.

[0161] In this invention, the support levels of each specification item are standardized to ensure that the support results of different items fall within a unified metric, facilitating the comprehensive calculation of the overall semantic consistency score. This standardization maps the satisfaction levels of multiple semantic constraints (preconditions, postconditions, invariants, anomaly constraints, etc.) to the interval [0,1], ensuring that the scoring results are comparable and weighted. The normalized results are used to form a patch feature vector together with other execution signals (such as coverage difference, assertion violation rate, and anomaly rate), providing a unified quantitative basis for subsequent screening and ranking.

[0162] In this embodiment, each entry in the "Repair Intent Description" can be aligned with the operational facts one by one, and the support level can be calculated:

[0163] For items 1 / 2 / 3, the support is calculated based on the return value hit rate and the assertion pass rate;

[0164] For item 4, support is calculated based on outlier statistics;

[0165] For item 5 (non-destructive item), calculate the support by checking if the return value for input 50 is 50.

[0166] The semantic consistency scores were summarized as follows: Patch A had the highest score; Patch B was penalized because "the processing path for 0 did not directly follow the zeroing branch"; Patch C had a significantly lower score due to the addition of new anomalies.

[0167] S7. Calculate the overall comprehensive score of candidate patches based on execution signals, editing stability indicators, and overall semantic consistency score, and output the most suitable patch based on the overall comprehensive score of candidate patches.

[0168] S71. Based on coverage difference, assertion violation rate, anomaly rate, consistency score and editing stability index, calculate the overall comprehensive score of candidate patches according to their respective weights.

[0169] Specifically, the overall score = coverage improvement weight × coverage metric + assertion weight × assertion pass metric + anomaly weight × (1 − new anomaly rate) + semantic weight × consistency score + stability weight × edit stability metric.

[0170] The weights of each component can be set empirically, or a light fit can be performed using a small number of historical labels (such as logistic regression), but without training a large model, and the overall score is calculated. The calculation formula is expressed as:

[0171]

[0172] The meanings of each parameter are as follows:

[0173] Coverage differential weights are used to measure the importance of improving execution coverage.

[0174] The neighborhood coverage improvement metric indicates the change in coverage of the patch-modified area and its neighboring rows.

[0175] Assertion weights reflect the impact of assertion pass rates on the overall score;

[0176] Assertion failure rate: This represents the proportion of assertions that fail during the operation.

[0177] Abnormal weights adjust the degree of influence on the abnormality rate indicator;

[0178] : Anomaly rate, representing the proportion of runtime anomalies or timeouts that occur during execution;

[0179] Semantic weights are used to adjust the contribution of semantic consistency scores to the overall score.

[0180] Semantic consistency score: This indicates the degree of matching between the patch behavior and the stated intent of the fix.

[0181] Stability weight, used to measure the importance of editing stability metrics;

[0182] : Edit stability metrics, representing the local syntactic and semantic stability of patch changes;

[0183] : Return value weights, used to adjust the impact of the return value distribution matching degree on the overall score;

[0184] : Return value consistency score, indicating how close the patch's returned result is to the expected output distribution.

[0185] The scoring model obtains the overall comprehensive score of candidate patches by standardizing and weighting each execution signal. The higher the value, the better the patch performs in terms of correctness, stability and semantic consistency.

[0186] Weights And the sum is 1; the weights of unused components are distributed proportionally.

[0187] S72. Constraints and tie-breaking: Candidate patches with the same overall score are determined based on the principle of minimum change and compilation / execution time. If the assertion violation rate is greater than 0 and the assertion is true on the critical assertion, or if the anomaly rate exceeds the threshold, the candidate patch is removed and does not enter the ranking.

[0188] The system defaults to removing critical assertions that fail; the default upper limit of the anomaly rate threshold exc(c) is 0.30; when exc(c) exceeds the threshold or a new fatal anomaly occurs, it will not be included in the sorting. The threshold can be configured within [0.1, 0.4] according to the project quality threshold.

[0189] If a critical assertion fails or a new fatal exception is added (such as a runtime error exceeding the threshold), the candidate is directly downgraded or eliminated. Candidates with the same overall score are judged based on the principle of minimal changes (fewer edits, lower risk labels) and compilation / execution time. If viol(c) > 0 is true on a critical assertion, or exc(c) exceeds the threshold (e.g., > 0.3), the patch is eliminated and not included in the ranking.

[0190] S73. Output the patch with the highest overall score, along with the corresponding score breakdown and evidence citations.

[0191] Specifically, the final output includes: the optimal patch, score breakdown, and evidence reference. The score breakdown includes the score and weight of each component, and the evidence reference includes the triggered invariant number, test case name, coverage report location, etc., to facilitate manual review and auditing.

[0192] In the aforementioned "integer pruning function" scenario, this embodiment leverages invariants and adversarial testing to enhance the verification strength of boundary inputs, reducing the probability of overfitting patches that pass solely based on the original test set being selected. Through semantic consistency alignment and evidence chain output, it enhances the interpretability and verifiability of the results. This method is also applicable to common defect types such as division by zero protection, index boundaries, set deduplication, and numerical overflow protection, demonstrating good versatility and engineering feasibility.

[0193] In summary, this invention provides an automated program repair method that combines executable invariants and differential signals. Through invariants and adversarial testing, it enhances the verification capability of patches under boundary conditions and reduces overfitted patches. It requires no training or fine-tuning of large language models, relying only on existing models and lightweight tools. The screening results can be traced back to specific invariants, tests, or execution signals, facilitating manual review and verification. It can be applied to different programming languages, different types of defects, and various candidate patch generation methods. This invention not only automatically generates and verifies candidate patches but also combines invariants and differential signals to achieve a comprehensive evaluation of patch effectiveness and robustness, thereby reducing the proportion of overfitted patches and improving repair accuracy and traceability.

[0194] Example 2

[0195] This embodiment provides a computer device, which may be a server, computer, etc., including a processor, memory, input device, display, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. When the processor executes the computer programs stored in the memory, it implements the automatic program repair method combining executable invariants and differential signals described in Embodiment 1 above.

[0196] Example 3

[0197] This embodiment provides a storage medium, which is a computer-readable storage medium that stores a computer program. When the program is executed by a processor, the processor executes the computer program stored in the memory to implement the automatic program repair method combining executable invariants and differential signals described in Embodiment 1 above.

[0198] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. An automatic program repair method combining executable invariants with differential signals, characterized in that, The method comprises the following steps: S1, receiving a program to be repaired and a test set, and calling a large language model to generate a plurality of candidate patches; S2, generating a repair intention description using the large language model, and forming an itemized behavior specification list according to the repair intention description; S3, generating a plurality of executable invariant assertion based on the large language model and injecting into the target function or call point, and generating an invariant assertion injection record table; S31, generating a plurality of executable invariant assertion based on the large language model, and the invariant assertion comprises: entry invariant assertion, exit invariant assertion, and in-process invariant assertion; S32, according to the input constraint, output constraint and internal logic requirement in the repair intention description, injecting the corresponding entry invariant assertion and exit invariant assertion in the call point or the target function; S33, when the invariant assertion is injected, each invariant assertion is attached with an assertion number and a semantic label, and an invariant assertion injection record table is formed after the invariant assertion injection is completed; S4, according to the example and boundary processing requirement in the repair intention description, generating a test case covering the boundary condition and the abnormal scene based on the large language model; S5, based on the invariant assertion injection record table and the test case, collecting execution signals when the candidate patch is running, and the execution signals comprise coverage difference, abnormal distribution, invariant assertion triggering condition and return value distribution; S6, aligning the itemized behavior specification list with the difference of the candidate patch and the running log in semantics, converting the patch difference into semantic editing features and calculating an editing stability index, calculating the overall semantic consistency score of the candidate patch according to the support degree of the specification item, and outputting the optimal patch according to the overall comprehensive score of the candidate patch. The receiving of the program to be repaired and the test set, and the calling of the large language model to generate a plurality of candidate patches comprises:

2. The method of claim 1, wherein the executable invariant is combined with the differential signal. S11, receiving software engineering information to be repaired, analyzing the software engineering information to generate engineering metadata, and arranging a failure context when a failure case or a stack trace is provided; S12, combining the first throwing position of the failure context with the baseline coverage to determine a suspected file set and a corresponding modification range, and writing the suspected file set and the corresponding modification range into a generation constraint; S13, the large model generates a plurality of candidate patches at a time, each candidate patch is output in a unified difference format or a minimum change block, and a de-duplication operation is performed on the candidate patches; S14, performing a pre-check on the candidate patch without changing the business logic, and marking the candidate patch as uncompileable and compileable. The generation of the repair intention description using the large language model, and the formation of the itemized behavior specification list according to the repair intention description comprises:

3. The method of claim 1, wherein the executable invariant is combined with the differential signal. S21, outputting a structured list of repair intention description using the large language model, and the structured list comprises: repair intention description abstract, precondition, postcondition, exception and boundary processing, non-destructive item and example. ​ S22, convert the natural language entries of preconditions and postconditions in the structured list into computable conditional predicates to obtain an entry list, assign a specification number and a version number to each entry list to form an entry behavior specification list.

4. The method of claim 1, wherein the executable invariant is combined with the differential signal. According to the examples and boundary processing requirements in the repair intention description, test cases covering boundary conditions and abnormal scenarios are generated based on a large language model, which includes: S41, generate a test intention list according to the examples and boundary processing requirements in the repair intention description, and generate a compilable test case according to the test intention list; S42, determine the value range and boundary point of the input parameter according to the preconditions and postconditions extracted in the repair intention description, set the upper limit of the number of test cases based on the value range and boundary point of the input parameter, and form the input data construction constraint.

5. The method of claim 1, wherein the executable invariant is combined with the differential signal. According to the invariance assertion injection record table and the test case, the execution signal is collected when the candidate patch is run, which includes coverage difference, abnormal distribution, invariance assertion triggering condition and return value distribution, which includes: S51, execute the candidate patch on the original test set and the test case generated in step S4 respectively in an isolated environment, set the execution timeout length and the total time length of the whole test for each case; S52, collect the coverage difference when running the candidate patch, and collect the improvement of class coverage, method coverage, line coverage and branch coverage respectively; calculate the coverage difference vector under the same test condition before and after the candidate patch, and calculate the line coverage difference, branch coverage difference and neighborhood coverage improvement respectively; S53, calculate the assertion violation rate and the abnormal rate respectively, analyze the test output and the error stream, and count the abnormal type distribution, the first abnormal position, the proportion of new abnormalities and calculate the abnormal rate; count the pass / fail times, trigger position and proportion of injected assertions, and correspond one by one with the assertion number to form an assertion profile table and calculate the assertion violation rate; S54, collect the value samples of the key variables under different test cases, calculate the numerical characteristics of the key variables, and count the value of the numerical characteristics of the key variables to obtain the key variable distribution, and calculate the return value consistency score of the key variable distribution and the expected relationship of the repair intention description by the return value consistency score function.

6. The method of claim 1, wherein, The entry behavior specification list and the difference and running log of the candidate patch are aligned in semantics, the patch difference is converted into semantic editing features, and the editing stability index is calculated, and the overall semantic consistency score of the candidate patch is calculated according to the support degree of the specification item, which includes: S61, semantic feature of patch difference, convert patch difference into semantic editing features, label each editing with risk label, and calculate editing stability index; S62, align the specification points to the running facts, take the postconditions / abnormal handling entries of the entry behavior specification list as the query items, align the specification entries and the running facts one by one, calculate the calculation support degree of each specification entry, and calculate the overall semantic consistency score of the candidate patch according to the support degree of each specification entry.

7. The method of claim 5, wherein the executable invariant is combined with the differential signal. The overall comprehensive score of the candidate patch is calculated based on the execution signal, the editing stability index, and the overall semantic consistency score, and the optimal patch is output according to the overall comprehensive score of the candidate patch, including: S71, based on the coverage difference, the assertion violation rate, the exception rate, the return value consistency score, the editing stability index and the overall semantic consistency score, the overall comprehensive score of the candidate patch is calculated according to the respective weights; S72, constraint and tie-breaking, the candidate patches with the same overall comprehensive score are judged according to the minimum change principle and the compilation / execution time consumption, if the assertion violation rate is greater than 0 and is established on the key assertion, or the exception rate exceeds the threshold, the candidate patch is excluded and does not enter the sorting; S73, output the patch with the highest comprehensive score, and output the corresponding score disassembly and evidence reference.

8. The method of claim 7, wherein the executable invariant is combined with the differential signal. The calculation formula of the overall comprehensive score is: ； wherein, denotes a coverage differential weight, denotes a neighborhood coverage promotion indicator, denotes an assertion weight, denotes an assertion violation rate, denotes an anomaly weight, denotes an anomaly rate, denotes a semantic weight, denotes an overall semantic consistency score, denotes a stability weight; denotes an edit stability indicator, denotes a return value weight, denotes a return value consistency score.

9. A computer device comprising a processor and a memory for storing a processor executable program, characterized in that, The processor executes the program stored in the memory, and realizes the automatic program repair method combining executable invariants and differential signals according to any one of claims 1-7.

10. A storage medium storing a program, characterized by comprising: The program is executed by the processor, and realizes the automatic program repair method combining executable invariants and differential signals according to any one of claims 1-7.

Images