Transaction report graph-based software defect positioning method and equipment and storage medium

Abstract

The invention relates to a software defect positioning method and device based on a transaction report graph and a storage medium, and the method comprises the following steps: a similarity calculation step: obtaining a defect report to be positioned, calculating the similarity between the defect report to be positioned and all historical transaction reports, generating a similar report set, the similarity is generated based on multiple of title information, natural language description, codes and stack tracking; a transaction report graph construction step: constructing a transaction report bipartite graph based on the similar report set so as to represent a relationship between a historical transaction report and a defect file; and a defect positioning step: creating a weight matrix, and performing a random walk algorithm in the transaction report bipartite graph to generate a final recommended defect file. Compared with the prior art, the method has the advantages of high software defect positioning accuracy and the like.

Description

Technical Field

[0001] This invention relates to the field of software defect localization, and in particular to a software defect localization method, device and storage medium based on transaction report graphs. Background Technology

[0002] During the development of large-scale projects, developers frequently encounter various defects, such as flawed process logic, unpredictable behavior, program crashes, environment configuration errors, and data interface interaction errors when relying on external APIs. To manage software defects more conveniently and systematically, most software projects introduce issue tracking systems like Jira to manage encountered defects. Defect-related information is typically recorded in defect reports, including a summary of the defect characteristics, defect classification, defect components, a natural language description of the defect, and the source code and stack trace of the part where the error occurred. If the defect report does not explicitly identify the file where the error occurred, developers must reproduce and locate the target defective file, a time-consuming and labor-intensive process for large and complex projects. To improve software quality and developer efficiency, it is necessary to locate and resolve encountered software defects promptly. Therefore, designing and implementing an automated software defect location system is a pressing technical problem in this field, aiming to reduce the time and labor consumed by developers in defect investigation and improve the efficiency and accuracy of software defect location.

[0003] Furthermore, software defect localization also presents challenges inherent in the problem itself. Since the search space for information retrieval-based defect localization methods is the source code, changes in source code versions often affect the effectiveness of these methods. In large software development projects, the number of source code versions is substantial, and defect reports do not specify which version of the defective file caused the defect. Different version selection strategies can significantly impact the effectiveness of defect localization methods. For example, if the search space is defined as the latest source code version, the file that caused the error may not be found during the defect localization search. If a strategy of searching within the corresponding source code version is adopted, then selecting and confirming the corresponding error version is extremely time-consuming and laborious. For example, the paper "A Defect Localization Method for Open Source Software Based on Secondary Propagation" (Li Yuancheng, Wang Boyan, Zhang Pan, Lai Fenggang, Huang Qiucen; Computer Applications Research, July 2020, Vol. 37, No. 7) discloses a secondary propagation method for locating defects in open source software. Based on information retrieval methods, it analyzes the specific location of defects from three aspects: the call relationships between various modules in the open source software, the module risk level, and historical defect reports. It assesses the module risk level by combining the correlation and call relationships between software modules with historical modification information of the open source software, constructs defect tags based on modified defect reports, and uses tag propagation to locate software defects. However, this method requires static analysis of the source code, which involves issues of version stability and data leakage.

[0004] In addition to the challenges brought about by version selection, attention also needs to be paid to the effectiveness of the method itself. Some information retrieval-based defect localization methods often perform poorly when faced with defect reports that do not explicitly specify the defect file, and may even fail to locate the target file. Therefore, special attention needs to be paid to and this problem needs to be solved when designing and implementing a software defect localization system. Summary of the Invention

[0005] The purpose of this invention is to overcome the problems of existing information retrieval-based software defect location methods in terms of version stability and data leakage effectiveness, and to provide a software defect location method, device and storage medium based on transaction report graphs, so as to improve the accuracy of software defect location tools.

[0006] To address the two major shortcomings of existing technologies, this invention fundamentally changes the paradigm of software defect localization. Existing information retrieval-based software defect localization methods rely on comparing defect reports with all source code of the project. This inherent limitation of the source code itself leads to inherent limitations in the method. During software development, source code versions are constantly updated and iterated. Different versions of the source code differ significantly in both content and availability. Therefore, when a defect report is specified, version selection becomes a significant factor affecting the accuracy of defect localization; different source code versions result in different defect localization outcomes. Furthermore, research has revealed that most defect reports explicitly mention the defect filename, indicating data leakage. Since existing software defect localization tools rely on source code, they can directly search for the corresponding filename. However, when dealing with datasets without data leakage, the localization effect is often poor.

[0007] This invention abandons the traditional approach of comparing with source code, and instead directly compares defect reports with historical transaction reports to locate software defects.

[0008] Specifically, the objective of this invention can be achieved through the following technical solutions: A software defect localization method based on transaction report graphs, comprising: The similarity calculation steps are as follows: obtain the defect report to be located, calculate the similarity between the defect report to be located and all historical transaction reports, and generate a set of similar reports. The similarity is generated based on multiple factors, including title information, natural language description, code, and stack trace. The transaction report graph construction step involves constructing a bipartite graph of transaction reports based on the set of similar reports to represent the relationship between historical transaction reports and defective files; The defect localization step involves creating a weight matrix and performing a random walk algorithm on the bipartite graph of the transaction report to generate the final recommended defect file.

[0009] Further, generating a title similarity value based on the title information includes: Extract all adjectives, nouns, and proper nouns from the title according to their parts of speech, and calculate the title similarity value between the defect report and the historical transaction report using the longest repeating substring method.

[0010] Further, generating a natural language description similarity value based on the natural language description includes: Natural language descriptions are extracted from defect reports and historical transaction reports respectively. The natural language descriptions are converted into multi-dimensional word vectors. The cosine similarity between the multi-dimensional word vectors is calculated to represent the similarity value of the natural language descriptions.

[0011] Further, generating code similarity values ​​based on the code includes: The code is extracted from the defect report and the historical transaction report respectively. The code is parsed using AST to extract the method names and class names in the code, and the duplication rate is calculated to obtain the code similarity value.

[0012] Further, generating stack trace similarity values ​​based on the stack trace includes: Extract stack trace information from defect reports and historical transaction reports respectively, parse the thrown exception types, and calculate the exception type repetition to obtain stack trace similarity values.

[0013] Furthermore, the generation of a similar report set includes: Based on title information, natural language description, code and / or stack trace, generate corresponding title similarity values, natural language description similarity values, code similarity values ​​and / or stack trace similarity values ​​between the defect report and all historical transaction reports, and use the average of the similarity values ​​as the final similarity score; The top n historical transaction reports with the highest similarity ranking are combined to form the similar report set.

[0014] Furthermore, the construction of the transaction report bipartite graph includes: Extract the ID of each historical transaction report from the similar report set, retrieve the corresponding defect file based on the ID, and construct the transaction report bipartite graph based on the correlation between the historical transaction report and the defect file. In the transaction report bipartite graph, the node is a transaction report or a defect file, and the edge between the nodes indicates that there is a repair relationship between the defect file and the transaction report.

[0015] Furthermore, the generation of the final recommended defect file includes: Construct an n×n weight matrix and assign initial values ​​to it. The initial values ​​are the similarity between the corresponding historical transaction reports and defect reports, where n is the number of nodes in the bipartite graph of the transaction reports. Construct an n×1 sorting matrix, and update the sorting matrix using a random walk algorithm based on the weight matrix until the sorting matrix converges or reaches the maximum iteration value; Based on the final ranking matrix, several defective files with ranking values ​​higher than the set value are selected as the final recommended defective files.

[0016] The present invention also provides an electronic device, comprising: One or more processors; Memory; and One or more programs stored in memory, the one or more programs including instructions for executing the software defect localization method based on transaction report graphs as described above.

[0017] The present invention also provides a computer-readable storage medium including one or more programs executable by one or more processors of an electronic device, the one or more programs including instructions for performing the software defect localization method based on transaction report graphs as described above.

[0018] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention, based on the concept of information retrieval methods, treats defect reports as input, compares and analyzes them with data in the retrieval space, and outputs a final set of potentially faulty files for developers to quickly identify the target defective files. This invention compares historical transaction reports with defect reports, avoiding version stability and data leakage issues caused by direct contact with source code. Furthermore, the data processing method is consistent, as both are transaction reports, eliminating the need for separate processing of the source code.

[0019] 2. This invention performs similarity calculations based on key information such as the title, natural language description, code examples, and stack traces of defect reports and historical transaction reports. The results are accurate and reliable, providing a reliable foundation for subsequent defect localization.

[0020] 3. The software defect location method based on the transaction report graph of this invention has achieved significant improvements in version stability and data leakage effectiveness. Specifically: under normal circumstances, the software defect location effect is improved compared with existing information retrieval-based defect location methods; in terms of version stability, it is more stable than existing methods, that is, under different version selection strategies, the defect location effect will not change too much due to version fluctuations, while the defect location effect of existing technologies will be significantly affected; in terms of anti-interference, that is, in the case of data leakage, the method of this invention can still maintain a high defect location accuracy in the dataset without data leakage, while the existing technology can hardly locate defective files correctly in the dataset without data leakage, and the defect location accuracy drops significantly. Attached Figure Description

[0021] Figure 1 This is an overview diagram of the software defect localization method based on transaction report graphs according to the present invention; Figure 2 This is an example diagram of a transaction report according to the present invention; Figure 3 This is a flowchart of the defect location steps according to the present invention; Figure 4 This is a comparison chart of experimental results according to the method of this invention. Detailed Implementation

[0022] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0023] Reference Figure 1 As shown, this embodiment provides a software defect localization method based on transaction report graphs, which consists of three stages: The first step is the similarity calculation. For a given defect report and historical transaction reports, four key pieces of information are extracted: title, natural language description, code example, and stack trace. This is the biggest difference between this method and existing technologies. Its fundamental idea is to shift from retrieving defect reports from source code to comparing historical transaction reports with defect reports. This avoids version stability and data leakage issues caused by direct contact with source code. Furthermore, the data processing method is consistent; both are transaction reports, eliminating the need for separate source code processing. The similarity is calculated using the average repetition value of strings between sets. For two strings, the longest common subsequence method is used to calculate the repetition value, which is then divided by the string length to obtain a repetition value between 0 and 1. This value is then divided by the number of strings in the set to obtain the average similarity. For natural language description similarity, cosine similarity is used, again yielding a similarity value between 0 and 1. Finally, the average of the four similarity values ​​is calculated to obtain the final similarity score.

[0024] Specifically, for title information, all adjectives, nouns, and proper nouns in the title are extracted according to part of speech, and the title similarity value between defect reports and transaction reports is calculated using the longest repeating substring method; for natural language descriptions, semantic similarity between descriptions is calculated, natural text is converted into 300-dimensional word vectors, and cosine similarity between vectors is calculated to represent the natural language description similarity value; for code, code in the report is extracted, code is parsed using AST, method names and class names in the code are extracted, and repetition is calculated to represent the code similarity value between reports; for stack traces, stack trace information mentioned in the report is extracted, exception types are parsed, and exception type repetition is calculated to represent the stack trace similarity value between reports.

[0025] A similarity score is determined based on the average of the above multiple similarity scores to measure the similarity between defect reports and historical transaction reports, thereby improving the accuracy of similarity calculation.

[0026] In this embodiment, after obtaining the similarity between the defect report and all historical transaction reports, the top 20 transaction reports with the highest similarity are taken as a set to form a similar report set.

[0027] The second step is the transaction report graph construction step. The transaction reports are ranked according to the previously calculated similarity, and the top few transaction reports are selected to form a similar report set. A transaction report bipartite graph is then constructed based on this similar report set.

[0028] Specifically, the process of constructing the transaction report bipartite graph in this embodiment includes: For the 20 most similar transaction reports, the transaction report IDs are extracted as keywords. The commit history of all files in the project is parsed using git log, and the transaction report IDs are retrieved from the commit information. The transaction reports are then associated with defective files, and finally a transaction report bipartite graph IFGraph is constructed. The graph has two types of nodes: transaction reports and defective files. The edges between nodes indicate that there is a repair relationship between the file and the transaction report.

[0029] The third step is the random walk iteration step. Random walk iterations are performed in the transaction report bipartite graph to find the files with the highest final walk probability as the located defect files, including: Construct an n×n weight matrix and assign initial values ​​to it. The initial values ​​are the similarity between the corresponding historical transaction reports and defect reports, where n is the number of nodes in the bipartite graph of the transaction reports. Construct an n×1 sorting matrix, and update the sorting matrix using a random walk algorithm based on the weight matrix until the sorting matrix converges or reaches the maximum iteration value; Based on the final ranking matrix, several defective files with ranking values ​​higher than the set value are selected as the final recommended defective files.

[0030] For ease of understanding, the following description, in conjunction with embodiments, will provide further details. Figure 2The example of the transaction report graph shown illustrates this, where CASSANDRA-11210 is the defect report to be located. This defect report indicates that when DNS cannot resolve the hostname, the replacement parameter is incorrectly ignored. The `getReplaceAddress()` method of `DatabaseDescriptor.java` is used to retrieve the replacement parameter, thereby fixing the defect report. The defect location process is shown in detail below for this defect report. First, similarity is calculated. For ease of understanding, the top six transaction reports are selected to construct the transaction report graph. These transaction reports are CASSANDRA-5916, CASSANDRA-7356, CASSANDRA-4802, CASSANDRA-6523, CASSANDRA-3736, and CASSANDRA-9436. These transaction reports include defect reports, new features, and optimizations. Subsequently, the commit history of these six transaction reports is analyzed using gitlog to find many-to-many correspondences with the defective files, and edges are used to connect the two nodes. Figure 2 The right side lists the candidate defect files: DatabaseDescriptor.java, StorageService.java, GossipDigestSynVerbHandler.java, Gossiper.java, SystemTable.java, SystemKeyspace.java, and CFMetaData.java. Next, edge weights are assigned. The weights are determined by the similarity calculated between the defect report and the transaction report. The similarity between CASSANDRA-11210 and CASSANDRA-5916 is 0.83. Therefore, all outgoing edges from the CASSANDRA-5916 node in the transaction report graph are assigned a weight of 0.83. In the graph, the edge weights between CASSANDRA-5916 and DatabaseDescriptor.java, StorageService.java, GossipDigestSynVerbHandler.java, Gossiper.java, and SystemTable.java are all 0.83. The same processing method is applied to the remaining transaction reports, ultimately constructing the complete transaction report graph.

[0031] After the transaction report graph is constructed, the third step, the final defect localization stage, is performed. This is done using a random walk iterative approach, referring to... Figure 3The algorithm flow for defect localization shown includes the following inputs: transaction report graph, maximum iteration count (iterationmaxiter), stopping threshold (ε), and iteration coefficient (α). The output is a final sorted list of defect files. Specific steps include: 1) Extract all nodes from the graph and store them in a list. In this embodiment, a total of 13 nodes were extracted from the transaction report graph.

[0032] 2) Generate a weight matrix based on the edge weights and use it as the transition matrix. The matrix has an n×n dimension, where n is the number of nodes, which is 13 in this case. Specifically, TransferMatrix[i][j] represents the weight of the edge from node i to j. In this example, the value of TransferMatrix[0][6] is 0.83 because it represents the weight of the edge from cassandra-5916 to StorageService.java.

[0033] 3) Initialize a rank vector as a sorting matrix, with its dimension equal to the size of all nodes. In this embodiment, the initial value is set to 1.

[0034] In this example, the initial RankVertor is 13×1, and the initial value is 1.

[0035] 4) Learning iteration: Start the loop, which will iterate no more than maxiter times. Copy the current ranking vector RankVector to a temporary vector TempVector as the calculation basis for this iteration; Calculate intermediate variable A: Perform matrix multiplication operation on the iteration coefficient alpha, the transpose of the transfer matrix (TransferMatrix.T, ensuring matrix multiplication dimension matching) and the temporary vector TempVector to reflect the influence of the ranking of the associated nodes on the current node (the stronger the association of the nodes, the more obvious the transmission effect on the ranking of the current node). In this embodiment, the provisional coefficient alpha is 0.8. Calculate intermediate variable B: Multiply (1 - alpha) with the temporary vector TempVector to retain the node's own initial ranking weight and avoid ranking from being completely dependent on associated nodes; Add B to A to get a new vector, then normalize this vector (so that the sum of the vector elements is 1 or of uniform magnitude), and finally update the result to a new temporary vector TempVector. For example, if an initial vector is (1,2,3,4), then the normalized vector will have values ​​of (0.183,0.365,0.548,0.730).

[0036] 5) Convergence judgment (early termination of iteration) Calculate the difference between the current ranking vector RankVector and the new temporary vector TempVector (usually the sum of the absolute values ​​of the differences between the vector elements, or the norm): If the difference is less than the preset stopping threshold ε, it means that the ranking vector has stabilized and the convergence condition is met, and the loop can be exited directly (without completing the remaining iterations). If the convergence condition is not met, RankVector is updated to TempVector obtained in this iteration, and the latest transfer matrix TransferMatrix is ​​generated again based on the bipartite graph G.

[0037] 6) Defect file screening and sorting: Based on the final ranking matrix RankVector, the corresponding defective file nodes are selected. Specifically, the top K nodes with ranking values ​​higher than a set value are retained. These nodes correspond to files suspected of being faulty. The magnitude of the values ​​in the final ranking matrix indicates the degree of suspicion of the file, and the defective file located by the defect report is output.

[0038] The pseudocode for the above process is shown below: Taking the first iteration as an example, the iteration process is explained in detail. In the first iteration, the score of node CASSANDRA-5916 is 0.8×(0.83×1+0.83×1+0.83×1+0.83×1+0.83×1)+0.21=3.5, and the score of DatabaseDescriptor.java is 0.8×(0.83+0.71)+0.2×1=1.432. If the difference between TempVertor and RankVertor is less than the threshold, the iteration terminates; otherwise, the vectors are updated and iterated. When the algorithm terminates, each node has its own corresponding ranking value in RankVertor. For defective file nodes, their values ​​are 0.605, 0.545, 0.314, 0.231, 0.164, and 0.164, respectively.

[0039] In this embodiment, the highest-ranking defective file node is DatabaseDescriptor.java at 0.605, indicating that this file is most likely the defective file to be repaired located by the defect report. As it turns out, DatabaseDescriptor.java is indeed the file that was repaired to resolve the CCASSANDRA-11210 defect report, proving the feasibility of the method.

[0040] To more comprehensively evaluate the effectiveness of the method of this invention, this embodiment conducts experimental verification on a real-world dataset. This embodiment selects real-world projects to construct the dataset, including both large and small projects to ensure representativeness, including ARIES, CALCITE, CASSANDRA, FLINK, HBASE, HIVE, GRODE, and NUTCH. To verify the ability of existing methods to handle non-data-leaked datasets, this embodiment removes the explicit mention of defect filenames from all transaction reports, thereby constructing a new non-data-leaked dataset. The dataset contains 17,184 transaction reports and 58,523 defect files, involving 656 source code versions. Similarly, this embodiment selects three baselines for comparison with the tools used in this embodiment: BugLocator, BRTracer, and Locus. BugLocator identifies the defect file involved in a bug report by comparing newly submitted bug reports with the source file and historical bug reports. During the comparison process, the system uses a simple average score to sort the files. BRTracer compares the stack trace in the bug report with the source file to locate the defect file. Locus builds natural language models and code models from the code revision history by comparing source files with bug reports.

[0041] First, two version selection strategies are used. The first strategy, called the latest version strategy, selects the latest version for comparison. The second strategy, called the multi-version strategy, selects the source code with the same version as when the defect report was submitted for comparison. The evaluation metrics used are MRR and MAP; higher values ​​indicate better defect localization. Regarding data leakage effectiveness, experimental results show that the method in this embodiment is significantly more effective than other methods. Figure 4 The overall effect diagram of the defect localization performance of the method of this invention and existing benchmarks in experiments is given. The horizontal axis represents different items, and the vertical axis represents evaluation indicators, namely MAP and MRR. The sub-figure titles explain the version selection strategy. Figure 4 In the text, (a) and (b) represent selecting the latest single-version matching strategy. Figure 4In the diagram, (c) and (d) represent multi-version selection strategies, and the different colored bars represent different tools. The tool of this invention, called BisL, is represented by the purple bar. From an overall perspective, it is clear that the defect localization effect of the method of this invention is significantly greater than that of other existing defect localization tools. Specifically, the effectiveness of all existing tools is significantly reduced on datasets without data leakage. For BugLocator and BRTracer, except for Calcite, the MRR and MAP values ​​are all below 0.1. Even with the newer technology Locus, all values ​​are below 0.2. Even in the best case, Calcite's MRR and MAP values ​​on BugLocator are only 0.13 and 0.144, respectively, while on BRTracer they are 0.162 and 0.185, respectively. In their evaluation, they did not remove error reports that displayed errors. In this setup, Lee et al. reported an MRR of 0.4168 for BugLocator in HBase and 0.3670 in Hive, while in the experiments of this embodiment, these values ​​were 0.082 and 0.126, respectively. Lee et al. reported an MRR of 0.4884 for BRTracer in HBase and 0.4521 in Hive, while in the experiments of this embodiment, these values ​​were 0.092 and 0.166, respectively. Lee et al. reported an MRR of 0.4059 for Locus in HBase and 0.4580 in Hive, while in the experiments of this embodiment, these values ​​were 0.2247 and 0.1030, respectively. This demonstrates that existing methods cannot effectively locate faults if the bug report does not explicitly mention the defective code element. This demonstrates that the method in this embodiment performs far better than other existing benchmark works in addressing the challenges of data breaches. It can be seen that on datasets without data breaches, the localization effect of benchmark works drops sharply, and it is almost impossible to locate the corresponding defective files.

[0042] Similarly, in multi-version experiments, defect localization tools generally yielded better results with the multi-version strategy. In this setting, BugLocator and BRTracer performed best in locating Cassandra faults. BugLocator's MRR and MAP values ​​were 0.209 and 0.219, respectively, while BRTracer's were 0.229 and 0.239. Locus performed best in locating Hive faults, with values ​​of 0.208 and 0.221. In contrast, BisL achieved better results in both settings. The bar chart clearly shows that BisL's is significantly higher than the other tools. In this example, both the MRR and MAP values ​​exceeded 0.15. For Nutch and Cassandra, the MRR values ​​in this example were 0.515 and 0.746, respectively. After calculating the significant differences between BisL and BugLocator, the p-value for MAP was 0.014, and the p-value for MRR was 0.014. In summary, after removing error reports that explicitly mentioned defective code elements in this embodiment, the baseline MAP and MRR values ​​dropped to approximately 0.1. Under these challenging settings, BisL achieved significantly better results than the baseline.

[0043] In addition to the challenge of data leakage, this embodiment also evaluates the effectiveness of the method from the perspective of version stability. This embodiment uses the relative changes in the MRR and MAP of the metrics to measure the stability of the method across different versions. The table below shows the overall stability of the method in this embodiment. First, it can be seen that when using the latest version as the search space strategy, the method in this embodiment performs significantly better. At the same time, when compared with the strategy of using multiple versions as the search space, the variation of the results of the method in this embodiment is also the smallest, significantly lower than the baseline. Overall, all methods performed better under a multi-version strategy. However, the differences between methods were negligible. After eliminating data leakage factors, different selection strategies did not produce significant differences. Compared to other tools, this invention is more stable because it does not require inputting source files. 11.6% of defect reports did not clearly indicate the version information containing the defect, making version determination difficult. Since each strategy has minimal impact on the results, the method of this invention becomes an ideal tool for locating defects.

[0044] If the above methods are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0045] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A software defect localization method based on transaction report graphs, characterized in that, include: The similarity calculation steps are as follows: obtain the defect report to be located, calculate the similarity between the defect report to be located and all historical transaction reports, and generate a set of similar reports. The similarity is generated based on multiple factors, including title information, natural language description, code, and stack trace. The transaction report graph construction step involves constructing a bipartite graph of transaction reports based on the set of similar reports to represent the relationship between historical transaction reports and defective files; The defect localization step involves creating a weight matrix and performing a random walk algorithm on the bipartite graph of the transaction report to generate the final recommended defect file.

2. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, Generate a title similarity value based on the title information, including: Extract all adjectives, nouns, and proper nouns from the title according to their parts of speech, and calculate the title similarity value between the defect report and the historical transaction report using the longest repeating substring method.

3. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, Generating natural language description similarity values ​​based on the natural language description includes: Natural language descriptions are extracted from defect reports and historical transaction reports respectively. The natural language descriptions are converted into multi-dimensional word vectors. The cosine similarity between the multi-dimensional word vectors is calculated to represent the similarity value of the natural language descriptions.

4. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, Generate code similarity values ​​based on the code, including: The code is extracted from the defect report and the historical transaction report respectively. The code is parsed using AST to extract the method names and class names in the code, and the duplication rate is calculated to obtain the code similarity value.

5. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, Generate stack trace similarity values ​​based on the stack trace, including: Extract stack trace information from defect reports and historical transaction reports respectively, parse the thrown exception types, and calculate the exception type repetition to obtain stack trace similarity values.

6. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, The generation of the similar report set includes: Based on title information, natural language description, code and / or stack trace, generate corresponding title similarity values, natural language description similarity values, code similarity values ​​and / or stack trace similarity values ​​between the defect report and all historical transaction reports, and use the average of the similarity values ​​as the final similarity score; The top n historical transaction reports with the highest similarity ranking are combined to form the similar report set.

7. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, The construction of the transaction report bipartite diagram includes: Extract the ID of each historical transaction report from the similar report set, retrieve the corresponding defect file based on the ID, and construct the transaction report bipartite graph based on the correlation between the historical transaction report and the defect file. In the transaction report bipartite graph, the node is a transaction report or a defect file, and the edge between the nodes indicates that there is a repair relationship between the defect file and the transaction report.

8. The software defect localization method based on transaction report graphs according to claim 1, characterized in that, The defect file that generates the final recommendation includes: Construct an n×n weight matrix and assign initial values ​​to it. The initial values ​​are the similarity between the corresponding historical transaction reports and defect reports, where n is the number of nodes in the bipartite graph of the transaction reports. Construct an n×1 sorting matrix, and update the sorting matrix using a random walk algorithm based on the weight matrix until the sorting matrix converges or reaches the maximum iteration value; Based on the final ranking matrix, several defective files with ranking values ​​higher than the set value are selected as the final recommended defective files.

9. An electronic device, characterized in that, include: One or more processors; Memory; and One or more programs stored in memory, the one or more programs including instructions for executing the software defect localization method based on transaction report graphs as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, It includes one or more programs executable by one or more processors of an electronic device, the one or more programs including instructions for performing the software defect localization method based on the transaction report graph as described in any one of claims 1-8.

Images