Code defect prediction method, readable storage medium and computer program product

Abstract

The embodiment of the invention discloses a code defect prediction method, a readable storage medium and a computer program product. The method comprises the following steps: constructing a plurality of prediction models and a plurality of agents; when the code library is updated, determining a plurality of update items, and obtaining new version codes of the plurality of update items; obtaining potential code defect types and potential code defect descriptions of a plurality of update items based on the new version code and the plurality of prediction models; generating defect reports of a plurality of update items based on the potential code defect types, the potential code defect descriptions and the plurality of agents; and carrying out authenticity verification on the defect report, and repairing the new version code after the authenticity verification is passed. According to the method, code defects can be efficiently and accurately predicted, and a defect report is given for repairing related defects, so that software research and development are facilitated.

Description

Technical Field

[0001] The present disclosure relates to the field of software engineering technology, and in particular to a code defect prediction method, a readable storage medium, and a computer program product. Background Art

[0002] In the software development process, early identification of code defects is an important but challenging issue. Existing technologies mainly rely on static code analysis and simple statistical models for code defect prediction. These methods often have difficulty identifying complex defect patterns and have low accuracy, resulting in many potential software problems being discovered only in the late stages of development, increasing the cost and time of repair. Moreover, most existing technologies require manual intervention, which is inefficient and error-prone. Summary of the invention

[0003] In view of this, the embodiments of the present disclosure provide a code defect prediction method, a readable storage medium, and a computer program product, which can efficiently and accurately predict code defects and provide defect reports for repairing related defects, thereby facilitating software development.

[0004] In a first aspect, the present disclosure provides a method for predicting code defects, which adopts the following technical solutions:

[0005] Build multiple predictive models and multiple agents;

[0006] When the code base is updated, several update projects are determined, and new version codes of the several update projects are obtained;

[0007] Based on the new version code and the multiple prediction models, obtaining potential code defect types and potential code defect descriptions of several update projects;

[0008] Generate defect reports for a plurality of update projects based on the potential code defect type, the potential code defect description, and the plurality of agents;

[0009] The defect report is verified for authenticity, and the new version code is repaired after the authenticity verification passes.

[0010] Optionally, the constructing of multiple prediction models includes:

[0011] Get historical defect data and current code base data;

[0012] Preprocessing the historical defect data and the current code base data;

[0013] Divide the pre-processed historical defect data according to project types to obtain multiple groups of project code defect data;

[0014] Combining each group of project code defect data with the current code base data to form multiple groups of training sets;

[0015] The pre-trained language models are fine-tuned using the multiple training sets to obtain the multiple prediction models.

[0016] Optionally, obtaining potential code defect types and potential code defect descriptions of several update projects based on the new version code and the multiple prediction models includes:

[0017] Selecting a target model from the plurality of prediction models based on the type of the update item;

[0018] Based on the new version code and the target model, potential code defects and potential code defect descriptions of corresponding update projects are obtained.

[0019] Optionally, obtaining potential code defects and potential code defect descriptions of corresponding updated projects based on the new version code and the target model includes:

[0020] Dividing the new version code into a plurality of code elements, and allocating potential energy to the plurality of code elements;

[0021] adjusting the attention value of the target model to the plurality of code elements according to the potential energy;

[0022] The new version code, the multiple code elements and the potential energy are input into the target model to obtain potential code defects and potential code defect descriptions output by the target model.

[0023] Optionally, if there are multiple update projects, the potential code defect types and potential code defect descriptions output by multiple target models are shared;

[0024] Based on the shared potential code defect types and potential code defect descriptions, potential code defect types and potential code defect descriptions output by multiple target models are retrieved.

[0025] Optionally, the defect report includes optimal repair suggestions;

[0026] Collecting historical repair data, performing feature extraction on the historical repair data, and obtaining a feature vector;

[0027] Initialize the weight vector;

[0028] Construct a reward function based on the feature vector and the weight vector;

[0029] The maximum entropy IRL algorithm is used to optimize the weight vector in the reward function;

[0030] Iteratively updating the weight vector in the reward function using the stochastic gradient ascent method until convergence, and obtaining the optimal policy network based on the updated reward function;

[0031] Based on the optimal strategy network, the potential code defect type, and the potential code defect description, an optimal repair suggestion is obtained.

[0032] Optionally, the adopting the maximum entropy IRL algorithm to optimize the weight vector in the reward function includes:

[0033] An objective function is set, and the weight vector is optimized by solving the objective function. The expression of the objective function is as follows:

[0034] max w0 [Σ i log P(a i |s i ,w 0 )-λ||w 0 || 2 ];

[0035] In the formula, P(a i |s i ,w 0 ) is the value in a given code state s i and the weight vector w 0 Take possible repair action a i , i is the number of a given code state, and λ is the coefficient of the regularization term.

[0036] Optionally, the adopting stochastic gradient ascent method to iteratively update the weight vector in the reward function includes:

[0037] A stochastic gradient function is set and the weight vector is updated using the stochastic gradient function. The expression of the stochastic gradient function is as follows:

[0038] w t+1 =w t +α[φ(s expert ,a expert )-E π [φ(s expert ,a expert )]-2λw t ];

[0039] Among them, t is the number of current iterations; w t is the weight vector in the current iteration. In the initial iteration, wt=w1=w0; w t+1 is the weight vector for the next iteration; α is the learning rate; π is the current strategy; E π [φ(s expert ,aexpert )] is the expected value of the feature vector under the current strategy; φ(s expert ,a expert ) is the feature vector, s expert is the code status during the historical repair process, a expert Restoration actions taken by experts during historical restoration.

[0040] In a second aspect, the embodiment of the present disclosure further provides a code defect prediction system, which adopts the following technical solution:

[0041] Building modules for building multiple prediction models and multiple agents;

[0042] A determination module is used to determine a number of update projects and obtain new version codes of the update projects when the code base is updated;

[0043] An obtaining module, configured to obtain potential code defect types and potential code defect descriptions of a plurality of update projects based on the new version code and the plurality of prediction models;

[0044] A generating module, configured to generate defect reports for a plurality of update projects based on the potential code defect type, the potential code defect description and the plurality of agents;

[0045] The repair module is used to verify the authenticity of the defect report and repair the new version code after the authenticity verification passes.

[0046] In a third aspect, the embodiments of the present disclosure further provide a computer device, which adopts the following technical solution:

[0047] The computer device comprises:

[0048] at least one processor; and,

[0049] a memory communicatively connected to the at least one processor; wherein,

[0050] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any of the above-mentioned code defect prediction methods.

[0051] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute any of the above-mentioned code defect prediction methods.

[0052] In a fifth aspect, an embodiment of the present disclosure further provides a computer program product, including a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0053] The code defect prediction method provided by the embodiment of the present disclosure can perform customized defect prediction for different project types by constructing multiple specialized prediction models and agents, thereby improving the accuracy of potential code defect types and descriptions. By automatically generating defect reports and verifying their authenticity, the need for manual intervention is reduced, the process of defect identification and repair is accelerated, thereby improving the efficiency of the entire defect management process, and accurate and timely defect prediction and report generation help to discover and repair potential code defects as early as possible, thereby reducing the cost and time of defect repair and reducing the overall cost of software maintenance. By continuously tracking and managing code defects, it helps to improve the quality and reliability of software products and reduce system failures and user dissatisfaction caused by defects. This design allows prediction models and agents to be easily added or updated to adapt to changing development needs and project types, enhances the scalability and flexibility of the system, and the prediction models and agents can be flexibly integrated into a variety of mainstream integrated development environments, such as Visual Studio Code or IntelliJ IDEA. This design greatly improves the practicality and ease of use of the system.

[0054] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0056] Figure 1 A flowchart of a code defect prediction method provided by an embodiment of the present disclosure;

[0057] Figure 2 A flowchart of a prediction model construction method provided by an embodiment of the present disclosure;

[0058] Figure 3 A flowchart of a method for predicting potential code defect types and describing potential code defects provided by an embodiment of the present disclosure;

[0059] Figure 4 Another flowchart of a method for predicting potential code defect types and describing potential code defects provided by an embodiment of the present disclosure;

[0060] Figure 5 A schematic diagram of the working principle of a large-scale software agent provided by an embodiment of the present disclosure;

[0061] Figure 6 A schematic diagram of a flow chart of an inverse reinforcement learning method provided in an embodiment of the present disclosure;

[0062] Figure 7 A functional block diagram of a code defect prediction system provided by an embodiment of the present disclosure;

[0063] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0064] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0065] It should be clear that the following embodiments of the present disclosure are described by specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other in the absence of conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0066] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0067] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The drawings only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0068] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0069] Reference Figure 1 The present disclosure provides a code defect prediction method, comprising the following steps:

[0070] S1: Build multiple prediction models and multiple agents;

[0071] S2: When the code base is updated, several update projects are determined, and new version codes of the several update projects are obtained;

[0072] S3: Based on the new version code and multiple prediction models, potential code defect types and potential code defect descriptions of several updated projects are obtained;

[0073] S4: Generate defect reports for several update projects based on potential code defect types, potential code defect descriptions, and multiple agents;

[0074] S5: Verify the authenticity of the defect report and fix the new version of the code after the authenticity verification passes.

[0075] The code defect prediction method provided by the present disclosure can perform customized defect prediction for different project types by constructing multiple specialized prediction models and agents, thereby improving the accuracy of potential code defect types and descriptions. By automatically generating defect reports and verifying their authenticity, the need for manual intervention is reduced, the process of defect identification and repair is accelerated, thereby improving the efficiency of the entire defect management process, and accurate and timely defect prediction and report generation help to discover and repair potential code defects as early as possible, thereby reducing the cost and time of defect repair and reducing the overall cost of software maintenance. By continuously tracking and managing code defects, it helps to improve the quality and reliability of software products and reduce system failures and user dissatisfaction caused by defects. This design allows prediction models and agents to be easily added or updated to adapt to changing development needs and project types, enhances the scalability and flexibility of the system, and the prediction models and agents can be flexibly integrated into a variety of mainstream integrated development environments, such as Visual Studio Code or IntelliJIDEA. This design greatly improves the practicality and ease of use of the system.

[0076] In S1, refer to Figure 2 A flowchart of a method for building a prediction model is shown. The method for building multiple prediction models includes the following steps:

[0077] S11: Obtain historical defect data and current code base data;

[0078] S12: preprocessing historical defect data and current code base data;

[0079] S13: Divide the preprocessed historical defect data according to project types to obtain multiple groups of project code defect data;

[0080] S14: combining each group of project code defect data with the current code base data to form multiple training sets;

[0081] S15: Use multiple groups of training sets to fine-tune the pre-trained language model to obtain multiple prediction models.

[0082] In S11, historical defect information is extracted from a project management system, a version control system, a defect tracking system, etc. The historical defect data includes at least one of a defect description, a defect code location (such as a file name where the defect code is located and a line number of the defect code), and a repair method.

[0083] Collect current code base data. The current code base data includes source code files of all current projects, including code snippets, code structure, comments, submission history and other information.

[0084] In S12, the collected historical defect data and current code base data are preprocessed, and the preprocessing includes data cleaning, standardization and labeling, wherein data cleaning refers to the removal of invalid or duplicate information, such as removing incomplete records, wrong entries or incorrectly formatted data and deleting duplicate information; standardization refers to data formatting and normalization processing, so that the historical defect data and the current code base data conform to the predetermined standard format; labeling refers to the automatic or manual labeling of defect types (such as performance issues, security vulnerabilities, etc.) for historical defect data according to the defect description, defect code location and repair method, and for the current code base data, static code analysis tools are used to identify potential defects and label the potential defects. In the labeling process, quality control is used to ensure the accuracy of the labels, such as cross-validation of labels, that is, different people label the same set of data to check consistency.

[0085] In S13, the pre-processed historical defect data is divided into data of different project types, which are recorded as project code defect data, wherein the projects include R&D projects, marketing projects, IT projects, etc. These projects can be further subdivided according to different functions.

[0086] In S14, each group of project code defect data is combined with the current code base data to form multiple training sets, each training set including a code snippet, related defect information and corresponding labels.

[0087] In S15, a suitable pre-trained language model is selected, such as a variant of GPT or BERT, the parameters of the pre-trained language model are initialized, and fine-tuning parameters are set, including hyperparameters such as learning rate, training rounds (epochs), and batch size. Traditional defect prediction models lack the ability to deeply learn historical data and cannot fully utilize a large amount of known defect information to improve prediction accuracy. The present application uses multiple sets of training sets to fine-tune the pre-trained language model respectively to obtain multiple prediction models, so that different prediction models can identify code defect patterns in different types of projects.

[0088] Furthermore, multiple agents are constructed, including multiple project agents and a general logic agent. Different project agents are for different types of projects. Each project agent corresponds to a prediction model, which is used to start the prediction model and process the output of the prediction model. The general logic agent is responsible for identifying logical errors and code style issues in the code base. Logical errors refer to conditional judgment errors, loop logic errors, incorrect branch processing, etc. in the code base, which cause the program running results to be inconsistent with expectations. Code style issues refer to the formatting, naming conventions, and comment usage of the code in the code base that do not comply with the established coding standards and style guidelines, affecting the readability and maintainability of the code.

[0089] In S2, the trained large model is integrated into the integrated development environment (IDE) used by the development team on a daily basis, such as Visual Studio Code or IntelliJ IDEA. Both are the main tools for developers to write, debug, and test code. Integrating the predictive model into the IDE allows developers to immediately obtain analysis and feedback on the predictive model while writing code.

[0090] When developers write or modify code, they can monitor changes in the code base (a library that integrates source code files of all projects) in real time through plug-ins in the integrated development environment (IDE) or through code version control hooks in the continuous integration / continuous deployment (CI / CD) pipeline, or use monitoring tools such as Datadog and New Relic to monitor developers' coding activities in real time and automatically detect newly written or modified code snippets. When the code base changes, the update project is located through the code update location, that is, the project where the code has changed. The update project may be one or more. According to the type of update project, the new version code of several update projects is extracted, and the corresponding project agent and general logic agent are automatically activated. The project agent starts the corresponding prediction model.

[0091] Multiple agents make collaborative improvements through distributed reinforcement learning algorithms (such as MAPPO) without directly sharing data. This means that multiple project agents and general logic agents not only learn independently, but also share their learning results. For example, after the general logic agent is activated, it analyzes all the codes in the code base and shares the newly learned logic errors and code style issues with other project agents, helping the project agents improve their ability to detect logic errors and code style issues.

[0092] Training each agent in different code bases and projects enables each agent to learn diverse code patterns and potential defects. This diverse training data can help the agent improve its ability to adapt to unknown situations, thereby enhancing the robustness of the system.

[0093] In S3, refer to Figure 3 The flowchart of the method for predicting potential code defect types and potential code defect descriptions is shown, "obtaining potential code defect types and potential code defect descriptions of several updated projects based on new version codes and multiple prediction models" includes the following steps:

[0094] S31: selecting a target model from a plurality of prediction models based on the type of the update project;

[0095] S32: Based on the new version code and the target model, potential code defects and potential code defect descriptions of the corresponding updated project are obtained.

[0096] In S31, according to the type of the update project and the project types to which the multiple prediction models are applicable, a prediction model applicable to the new version code of the update project is selected and recorded as a target model.

[0097] In S32, based on the new version code of the update project and the corresponding target model, the target model outputs the potential code defect type and the potential code defect description of the update project.

[0098] Further, refer to Figure 4 Another flow chart of the method for predicting potential code defect types and describing potential code defects is shown, where S32 specifically includes the following steps:

[0099] S321: Divide the new version code into multiple code elements, and allocate potential energy to the multiple code elements;

[0100] S322: adjusting the attention value of the target model to the multiple code elements according to the potential energy;

[0101] S323: Input the new version code, multiple code elements and potential energy into the target model to obtain potential code defects and potential code defect descriptions output by the target model.

[0102] In S321, the new version code is statically analyzed and divided into multiple code elements, such as functions, classes, and variables. The new version code represents a field, and potential energy is allocated to multiple code elements to simulate the relationship between code elements. The potential energy is obtained by weighted summation based on characteristics such as the complexity of the code elements, historical defect rate, and code coverage.

[0103] In S322, an anisotropic attention mechanism is used, that is, the attention value of the target model to multiple code elements is adjusted according to the potential energy. The higher the potential energy of the code element, the higher the attention value of the target model to the code element. Correspondingly, the target model pays more attention to the code element. This anisotropic attention mechanism allows the target model to pay more attention to code elements with higher potential energy (i.e., more important or more likely to have defects) when analyzing the new version of the code.

[0104] In S323, the new version code, multiple code elements, and their potential energy are input into the target model, and the new version code is analyzed using the anisotropic attention mechanism, and the potential code defect type and potential code defect description of the corresponding update project are obtained according to the attention value. There are several potential code defect types, and the potential code defect types correspond to the potential code defect descriptions one by one. The potential code defect description includes code elements with potential defects and defect details.

[0105] Suppose there is a complex Python class with multiple methods and attributes:

[0106]

[0107]

[0108] Analyzing the above code, we divide it into multiple code elements and give them potential energy. The code elements include public methods (such as `process` and `reset`), private methods (such as `_process_dict` and `_process_list`), attributes (such as `data`, `processed` and `_temp_result`), control structures (such as if statements and for loops), and data operations (such as list comprehensions and dictionary operations). Among them, public methods are assigned high potential energy because they are the main interface of the class, and they are high potential energy. Private methods are assigned high potential energy because they contain core logic but are not directly exposed, and they are medium potential energy. Attributes are assigned low potential energy, and they are low potential energy. However, `_temp_result` among the attributes is private, so its potential energy is slightly higher than `data` and `processed`. Control structures are assigned high potential energy because they control program flow, and they are medium potential energy. Data operations are assigned high potential energy because they may hide complex logic, and they are medium potential energy.

[0109] When analyzing the new version of the code, the target model will dynamically adjust its focus value according to the potential of different code elements, and then adjust the focus to facilitate better defect prediction. For example, when analyzing the `process` method, it will pay more attention to its internal control flow and calls to private methods. When analyzing private methods, it will check the data operation logic more carefully. When analyzing attributes, it will consider their usage patterns in the entire class.

[0110] Furthermore, project agents exchange information through predefined communication protocols (such as message queues and RESTful APIs). If there are multiple update projects, the potential code defect types and potential code defect descriptions output by multiple target models are shared, that is, the potential code defect types and potential code defect descriptions are formatted into a format that can be understood by other project agents, and then sent to other project agents through the system's message passing interface. After receiving these data, other project agents transmit them to their own prediction models. The prediction model further analyzes the corresponding new version of the code based on the shared potential code defect types and potential code defect descriptions, and re-outputs the potential code defect types and potential code defect descriptions of the corresponding updated projects to determine whether the relevant inputs or logics are processed correctly, thereby achieving coordinated processing between agents.

[0111] Reference Figure 5The schematic diagram of the working principle of a large-scale software agent is shown. A large-scale software is used to illustrate the working principle of the agent. According to different project types, three types of project agents are set up, namely front-end security agent (abbreviated as A1), back-end performance agent (abbreviated as A2) and database agent (abbreviated as A3). A1 focuses on identifying front-end security vulnerabilities such as XSS and CSRF, A2 focuses on performance issues of back-end code, such as deadlocks and memory leaks, and A3 specifically detects database-related issues such as SQL injections and non-optimized queries. The general logic agent is referred to as A4.

[0112] When a developer submits a new code, including front-end JavaScript and back-end Java, A1 and A2 will be activated, and they will communicate with each other and exchange information about code structure and potential code. For example, A1 finds an unsafe user input processing that may cause XSS, and passes this information to A2 so that A2 can check whether the back-end handles this input correctly. Distributed reinforcement learning is also performed between the agents to achieve collaborative improvement.

[0113] In S4, when the project agent detects that the corresponding available model outputs potential code defect types and potential code defect descriptions, it generates optimal repair suggestions based on the potential code defect types and potential code defect descriptions. The project agent integrates the potential code defect types, potential code defect descriptions, and optimal repair suggestions, and outputs a defect report for the updated project. This report can help the development team understand possible problems in the new code and provide the information needed to fix these problems.

[0114] Furthermore, the project agent is subjected to inverse reinforcement learning (IRL), which enables the project agent to observe how experts repair discovered code defects and learn how to give optimal repair suggestions. This method can infer the reward function of the environment by learning the behavior of experts, and then train a better policy network.

[0115] Specifically, refer to Figure 6 The flowchart of the inverse reinforcement learning method shown in the figure shows that the inverse reinforcement learning is performed on the project agent to obtain the optimal repair suggestion, including the following steps:

[0116] S41: Collect historical repair data, extract features from the historical repair data, and obtain feature vectors;

[0117] S42: Initialize weight vector;

[0118] S43: constructing a reward function based on the feature vector and the weight vector;

[0119] S44: Use the maximum entropy IRL algorithm to optimize the weight vector in the reward function;

[0120] S45: Use the stochastic gradient ascent method to iteratively update the weight vector in the reward function until convergence, and obtain the optimal strategy network based on the updated reward function;

[0121] S46: Obtain optimal repair suggestions based on the optimal strategy network, potential code defect types, and potential code defect descriptions.

[0122] In S41, whenever the expert submits a code to fix a defect, the relevant repair data is captured through the code version control hook and recorded as historical repair data. The historical repair data includes at least one of the original defect code, the fixed code, and the intermediate version. It can also include submission information and defect tracking records to facilitate information tracking. The submission information includes the submitter of the defect fix code, submission time, submission message, etc. If the expert makes multiple submissions in the process of fixing the defect, the hook can capture and store these intermediate versions to analyze the evolution of the repair process.

[0123] Select an AST analysis tool that is suitable for the project programming language, such as libclang for C / C++, Roslyn for C#, or Esprima for JavaScript. Perform AST analysis on the captured original defective code and the fixed code, and convert the original defective code and the fixed code into a tree structure, where each node represents a structural element of the code, such as a variable declaration, a loop statement, etc.

[0124] Use deep learning models (such as convolutional neural networks or Transformer) to automatically learn high-level feature representations, extract features from the two transformed tree structures, and obtain the feature vector φ(s expert ,a expert ), where s expert is the code status during the historical repair process, a expert Restoration actions taken by experts during historical restoration. expert Refers to the current situation of the code in the historical version, s expertIt includes at least one of the following indicators: code complexity index, syntax pattern, data flow characteristics, and code style index. Code complexity index is a series of indicators that measure the complexity of code status, such as the nesting depth of loops, the calling relationship of functions, etc., which help evaluate the maintainability of the code and the potential defect risk; syntax pattern is the grammatical structure in the code, such as the acquisition and release order of locks; data flow characteristics include the definition, use, and transfer of variables, etc. These characteristics help analyze potential errors in the code, such as null pointer exceptions or resource leaks; code style indicators include code naming conventions, comment density, etc., which help evaluate the readability and consistency of the code. expert It is the action taken by experts to fix defects in the code, including modifying the code, refactoring the code structure, adding or deleting preset functions, etc. The repair action is the expert's attempt to change the code status.

[0125] In S42 and S43, for the project agent, a weight vector w is initialized 0 , the feature vector and weight vector constitute the reward function, which is expressed as follows:

[0126] R(s expert )=w 0 T φ(s expert );

[0127] Among them, R(s expert ) is the reward function; w 0 T w 0 The transpose of φ(s expert ) is s expert The feature representation of this vector contains the description s expert a series of characteristics.

[0128] In S44, the maximum entropy IRL algorithm is used to find a suitable weight vector so that the observed expert behavior (repair suggestion) is optimal among all possible repair actions. Set the objective function and obtain a suitable weight vector by solving the objective function. The expression of the objective function is as follows:

[0129] max w0 [Σ i log P(a i |s i ,w 0 )-λ||w 0 || 2 ];

[0130] Among them, P(a i |s i ,w 0 ) is the value in a given code state s iand the weight vector w 0 Take possible repair action a i The probability of i being the number of a given code state, a i is the possible repair actions to be taken at a given code state, and λ is the coefficient of the regularization term.

[0131] In S45, the appropriate weight vector w obtained in S44 is 0 Perform iterative updates. In the initial iteration, w t =w 1 =w 0 , and then use the stochastic gradient function for iterative update. The expression of the stochastic gradient function is as follows:

[0132] w t+1 =w t +α[φ(s expert ,a expert )-E π [φ(s expert ,a expert )]-2λw t ];

[0133] Among them, t is the number of current iterations; w t is the weight vector at the current iteration; w t+1 is the weight vector for the next iteration; α is the learning rate; π is the current strategy; E π [φ(s expert ,a expert )] is the expected value of the feature vector under the current strategy, which is estimated by the Monte Carlo method, that is, by sampling multiple trajectories under the learned strategy.

[0134] After convergence, stop iteration, and use reinforcement learning algorithm (such as PPO or SAC) to learn the optimal strategy based on the updated reward function to obtain the optimal strategy network π(a|s). π(a|s) is part of the project agent. π(a|s) can be parameterized using a deep neural network. The input is the feature representation of the current code state, and the output is the reward value distribution of different repair suggestions.

[0135] In S46, a feature representation of the current code state is obtained based on the potential code defect type and the potential code defect description, and the feature representation of the current code state is input into π(a|s) to obtain reward values ​​for different repair suggestions, and the repair suggestion with the highest reward value is selected as the optimal repair suggestion.

[0136] Reference Figure 5, the project agent performs inverse reinforcement learning. For example, when A2 finds a potential deadlock problem, it automatically records how the expert refactors the code to avoid the deadlock. In this way, it learns the expert's implicit reward function, making the future repair suggestions more in line with actual development best practices. Suppose the developer submits the following code snippet:

[0137]

[0138] For the above code, A1 detects a potential XSS vulnerability because the user input is directly inserted into innerHTML. A1 passes this information to A2 and A3. A3 detects the risk of SQL injection because the user input is directly spliced ​​into the SQL query. A4 notices that the input processing between the front-end and back-end is inconsistent, which may lead to potential problems. Based on this information, a comprehensive defect report is generated. The defect report recommends that developers use appropriate escape functions to handle user input on the front-end and use parameterized queries on the back-end to prevent SQL injection. In the process of generating repair suggestions, the agent learns how senior developers fix these problems and obtains best practices. For example, experts use React's dangerouslySetInnerHTML or Java's PreparedStatement, and then convert them into their own repair suggestions. Through this experience, all project agents have updated their prediction models and improved their ability to detect similar problems. Through this example, it shows how multi-agent systems work together, use distributed learning to improve robustness, and continuously improve the quality of their suggestions through inverse reinforcement learning. This method enables the system to handle complex code defect prediction tasks across multiple technical fields. For A4, it can also participate in inverse reinforcement learning to optimize A4's recognition ability.

[0139] Combined with the above S32 example of a complex Python class, based on the representation of anisotropic fields, attention mechanism and inverse reinforcement learning, the target model can explore more diverse defect modes, and the project agent can give the best repair suggestions. For example:

[0140] The potential code defect type is a state management issue. The potential code defect is described as the `processed` flag and the `_temp_result` cache may cause race conditions in a multi-threaded environment, and may return inconsistent or incomplete results during concurrent access. The optimal repair suggestion is to consider using thread-safe mechanisms, such as locks or thread-local storage.

[0141] The potential code defect type is performance optimization opportunity. The potential code defect is described as the `_process_dict` and `_process_list` methods create new lists or dictionaries each time they are called. For large data sets, this may cause unnecessary memory allocation and performance overhead. The optimal repair suggestion is to consider using generators or iterators to process large data sets.

[0142] The potential code defect type is insufficient exception handling. The potential code defect is described as the code not handling possible exceptions, such as accessing a non-existent key in `_process_dict`, which may crash when processing abnormal data. The optimal repair suggestion is to add appropriate exception handling, such as using the `dict.get()` method or a try-except block.

[0143] The potential code defect type is a type safety issue. The potential code defect is described as the `_process_dict` and `_process_list` methods assume that all items can call `upper()` or `lower()`, which may cause exceptions when processing non-string data. The optimal repair suggestion is to add type checks or use more robust type conversion methods.

[0144] The potential code defect type is a naming convention issue. The potential code defect is described as using a single underscore prefix (such as `_temp_result`) to indicate a private attribute. However, this is only a convention and cannot truly prevent external access. It may cause the class encapsulation to be accidentally destroyed. The optimal repair suggestion is to consider using a double underscore prefix to implement name rewriting to enhance privacy.

[0145] Through the diversity learning method enhanced by anisotropic fields, the target model can more comprehensively understand the relationship between code structure and code elements, dynamically adjust the focus according to the importance of different code elements, discover subtle or complex defect patterns that may be overlooked by traditional homogeneity analysis, enhance the adaptability to unknown defect patterns, improve the comprehensiveness and accuracy of predictions, and provide more targeted and diverse modification suggestions in combination with inverse reinforcement learning. This makes defect prediction not only limited to finding obvious errors, but also identifies potential design problems, performance bottlenecks and best practice deviations, thereby helping developers to comprehensively improve code quality.

[0146] This disclosure also gives another example, when the developer has just submitted the following Python code:

[0147]

[0148]

[0149] Through the analysis of the target model and related agents, the following results are obtained:

[0150] The potential code defect type is SQL injection vulnerability. The potential code defect description is that the function directly concatenates the user input (user_id) into the SQL query string, which may lead to SQL injection attacks. Attackers may execute arbitrary SQL commands through carefully constructed user_id parameters, which may lead to unauthorized data access, data leakage, data corruption, and even the collapse of the entire system. The best repair recommendation is to use parameterized queries to prevent SQL injection. Modify the code as follows:

[0151] ```Python

[0152] query="SELECT*FROM users WHERE id=%s"

[0153] cursor.execute(query,(user_id,))

[0154] ```

[0155] The potential code defect type is resource leakage. The potential code defect is described as the database connection and cursor are not closed correctly after the function is executed. Long-term operation may cause the database connection resources to be exhausted, affecting system performance and even causing the application to crash. The best repair suggestion is to use Python's with statement or ensure that resources are closed correctly in the finally block, for example:

[0156]

[0157]

[0158] The potential code defect type is insufficient error handling. The potential code defect description is that the function does not perform any exception handling. If the database operation fails, it may cause uncaught exceptions, which may cause application crashes or unexpected behavior when there are database connection problems or query execution errors. The best repair suggestion is to add appropriate exception handling logic, such as:

[0159]

[0160] The potential code defect type is a potential performance issue. The potential code defect is described as creating a new database connection each time the function is called, which may be inefficient in high concurrency situations. In high traffic situations, frequent establishment and disconnection of database connections may lead to performance degradation and resource waste. The optimal repair suggestion is to consider using a connection pool to manage database connections. This is beyond the scope of a single function and needs to be implemented at a higher level. For example, an ORM library such as SQLAlchemy can be used to manage the connection pool.

[0161] Through the above examples, we can clearly see how the target model analyzes the code and predicts a variety of potential code defects. For each code defect, a detailed description of the potential code defect is provided, which includes the possible impact, and then gives specific repair suggestions. This detailed analysis and suggestions can help developers quickly understand the problem and take appropriate measures to improve code quality and security.

[0162] In S5, in the process of repairing the new version of the code based on defect reports, in order to ensure the effectiveness and continuity of defect management, a defect tracking method is adopted. Specifically, a defect database is created to store all predicted and actually discovered defect information. The defect database is the core of the defect tracking system and records the detailed information of each code defect, including the nature, location, severity and related code elements of the defect.

[0163] The defect tracking system has an automatic status update function, which can continuously track the status changes of code defects in defect reports and store these changes in the defect database. The status of code defects includes at least one of newly discovered, confirmed, being fixed, fixed, and false positive.

[0164] Among them, newly discovered refers to the newly generated potential code defect type and potential code defect description, being confirmed refers to the development team confirming the authenticity of the newly generated potential code defect type and potential code defect description, being repaired refers to repairing according to the optimal repair suggestion after the authenticity is confirmed, fixed refers to the code defect has been repaired and passed the test, and false positive refers to the code defect confirmed as a false positive. This automated status tracking mechanism greatly improves the efficiency of defect management and ensures the real-time update of defect information.

[0165] The defect tracking system also provides an intelligent reminder function. According to the severity of the code defects and the progress of repair, the defect tracking system will automatically send reminders and reports to relevant developers, ensuring that the development team can respond to defect repair needs in a timely manner and take corresponding measures.

[0166] Through this series of defect tracking measures, not only can the accuracy of defect prediction be improved, but also it can ensure that code defects are handled in a timely and effective manner, providing a strong guarantee for the quality and stability of software development, and helping the development team optimize its repair strategy and resource allocation.

[0167] The overall architecture of the above-mentioned software code defect prediction and tracking system includes a data collection module, a prediction model training module, a real-time code analysis module, a defect tracking module and a model optimization module. This modular design enables the system to have good scalability and maintainability.

[0168] Reference Figure 7 The present disclosure provides a code defect prediction system, comprising:

[0169] A construction module 101 is used to construct multiple prediction models and multiple intelligent agents;

[0170] The determination module 102 is used to determine a number of update projects and obtain new version codes of the number of update projects when the code base is updated;

[0171] An obtaining module 103 is used to obtain potential code defect types and potential code defect descriptions of several update projects based on the new version code and multiple prediction models;

[0172] A generating module 104, for generating defect reports of a plurality of update projects based on the potential code defect type, the potential code defect description and the plurality of agents;

[0173] The repair module 105 is used to verify the authenticity of the defect report and repair the new version code after the authenticity verification passes.

[0174] The various variations and specific examples of the code defect prediction method provided above are also applicable to the code defect prediction system provided in the present disclosure. Through the above detailed description of the code defect prediction method, those skilled in the art can clearly know the implementation method of the code defect prediction system. For the sake of brevity of the specification, it will not be described in detail here.

[0175] The computer device according to the embodiment of the present disclosure includes a memory and a processor. The memory is used to store non-temporary computer-readable instructions. Specifically, the memory may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may, for example, include a read-only memory (ROM), a hard disk, a flash memory, etc.

[0176] The processor may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of the present disclosure, the processor is used to run the computer-readable instructions stored in the memory, so that the computer device performs all or part of the steps of the code defect prediction method of each embodiment of the present disclosure.

[0177] Those skilled in the art should be able to understand that in order to solve the technical problem of how to obtain a good user experience, the present embodiment may also include well-known structures such as a communication bus and an interface, and these well-known structures should also be included in the protection scope of the present disclosure.

[0178] like Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure is shown, which is a schematic diagram of the structure of a computer device suitable for implementing the embodiment of the present disclosure. Figure 8 The computer device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0179] like Figure 8 As shown, the computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) or a program loaded from a storage device into a random access memory (RAM). In the RAM, various programs and data required for the operation of the computer device are also stored. The processor, ROM, and RAM are connected to each other via a bus. An input / output (I / O) interface is also connected to the bus.

[0180] Typically, the following devices can be connected to the I / O interface: input devices such as sensors or visual information acquisition devices; output devices such as display screens; storage devices such as tapes, hard disks, etc.; and communication devices. The communication device can allow the computer device to communicate with other devices (such as edge computing devices) wirelessly or by wire to exchange data. Figure 8 A computer device having various devices is shown, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0181] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the code defect prediction method of the embodiment of the present disclosure are executed.

[0182] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0183] According to the computer-readable storage medium of the embodiment of the present disclosure, non-transitory computer-readable instructions are stored thereon. When the non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the code defect prediction method of each embodiment of the present disclosure are executed.

[0184] The above-mentioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or mobile hard disk), media with built-in rewritable non-volatile memory (e.g., memory card) and media with built-in ROM (e.g., ROM box).

[0185] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0186] The basic principles of the present disclosure are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, and are not limitations. The above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0187] In the present disclosure, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. The block diagrams of the devices, devices, equipment, and systems involved in the present disclosure are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0188] Additionally, as used herein, "or" used in a list of items beginning with "at least one" indicates a separate list, so that, for example, a list of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not mean that the example described is preferred or better than other examples.

[0189] It should also be noted that in the system and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0190] Various changes, substitutions, and modifications of the techniques described herein may be made without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of the present disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and actions described above. Currently existing or later to be developed processes, machines, manufactures, compositions of events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein may be utilized. Thus, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or actions within their scope.

[0191] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0192] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A code defect prediction method, characterized in that: include: Build multiple predictive models and multiple agents; When the code base is updated, several update projects are determined, and new version codes of the several update projects are obtained; Based on the new version code and the multiple prediction models, obtaining potential code defect types and potential code defect descriptions of several update projects; Generate defect reports for a plurality of update projects based on the potential code defect type, the potential code defect description, and the plurality of agents; The defect report is verified for authenticity, and the new version code is repaired after the authenticity verification passes.

2. The code defect prediction method according to claim 1, characterized in that: The constructing of multiple prediction models comprises: Get historical defect data and current code base data; Preprocessing the historical defect data and the current code base data; Divide the pre-processed historical defect data according to project types to obtain multiple groups of project code defect data; Combining each group of project code defect data with the current code base data to form multiple groups of training sets; The pre-trained language models are fine-tuned using the multiple training sets to obtain the multiple prediction models.

3. The code defect prediction method according to claim 1, characterized in that: The obtaining, based on the new version code and the multiple prediction models, potential code defect types and potential code defect descriptions of a plurality of update projects includes: Selecting a target model from the plurality of prediction models based on the type of the update item; Based on the new version code and the target model, potential code defects and potential code defect descriptions of corresponding update projects are obtained.

4. The code defect prediction method according to claim 3, characterized in that: The obtaining, based on the new version code and the target model, potential code defects and potential code defect descriptions of corresponding update projects includes: Dividing the new version code into a plurality of code elements, and allocating potential energy to the plurality of code elements; adjusting the attention value of the target model to the plurality of code elements according to the potential energy; The new version code, the multiple code elements and the potential energy are input into the target model to obtain potential code defects and potential code defect descriptions output by the target model.

5. The code defect prediction method according to claim 4, characterized in that: If there are multiple update items, the potential code defect types and potential code defect descriptions output by multiple target models are YY+242275P to share; Based on the shared potential code defect types and potential code defect descriptions, potential code defect types and potential code defect descriptions output by multiple target models are retrieved.

6. The code defect prediction method according to claim 1, characterized in that: The defect report includes optimal repair suggestions; Collecting historical repair data, performing feature extraction on the historical repair data, and obtaining a feature vector; Initialize the weight vector; Construct a reward function based on the feature vector and the weight vector; The maximum entropy IRL algorithm is used to optimize the weight vector in the reward function; Iteratively updating the weight vector in the reward function using the stochastic gradient ascent method until convergence, and obtaining the optimal policy network based on the updated reward function; Based on the optimal strategy network, the potential code defect type, and the potential code defect description, an optimal repair suggestion is obtained.

7. The code defect prediction method according to claim 6, characterized in that: The method of using the maximum entropy IRL algorithm to optimize the weight vector in the reward function includes: An objective function is set, and the weight vector is optimized by solving the objective function. The expression of the objective function is as follows: max w0 [S i log P(a i |s i ,w0)-λ||w0|| 2 ]; In the formula, P(a i |s i ,w0) is the state of the given code s i and weight vector w0 to take possible repair action a i , i is the number of a given code state, and λ is the coefficient of the regularization term.

8. The code defect prediction method according to claim 7, characterized in that: The step of iteratively updating the weight vector in the reward function using the stochastic gradient ascent method includes: A stochastic gradient function is set and the weight vector is updated using the stochastic gradient function. The expression of the stochastic gradient function is as follows: w t+1 =w t +α[φ(s expert ,a expert )-E π [φ(s expert ,a expert )]-2λw t ]; Among them, t is the number of current iterations; w t is the weight vector in the current iteration. In the initial iteration, wt=w1=w0; w t+1 is the weight vector for the next iteration; α is the learning rate; π is the current strategy; E π [φ(s expert ,a expert )] is the expected value of the feature vector under the current strategy; φ(s expert ,a expert ) is the feature vector, s expert is the code status during the historical repair process, a expert Restoration actions taken by experts during historical restoration.

9. A computer-readable storage medium, characterized in that: The computer readable storage medium stores computer instructions, the YY+242275P The computer instructions are used to enable a computer to execute the code defect prediction method described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images