Software defect automatic repair method and device, equipment and storage medium

Abstract

The invention provides a software defect automatic repairing method and device, equipment and a storage medium. Relates to the technical field of program automatic repair. The method comprises the steps of problem description, input preprocessing of a code warehouse, hierarchical positioning based on a function signature, and generation and verification of a repair scheme. After the code warehouse is preprocessed, the code warehouse is matched with the input defect description information to carry out a first round of defect function positioning, the positioned defect functions are used as candidate functions, if the number of the positioned defect functions does not reach five, defect file positioning is carried out, and then a second round of defect function positioning is carried out; according to the method, at least five positioned defect functions are ensured, a repair scheme is generated based on the at least five positioned defect functions, the repair scheme is verified / tested to obtain a unique optimal scheme, and the defective software is automatically repaired based on the unique optimal scheme. According to the method, the positioning accuracy is ensured, and the efficiency is improved by dynamically adjusting the analysis hierarchy.

Description

Technical Field

[0001] This application relates to the technical field of program automatic repair, and particularly to a method, device, equipment and storage medium for automatic software defect repair. Background Art

[0002] In recent years, large language models (LLMs) have made significant progress in software development tasks such as code generation, program repair, and test generation. Currently, the industry generally adopts an agent-based approach to perform end-to-end software development tasks, and these agents have the ability to use tools, run commands, observe feedback, and plan future actions.

[0003] However, the agent-based approach has the following problems:

[0004] 1. Tool usage and design are complex. The current agent-based approach requires an abstraction layer to be applied between the agent and the environment, and this abstraction and API call specification require careful design of the input / output format, which easily leads to inaccurate tool usage.

[0005] 2. Decision-making planning lacks control. The agent system decides the current actions based on previous actions and environmental feedback, and often lacks an effective verification mechanism.

[0006] 3. The self-reflection ability is limited. Existing agents are difficult to effectively filter information or correct irrelevant, incorrect, or misleading information.

[0007] In addition, existing code analysis methods based on large language models often have ambiguity problems in function location. Since functions with the same name are difficult to distinguish in text similarity analysis, it is easy to lead to inaccurate location. At the same time, most methods adopt a fixed hierarchical strategy, and even when the problem description is clear, a complete hierarchical traversal is required, resulting in unnecessary computational overhead. Summary of the Invention

[0008] This application provides a method, device, equipment and storage medium for automatic software defect repair, and proposes an adaptive hierarchical location strategy, which preferentially attempts to directly locate to the specific function signature, and automatically degrades to file-level analysis when direct location fails. By including complete path information, class names, and parameter lists in each candidate function, the ambiguity problem of function location is effectively avoided. Compared with the prior art, this application not only ensures the accuracy of location, but also improves the efficiency by dynamically adjusting the analysis level.

[0009] In a first aspect, this application provides a method for automatic software defect repair, including:

[0010] Obtain the problem description and the code repository to be repaired, perform semantic analysis on the problem description, extract the feature information, and parse the code repository to be repaired into a tree-like directory structure; wherein, the feature information includes key terms, function names, and class names.

[0011] Based on the feature information, conduct a targeted search in the code repository to be repaired to locate candidate functions, and generate complete function signatures based on the candidate functions.

[0012] In the case where the number of candidate functions is less than five, based on the feature information, screen out the five most relevant source code files from the tree-like directory structure, and use a large language model to analyze the source code files to screen out the five most relevant functions as candidate functions.

[0013] In the case where the number of candidate functions is at least five, input at least five of the candidate functions and their complete function signatures into a large language model, and generate multiple sets of repair solutions based on a preset prompt template and the randomness of the results generated by the large language model.

[0014] Verify the multiple sets of repair solutions, and use the repair solution that passes the verification as the target repair solution.

[0015] Use test cases to screen the target repair solution, screen out the unique optimal solution, and repair the software defect based on the optimal solution.

[0016] In one possible design, each set of repair solutions includes code change content and reasons for change that meet the format requirements.

[0017] In one possible design, the complete function signature includes the file path, the class name it belongs to, the function name, and / or the parameter list.

[0018] In one possible design, verifying the multiple sets of repair solutions and using the repair solution that passes the verification as the target repair solution includes:

[0019] Verify the repair solution. If the patch format in the repair solution meets the set requirements, the code after applying the patch conforms to the set syntax rules, and there are code changes in the patch, then determine that the repair solution passes the verification, and use the repair solution as the target repair solution.

[0020] In one possible design, using test cases to screen the target repair solution and screen out the unique optimal solution includes:

[0021] Using the target repair solution as a candidate solution, continuously generate targeted reproduction test cases through a large language model, and perform test verification on the candidate solution to obtain the only optimal solution;

[0022] In a possible design, using the target repair solution as a candidate solution, continuously generate targeted reproduction test cases through a large language model, and perform test verification on the candidate solution to obtain the only optimal solution, including:

[0023] If there is only one candidate solution passing all test cases in a certain verification, use the candidate solution as the only optimal solution;

[0024] If there are multiple candidate solutions passing the test or all candidate solutions fail the test in a certain verification, let the large language model generate new test cases for verification until the only optimal solution is screened out.

[0025] In a second aspect, the present application provides a software defect automatic repair device, and the device includes:

[0026] An input preprocessing module, configured to obtain a problem description and a code repository to be repaired, perform semantic analysis on the problem description, extract feature information, and parse the code repository to be repaired into a tree-like directory structure; wherein, the feature information includes key terms, function names, and class names;

[0027] A direct function location module, configured to perform directional search in the code repository to be repaired based on the feature information to locate candidate functions, and generate complete function signatures according to the candidate functions;

[0028] A file-level analysis module, configured to, when the number of candidate functions is less than five, screen out five most relevant source code files from the tree-like directory structure based on the feature information, and use a large language model to analyze the source code files to screen out five most relevant functions as candidate functions;

[0029] A repair solution generation module, configured to, when the number of candidate functions is at least five, input at least five of the candidate functions and their complete function signatures into a large language model, and generate multiple groups of repair solutions based on a preset prompt word template and the randomness of the large language model generation results;

[0030] A legality verification module, configured to verify the multiple groups of repair solutions, and use the repair solution that passes the verification as the target repair solution;

[0031] The test case screening module is configured to screen the target repair solution using test cases, screen out the only optimal solution, and repair software defects based on the optimal solution.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, including: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the software defect automatic repair method described in the first aspect above and various possible designs of the first aspect.

[0033] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the software defect automatic repair method described in the first aspect above and various possible designs of the first aspect are implemented.

[0034] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, the software defect automatic repair method described in the first aspect above and various possible designs of the first aspect are implemented.

[0035] The software defect automatic repair method, device, equipment, and storage medium provided by the present application have at least the following beneficial effects:

[0036] 1. By using a complete function signature including path, class name, and parameter list, the present application accurately distinguishes and locates functions with the same name, avoiding positioning errors caused by function name duplication.

[0037] 2. The present application adopts an adaptive strategy of dynamically determining whether file-level analysis is required, and directly locates to the function level when the problem description is clear enough, greatly reducing unnecessary analysis overhead.

[0038] 3. Through a simple and complete function signature mechanism, the present application can effectively avoid ambiguity when retrieving specific content, reducing the difficulty of deployment.

[0039] 4. Facing problem descriptions of uneven quality, the system of the present application can automatically select an appropriate positioning strategy according to the clarity of the description, and has stronger fault tolerance. Description of the Drawings

[0040] The drawings here are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0041] Figure 1The overall implementation flowchart of a software defect automatic repair method provided by an embodiment of this application;

[0042] Figure 2 The flowchart of a software defect automatic repair method provided by an embodiment of this application;

[0043] Figure 3 The interface diagram of the first prompt word format example for sending a problem description to a large language model provided by an embodiment of this application;

[0044] Figure 4 The interface diagram of the second prompt word format example for sending a problem description and repository structure information to a large language model provided by an embodiment of this application;

[0045] Figure 5 The interface diagram of the third prompt word format example for sending file content to a large language model provided by an embodiment of this application;

[0046] Figure 6 The interface diagram of the fourth prompt word format example for generating repair code provided by an embodiment of this application; where (a), Interface 1; (b), Interface 2; Interface 1 and Interface 2 are two consecutive interfaces;

[0047] Figure 7 The output example interface diagram of a large language model for a specific problem provided by an embodiment of this application;

[0048] Figure 8 The interface diagram of the fifth prompt word format example for generating new test cases provided by an embodiment of this application;

[0049] Figure 9 The structural schematic diagram of a software defect automatic repair device provided by an embodiment of this application.

[0050] Through the above-mentioned drawings, the clear embodiments of this application have been shown, and there will be more detailed descriptions hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of this application in any way, but to illustrate the concept of this application to those skilled in the art by referring to specific embodiments. Detailed implementation manners

[0051] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with this application. On the contrary, they are merely examples of devices and methods consistent with some aspects of this application as detailed in the appended claims.

[0052] In the technical solution of this application, the processing of information such as financial data or user data, including collection, storage, use, processing, transmission, provision, and disclosure, complies with the provisions of relevant laws and regulations and does not violate public order and good customs.

[0053] It should be noted that in the embodiments of this application, certain existing solutions in the industry such as software, components, and models may be mentioned. They should be considered exemplary. The purpose is only to illustrate the feasibility in the implementation of the technical solution of this application, but it does not mean that the applicant has already or necessarily used this solution.

[0054] The following uses specific embodiments to elaborate in detail on the technical solution of this application and how the technical solution of this application solves the above technical problems. These several specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below in conjunction with the accompanying drawings.

[0055] The embodiment of this application provides a method for automatically repairing software defects. This method is particularly applicable to the following scenarios through an adaptive hierarchical strategy and precise function signature positioning:

[0056] 1. Function location in large code repositories:

[0057] A) Existing methods often cannot accurately distinguish functions with the same name, resulting in inaccurate location results;

[0058] B) This application achieves precise positioning through complete function signatures (including path, class name, and parameter information);

[0059] C) This application effectively avoids ambiguity caused by duplicate function names in large code libraries.

[0060] 2. Situations with inconsistent clarity of problem descriptions:

[0061] A) Existing methods usually adopt a fixed hierarchical strategy, resulting in high computational overhead;

[0062] B) This application adopts an adaptive hierarchical strategy and directly performs function-level positioning on clear problem descriptions;

[0063] C) This application only degrades to file-level analysis when necessary, improving the processing efficiency.

[0064] 3. Scenarios of collaborative repair of multiple functions:

[0065] A) Existing methods are difficult to locate multiple related functions simultaneously;

[0066] B) This application outputs a fixed number (such as 5) of candidate functions;

[0067] C) This application supports the correlation analysis and collaborative repair of multiple functions.

[0068] Figure 1 This is the overall implementation flowchart of a software defect automatic repair method provided by an embodiment of this application. As Figure 1 shown, the overall implementation process of the software defect automatic repair method provided by an embodiment of this application includes steps such as problem description and input preprocessing of the code repository, hierarchical localization based on function signatures, generation and verification of repair solutions, etc. Specifically, after the code repository undergoes code repository preprocessing, it cooperates with the input defect description information to perform the first-round defect function localization. The located defect functions are used as candidate functions. If the number of located defect functions does not reach five, then after defect file localization, the second-round defect function localization is performed to ensure that at least five defect functions are located. Based on at least five located defect functions, a repair solution is generated and the repair solution is verified / tested. The verification / test mainly tests and verifies each repair solution by generating reproduction test cases. During the test verification process, the legality of the repair solution is detected at the same time, that is, it is judged whether the format requirements of the repair solution meet the set requirements. Finally, a unique optimal solution is obtained. Based on this unique optimal solution, the defective software can be automatically repaired to complete the repair process.

[0069] Specifically, Figure 2 This is the flowchart of a software defect automatic repair method provided by an embodiment of this application. This software defect automatic repair method is implemented using the Python language and uses a large language model for problem analysis and code generation. As Figure 2 shown, it includes steps S10 to S60.

[0070] S10: Obtain the problem description and the code repository to be repaired, perform semantic analysis on the problem description, extract the obtained feature information, and parse the code repository to be repaired into a tree-like directory structure; among them, the feature information includes key terms, function names, and class names.

[0071] In this embodiment, step S10 is the step of receiving and preprocessing the input information, that is, receiving the problem description and the code repository to be repaired, performing semantic analysis on the problem description, extracting feature information such as key terms, function names, and class names, and at the same time parsing the code repository into a tree-like directory structure.

[0072] Exemplarily, in the input preprocessing stage, the problem description is first processed. By analyzing the content of the problem description through a large language model, the following information is extracted: possible complete function signatures, file path information, and a rough description of the localization reason; among them, an example expression of a possible complete function signature is as follows: pytest.src._pytest.assertion.rewrite.AssertionRewriter.run.

[0073] For the processing of the code repository, the following steps S101 to S103 are adopted:

[0074] S101: Use the os and pathlib libraries of Python to traverse the repository directory structure;

[0075] S102: Build a tree-like file organization structure;

[0076] S103: For each file, establish a basic information index through the analysis of the abstract syntax tree, including:

[0077] - The full path of the file;

[0078] - The list of class names defined in the file and the list of function signatures contained therein;

[0079] - The list of function signatures directly defined in the file.

[0080] S20: Based on the feature information, perform a directional search in the code repository to be repaired to locate candidate functions, and generate complete function signatures according to the candidate functions.

[0081] In this embodiment, in step S20, an attempt is made to directly locate the candidate functions. Use the large language model to analyze the problem description, extract information such as possible function names, class names, and file paths, and perform a directional search in the code repository. For each matched function, generate a complete function signature including the file path, the class name it belongs to (if any), the function name, and the parameter list. When at least 5 candidate functions can be found, directly enter step S40; otherwise, transfer to step S30.

[0082] S30: In the case where the number of candidate functions is less than five, based on the feature information, screen out five most relevant source code files from the tree-like directory structure, and use the large language model to analyze the source code files to screen out five most relevant functions as candidate functions.

[0083] In this embodiment, step S30 is a file-level analysis step. Based on the key information extracted from the problem description and combined with the directory structure of the code repository, locate 5 most relevant source code files. Subsequently, use the large language model to analyze the content of these files, select 5 most relevant functions from them, and generate their complete function signatures.

[0084] Exemplarily, the function location can be specifically implemented in the following way:

[0085] First, attempt direct function location. Send the problem description to the large language model according to the first prompt word format example as shown in Figure 3 Extract the key information from the results returned by the model for searching in the code repository. As shown inFigure 3 In the prompt format template shown, it includes a user instruction, namely "According to the following problem description, locate the functions related to it in the code repository and provide the complete signature of each function (including file path, class name, function name, and its parameter list)". The example problem description is "Given a string, determine whether the string is a palindrome". After inputting the above two key statements, an example of the result given by the large language model is "The complete function signature corresponding to the problem description 'Given a string, determine whether the string is a palindrome' is: - file path; - function signature".

[0086] When not enough candidate functions can be found through direct location, the system enters the file-level analysis stage. Send the problem description and repository structure information to the large language model according to the second prompt format example as shown Figure 4 to obtain the 5 most relevant files. As shown Figure 4 The core information content to be obtained includes "problem description" and "code repository directory structure". Both of these core information contents are processed by step S10 and can be directly obtained. When the corresponding content is obtained, the large language model will perform corresponding processing and finally obtain five relevant file paths. Five of the most relevant source code files can be located according to this relevant file path.

[0087] Then, the contents of these files are provided to the large language model for analysis according to the third prompt format example as shown Figure 5 to obtain the complete signature information of the 5 most relevant functions.

[0088] S40: When the number of candidate functions is at least five, input at least five candidate functions and their complete function signatures into the large language model, and generate multiple sets of repair solutions based on the preset prompt format template and the randomness of the results generated by the large language model.

[0089] In this embodiment, taking five candidate functions as an example, the complete contents of the 5 located candidate functions can be provided to the large language model. With the help of the given prompt format template and the randomness of the results generated by the large language model, 10 sets of repair solutions are generated. Each repair solution contains specific code change content that meets the format requirements and the reasons for the changes.

[0090] S50: Verify multiple sets of repair solutions, and use the repair solutions that pass the verification as the target repair solutions.

[0091] In this embodiment, step S50 is used to verify the legality of the repair plan. The generated repair plan is verified for legality, including checking whether the patch format meets the specification requirements, verifying whether the code after applying the patch conforms to the syntax rules, and confirming whether the patch has produced effective code changes. If the repair plan meets all the above conditions, the repair plan is taken as the target repair plan, and step S60 is executed.

[0092] Exemplarily, the generation of the repair plan can be specifically implemented in the following ways:

[0093] Generate a repair plan based on the located candidate functions or files. Each repair plan contains the following content:

[0094] 1. Repair patch, specifying the specific code modification content.

[0095] 2. A detailed description of the reason for the repair, explaining why the repair is needed and the expected improvement effect.

[0096] Using a large language model, generate repair code through the fourth example of the prompt format as shown in Figure 6 while ensuring the consistency of the patch with the context. In the generated repair plan, comments will be attached to explain the modification logic.

[0097] Finally, the content as shown in Figure 7 (taking the output of the large language model for a specific problem as an example) will be generated, and specific patch information can be extracted from the generated content for further processing in the subsequent process.

[0098] S60: Use test cases to screen the target repair plan, screen out the only optimal plan, and repair the software defect based on the optimal plan.

[0099] In this embodiment, the optimal plan is screened based on test cases. For the repair plans that pass the legality verification (i.e., the target repair plans), the system enters the iterative screening stage, continuously generates targeted reproduction test cases through the large language model, and performs test verification on all candidate plans. If only one plan passes all the test cases in a certain verification, the plan will be selected as the final repair plan; if there are multiple plans passing the test, or all plans fail the test, the system will continue to generate new test cases for verification until the only optimal plan is screened out.

[0100] Exemplarily, this embodiment generates and executes test cases in an iterative manner. In the test case generation stage, the problem description, candidate repair plans, and historical test cases will be sent to the large language model, in accordance with the format as shown in Figure 8The fifth example of the prompt format shown generates new test cases. These test codes will be saved as Python test files, which contain the necessary import statements and third-party test tools. Test cases for different scenarios will be generated in each iteration to ensure coverage of more boundary cases.

[0101] Before executing the tests, an independent test environment needs to be prepared for each candidate solution. This includes copying the project's dependency files and configuration files, applying the fix patches to the test environment, and setting the environment variables required during test runtime. This isolated environment design ensures the accuracy and repeatability of the test results. The test environment is built based on Docker and implemented with the environment setup scripts that usually come with the project itself.

[0102] During the test execution process, the Python unittest framework is used to run the tests and collect detailed execution results. These results include the pass or fail status of the tests, specific error messages and stack traces, and the execution time of the tests. All test results will be stored in the result set for subsequent analysis and decision-making.

[0103] In the result analysis phase, the test pass rate of each fix solution will be counted, and the execution situation of each test case will be recorded in detail. The system will decide whether to continue generating new test cases based on the test results. When the system finds that a certain fix solution is the only one that passes all test cases, this solution will be marked as the final fix solution.

[0104] In summary, in view of the deficiencies of the existing software defect automatic repair methods, this application proposes a software defect automatic repair method based on hierarchical localization. Through the adaptive hierarchical localization strategy and complete function signature information, the accuracy of localization and the efficiency of repair are significantly improved, which is especially suitable for scenarios such as large code repositories, complex and diverse problem descriptions, and multi-function collaborative repair. This application has wide applicability and is suitable for various software engineering scenarios such as program repair, code review, and automated test generation. The dynamic hierarchical analysis mechanism and modular design simplify the deployment and integration of the system and can adapt to multiple programming languages and development environments. This application also has strong application potential and can be widely applied to all aspects of software development, including code repair, code quality assurance, and continuous integration scenarios. By providing an efficient, accurate, and flexible repair method, the development efficiency is significantly improved, and important technical support is provided for solving complex software defects.

[0105] The embodiment of this application also provides a software defect automatic repair device, as Figure 9 shown, the software defect automatic repair device includes:

[0106] The input preprocessing module 901 is configured to obtain a problem description and a code repository to be repaired, perform semantic analysis on the problem description, extract feature information, and parse the code repository to be repaired into a tree-like directory structure; wherein the feature information includes key terms, function names, and class names;

[0107] A direct function location module 902 is configured to perform a directed search in the code repository to be repaired based on the feature information to locate a candidate function, and generate a complete function signature according to the candidate function;

[0108] The file-level analysis module 903 is configured to, when the number of the candidate functions is less than five, select five most relevant source code files from the tree-like directory structure based on the feature information, analyze the source code files using a large language model, and select the five most relevant functions as candidate functions;

[0109] The repair solution generation module 904 is configured to input at least five candidate functions and their complete function signatures into the large language model when the number of the candidate functions is at least five, and generate multiple groups of repair solutions based on a preset prompt word template and the randomness of the result generated by the large language model;

[0110] The legality verification module 905 is configured to verify the multiple groups of repair solutions, and use the repair solutions that pass the verification as target repair solutions;

[0111] The test case screening module 906 is configured to screen the target repair solution using the test case, screen out a unique optimal solution, and repair the software defect based on the optimal solution.

[0112] An embodiment of the present application provides an electronic device, which may include: a processor and a memory, wherein the processor and the memory may communicate with each other; illustratively, the processor and the memory communicate with each other via a communication bus.

[0113] The processor executes the computer execution instructions stored in the memory, so that the processor executes the scheme in the above embodiment. The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components.

[0114] The communication bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. The system bus can be divided into an address bus, a data bus, a control bus, etc. The transceiver is used to implement communication between the database access device and other computers (such as clients, read-write libraries, and read-only libraries). The memory may include random access memory (RAM), and may also include non-volatile memory.

[0115] The electronic device provided by the embodiments of the present application may be the terminal device in the above embodiments.

[0116] The embodiments of the present application also provide a computer-readable storage medium storing computer instructions, which, when running on a computer, cause the computer to execute the technical solutions of the software defect automatic repair method in the above embodiments.

[0117] The embodiments of the present application also provide a computer program product including a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when at least one processor executes the computer program, the technical solutions of the software defect automatic repair method in the above embodiments can be implemented.

[0118] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules is only a logical function division, and there may be other division methods in actual implementation. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or modules can be in electrical, mechanical or other forms.

[0119] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to implement the solutions of this embodiment.

[0120] In addition, in each embodiment of the present application, each functional module can be integrated into a processing unit, or each module can exist physically alone, or two or more modules can be integrated into one unit. The unit formed by the above modules can be implemented in the form of hardware, or in the form of a hardware plus software functional unit.

[0121] The integrated module implemented in the form of a software functional module can be stored in a computer-readable storage medium. The above software functional module is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute some steps of the methods in each embodiment of the present application.

[0122] It should be understood that the above processor can be a Central Processing Unit (CPU for short), or other general-purpose processors, Digital Signal Processors (DSP for short), Application Specific Integrated Circuits (ASIC for short), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in combination with the invention can be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

[0123] The memory may include high-speed RAM memory, and may also include non-volatile storage NVM, such as at least one disk memory, and can also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk, or an optical disc, etc.

[0124] The bus can be an Industry Standard Architecture (ISA for short) bus, a Peripheral Component Interconnect (PCI for short) bus, or an Extended Industry Standard Architecture (EISA for short) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0125] The above storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium accessible by a general-purpose or special-purpose computer.

[0126] An exemplary storage medium is coupled to a processor, enabling the processor to read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic control unit or a master control device.

[0127] Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments; and the foregoing storage medium includes various media that can store program codes, such as ROM, RAM, magnetic disk or optical disk.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for automatically repairing software defects, characterized in that: The method comprises: Obtain a problem description and a code repository to be repaired, perform semantic analysis on the problem description, extract feature information, and parse the code repository to be repaired into a tree-like directory structure; wherein the feature information includes key terms, function names, and class names; Based on the feature information, a directed search is performed in the code repository to be repaired to locate a candidate function, and a complete function signature is generated according to the candidate function; When the number of the candidate functions is less than five, based on the feature information, five most relevant source code files are selected from the tree-like directory structure, and the source code files are analyzed using a large language model to select the five most relevant functions as candidate functions; When the number of the candidate functions is at least five, inputting at least five of the candidate functions and their complete function signatures into a large language model, and generating multiple groups of repair solutions based on a preset prompt word template and the randomness of the generated results of the large language model; Verifying the multiple groups of repair solutions, and taking the verified repair solutions as target repair solutions; The target repair solutions are screened using test cases to select a unique optimal solution, and the software defects are repaired based on the optimal solution.

2. The method for automatically repairing software defects according to claim 1, characterized in that: Each set of fixes contains the code changes and reasons for the changes in a format that meets the requirements.

3. The method for automatically repairing software defects according to claim 1, characterized in that: The complete function signature includes a file path, a class name, a function name and / or a parameter list.

4. The method for automatically repairing software defects according to claim 1, characterized in that: Verifying the multiple groups of repair solutions and taking the verified repair solutions as target repair solutions includes: The repair plan is verified. If the patch format in the repair plan meets the set requirements, the code after applying the patch meets the set syntax rules, and the code changes are generated in the patch, the repair plan is determined to have passed the verification and the repair plan is used as the target repair plan.

5. The method for automatically repairing software defects according to claim 1, characterized in that: The target repair solution is screened using test cases to select the only optimal solution, including: The target repair solution is used as a candidate solution, and targeted reproduction test cases are continuously generated through a large language model. Test verification is performed on the candidate solution to obtain a unique optimal solution.

6. The method for automatically repairing software defects according to claim 5, characterized in that: The target repair solution is used as a candidate solution, and targeted recurrence test cases are continuously generated through a large language model. The candidate solution is tested and verified to obtain the only optimal solution, including: If only one candidate solution passes all test cases in a certain verification, the candidate solution is taken as the only optimal solution; If multiple candidate solutions pass the test or all candidate solutions fail the test in a certain verification, the large language model will generate new test cases for verification until the only optimal solution is screened out.

7. A software defect automatic repair device, characterized in that: The device comprises: An input preprocessing module is configured to obtain a problem description and a code repository to be repaired, perform semantic analysis on the problem description, extract feature information, and parse the code repository to be repaired into a tree-like directory structure; wherein the feature information includes key terms, function names, and class names; A direct function location module is configured to perform a directed search in the code repository to be repaired based on the feature information to locate a candidate function, and generate a complete function signature according to the candidate function; A file-level analysis module is configured to, when the number of the candidate functions is less than five, select five most relevant source code files from the tree-like directory structure based on the feature information, analyze the source code files using a large language model, and select the five most relevant functions as candidate functions; A repair solution generation module is configured to input at least five candidate functions and their complete function signatures into a large language model when the number of the candidate functions is at least five, and generate multiple groups of repair solutions based on a preset prompt word template and the randomness of the result generated by the large language model; A legality verification module is configured to verify the multiple groups of repair solutions, and use the repair solutions that pass the verification as target repair solutions; The test case screening module is configured to screen the target repair solution using the test case, screen out the only optimal solution, and repair the software defects based on the optimal solution.

8. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the software defect automatic repair method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the software defect automatic repair method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method for automatically repairing software defects according to any one of claims 1 to 6 is implemented.

Images