A defect positioning method and system based on historical defect data query expansion

Abstract

This invention discloses a defect localization method and system based on historical defect data query expansion. The method includes: acquiring project source code and historical defect reports from a version control system and a defect tracking system to construct an initial dataset; preprocessing the initial dataset; training a word embedding model using the preprocessed dataset and outputting word vectors to a HAN model; the HAN model identifying the symptom category and cause category of the defect report to be located; acquiring relevant historical fixed defect data based on the cause category; expanding the query vector of the defect report to be located using the historical fixed defect data to obtain an expanded query vector; and locating the defect based on the similarity between the expanded query vector and the source code to generate a list of suspicious code elements. This invention can significantly improve the accuracy of defect localization, reduce the time and effort spent by maintenance personnel in locating software defects, and improve software maintenance efficiency.

Description

Technical Field

[0001] This invention relates to the field of defect location technology, and specifically to a defect location method and system based on historical defect data query expansion. Background Technology

[0002] As software systems become increasingly large and complex, the impact and consequences of software defects on software security are becoming more severe, leading to system crashes, business interruptions, economic losses, and even threats to personal safety. To improve software maintenance efficiency, many projects now utilize defect tracking systems for defect management. Defect reports are documents that record and describe software defects discovered during software development and maintenance. They are typically created by testers, users, or other stakeholders and submitted to the development team. The purpose of defect reports is to accurately describe the nature, manifestation, and impact of defects, allowing the development team to understand and fix problems based on these reports.

[0003] Large software systems typically contain tens of thousands of source files, making manual defect location extremely costly. To reduce the costs of software construction and maintenance, researchers are dedicated to developing automated defect location technologies. Information retrieval-based methods are a common approach. This method treats defect reports as queries and source code as documentation for analysis. However, due to varying levels of coding skills and expressive abilities among different submitters, some defect reports contain insufficient information and have low relevance to the actual defective source code. Summary of the Invention

[0004] To address the aforementioned technical problems in the existing technology, this invention provides a defect location method and system based on historical defect data query expansion, which improves the quality of the query and the accuracy of defect location.

[0005] According to one aspect of the present invention, a defect localization method based on historical defect data query expansion is provided, the method comprising: S1. Obtain the project source code and historical defect reports from the version control system and defect tracking system to build the initial dataset; S2. Perform text preprocessing on the initial dataset to obtain the preprocessed dataset; S3. Train a word embedding model using the preprocessed dataset. The word embedding model converts the words in the historical defect reports into word vectors and inputs them into the HAN model. S4. Use the HAN model to identify the symptom category and cause category of the defect report to be located; S5. Obtain relevant historical fixed defect data according to the cause category; S6. Expand the query vector of the defect report to be located using historical repaired defect data to obtain the expanded query vector; S7. The word embedding model uses the similarity between the expanded query vector and the source code to locate defects and generate a list of suspicious code elements.

[0006] According to another aspect of the present invention, a defect localization system based on historical defect data query expansion is provided, comprising: The dataset building module is used to obtain project source code and historical defect reports from version control systems and defect tracking systems to build the initial dataset; The preprocessing module is used to perform text preprocessing on the initial dataset to obtain a preprocessed dataset; The word embedding training module is used to train a word embedding model using a preprocessed dataset. The word embedding model converts words in historical defect reports into word vectors and inputs them into the HAN model. The cause identification and classification module is used to identify the symptom category and cause category of the defect report to be located using the HAN model; The historical related defect acquisition module is used to acquire relevant historical fixed defect data according to the cause category. The query expansion module is used to expand the query vector of the defect report to be located using historical repaired defect data, so as to obtain the expanded query vector. The defect localization module is used to locate defects by comparing the similarity between the expanded query vector and the source code, and generate a list of suspicious code elements.

[0007] Compared with existing technologies, this invention has the following significant advantages: 1. By mining the correlation between defect cause categories and defect symptom categories from historical defect data, it can accurately predict the cause category of new defect reports, and based on this, extract relevant code elements from historical fixed defect data for query expansion, effectively making up for the problem of insufficient information in the original defect reports and significantly improving the quality of query vectors; 2. By using the HAN model for multi-dimensional category recognition and combining it with an incrementally trained word embedding model, it can more accurately capture the semantic relationship between defect reports and source code, thereby greatly improving the accuracy of static defect localization and reducing the cost and difficulty of software maintenance. Attached Figure Description

[0008] Figure 1 A schematic diagram of a defect localization method based on historical defect data query expansion provided by the present invention;

[0009] Figure 2 This is a screenshot of the defect report summary section of the Bugzilla defect tracking system in an embodiment of the present invention;

[0010] Figure 3 This is a screenshot of the defect report description section of the Bugzilla defect tracking system in an embodiment of the present invention;

[0011] Figure 4 This is a schematic diagram of the architecture of the HAN model in an embodiment of the present invention. Detailed Implementation

[0012] Example 1

[0013] See Figure 1 This embodiment provides a defect location method based on historical defect data query expansion. This method aims to transform unstructured defect reports into high-precision code location results through an automated process, specifically including the following steps: Step S1: Obtain the project source code and historical defect reports from the version control system and defect tracking system to build the initial dataset.

[0014] Specifically, the source code for AspectJ, Birt, Eclipse, and JDT is obtained from the Git version control system, and historical defect reports for the corresponding projects are crawled from the Bugzilla defect tracking system to build the initial dataset. During this step, a network connection can be established with the target code repository and the defect management platform, and data can be downloaded in batches by calling the corresponding application programming interfaces (APIs). Furthermore, to ensure data integrity, retry mechanisms and breakpoint resume functionality can be implemented.

[0015] Step S2: Perform text preprocessing on the initial dataset to obtain the preprocessed dataset.

[0016] Specifically, the process involves deleting punctuation marks from historical defect reports and the project source code, using a code parser to parse the source code into an abstract syntax tree, and recording the identifiers contained in the source code through the abstract syntax tree to generate a set of words representing the source file; obtaining the summary and description parts of historical defect reports, performing identifier extraction, word segmentation, stop word removal, filtering of non-English tokens, and stemming on the historical defect reports, and splitting the composite tokens using camelCase identification.

[0017] The identifiers can be packages, classes, methods, and variable names, etc., used to generate a set of terms to represent the source file. See also... Figure 2 and Figure 3The screenshots show the summary and description sections of a defect report, providing helpful information for defect localization. Defect reports typically contain concatenations of non-English tokens and words. This step involves first using the NLTK toolkit to extract identifiers, segment words, remove stop words, filter non-English tokens, and stem the words in the summary and description sections of the defect report. Then, the composite tokens generated using camelCase are split.

[0018] For example, “commonviewer” can be split into “common” and “viewer”, and then the stem of the token can be extracted using the PorterAlgorith stemming algorithm, stemming “common” and “viewer” into “common” and “view”.

[0019] Step S3: Train a word embedding model using the preprocessed dataset. The word embedding model converts the words in the historical defect reports into word vectors and inputs them into the HAN model.

[0020] Specifically, the word embedding model is executed in a skip-gram manner, where the embedding layer is initialized using an embedding model pre-trained from a full-domain corpus. The initialized word embedding model is then incrementally trained using the pre-processed dataset to obtain the Word2vec word embedding model. The HAN model used in step S4 cannot directly process raw text; it requires numerical input. The word embedding model trained in this step can convert the words in the defect report into word vectors, which serve as the input layer of the HAN model.

[0021] For example, word embedding models are trained using a skip-gram approach, where the embedding layer is initialized using a pre-trained embedding model from a domain-wide corpus (e.g., open-source software libraries and swarm intelligence communities in the SE domain), and the initialized word embedding model is incrementally trained using a pre-processed dataset. In some embodiments, the initialized embedding model can be either SCOR or a Stack Overflow-based embedding model.

[0022] Step S4: Use the HAN model to identify the symptom category and cause category of the defect report to be located.

[0023] Specifically, the title and description of the defect report to be located are taken as input, and a pre-trained automatic defect symptom classifier is used for identification to obtain the symptom probability vector and cause probability vector of the defect report to be located, and to determine the symptom category and cause category; where each element in the vector represents the predicted probability value of the category corresponding to the defect report to be located.

[0024] For example, the defect report to be located can be understood as a new defect report, with the title and description of the new defect report as input; the defect symptom automatic classifier of the pre-trained HAN model is used for identification to obtain the symptom probability vector of the new defect report. V A and cause probability vector V Craw In this process, each element in the symptom probability vector and cause probability vector represents the predicted probability value of the symptom category and cause category corresponding to the defect, respectively. In this step, the newly input text is converted into a sequence of word vectors, which are then passed sequentially through a word-level bidirectional recurrent neural network, a word-level attention layer, a sentence-level bidirectional recurrent neural network, and a sentence-level attention layer, ultimately outputting the classification result. (See also...) Figure 4 The architecture of the HAN model mainly consists of a word sequence encoder, a word-level attention layer, a sentence sequence encoder, a sentence-level attention layer, and a Softmax layer.

[0025] Step S5: Obtain relevant historical fixed defect data based on the cause category.

[0026] Specifically, based on the cause category with the highest predicted probability value in new defect reports, the system mines the causal relationship between causes and symptoms from historical defect categories and extracts corresponding historical defect report terms and fix codes from historically fixed defects. The system can perform fast retrieval in a pre-built historical defect index and accelerate the matching process using data structures such as inverted indexes.

[0027] Step S6: Expand the query vector of the defect report to be located using historical repaired defect data to obtain the expanded query vector.

[0028] Specifically, defect report terms and repair code elements are extracted from historical repaired defect data to generate extended vectors; the original word embedding vectors of the defect reports to be located are fused with the extended vectors to generate extended query vectors with a unified representation.

[0029] Step S7: The word embedding model uses the similarity between the expanded query vector and the source code to locate defects and generate a list of suspicious code elements.

[0030] Specifically, the predicate embedding model calculates the similarity between the source code and the expanded query vector, and sorts them from high to low similarity to generate a list of suspicious code elements. This series of steps ultimately transforms abstract semantic matching into intuitive code file sorting, directly serving software maintainers. This step uses a word embedding model to map the query statement and the source code to a similar space, thereby achieving accurate matching.

[0031] The symptom and cause categories for defect reports are shown in Tables 1 and 2 below.

[0032] Table 1. Symptom Categories and Descriptions of Defect Reports

[0033] Symptom categories Related Explanation Security flaws Systems, programs, and data are unintentionally or maliciously damaged, altered, or leaked. Reliability defects The software does not consistently perform its intended functions and experiences unplanned interruptions, crashes, or hangs. Input problem Inappropriate input, correct input not accepted or incorrect input accepted, incorrect data source, incomplete / missing parameters. Output problem The output data is incomplete / missing, the result is incomplete / missing, or there is a data processing error. Message defects The system information is incorrect; the information notification is unclear or unreasonable. Performance defects The software speed as perceived by customers and their end users, i.e., the software functions correctly but runs / responds slowly. Usability defects Software and publications that make a product difficult to understand and inconvenient for end users do not affect its functionality. Capability The software does not perform its intended functions and does not meet known requirements. Requirements The customer's software requirements were not met.

[0034] Table 2. Categories and Explanations of Defect Reports

[0035] Cause type Related Explanation Resources This refers to defects in the initialization, manipulation, and release of data, variables, or other resources. Check A defect that occurs when verifying a defect or detecting an invalid value. Interface Defects that arise when interacting with other parts of the software. Logic Defects arising from comparison operations, control flow, computation, and other types of logic errors. Timing A defect that occurs in multithreaded applications where concurrent threads or processes use shared resources. Program (Function) Defects caused by missing functionality or incorrect implementation. Support Defects caused by errors in the support system and libraries or their configuration, change management, or version control. Document Defects caused by missing, inaccurate, inconsistent, or incomplete documentation.

[0036] Example 2

[0037] This embodiment provides a defect localization system based on historical defect data query expansion. The system may include a dataset construction module, a preprocessing module, a word embedding training module, a cause identification and classification module, a historical related defect acquisition module, a query expansion module, and a defect localization module. These modules can be implemented by hardware, software, or a combination thereof. In some embodiments, the modules can communicate and exchange data through a high-speed data bus, shared memory, or a network interface.

[0038] The dataset construction module is used to acquire project source code and historical defect reports from version control systems and defect tracking systems to build an initial dataset. Specifically, the dataset construction module can acquire the source code of the target software project from version control systems such as Git, and crawl the corresponding project's defect reports from defect tracking systems such as Bugzilla. In some embodiments, the acquired defect reports may include fields such as summary, description, commit time, committer information, and status.

[0039] The preprocessing module performs text preprocessing on the initial dataset to obtain a preprocessed dataset. Specifically, the preprocessing module can use a code parser to parse the source code into an abstract syntax tree (AST). Through the AST, the preprocessing module can accurately record the identifiers contained in the source code, such as package names, class names, method names, and variable names. In some embodiments, after extracting these identifiers, a set of terms can be generated to represent the source file. This AST-based extraction method can filter out syntax keywords and punctuation marks in the source code, retaining the identifiers with the most semantic value.

[0040] Furthermore, the preprocessing module is configured to perform word segmentation, stop word removal, and stemming operations on the summaries and descriptions in defect reports. Since defect reports are typically written in natural language, they contain a large number of stop words that are useless for defect localization; stop word removal can significantly reduce the dimensionality of the data. Simultaneously, stemming can restore words of different forms to their root forms, thereby reducing the sparsity of the vocabulary. In some embodiments, the preprocessing module can also split camelCase compound tokens. In the programming field, developers frequently use camelCase naming (e.g., commonviewer); the preprocessing module can split this into two independent tokens, "common" and "viewer," for better semantic matching with natural language descriptions.

[0041] The word embedding training module is used to train the word embedding model using a preprocessed dataset. Specifically, the word embedding training module can perform word embedding model training in a skip-gram manner. In the skip-gram manner, the model predicts context words using the center word, thereby learning distributed representations of vocabulary from a large corpus. In some embodiments, the embedding layer of the word embedding model is initialized using an embedding model pre-trained from a full-domain corpus. The full-domain corpus may include open-source software libraries and swarm intelligence community question-answering data from the software engineering field. Initializing the model using a pre-trained word embedding model provides the model with rich prior semantic knowledge.

[0042] The word embedding training module is also configured to incrementally train the initialized word embedding model using a preprocessed dataset. Since the target software project may contain domain-specific vocabulary and proper nouns, directly using the pre-trained word embedding model may not accurately represent the semantics of these words. By incrementally training on the target project's dataset, the word embedding model can fine-tune its weights to better adapt to the context of the current project.

[0043] The cause identification and classification module is used to identify the symptom and cause categories of the defect report to be located using the HAN model. Specifically, the module takes the title and description of the defect report to be located (which can be understood as a new defect report) as input and uses a pre-trained HAN model's automatic defect symptom classifier for identification. The HAN model can calculate attention weights at both the word and sentence levels, thereby accurately capturing the key information most important for the classification decision. After learning from the HAN model and performing a softmax operation, the symptom probability vector of the new defect report can be obtained. V A and cause probability vector V CrawThe Softmax operation transforms the model's raw output into a normalized probability distribution. Each element in the symptom probability vector and cause probability vector represents the predicted probability that the defect belongs to the corresponding symptom category and cause category, respectively. For example, symptom categories may include security defects, reliability defects, performance defects, etc.; cause categories may include resources, interfaces, logic, timing, etc. In this way, the cause identification and classification module can not only provide the most probable category but also the confidence level of the classification.

[0044] The historical related defect acquisition module is used to retrieve relevant historical fixed defect data based on cause categories. Specifically, this module can mine the causal relationship between causes and symptoms from historical defect categories based on the cause category with the highest predicted probability value for new defect reports. Once the most probable cause category is determined, the module extracts the corresponding historical defect report terms and fix codes from historically fixed defects. This historical data contains specific code snippets and discussion records modified by predecessors when solving similar problems, and has extremely high reference value. For example, if a new defect is classified as the "interface" cause category, the module will retrieve all historical defects caused by interface issues and extract key identifiers from their fix codes.

[0045] The query expansion module expands the query vector of the defect report to be located using historically fixed defect data, resulting in an expanded query vector. Specifically, the module fuses the original query embedding vector with the expanded vector corresponding to the code elements extracted from historically fixed defects, generating a unified expanded query vector. In some embodiments, the vector fusion process can be implemented in various ways. For example, vector concatenation can be used to concatenate the original query vector and the expanded vector in terms of dimensions; or a weighted summation method can be used to assign different weights to the expanded vector based on the similarity between historical and new defects. Through this vector fusion, the expanded query vector not only includes the surface semantics of the new defect report but also incorporates the deeper remediation context of historically similar defects.

[0046] The defect localization module is used to locate defects based on the similarity between the expanded query vector and the source code, generating a list of suspicious code elements. Specifically, the defect localization module calculates the similarity between the source code (which has been converted into source file code vectors by the preprocessing and word embedding modules) and the expanded query vector. In some embodiments, the similarity calculation can use metrics such as cosine similarity, Euclidean distance, or Manhattan distance. After calculation, the defect localization module sorts the similarities from high to low, generating a list of suspicious code elements. This list shows maintenance personnel the ranking of source files or code snippets most likely to contain defects. Maintenance personnel can check each element in the order of this list, thereby greatly narrowing the search scope.

[0047] All embodiments described above are not limited to the illustrated embodiments and can, of course, be combined with each other. Although the present invention has been described with reference to the embodiments shown in the accompanying drawings, these are merely exemplary, and those skilled in the art will understand that various modifications and equivalent embodiments can be made therefrom.

Claims

1. A defect localization method based on historical defect data query expansion, characterized in that, The method includes: S1. Obtain the project source code and historical defect reports from the version control system and defect tracking system to build the initial dataset; S2. Perform text preprocessing on the initial dataset to obtain the preprocessed dataset; S3. Train a word embedding model using the preprocessed dataset. The word embedding model converts the words in the historical defect reports into word vectors and inputs them into the HAN model. S4. Use the HAN model to identify the symptom category and cause category of the defect report to be located; S5. Obtain relevant historical fixed defect data according to the cause category; S6. Expand the query vector of the defect report to be located using historical repaired defect data to obtain the expanded query vector; S7. The word embedding model uses the similarity between the expanded query vector and the source code to locate defects and generate a list of suspicious code elements.

2. The method of claim 1, wherein, The steps for preprocessing the initial dataset include: Remove historical defect reports and punctuation marks from the project source code; use a code parser to parse the source code into an abstract syntax tree; and use the abstract syntax tree to record the identifiers contained in the source code to generate a set of words representing the source file. Obtain the summary and description portions of the historical defect report, and perform identifier extraction, word segmentation, stop word removal, non-English token filtering, and stemming operations on the historical defect report. Also, split the composite token using camelCase identification.

3. The method of claim 1, wherein, The steps for training a word embedding model using the preprocessed dataset include: The word embedding model is executed in a skip-gram manner, wherein the embedding layer is initialized using an embedding model pre-trained from a full-domain corpus; The preprocessed dataset is used to incrementally train the initialized word embedding model to obtain the Word2vec word embedding model.

4. The method of claim 1, wherein, The steps for identifying the symptom and cause categories of a defect report to be located using the HAN model include: The title and description of the defect report to be located are used as input, and a pre-trained automatic defect symptom classifier is used for identification to obtain the symptom probability vector and cause probability vector of the defect report to be located, and to determine the symptom category and cause category. Each element in the vector represents the predicted probability value of the category corresponding to the defect report to be located.

5. The method of claim 1, wherein, The steps of expanding the query vector of the defect report to be located using historical repaired defect data include: Extract defect report terms and repair code elements from the historical repaired defect data to generate an extended vector; The original word embedding vector of the defect report to be located is fused with the extended vector to generate an extended query vector with a unified representation.

6. A defect location system based on historical defect data query and expansion, characterized in that, include: The dataset building module is used to obtain project source code and historical defect reports from version control systems and defect tracking systems to build the initial dataset; The preprocessing module is used to perform text preprocessing on the initial dataset to obtain a preprocessed dataset; The word embedding training module is used to train a word embedding model using a preprocessed dataset. The word embedding model converts words in historical defect reports into word vectors and inputs them into the HAN model. The cause identification and classification module is used to identify the symptom category and cause category of the defect report to be located using the HAN model; The historical related defect acquisition module is used to acquire relevant historical fixed defect data according to the cause category. The query expansion module is used to expand the query vector of the defect report to be located using historical repaired defect data, so as to obtain the expanded query vector. The defect localization module is used to locate defects by comparing the similarity between the expanded query vector and the source code, and generate a list of suspicious code elements.

7. The system according to claim 6, characterized in that, The preprocessing module is specifically used to: delete historical defect reports and punctuation marks in the project source code, use a code parser to parse the source code into an abstract syntax tree, and record the identifiers contained in the source code through the abstract syntax tree to generate a set of words representing the source file; Obtain the summary and description portions of the historical defect report, and perform identifier extraction, word segmentation, stop word removal, non-English token filtering, and stemming operations on the historical defect report. Also, split the composite token using camelCase identification.

8. The system according to claim 6, characterized in that, The word embedding training module is specifically used for: executing the word embedding model in a skip-gram manner, wherein the embedding layer is initialized using an embedding model pre-trained from a full-domain corpus; and incrementally training the initialized word embedding model using the preprocessed dataset to obtain the Word2vec word embedding model.

9. The system according to claim 6, characterized in that, The cause identification and classification module is specifically used to: take the title and description of the defect report to be located as input, use a pre-trained automatic defect symptom classifier for identification, obtain the symptom probability vector and cause probability vector of the defect report to be located, and determine the symptom category and cause category; wherein, each element in the vector represents the predicted probability value of the category corresponding to the defect report to be located.

10. The system according to claim 6, characterized in that, The query expansion module is specifically used to: extract defect report terms and repair code elements from the historical repaired defect data to generate an expansion vector; and perform vector fusion between the original word embedding vector of the defect report to be located and the expansion vector to generate an expanded query vector with a unified representation.

Images