A multi-dimensional and multi-attention software defect location method, system and device

Abstract

The present application discloses a multi-dimensional multi-attention software defect location method, system and device, which obtains the software program code of the defect to be located; extracts the first dynamic execution information, the first historical modification information and the first static semantic information in the software program code of the defect to be located, wherein the first dynamic execution information is used to characterize the abnormal risk of the software program code of the defect to be located at runtime, the first historical modification information is used to characterize the defect risk of the software program code of the defect to be located in history, and the first static semantic information has the contextual semantic information in the software program code of the defect to be located; fuses the first dynamic execution information, the first historical modification information and the first static semantic information to obtain a first fused information vector; inputs the first fused information vector into a trained multi-head attention defect location model to obtain a defect location result. The present application can improve the accuracy of software defect location.

Description

Technical Field

[0001] The present application relates to the technical field of software defect location, and in particular to a multi-dimensional and multi-attention software defect location method, system and device. Background Art

[0002] Existing technologies, such as Spectrum-based Fault Localization (SBFL), mainly target test coverage information and cannot distinguish between elements that are accidentally executed by test cases and actual faulty elements. In addition, since it only uses test coverage information, it cannot locate the real cause of the error, for example, it does not use program semantic information and historical submission information to locate the error. As a result, the existing technology has poor software defect location effect in actual projects and has a relatively low accuracy rate. Summary of the invention

[0003] The present application aims to propose a multi-dimensional and multi-attention software defect localization method, system and device, which can analyze software code from a multi-dimensional perspective, thereby improving the accuracy of software defect localization.

[0004] In a first aspect, an embodiment of the present application provides a multi-dimensional and multi-attention software defect location method, the method comprising:

[0005] Obtaining software program code of the defect to be located;

[0006] Extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code with the defect to be located, wherein the first dynamic execution information is used to characterize the abnormality risk of the software program code with the defect to be located during runtime, the first historical modification information is used to characterize the defect risk in history of the software program code with the defect to be located, and the first static semantic information has contextual semantic information in the software program code with the defect to be located;

[0007] Fusing the first dynamic execution information, the first historical modification information, and the first static semantic information to obtain a first fused information vector;

[0008] The first fusion information vector is input into the trained multi-head attention defect localization model to obtain the defect localization result.

[0009] Compared with the prior art, the first aspect of the present application has the following beneficial effects:

[0010] The method extracts the first dynamic execution information, the first historical modification information and the first static semantic information from the software program code of the defect to be located, wherein the first dynamic execution information is used to characterize the abnormal risk of the software program code of the defect to be located at runtime, the first historical modification information is used to characterize the defect risk in the history of the software program code of the defect to be located, and the first static semantic information has the contextual semantic information in the software program code of the defect to be located; the first dynamic execution information, the first historical modification information and the first static semantic information are fused to obtain the first fused information vector; the first fused information vector is input into the trained multi-head attention defect location model to obtain the defect location result. In this way, by combining the first dynamic execution information, the first historical modification information and the first static semantic information, more comprehensive and accurate information can be obtained, thereby improving the accuracy and robustness of software defect location.

[0011] In some implementations, extracting the first dynamic execution information, the first historical modification information, and the first static semantic information from the software program code containing the defect to be located includes:

[0012] Using a test case set to test the software program code of the defect to be located to obtain a test result;

[0013] Calculating, according to the test results, a first defect suspicion degree of each line of code in the software program code of the defect to be located;

[0014] The first defect suspicion level is used as the first dynamic execution information in the software program code of the defect to be located.

[0015] In some implementations, extracting the first dynamic execution information, the first historical modification information, and the first static semantic information from the software program code containing the defect to be located includes:

[0016] Using a problem tracking system and a version control system to extract modification information of each line of code in the software program code of the defect to be located;

[0017] Calculating a second defect suspicion degree of each line of code according to the modification information of each line of code;

[0018] The second defect suspicion level is used as the first historical modification information in the software program code of the defect to be located.

[0019] In some implementations, the extracting modification information of each line of code in the software program code with the defect to be located by using the issue tracking system and the version control system includes:

[0020] Using the issue tracking system to obtain the commit records for fixing the defects;

[0021] According to the defect repair submission record, the version control system is used to determine the first defect-introducing version corresponding to the software program code for the defect to be located and the number of the first defect-introducing versions, wherein the first defect-introducing version is used to characterize the bug-introducing version corresponding to the software program code for the defect to be located;

[0022] Using the version control system, extract the number of times each line of code in the software program code to be located with the defect is modified in the first defect-introducing version and the number of all modified versions of each line of code, wherein the modified version is used to represent the modified version of each line of code;

[0023] The number of the first defect-introducing versions, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code are used as modification information of each line of code.

[0024] In some implementations, extracting the first dynamic execution information, the first historical modification information, and the first static semantic information from the software program code containing the defect to be located includes:

[0025] Performing data cleaning and word segmentation on the software program code of the defect to be located to obtain a processed result;

[0026] The processed results are input into the BERT model for word embedding processing to generate a word vector for each code snippet;

[0027] Inputting the word vector of each code snippet into the position encoder for position encoding to obtain a position encoding result;

[0028] The position encoding result is subjected to feature extraction by a CodeBert encoder including a plurality of stacked encoding modules to obtain first static semantic information.

[0029] In some embodiments, before inputting the first fused information vector into the trained multi-head attention deficit localization model, the method further includes:

[0030] Obtaining second defect-introducing versions and defective code lines in all submitted software program codes, where the second defect-introducing versions are used to characterize the bug-introducing versions corresponding to all submitted software program codes;

[0031] Build a multi-head attention deficit localization model that includes a Transformer encoder, a fully connected layer, and a normalized exponential function;

[0032] Based on the second defect-introducing version and the defective code line, the multi-head attention defect localization model is trained to obtain a trained multi-head attention defect localization model.

[0033] In some implementations, the training of the multi-head attention defect localization model based on the second defect-introducing version and the defective code line to obtain the trained multi-head attention defect localization model includes:

[0034] Extracting second dynamic execution information, second historical modification information, and second static semantic information from the second defect-introducing version;

[0035] Fusing the second dynamic execution information, the second historical modification information, and the second static semantic information to obtain a second fused information vector;

[0036] Tagging the code lines in the second defect-introducing version according to the defective code lines to obtain labeled code lines;

[0037] The marked code lines and the second fusion information vector are used to train the multi-head attention deficit localization model to obtain a trained multi-head attention deficit localization model.

[0038] In a second aspect, the embodiment of the present application further provides a multi-dimensional and multi-attention software defect localization system, the system comprising:

[0039] A data acquisition unit, used to acquire the software program code of the defect to be located;

[0040] an information extraction unit, configured to extract first dynamic execution information, first historical modification information, and first static semantic information from the software program code with the defect to be located, wherein the first dynamic execution information is used to characterize the abnormality risk of the software program code with the defect to be located during runtime, the first historical modification information is used to characterize the defect risk in history of the software program code with the defect to be located, and the first static semantic information has contextual semantic information in the software program code with the defect to be located;

[0041] an information fusion unit, configured to fuse the first dynamic execution information, the first historical modification information, and the first static semantic information to obtain a first fused information vector;

[0042] The defect localization unit is used to input the first fusion information vector into the trained multi-head attention defect localization model to obtain a defect localization result.

[0043] In the third aspect, an embodiment of the present application also provides an electronic device, comprising at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute a multi-dimensional and multi-attention software defect location method as described above.

[0044] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute a multi-dimensional and multi-attention software defect localization method as described above.

[0045] It can be understood that the beneficial effects of the second to fourth aspects compared with the related art are the same as the beneficial effects of the first aspect compared with the related art. Please refer to the relevant description in the first aspect, and no further details will be given here. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0047] Figure 1 It is a flowchart of an embodiment of the multi-dimensional and multi-attention software defect localization method provided by the present application;

[0048] Figure 2 It is a schematic diagram of the overall structural framework in the best embodiment of the multi-dimensional and multi-attention software defect localization method provided by the present application;

[0049] Figure 3 It is a schematic diagram of the data preparation and data preprocessing flow in the best embodiment of the multi-dimensional and multi-attention software defect localization method provided by the present application;

[0050] Figure 4 This is a schematic diagram of the historical modification information capture process in the best embodiment of the multi-dimensional and multi-attention software defect location method provided by the present application;

[0051] Figure 5 It is a schematic diagram of the static semantic information extraction process in the best embodiment of the multi-dimensional and multi-attention software defect localization method provided by the present application;

[0052] Figure 6 This is a schematic diagram of Bert word embedding in the best embodiment of the multi-dimensional and multi-attention software defect localization method provided by the present application;

[0053] Figure 7It is a schematic diagram of a combined vector process in a best embodiment of a multi-dimensional and multi-attention software defect localization method provided by the present application;

[0054] Figure 8 It is a schematic diagram of the structure of a multi-head attention defect localization model in the best embodiment of the multi-dimensional multi-attention software defect localization method provided by the present application;

[0055] Fig. 9 It is a structural diagram of an embodiment of the multi-dimensional and multi-attention software defect localization system provided by the present application. DETAILED DESCRIPTION

[0056] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limiting the present application.

[0057] In the description of this application, if there is a description of first, second, etc., it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0058] In the description of the present application, it should be understood that the descriptions involving orientation, such as the orientation or positional relationship indicated as up, down, etc., are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0059] In the description of this application, it should be noted that, unless otherwise clearly defined, terms such as setting, installing, connecting, etc. should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meaning of the above terms in this application based on the specific content of the technical solution.

[0060] Existing technologies, such as the defect localization technology based on program spectrum (SBFL), mainly focus on test coverage information and cannot distinguish between elements accidentally executed by test cases and actual faulty elements. In addition, since it only uses test coverage information, it cannot locate the real cause of the error, for example, it does not use program semantic information and historical submission information to locate the error. As a result, the existing technology has poor software defect location effect in actual projects and has a relatively low accuracy rate.

[0061] In order to solve the problem that the existing technologies have poor software defect localization effect and low accuracy in actual projects, the present application proposes a multi-dimensional and multi-attention software defect localization method, system and device.

[0062] Reference Figure 1 The embodiment of the present application provides a multi-dimensional and multi-attention software defect location method, which is applied to an electronic device, which may be a server or a mobile terminal. The multi-dimensional and multi-attention software defect location method includes the following steps:

[0063] Step S100, obtaining the software program code of the defect to be located;

[0064] Step S200, extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code with the defect to be located, wherein the first dynamic execution information is used to characterize the abnormality risk of the software program code with the defect to be located during operation, the first historical modification information is used to characterize the defect risk in history of the software program code with the defect to be located, and the first static semantic information has contextual semantic information in the software program code with the defect to be located;

[0065] Step S300, fusing the first dynamic execution information, the first historical modification information and the first static semantic information to obtain a first fused information vector;

[0066] Step S400: input the first fusion information vector into the trained multi-head attention defect localization model to obtain a defect localization result.

[0067] In this embodiment, by extracting the first dynamic execution information, the first historical modification information and the first static semantic information from the software program code of the defect to be located, the first dynamic execution information is used to characterize the abnormal risk of the software program code of the defect to be located at runtime, the first historical modification information is used to characterize the defect risk in the history of the software program code of the defect to be located, and the first static semantic information has the contextual semantic information in the software program code of the defect to be located; the first dynamic execution information, the first historical modification information and the first static semantic information are fused to obtain a first fused information vector; the first fused information vector is input into the trained multi-head attention defect localization model to obtain a defect localization result. In this way, by combining the first dynamic execution information, the first historical modification information and the first static semantic information, more comprehensive and accurate information can be obtained, thereby improving the accuracy and robustness of software defect localization.

[0068] The software program code with the defect to be located may be the software program code with the bug to be located.

[0069] The above-mentioned fusion of the first dynamic execution information, the first historical modification information and the first static semantic information to obtain the first fused information vector may be fusion of the first dynamic execution information, the first historical modification information and the first static semantic information by splicing them together to obtain the first fused information vector.

[0070] The above-mentioned input of the first fused information vector into the trained multi-head attention defect localization model to obtain the defect localization result can be directly using the trained multi-head attention defect localization model to perform defect localization on the first fused information vector to obtain the defect localization result corresponding to the software program code of the defect to be located.

[0071] In some implementations, extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code for the defect to be located includes:

[0072] Use the test case set to test the software program code with the defect to be located and obtain the test results;

[0073] Calculate the first defect suspicion of each line of code in the software program code of the defect to be located according to the test results;

[0074] The first defect suspicion level is used as the first dynamic execution information in the software program code of the defect to be located.

[0075] In this embodiment, a test case set is used to test the software program code with defects to be located, and the test results are obtained; then, based on the test results, the first defect suspicion of each line of code in the software program code with defects to be located is calculated; and the first defect suspicion is used as the first dynamic execution information in the software program code with defects to be located. In this way, the defect suspicion of each line of code calculated reflects the abnormal risk of the code at runtime, laying a good data foundation for later software defect location.

[0076] The test result may be how many times the software program code including the defect to be located has passed the test, and how many times it has failed the test.

[0077] The above-mentioned calculation of the first defect suspicion of each line of code in the software program code for the defect to be located based on the test results can be based on the test results, using a program spectrum-based defect localization technology (SBFL) to calculate the defect suspicion (i.e., the first defect suspicion) of each line of code in the software program code for the defect to be located.

[0078] In some implementations, extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code for the defect to be located includes:

[0079] Use the issue tracking system and version control system to extract the modification information of each line of code in the software program code where the defect is to be located;

[0080] Calculate the second defect suspicion of each line of code according to the modification information of each line of code;

[0081] The second defect suspicion level is used as the first historical modification information in the software program code of the defect to be located.

[0082] In this embodiment, the problem tracking system and the version control system are used to extract the modification information of each line of code in the software program code of the defect to be located; then, based on the modification information of each line of code, the second defect suspicion of each line of code is calculated; and the second defect suspicion is used as the first historical modification information in the software program code of the defect to be located. In this way, the problem tracking system and the version control system extract the historical modification information corresponding to the software program code of the defect to be located, and reveal the modification and defect history of the code line through the historical information, laying a good data foundation for the later software defect location.

[0083] The above-mentioned problem tracking system can be an application software that allows an enterprise to report and track the progress of each problem identified by a computer system user until the problem is finally resolved.

[0084] The above version control system can be a commonly used code version control software that can help developers in a software team work together and archive a complete history of their work.

[0085] The above-mentioned calculation of the second defect suspicion level of each line of code according to the modification information of each line of code may be to calculate the defect suspicion level (i.e., the second defect suspicion level) of each line of code according to the modification information of each line of code by adopting a historical spectrum based defect location (HSFL) method.

[0086] In some implementations, the issue tracking system and the version control system are used to extract modification information of each line of code in the software program code for the defect to be located, including:

[0087] Use the issue tracking system to obtain commit records for fixing defects;

[0088] According to the submission record of the defect repair, the version control system is used to determine the first defect-introducing version and the number of the first defect-introducing versions corresponding to the software program code of the defect to be located, wherein the first defect-introducing version is used to represent the version of the software program code of the defect to be located corresponding to the bug.

[0089] Using a version control system to extract the number of times each line of code in the software program code with the defect to be located has been modified in the first defect-introducing version and the number of all modified versions of each line of code, where the modified version is used to characterize the modified version of each line of code;

[0090] The number of the first defect-introducing version, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code are used as modification information of each line of code.

[0091] In this embodiment, the issue tracking system (ITS) provides a submission record of introducing and repairing defects. Through these submission information, the version control system can be used to locate the specific version of the introduced defect corresponding to each line of code in the software program code to be located (i.e., the first defect-introducing version). Then, the number of the first defect-introducing versions, the number of times each line of code has been modified in the first defect-introducing version, and the number of all modified versions of each line of code are used as the modification information of each line of code, which can better calculate the second defect suspicion of each line of code, so as to lay a good data foundation for the later software defect location.

[0092] The above-mentioned introducing defect may refer to introducing a bug.

[0093] The number of all modified versions mentioned above may be the sum of the number of times each line of code is modified in the first defect-introducing version and the number of times each line of code is modified in the non-defect-introducing version. The defect-introducing version may be a version that introduces a bug, and the non-defect-introducing version may be a version that is modified to add certain functions, both of which require code modification.

[0094] The number of the first defect-introducing version, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code are used as the modification information of each line of code. Since the number of all modified versions is the sum of the number of times each line of code is modified in the first defect-introducing version and the number of times each line of code is modified in the non-defect-introducing version, the number of times each line of code is modified in the non-defect-introducing version can be calculated from the number of all modified versions of each line of code minus the number of times each line of code is modified in the first defect-introducing version. Therefore, the number of the first defect-introducing version, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code are used as the modification information of each line of code, and the second defect suspicion calculation of each line of code can be performed later.

[0095] For example, the versions of a project that have been identified as introducing defects are: version 1, version 2, version 3, and version 5, and the versions that have modified a certain line of code (all modified versions of each line of code) are: version 1, version 4, and version 5. The number of all modified versions of each line of code is 3 (i.e., version 1, version 4, version 5), the number of the first version that introduced defects is 4 (i.e., version 1, version 2, version 3, version 5), and the number of times each line of code was modified in the first version that introduced defects is 2 (i.e., version 1, version 5). It can be calculated that the number of times each line of code was modified in the version without introducing defects is 1 (i.e., version 4).

[0096] In some implementations, extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code for the defect to be located includes:

[0097] Perform data cleaning and word segmentation on the software program code for the defect to be located to obtain the processed results;

[0098] The processed results are input into the BERT model for word embedding processing to generate word vectors for each code snippet;

[0099] Input the word vector of each code snippet into the position encoder for position encoding to obtain the position encoding result;

[0100] The position encoding result is subjected to feature extraction by a CodeBert encoder including multiple stacked encoding modules to obtain the first static semantic information.

[0101] In this embodiment, by performing data cleaning and word segmentation on the software program code to be located for defects, filtering out information such as comment lines, and then using a word segmenter to tokenize the code lines, the code text can be converted into an input format suitable for processing. By inputting the processed results into the BERT model for word embedding processing, a word vector for each code snippet is generated; then the word vector of each code snippet is input into the position encoder for position encoding to obtain a position encoding result; the position encoding result is then subjected to feature extraction through a CodeBert encoder comprising multiple stacked encoding modules to obtain the first static semantic information. In this way, the CodeBert encoder captures important semantic information such as the structure, variables, and syntax of the code line, while paying attention to multiple levels of information such as variable dependencies, control flows, and function calls in the code line, and combining this information to generate a rich code semantic representation. It can lay a good data foundation for later software defect location.

[0102] In some embodiments, before inputting the first fused information vector into the trained multi-head attention deficit localization model, the method further includes:

[0103] Obtaining second defect-introducing versions and defective code lines in all submitted software program codes, where the second defect-introducing versions are used to characterize the bug-introducing versions corresponding to all submitted software program codes;

[0104] Build a multi-head attention deficit localization model that includes a Transformer encoder, a fully connected layer, and a normalized exponential function;

[0105] Based on the second defect-introducing version and the defective code line, a multi-head attention defect localization model is trained to obtain a trained multi-head attention defect localization model.

[0106] In this embodiment, a multi-head attention defect localization model including a Transformer encoder, a fully connected layer, and a normalized exponential function is constructed, that is, the encoder part of the Transformer model is used to capture the global dependencies between code lines. Transformer can dynamically focus on long-distance dependencies between code lines through a multi-head self-attention mechanism, which can not only process local features, but also identify complex logical dependencies across lines (such as control flow, function calls, etc.). This approach greatly improves the global understanding ability of the multi-head attention defect localization model of this embodiment for code defects.

[0107] The above-mentioned obtaining of the second defect-introducing version and defective code lines in all submitted software program codes may be by using an issue tracking system to obtain the defect-fixing submission records corresponding to all submitted software program codes; and using a version control system to obtain the second defect-introducing version and defective code lines in all submitted software program codes based on the defect-fixing submission records corresponding to all submitted software program codes.

[0108] In some implementations, based on the second defect-introducing version and the defective code line, a multi-head attention defect localization model is trained to obtain a trained multi-head attention defect localization model, including:

[0109] Extracting second dynamic execution information, second historical modification information, and second static semantic information from the second defect-introducing version;

[0110] Fusing the second dynamic execution information, the second historical modification information, and the second static semantic information to obtain a second fused information vector;

[0111] Labeling the code lines in the second defect-introducing version according to the defective code lines to obtain labeled code lines;

[0112] The marked code lines and the second fused information vector are used to train the multi-head attention deficit localization model to obtain a trained multi-head attention deficit localization model.

[0113] In this embodiment, the second dynamic execution information, the second historical modification information, and the second static semantic information are fused to obtain a second fused information vector; then, the code lines in the second defect-introducing version are labeled according to the defective code lines to obtain labeled code lines; and the labeled code lines and the second fused information vector are used to train the multi-head attention defect localization model to obtain a trained multi-head attention defect localization model. In this way, the behavior of the code at runtime is reflected by dynamic information, the modification and defect history of the code line are revealed by historical information, and the context and logical semantics of the code line are captured by static semantic information. By fusing these three dimensions, a more comprehensive and accurate suspicion assessment can be obtained, thereby improving the accuracy and robustness of the trained multi-head attention defect localization model when locating software defects.

[0114] To facilitate understanding by those skilled in the art, a set of best embodiments is provided below:

[0115] Spectrum-based Fault Localization (SBFL) locates software defects by analyzing the results of program execution test cases. The core idea of ​​SBFL is to use coverage information (i.e., the frequency and pattern of code execution) and the execution results of test cases to determine the most likely location of defects in the code. The basic principle is that defective lines of code are most likely to be executed multiple times by test cases that reveal the defects.

[0116] Current defect localization methods usually focus on studying man-made failures and simple small programs, but do not study the actual defects that occur in the project (for example, the mutations generated by mutation-based defect localization technology are all artificially added, not real defects in reality), resulting in poor defect localization results in actual projects.

[0117] Since the current defect location method only uses the changes in test coverage or test pass / fail status after mutation to locate defects, it focuses on a single dimension and does not make good use of multi-dimensional information such as static semantic information of the code (i.e., factors such as the logical relationship between codes, control flow, and data dependency) and historical information (i.e., historical data in the version control system, for example, which lines are often modified in the version that introduces the defect) to locate defects.

[0118] This makes the defect location technology based on program spectrum have the following disadvantages:

[0119] (1) SBFL and other techniques mainly target test coverage information and cannot distinguish between elements accidentally executed by test cases and actual faulty elements.

[0120] (2) Since it only uses the test coverage information, it cannot locate the real cause of the error. For example, it does not use program semantic information and historical submission information to locate the error.

[0121] (3) Research usually focuses on human-caused failures and simple small programs, but does not study real defects that occur in large projects.

[0122] The technical solution of this embodiment studies the real defects (i.e. bugs) generated in actual projects, extracts multi-dimensional information such as real project historical submission information, program context semantic information, and program dynamic execution information, and uses the multi-dimensional information extracted from real projects to build a Transformer-based software defect location model (i.e. multi-head attention defect location model) to locate defects, thereby improving the performance of the software defect location method in actual projects. The specific process includes:

[0123] (1) Training data preparation and preprocessing: First, use the issue tracking system to identify the commits that fix the defects by filtering keywords such as "Fix" and "Resolve". Then use the version control system to determine the specific lines fixed in the commits that fix the defects. Then use the git blame tool to trace the history of the repair code lines and find out which commit first introduced the repair code line. Then mark the commit as the commit that introduced the defect and mark the repair code line as a defective line.

[0124] The versions corresponding to all defect-introducing submissions are used as training data sets, and the EvoSuite test generation tool is used to build corresponding test case groups for the defect-introducing versions in the training data sets. The test case groups are run separately, and the traditional SBFL is used to calculate the statement suspicion to capture its dynamic execution information. Then, the version control system is used to obtain the historical modification submissions of each line of code in the version corresponding to each defect-introducing submission, and it is combined with the previously obtained defect-introducing version. The historical spectrum (the main principle is: the more times a line of code is modified in the defect-introducing submission (i.e., the defect-introducing version) is used. The more likely it is to contain defects) calculation formula is used to obtain the suspicion of each line of statement to capture its historical modification information. Finally, the pre-trained CodeBert encoder is used to capture the static semantic information in the code.

[0125] (2) Training defect localization model: Utilize the three dimensions of information captured in the training data preparation and preprocessing stages, including: dynamic execution information (calculating the suspicion of each line of code through SBFL), historical modification information (capturing the risk of code modification history based on the historical spectrum), and static semantic information (using the pre-trained CodeBert to extract the semantic features of the code). After fusing the information of these three dimensions, a feature vector of each line of code is formed, which is used as the input of the multi-head attention defect localization model to train the Transformer-based software defect localization model. Using the Transformer's multi-head self-attention mechanism, the model can capture the global dependencies between code lines, thereby improving the accuracy of locating defective lines.

[0126] (3) Defect location: For a new submission (i.e., the software program code with defects to be located), first, three dimensions of information (i.e., dynamic execution information, historical modification information, and static semantic information) are extracted from the new submission. For dynamic execution information, the EvoSuite test generation tool is used to generate test cases, build a test case group for the new submission, and then run these test cases to capture the coverage information of the code in the new submission when running the test cases. Then, SBFL is used to calculate the suspicion of each line of statement to capture its dynamic execution information. For historical modification information, the version control system is used to obtain all modified versions of each line of code in the new submission. Combined with the defect-introducing versions obtained in the data preparation and preprocessing stages, the historical spectrum calculation formula is used to obtain the suspicion of each line of statement to capture its historical modification information. For static semantic information, the new submission is input into the pre-trained CodeBert model after data preprocessing to convert it into a vector group with context information; then the information of these three dimensions is combined to form a feature vector for each line of code, which is input into the Transformer model for prediction and the final suspicion score of each line of code is output. The higher the suspicion score, the more likely the line is to have a defect.

[0127] The specific technical solution implementation principle of this embodiment includes:

[0128] The overall structural framework of the technical solution of this embodiment is as follows Figure 2 As shown in the figure, for a new submission, its dynamic execution information, historical modification information and static semantic information are captured respectively, and then the information of these three dimensions is combined as the feature vector of each line of code and input into the trained multi-head attention defect localization model, and the final suspicion score of each line of code is output through the multi-head attention defect localization model. The following is a detailed introduction to each stage:

[0129] Dynamic execution information capture: New submissions (i.e. newly submitted code) will be tested through a set of test cases, and test coverage information (i.e. including passed or failed test cases) records the execution results of each line of code in different situations (e.g. how many tests passed, how many tests failed). Finally, through the traditional SBFL (Spectrum-Based Fault Localization) algorithm, using the code execution results and test coverage information, the suspicion of each line of code (i.e. first defect suspicion) is calculated to reflect the abnormal risk of the code at runtime.

[0130] Capture of version control history information: The issue tracking system (ITS) provides commit records for introducing and fixing defects. Through these commit information, the version control system (VCS) can be used to locate the specific version that introduced the defect. For new commits, the modification records of each line of code can be extracted from the version control system to view the number of times and content it has been modified in different versions. Finally, based on these modification information, the suspicion degree of each line of code (i.e., the second defect suspicion degree) is calculated using the suspicion degree formula of the historical spectrum. The more times a line of code is modified by defect commits, the higher its suspicion degree. In this way, the defect risk in the code history is captured.

[0131] Static semantic information capture: First, the code must be preprocessed, including data cleaning and word segmentation, to convert the code text into an input format suitable for processing, and then the code is word-embedded through the BERT model to generate vector representations of each code snippet. These vectors contain the semantic information of the code, and finally, the encoder part of the Transformer model (i.e., CodeBert encoder) is used to further extract features from the code. The multi-head self-attention mechanism is used to capture the global dependencies and static structural information between code lines.

[0132] Information fusion and Transformer model: First, the extracted dynamic execution information (i.e., SBFL suspicion), historical modification information (i.e., historical spectrum suspicion), and static semantic information (i.e., vectors extracted by BERT encoder) are combined to generate a comprehensive feature representation of each line of code. These features are then processed by the multi-head attention defect localization model. The multi-head self-attention mechanism in the multi-head attention defect localization model can capture the complex dependencies between code lines and identify potential defect clues. Finally, the multi-head attention defect localization model outputs a defect suspicion score for each line of code. This score reflects the risk level of the line of code in multiple dimensions (i.e., including dynamic execution, historical modification, and static semantics).

[0133] The following is a detailed introduction to the detailed process from data preparation to the construction of the multi-head attention defect localization model and then to the final defect localization. There are three main steps to use historical submission information for two-stage defect localization:

[0134] (1) Data preparation and data preprocessing.

[0135] (2) Construction of defect classification model and defect location model.

[0136] (3) Use a two-stage model to locate defects.

[0137] The following are the details of these three steps:

[0138] 1. Data preparation and data preprocessing.

[0139] In this stage, we first use the version control system and issue tracking system and the corresponding test case group to extract three dimensions of information, including dynamic execution information, historical modification information, and static semantic information. Before extracting these three dimensions of information, we must first prepare the data for extracting the three dimensions of information and subsequent training models (marked defect lines as labels). The process is as follows: Figure 3 shown.

[0140] First, use the issue tracking system to identify the commit that fixes the defect, then identify the specific code lines that are fixed from the commit (that is, the commit that fixes the bug), and then use the tools of the version control system to trace each fixed line and find the commit (that is, the version) in which they were originally introduced. In this way, you can determine in which version the defects of these code lines were first introduced, and finally mark the versions that introduce the defects and their related defective code lines.

[0141] Next, the three-dimensional information of all defect-introducing commits (i.e., versions that introduced defects) will be extracted for use in subsequent model training.

[0142] (1) Dynamic execution information extraction: For all submissions that introduce defects, we use the EvoSuite test generation tool to generate a test case group for them. We run these test cases to obtain the coverage information of each line of code, and then use the following SBFL calculation formula to calculate the defect suspicion of each line of statement to capture the dynamic execution information of the code.

[0143] ;

[0144] in, Represents a line of code, Indicates the line of code executed in the failed test case The number of times (i.e., in how many failed tests the line was executed), Represents the total number of failed test cases. Indicates that the code line was executed in the successful test case The number of times (i.e., in how many successful tests the line was executed).

[0145] Historical modification information extraction: For all commits that introduce defects, use the version control system to obtain all modified versions of each line. Then, combined with the defect-introducing versions obtained in the data preparation phase, use the following historical spectrum calculation formula to calculate the defect suspicion of each statement.

[0146] ;

[0147] in, Represents a line of code, Indicates that the line of code In how many commits that introduced the bug were modified, Indicates that the line of code The number of commits that did not introduce the bug was modified, where the commits that did not introduce the bug are all the modified versions of the line of code minus the versions that introduced the bug in all the modified versions of the line, Indicates the number of all defect-introducing commits. The core idea of ​​the historical spectrum is very similar to SBFL, that is, the code that causes errors should be modified more by commits that cause errors and less by commits that do not cause errors. The process of capturing historical modification information is as follows: Figure 4 shown.

[0148] Static semantic information extraction: This process and Figure 2 Consistent with the static semantic extraction in , for all commits that introduce defects, they are first preprocessed to filter out information such as comment lines, and then the code lines are tokenized using a tokenizer. The preprocessed information is then embedded and encoded. The specific process is as follows: Figure 5 shown.

[0149] like Figure 5 As shown, firstly, the preprocessed data is subjected to Bert word embedding operation to transform it into a word vector with position encoding information. The Bert word embedding content is as follows Figure 6As shown in the figure, we can see that the word vector after the Bert word embedding operation not only includes the word embedding corresponding to each token (i.e. Token Embeddings, used to characterize the meaning of each token), but also each token will have a segment embedding (i.e. Segment Embeddings, used to indicate which line of code it belongs to). In addition, each token will also have a position embedding (i.e. Position Embeddings, used to indicate the relative position of the token in the sequence). Finally, the three are added together to obtain a complete word vector with semantic information, structural information, and sequential information.

[0150] The word vector with position encoding is input into the pre-trained CodeBert encoder (CodeBert encoder has been pre-trained on a large number of existing code datasets), and the extracted word vector is used to capture important semantic information such as the structure, variables, and syntax of the code line. The pre-trained CodeBert encoder includes 12 stacked encoding modules, each of which contains a multi-head attention layer, addition and layer normalization, and a feedforward network layer. The output of the previous encoding module is used as the input of the next encoding module, and the structure of each encoding module is the same.

[0151] The CodeBert encoder can capture semantic information between code lines, mainly relying on the self-attention mechanism in the Transformer encoder. The self-attention mechanism allows the model to focus on other related code lines while processing one code line, thereby capturing the dependencies and contextual relationships between codes.

[0152] For the input sequence , the self-attention mechanism generates a query vector Q, a key vector K, and a value vector V for each input token. These vectors are generated by linear transformation:

[0153] ;

[0154] in, , , is a learnable weight matrix used to generate query, key, and value vectors respectively. For the code, the input It can be a token representation in a code snippet, including variable names, keywords, and operators.

[0155] For each token ( ), the self-attention mechanism calculates its relevance to other tokens (i.e., semantic dependencies). This relevance is calculated by the dot product of the query vector Q and the key vector K, and then normalized by the softmax function. The calculation formula is as follows:

[0156] ;

[0157] Among them, Q is the query matrix, that is, the representation of the current token, K is the key matrix, that is, the representation of all other tokens, and V is the value matrix, that is, the output after weighted summation. is the dimension of the key vector, used for scaling.

[0158] Through this formula, CodeBert can capture the correlation between each token (or code line) and other tokens. Especially for code, the definition and use of variables may be far apart, but the self-attention mechanism allows the model to "pay attention" to its definition and operation in other locations while processing a variable, thereby capturing the semantic dependencies between code lines.

[0159] The multi-head self-attention mechanism used in the multi-head attention layer in CodeBert is an extension of the above single-head attention mechanism. Its main idea is:

[0160] (1) The model computes multiple self-attention representations in parallel through multiple independent “heads” instead of using only a single self-attention mechanism, which allows the model to capture different contextual dependencies from multiple perspectives.

[0161] (2) Each head performs the same operation as single-head self-attention, but their weights are different so that each head can focus on different parts of the input sequence.

[0162] (3) Finally, the outputs of all heads are concatenated together and a linear transformation is performed to generate the final output.

[0163] The formula used by the multi-head self-attention mechanism is as follows:

[0164] ;

[0165] ;

[0166] in, is the output of the ith head, which uses a different projection matrix , , Perform a linear transformation on queries, keys, and values, It is the weight matrix of the concatenated output after linear transformation.

[0167] CodeBert's multi-head self-attention mechanism can capture complex dependencies in code snippets from multiple perspectives by computing multiple self-attention representations in parallel. It can simultaneously focus on multiple levels of information such as variable dependencies, control flow, and function calls in the code line, and combine this information to generate rich code semantic representations.

[0168] 2. Training of the Transformer-based defect localization model (i.e., multi-head attention defect localization model).

[0169] In order to use the information of three dimensions for model training, the information of three dimensions is first combined (i.e. fused). The process of combining vectors is as follows: Figure 7 shown.

[0170] Since the feature representation of each sentence extracted by static features is a tensor of shape (N, 768), where N is the number of tokens in a sentence, it needs to be converted into a vector to represent the entire sentence. In the Bert model, a common practice is to use the vector representation of the very beginning [CLS] as the vector representation of the entire sentence, because [CLS] is specifically designed to capture semantic information at the entire sequence or sentence level, so the vector representation of [CLS] is chosen as the vector representation of the entire sentence. After extracting the vector representation of the entire sentence, it is combined with the dynamic execution information and historical modification information, and the combined form is as follows:

[0171] ;

[0172] in, is the static feature representation of the sentence, From SBFL suspicion score, representing dynamic execution information, represents the historical spectrum suspicion score, Represents the combined information (ie, the second fusion information vector).

[0173] Use the cat function in the torch library to concatenate the vectors and input them into the built Transformer model (i.e., the multi-head attention defect localization model) for training. In this combined vector, the static semantic information (768 dimensions) provides the context and structural semantic information of the code line. It is good at capturing information such as how the code is written, variable dependencies, and control flow. However, in some cases, the static structure of the code may not show obvious defects. Dynamic execution information and historical modification information can make up for this deficiency. Dynamic execution information and historical modification information can provide additional dimensions to help the model identify defects that are difficult to find in static analysis. For example, if a seemingly correct code fails in multiple test cases and has been modified many times in history, the scalars of these two dimensions can effectively reveal its potential risks.

[0174] Although dynamic execution information and historical modification information are only 1-dimensional scalars in the final vector, their influence is still very large. First, they provide additional dimensions that static semantic information cannot capture, helping to more comprehensively evaluate the defect risk of code lines from a dynamic and historical perspective. In addition, the multi-head self-attention mechanism of the Transformer model can dynamically adjust the weights of these scalars according to task requirements. Even if the dimension is small, the importance of these features will be significantly amplified. Finally, in practice, this scalar information can help the model more accurately identify defects that are not easy to find in static semantic analysis, thereby improving the effect of defect location.

[0175] In the defect localization task, we choose to use only the encoder part of the Transformer, input the combined feature vector (that is, the feature vector that combines static semantic information, dynamic execution information, and historical modification information) into the encoder for feature extraction, and build a classification head based on the encoder for training. Because there is no need for a generative task (which usually requires a decoder), the encoder is sufficient to meet the needs of feature extraction and defect localization tasks. The structure of the multi-head attention defect localization model used is as follows: Figure 8 shown.

[0176] The encoder feature extraction part on the left has the same structure as the encoder part of the traditional Transformer model. The encoder feature extraction part on the left (i.e., the Transformer encoder) contains two stacked encoding modules (i.e., two serially connected encoding modules). The output of the previous encoding module serves as the input of the next encoding module. The structure of each encoding module is the same. The following will briefly introduce the role of each layer, specifically:

[0177] Input embedding layer: Since the input of this defect localization model is a 770-dimensional vector, no additional embedding operation is required, but a linear transformation can be performed to ensure that the dimension is consistent with the hidden layer size of the encoder (768 dimensions).

[0178] Position Encoder: Transformer does not have a recursive or convolutional structure, so it uses positional encoding to capture the position information in the sequence. For each line of code vector input, Transformer uses positional encoding to inject position information so that the model can perceive the order of the input. The specific operation is to generate a 770-dimensional position information vector for each line of code, and then add this position encoding vector to the input 770-dimensional feature vector, so that each line of code not only contains its own static, dynamic, and historical information, but also carries its position information.

[0179] Multi-head attention layer: Consistent with the multi-head attention layer in CodeBert, it captures the global dependencies between inputs by computing the correlation between each position in the input sequence and every other position.

[0180] Feedforward Neural Network: The vectors processed by the multi-head self-attention mechanism are further subjected to feature transformation and nonlinear mapping to enhance the representation ability of the model. The role of the multi-head self-attention mechanism is to capture the relationship between input vectors (such as dependencies between lines of code) through the global context and generate a context-enhanced representation of each vector. However, the attention mechanism itself is linear, which means that it cannot introduce enough nonlinear features. The main role of the feedforward neural network (FFN) is to introduce nonlinear mapping for each input vector to enhance the expressive power of the model so that it can handle complex feature relationships. The nonlinear activation functions of FFN (such as ReLU) enable the model to transition from linear representation to a more complex feature space. In the Transformer encoder, each input vector is independently passed to a feedforward neural network for further processing after being processed by multi-head self-attention. This process is similar to performing feature transformation on each vector individually.

[0181] Addition and layer normalization: In the Transformer encoder, a residual connection is used for addition, that is, the input is directly added to the output of the sublayer, and the result of the addition is used as the input of the next layer. The formula for the residual connection is as follows:

[0182] ;

[0183] in, is the input vector of this layer, is the specific operation of this layer (such as self-attention mechanism or feedforward neural network), Add the input to the output of the sublayer and pass it to the next layer, .

[0184] Using residual connections can first prevent problems such as gradient vanishing and gradient exploding. Deep neural networks are prone to gradient vanishing or gradient exploding during training, especially when there are many layers, the gradient may not be effectively transmitted. Directly participating in the output ensures that the gradient can be passed back along the shortcut, making deep networks easier to train. In addition, the residual connection ensures that the input information can be directly passed to the subsequent layers, even if the intermediate layers fail to capture effective features. In this way, even if some layers of the model perform poorly, the features of the original input will not be completely lost.

[0185] Layer Normalization is to standardize the output of each layer to ensure that the distribution of the output remains stable, prevent the activation value from being too large or too small, and thus accelerate the convergence process of the model. Its formula is as follows:

[0186] ;

[0187] in, Represents input The mean of Represents input The standard deviation of and Respectively represent learnable scaling and offset parameters, which are used to restore the expressive power of normalized features. The layer normalization operation is normalization performed on each feature dimension, that is, all features of each input sample are standardized to ensure that the distribution of each layer output is smoother. It has two main functions: one is to stabilize the training process. Layer normalization makes the output of each layer have a more stable distribution, prevents excessive or small fluctuations in values ​​during model training, and reduces the instability of gradient updates. The other is to accelerate model convergence. By standardizing the output of each layer, the model training can converge faster because the activation values ​​of each layer are standardized to a relatively stable range, so that the weight update of the model is smoother.

[0188] Fully connected layer: Converts the feature vector output by the model to the output dimension required by the classifier, performs linear combination of features and finally obtains a task-related representation. In the defect localization task, the output of the fully connected layer can be mapped to the defect or non-defect category.

[0189] Normalized exponential function: Converts the classification scores output by the fully connected layer into probability distribution to ensure that the final output results can be used for classification decisions.

[0190] Training model: Use the defective code lines obtained from data preparation and data preprocessing to label each line of code, that is, mark which lines of code are defective and which lines of code are not defective. Use whether the code line is defective as a label (1 for defective and 0 for non-defective) and the combined vector as input, input the combined vector and label into the built Transformer-based defect localization model (i.e., multi-head attention defect localization model) for training, and use it for subsequent defect localization.

[0191] 3. Use the trained Transformer-based defect localization model to locate defects.

[0192] (1) Extract three dimensions of information from new submissions.

[0193] When there is a new submission (i.e., the software program code for which defects are to be located), the three dimensions of information in the new submission must first be extracted. The process is as follows:

[0194] Dynamic execution information capture: First, run the test cases and record the coverage information of each line of code in the passed and failed test cases. By analyzing this information, the suspicion score (i.e., first defect suspicion) of each line of code can be calculated using traditional SBFL methods (such as Ochiai suspicion calculation), indicating its possibility of causing test failure, thereby capturing the dynamic behavior information of the code during execution.

[0195] Capturing historical modification information: Through the issue tracking system (ITS) and version control system (VCS), extract the historical modification records of each line of code. Specifically, there are two steps. First, obtain the commit version that introduced the defect, and identify which commits originally introduced the defect by tracking the commits that fixed the defect. Then, obtain all historical modification versions of each line of code, and combine the formula of the historical spectrum to calculate the suspicion score (i.e., the second defect suspicion) of each line of code, indicating the possibility that it has been frequently modified or fixed in history. This score captures the historical stability and risk of the code.

[0196] Static semantic information capture: By preprocessing the code text, the code lines are converted into word embedding representations. The Bert word embedder is used to perform static semantic analysis on the code, and the words, paragraphs, and position information of each line of code are converted into a high-dimensional vector representation. This vector representation captures the semantic features of the code.

[0197] (2) Combining three-dimensional information and defect location.

[0198] The combination process is as follows Figure 7As shown in the figure, first, the vector representation of each code line [CLS] is extracted as the vector representation of the entire sentence, and then the cat function is used to combine the three-dimensional information to obtain the final input of the Transformer-based defect localization model.

[0199] The combined vector is input into the trained defect localization model to obtain the final defect probability score for each line of code. The larger the defect probability score, the greater the possibility that the line of code has a defect.

[0200] Compared with the prior art, this embodiment has the following advantages:

[0201] (1) Organically combine dynamic execution information, historical modification information, and static semantic information. Each dimension of information provides defect risk assessment from different perspectives. Dynamic information reflects the behavior of the code at runtime, historical information reveals the modification and defect history of the code line, and static semantic information captures the context and logical semantics of the code line. By integrating these three dimensions, a more comprehensive and accurate suspicion assessment can be obtained, thereby improving the accuracy and robustness of defect location.

[0202] (2) The Transformer model was introduced, and its encoder part was used to capture the global dependencies between code lines. The Transformer can dynamically focus on the long-distance dependencies between code lines through the multi-head self-attention mechanism. It can not only process local features, but also identify complex logical dependencies across lines (such as control flow and function calls). This approach greatly improves the model's ability to understand code defects globally.

[0203] (3) Historical modification information is introduced. The historical modification records of each line of code are obtained through the issue tracking system and version control system, and the suspicion is calculated in combination with the historical spectrum formula. This allows the defect possibility of a code line to be evaluated not only based on the current dynamic behavior of the code, but also through its modification history. By analyzing the stability of the code and the historical repair records, potential defects can be identified more comprehensively.

[0204] For better explanation, this embodiment is given as follows:

[0205] Step (1) Build a dataset.

[0206] From real projects, use the version control system and issue tracking system to find the commits that introduce defects, mark the defective code lines, and organize them into a defect dataset.

[0207] Step (2) extracts information of three dimensions from the defect dataset, namely, dynamic execution information, historical modification information, and static semantic information.

[0208] Specifically, dynamic execution information capture: use the EvoSuite test generation tool to build a test case group for the defective version, obtain its runtime code coverage information, and use the SBFL calculation formula to obtain the suspicion score of each line of code, that is, dynamic execution information; historical modification information capture: use the version control system to find the modification history of each line in the code, and combine the version that introduced the defect to use the historical spectrum calculation formula to obtain the suspicion score of each line of code, that is, historical modification information; static semantic information capture, directly use the pre-trained CodeBert model to extract static semantic information in the code, and output the vector representation of each code line (with contextual semantic information), that is, static semantic information.

[0209] Step (3) preprocesses the information in three dimensions.

[0210] The collected information of the three dimensions of each line of code is combined into a vector as the feature vector (ie, the combined vector) of the line of code.

[0211] Step (4) Defect localization model training.

[0212] The feature vector containing three-dimensional information preprocessed in the defect data set is input into the defect location model constructed in this embodiment for training. The model parameters are saved to obtain a model file.

[0213] Step (5) uses the defect localization model to locate the defect.

[0214] The three-dimensional information of the newly submitted code is extracted as in step (2), and after preprocessing, it is input into the model constructed in step (4). The defect probability of each line of code can be obtained. The higher the defect probability, the greater the possibility of containing defects. The code lines with defect probability greater than 0.5 are marked as defective, and the final defect report is generated.

[0215] Reference Fig. 9 The embodiment of the present application also provides a multi-dimensional and multi-attention software defect localization system, which includes a data acquisition unit 100, an information extraction unit 200, an information fusion unit 300 and a defect localization unit 400, wherein:

[0216] The data acquisition unit 100 is used to acquire the software program code of the defect to be located;

[0217] The information extraction unit 200 is used to extract first dynamic execution information, first historical modification information, and first static semantic information from the software program code with the defect to be located, wherein the first dynamic execution information is used to characterize the abnormality risk of the software program code with the defect to be located during operation, the first historical modification information is used to characterize the defect risk in history of the software program code with the defect to be located, and the first static semantic information has contextual semantic information in the software program code with the defect to be located;

[0218] An information fusion unit 300, configured to fuse the first dynamic execution information, the first historical modification information and the first static semantic information to obtain a first fused information vector;

[0219] The defect localization unit 400 is used to input the first fusion information vector into the trained multi-head attention defect localization model to obtain a defect localization result.

[0220] It should be noted that since the multi-dimensional and multi-attention software defect localization system in this embodiment and the above-mentioned multi-dimensional and multi-attention software defect localization method are based on the same inventive concept, the corresponding contents in the method embodiment are also applicable to the system embodiment and will not be described in detail here.

[0221] An embodiment of the present application also provides an electronic device, comprising: at least one control processor and a memory for communicating with the at least one control processor.

[0222] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0223] The non-transient software program and instructions required to implement the multi-dimensional multi-attention software defect location method of the above embodiment are stored in the memory. When executed by the processor, the multi-dimensional multi-attention software defect location method of the above embodiment is executed, for example, the above described Figure 1 The method comprises steps S100 to S400.

[0224] The system embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0225] The present application also provides a computer-readable storage medium storing computer-executable instructions, which are executed by one or more control processors to enable the one or more control processors to execute a multi-dimensional and multi-attention software defect location method in the above method embodiment, for example, to execute the above described Figure 1 The functions of method steps S100 to S400 in the method.

[0226] It will be appreciated by those skilled in the art that all or some of the steps and systems in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0227] The above is a specific description of the preferred implementation of the embodiments of the present application, but the embodiments of the present application are not limited to the above-mentioned implementation methods. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit of the embodiments of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the embodiments of the present application.

Claims

1. A multi-dimensional and multi-attention software defect location method, characterized in that: The method comprises: Obtaining software program code of the defect to be located; Extracting first dynamic execution information, first historical modification information, and first static semantic information from the software program code with the defect to be located, wherein the first dynamic execution information is used to characterize the abnormal risk of the software program code with the defect to be located during operation, the first historical modification information is used to characterize the defect risk in history of the software program code with the defect to be located, and the first static semantic information has contextual semantic information in the software program code with the defect to be located; wherein the extracting the first dynamic execution information, the first historical modification information, and the first static semantic information from the software program code with the defect to be located includes: The problem tracking system and the version control system are used to extract the modification information of each line of code in the software program code of the defect to be located; specifically including: Using the issue tracking system to obtain the commit records for fixing the defects; According to the defect repair submission record, the version control system is used to determine the first defect-introducing version corresponding to the software program code for the defect to be located and the number of the first defect-introducing versions, wherein the first defect-introducing version is used to characterize the bug-introducing version corresponding to the software program code for the defect to be located; Using the version control system, extract the number of times each line of code in the software program code to be located with the defect is modified in the first defect-introducing version and the number of all modified versions of each line of code, wherein the modified version is used to represent the modified version of each line of code; taking the number of the first defect-introducing versions, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code as modification information of each line of code; Calculating a second defect suspicion degree of each line of code according to the modification information of each line of code; Using the second defect suspicion level as first historical modification information in the software program code of the defect to be located; Fusing the first dynamic execution information, the first historical modification information, and the first static semantic information to obtain a first fused information vector; The first fusion information vector is input into the trained multi-head attention defect localization model to obtain the defect localization result.

2. The multi-dimensional and multi-attention software defect location method according to claim 1 is characterized in that: The extracting of the first dynamic execution information, the first historical modification information and the first static semantic information from the software program code of the defect to be located includes: Using a test case set to test the software program code of the defect to be located to obtain a test result; Calculating, according to the test results, a first defect suspicion degree of each line of code in the software program code of the defect to be located; The first defect suspicion level is used as the first dynamic execution information in the software program code of the defect to be located.

3. The multi-dimensional and multi-attention software defect location method according to claim 1 is characterized in that: The extracting of the first dynamic execution information, the first historical modification information and the first static semantic information from the software program code of the defect to be located includes: Performing data cleaning and word segmentation on the software program code of the defect to be located to obtain a processed result; The processed results are input into the BERT model for word embedding processing to generate a word vector for each code snippet; Inputting the word vector of each code snippet into the position encoder for position encoding to obtain a position encoding result; The position encoding result is subjected to feature extraction by a CodeBert encoder including a plurality of stacked encoding modules to obtain first static semantic information.

4. The multi-dimensional and multi-attention software defect location method according to claim 1 is characterized in that: Before inputting the first fused information vector into the trained multi-head attention deficit localization model, the method further includes: Obtaining second defect-introducing versions and defective code lines in all submitted software program codes, where the second defect-introducing versions are used to characterize the bug-introducing versions corresponding to all submitted software program codes; Build a multi-head attention deficit localization model that includes a Transformer encoder, a fully connected layer, and a normalized exponential function; Based on the second defect-introducing version and the defective code line, the multi-head attention defect localization model is trained to obtain a trained multi-head attention defect localization model.

5. The multi-dimensional and multi-attention software defect location method according to claim 4 is characterized in that: The step of training the multi-head attention defect localization model based on the second defect-introducing version and the defective code line to obtain a trained multi-head attention defect localization model includes: Extracting second dynamic execution information, second historical modification information, and second static semantic information from the second defect-introducing version; Fusing the second dynamic execution information, the second historical modification information, and the second static semantic information to obtain a second fused information vector; Tagging the code lines in the second defect-introducing version according to the defective code lines to obtain labeled code lines; The marked code lines and the second fusion information vector are used to train the multi-head attention deficit localization model to obtain a trained multi-head attention deficit localization model.

6. A multi-dimensional and multi-attention software defect localization system, characterized in that: The system comprises: A data acquisition unit, used to acquire the software program code of the defect to be located; An information extraction unit is used to extract first dynamic execution information, first historical modification information, and first static semantic information from the software program code of the defect to be located, wherein the first dynamic execution information is used to characterize the abnormal risk of the software program code of the defect to be located at runtime, the first historical modification information is used to characterize the defect risk of the software program code of the defect to be located in history, and the first static semantic information has contextual semantic information in the software program code of the defect to be located; wherein the extracting of the first dynamic execution information, the first historical modification information, and the first static semantic information from the software program code of the defect to be located includes: The problem tracking system and the version control system are used to extract the modification information of each line of code in the software program code of the defect to be located; specifically including: Using the issue tracking system to obtain the commit records for fixing the defects; According to the defect repair submission record, the version control system is used to determine the first defect-introducing version corresponding to the software program code for the defect to be located and the number of the first defect-introducing versions, wherein the first defect-introducing version is used to characterize the bug-introducing version corresponding to the software program code for the defect to be located; Using the version control system, extract the number of times each line of code in the software program code to be located with the defect is modified in the first defect-introducing version and the number of all modified versions of each line of code, wherein the modified version is used to represent the modified version of each line of code; taking the number of the first defect-introducing versions, the number of times each line of code is modified in the first defect-introducing version, and the number of all modified versions of each line of code as modification information of each line of code; Calculating a second defect suspicion degree of each line of code according to the modification information of each line of code; Using the second defect suspicion level as first historical modification information in the software program code of the defect to be located; an information fusion unit, configured to fuse the first dynamic execution information, the first historical modification information, and the first static semantic information to obtain a first fused information vector; The defect localization unit is used to input the first fusion information vector into the trained multi-head attention defect localization model to obtain a defect localization result.

7. An electronic device, characterized in that: It includes at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor to enable the at least one control processor to execute the multi-dimensional and multi-attention software defect location method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the multi-dimensional and multi-attention software defect localization method as described in any one of claims 1 to 5.

Images