Large model driven software defect multi-dimensional intelligent detection method and device

Abstract

This invention discloses a large-model-driven multi-dimensional intelligent detection method and apparatus for software defects, belonging to the field of artificial intelligence software testing technology. It includes generating abstract syntax trees, control flow graphs, and data flow graphs from source code through static analysis, and matching and filtering relevant historical defect knowledge. By combining multi-dimensional code representation with historical knowledge, a multi-level prompt input pre-trained large language model is constructed to generate an initial draft report containing the location, type, and context of potential defects. A strategy consisting of dynamic symbolic execution path verification, historical defect pattern matching verification, and code change impact scope verification is employed to verify the authenticity and prioritize the draft report, outputting the final report. This method can deeply understand code semantics and combine historical experience, improving the accuracy of defect detection and effectively reducing false positives through multi-source verification.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence software testing technology, specifically a method and device for multi-dimensional intelligent detection of software defects driven by a large model. Background Technology

[0002] Current software defect detection primarily relies on static analysis tools, dynamic testing, and traditional machine learning-based methods. Static analysis tools scan code based on predefined rules, quickly identifying coding style issues; however, their rule bases are difficult to maintain, and they struggle to identify logical defects requiring complex semantic understanding. Machine learning-based detection methods learn patterns from historical data through feature engineering, but their performance heavily depends on feature quality, lacks depth in capturing deep semantics and contextual information, and has limited generalization ability. Large language models have been introduced into code analysis tasks, capable of understanding the natural language semantics of code, providing a new approach to defect detection. However, directly inputting code snippets into general-purpose large models results in a lack of in-depth understanding of program structure, data dependencies, and other professional knowledge, and fails to effectively utilize project-specific historical defect experience, leading to low accuracy and high false positive rates in generated defect reports.

[0003] The key to improving detection accuracy lies in organically combining a program's static structural information, dynamic behavioral characteristics, and domain history knowledge to form a comprehensive input that the model can deeply understand. Meanwhile, the defect guesses generated by large language models contain uncertainties. Designing an effective automatic verification mechanism to cross-validate and assess the credibility of preliminary results is another core challenge in ensuring report reliability and guiding the efficient allocation of testing resources. Existing technologies struggle to systematically integrate this heterogeneous information and implement closed-loop verification. Summary of the Invention

[0004] This invention aims to solve at least one of the technical problems existing in the prior art; To this end, this invention proposes a large-model-driven multi-dimensional intelligent detection method for software defects, including: Perform static analysis on the software source code to generate a set of abstract syntax trees, control flow graphs, and data flow graphs for the software source code; Receive historical software defect data records provided by an external database, and match and filter the historical software defect data records based on the file path and structure information of the software source code to form a set of historical defect knowledge related to the current software source code; Using the abstract syntax tree, control flow graph, and data flow graph set as input, and combining the historical defect knowledge set, a multi-level code semantic understanding prompt is constructed in the context window of the pre-trained large language model. The pre-trained large language model is used to process the multi-level code semantic understanding prompts to generate an initial draft defect report containing the potential defect location, defect type, and defect generation context. The initial defect report draft is verified for authenticity and prioritized using a multi-dimensional verification strategy, which includes dynamic symbolic execution path verification, historical defect pattern matching degree verification, and code change impact scope verification. Output the final software defect detection report after processing by the multi-dimensional verification strategy.

[0005] Furthermore, the matching and filtering of the historical software defect data records includes: Parse the software's historical defect data records and extract the source code file path, function signature, and defect-introducing code submission identifier associated with each historical defect record; Extract the signatures of all function definitions and their file paths from the currently analyzed software source code; Based on the function signature similarity algorithm, the similarity between each function signature in the current software source code and the function signature associated with the software's historical defect records is calculated. If the similarity of the function signature exceeds a preset threshold and the file path contains the function, then the software history defect record is determined to be related to the current function and is included in the history defect knowledge set.

[0006] Furthermore, the construction of multi-level code semantic understanding prompts includes: The multi-level code semantic understanding prompts include code structure description, control logic description, data dependency description, and associated historical defect pattern description; The structured hierarchical information, key node types, and variable declaration information of code blocks are extracted from the abstract syntax tree to form the code structure description; The branch decision conditions, loop structures, and jump relationships between basic blocks are extracted from the control flow graph to form the control logic description. The definitions, uses, and propagation chains of variables are extracted from the data flow graph to form the data dependency description; From the historical defect knowledge set, extract historical defect pattern descriptions related to the current analysis code. The historical defect pattern descriptions include defect code snippets, defect fix patches, and defect triggering conditions. According to the predefined template, the code structure description, control logic description, data dependency description, and associated historical defect pattern description are organized into a structured natural language sequence to form the multi-level code semantic understanding prompt.

[0007] Furthermore, the process of using the pre-trained large language model to handle the multi-level code semantic understanding prompts includes: The multi-level code semantic understanding prompts are used as input text sequences and fed into the pre-trained large language model; Activate the code understanding-specific adaptation layer in the pre-trained large language model. The code understanding-specific adaptation layer is obtained by fine-tuning the parameters using code corpus and defect repair on the basis of the general large language model. The autoregressive text generation mechanism of the pre-trained large language model generates coherent text containing code location markers, which is the initial defect report draft. The code location markers are used to indicate the specific line number or code block range of the potential defect in the source code.

[0008] Furthermore, the dynamic symbol execution path verification includes: Parse the code path conditions corresponding to the potential defect locations from the initial defect report draft; Using the code path conditions as the starting point of the constraint, the dynamic symbolic execution engine is started to perform symbolic execution on the relevant code paths; During symbolic execution, path constraints are collected, and an attempt is made to solve the path constraints using a constraint solver. If the path constraint is solvable, it proves that there is a reachable code execution path at the potential defect location, and the verification result confirms that the defect actually exists; otherwise, it is marked as an unreachable path warning.

[0009] Furthermore, the historical defect pattern matching degree verification includes: From the historical defect knowledge set, select known defect patterns that are the same type as the defect in the initial defect report draft; Calculate the semantic similarity between the defect context described in the initial defect report draft and the defect context of each selected known defect pattern; If the semantic similarity of a known defect pattern exceeds a preset matching threshold, the defect report is given a higher confidence level of authenticity, and the repair solution of the matched known defect pattern is added to the report as reference information.

[0010] Furthermore, the verification of the scope of impact of the code change includes: Identify the variables, functions, or data structures involved in the potential defect locations in the initial defect report draft; Based on the data flow graph and control flow graph, analyze other code regions affected by the variables, functions or data structures to determine the potential propagation range of the defect; Based on the importance of the code modules covered by the potential propagation scope and whether they involve critical business logic, the severity level of the defects in the initial defect report draft is assigned.

[0011] Furthermore, the multi-dimensional verification strategy for verifying the authenticity and prioritizing the initial defect report draft includes: Set path reachability weights for the verification results of the path verification of the dynamic symbol; Set pattern matching weights for the verification results of the historical defect pattern matching verification; Set an impact severity weight for the verification results of the scope of impact verification of the code change; The priority score of each initial defect report draft is calculated by multiplying its path reachability, pattern matching degree, and impact severity level by their respective weights and then summing them by weight. All verified defect reports are sorted in descending order according to the priority scores to generate a sorted defect list, which is then integrated into the final software defect detection report.

[0012] Furthermore, the method also includes incremental updates to the historical defect knowledge set: After the final software defect detection report is confirmed and fixed, collect the actual defect information, related code context and its fix patch confirmed in this detection; The actual defect information, related code context, and their fixes are converted into a structured record format. The newly generated structured records are merged with the existing historical defect knowledge set to form an updated historical defect knowledge set, which is used for subsequent defect detection tasks.

[0013] Furthermore, the present invention also includes a large model-driven multi-dimensional intelligent detection device for software defects. The device includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the large model-driven multi-dimensional intelligent detection method for software defects as described above.

[0014] Compared with the prior art, the beneficial effects of the present invention are: By structurally integrating abstract syntax trees, control flow graphs, and data flow graphs with a set of historical defect knowledge for matching, a multi-layered hint system for a large language model is constructed. The model can simultaneously parse the syntactic structure, logical execution flow, and data dependencies of code, and reason by referencing similar historical contexts. This fusion of inputs frees the model from dependence on single code texts or simple features, enabling it to understand code intent and potential anomalies from a multi-dimensional semantic level. This allows for more accurate identification of defects hidden in complex logic and data interactions, especially semantic-level vulnerabilities that are difficult to cover with traditional rules.

[0015] A three-dimensional verification framework comprised of dynamic symbolic execution, historical pattern matching, and change impact analysis is used to cross-validate the initial model report. Dynamic symbolic execution verifies the authenticity of defect triggering conditions from the perspectives of path reachability and constraint satisfaction. Historical defect pattern matching assesses the similarity between current defect characteristics and known problems from a statistical probability perspective. Code change impact analysis evaluates the stability and impact range of defect-related modules from a software evolution perspective. This multi-source evidence weighted evaluation mechanism can filter out false alarms caused by model illusions or insufficient context, and comprehensively quantifies the urgency of defects based on path feasibility, historical recurrence probability, and impact range coefficient, achieving automatic credibility classification and priority ranking of detection results. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the steps of the large model-driven multi-dimensional intelligent detection method for software defects described in this invention. Figure 2 A flowchart for matching and filtering historical software defect data records; Figure 3 A flowchart for constructing multi-level code semantic understanding prompts; Figure 4 A bar chart showing the semantic similarity distribution of defect types; Figure 5 A trend analysis chart for incremental updates of historical defect knowledge sets. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0018] See Figure 1The system performs static analysis on the software source code, generating an abstract syntax tree, control flow graph, and data flow graph set. It receives historical defect data records from an external database and matches and filters these records based on the file paths and structure information of the current software source code, forming a historical defect knowledge set related to the current source code. Using the abstract syntax tree, control flow graph, and data flow graph set as input, and combining them with the historical defect knowledge set, it constructs multi-level code semantic understanding prompts within the context window of a pre-trained large language model. This pre-trained large language model processes the multi-level code semantic understanding prompts, generating an initial defect report draft containing the potential defect location, defect type, and defect generation context. A multi-dimensional verification strategy is employed to verify the authenticity and prioritize the initial defect report draft. This strategy includes dynamic symbolic execution path verification, historical defect pattern matching degree verification, and code change impact scope verification. The final software defect detection report, processed by the multi-dimensional verification strategy, is output.

[0019] See Figure 2In one embodiment of the present invention, parsing historical software defect data records involves reading records stored in an external database. The external database stores each historical defect record in a specific format, where the associated source code file path is the complete path of the file within the version control system, the function signature includes the function name, parameter list, and return value type, and the defect-introducing code commit identifier is the commit hash value within the version control system. The signatures of all function definitions and their corresponding file paths are extracted from the currently analyzed software source code. This process is accomplished by traversing the abstract syntax tree of the software source code. Each function definition node in the abstract syntax tree contains the function name, parameter list, return type, and its location information within the source code file. This information is extracted and organized into structured function signature entries. A function signature similarity algorithm is used to calculate the similarity between each function signature in the current software source code and the function signatures associated with the historical software defect records. The function signature similarity algorithm comprehensively compares the function name, parameter type sequence, and return value type, generating a quantified similarity score. The preset threshold is a value between zero and one. The file path inclusion relationship refers to the file path where the currently analyzed function is located, and whether there is a prefix match or subdirectory relationship between the source code file path associated with the historical defect records. In practical implementation, the logic for determining the relevance of historical software defect records to the current function is as follows: only when the function signature similarity score is higher than a preset threshold, and the file path of the current function is a subpath of the file path associated with the historical defect record, or both are identical, will this historical defect record be included in the historical defect knowledge set constructed for the current function. In practice, matching historical software defect records are included in the historical defect knowledge set. Each record in the set fully retains the original historical defect record information, including defective code snippets, fixes, and defect triggering conditions. An optional calculation formula for the function signature similarity algorithm is: in; This represents the final calculated similarity of the function signatures. The similarity score represents the function names. The similarity score represents the list of parameters. The similarity score represents the return value type. It is the weighting coefficient of the function name similarity score. These are the weighting coefficients for the parameter list similarity score. It is the weighting coefficient of the return value type similarity score. , , All are non-negative real numbers, and satisfy the following conditions: The relationship is as follows. In some embodiments, the similarity score of function names is calculated using the edit distance algorithm, which normalizes the function name strings to lowercase before comparison. Calculating the similarity score of parameter lists requires comparing the parameter type sequence item by item, taking into account both the number and order of parameters. Calculating the similarity score of return value types directly compares whether the return type identifiers are completely identical. It is understood that the specific weight coefficients of the function signature similarity algorithm can be adjusted according to the characteristics of different programming languages. In some embodiments, for object-oriented programming languages, the function signature similarity algorithm also considers the class name or namespace prefix when comparing function names, and performs more complex type inheritance relationship matching when comparing parameter lists. Optionally, the judgment of file path inclusion relationship not only checks the direct file path string prefix matching, but also parses the directory separator in the path to ensure that the path inclusion relationship is a logical directory inclusion rather than a random string match. Optionally, the function signature can be standardized before similarity calculation, removing irrelevant spaces and comments, so that the comparison process focuses on the consistency of semantic structure. It is understandable that standardized function signatures can reduce misjudgments of similarity due to differences in writing, thereby making the matching and filtering more closely resemble the actual code structure.

[0020] See Figure 3In one embodiment of the present invention, the process of constructing multi-level code semantic understanding prompts involves the generation and integration of multiple descriptive parts. These multi-level code semantic understanding prompts include code structure descriptions, control logic descriptions, data dependency descriptions, and descriptions of associated historical defect patterns. The structured hierarchical information, key node types, and variable declaration information of code blocks are extracted from the abstract syntax tree to constitute the code structure description. For example, for a source code containing function definitions and conditional statements, the abstract syntax tree parser traverses the tree nodes, identifies function declaration nodes, parameter list nodes, compound statement nodes, and conditional expression nodes, and converts the type, hierarchical relationship, and attribute information of these nodes into descriptive paragraphs in text form. In a specific implementation, branch judgment conditions, loop structures, and jump relationships between basic blocks are extracted from the control flow graph to constitute the control logic description. The control flow graph decomposes the code into basic blocks and connects them with directed edges. The analysis tool traverses the edges and nodes in the graph, extracting the predicate expression of each conditional branch, the entry and exit conditions of the loop, and the control transfer logic between blocks, forming a descriptive description of the program execution flow. In practical implementation, the definition, usage, and propagation chains of variables are extracted from the data flow graph to form a data dependency description. The data flow graph tracks the state changes of variables between program points. For each variable, its definition and usage points are marked, and a definition-use chain is established. This chain information is combined with the variable type to generate text describing how data flows between different code parts. In practical implementation, historical defect pattern descriptions related to the currently analyzed code are extracted from the historical defect knowledge set. These historical defect pattern descriptions include defective code snippets, defect fix patches, and defect triggering conditions. The matching process is based on function signatures and path filtering results. All related records are retrieved from the historical defect knowledge set, and then the defect context and fix information stored in these records are extracted. The code structure description, control logic description, data dependency description, and associated historical defect pattern description are organized into a structured natural language sequence according to a predefined template. An optional template formula is expressed as: in: This represents the final generated multi-level code semantic understanding hint text sequence. Represents a predefined template function. Text representing the code structure description. Text representing the control logic description. The data depends on the descriptive text. Represents the text describing the associated historical defect patterns, template function The specific implementation involves concatenating four descriptive texts into a coherent natural language paragraph in a fixed order and using delimiters.

[0021] In some embodiments, when extracting key node types from the abstract syntax tree, special attention is paid to node types that may cause defects, such as null pointer dereferencing, array access, or resource allocation points, and the location information of these nodes in the code is also embedded in the code structure description. It can be understood that the code structure description focuses on the static syntactic view of the code, the control logic description focuses on the dynamic view of the execution path, the data dependency description focuses on the value flow view, and the historical defect pattern description provides a contextual risk view. Their combination provides multi-dimensional semantic information for subsequent model analysis. The implementation of using a pre-trained large language model to process multi-level code semantic understanding prompts includes feeding multi-level code semantic understanding prompts as input text sequences into the pre-trained large language model. The input text sequences are converted into token ID sequences by the model's tokenizer, and necessary sequence start and end markers are added. A code understanding-specific adapter layer in the pre-trained large language model is activated. This code understanding-specific adapter layer is obtained by fine-tuning parameters using code corpora and defect repair pairs on the basis of the general large language model. This adapter layer is typically inserted between the original model layers in the form of LoRA or adapter modules. When processing the input sequence, the parameters of the adapter layer are loaded and participate in the forward computation. A pre-trained large language model employs an autoregressive text generation mechanism to generate coherent text containing code location markers. Autoregressive generation is conditional on input prompts, predicting subsequent sequences token-by-token until a specific token indicating the end is generated or the maximum length is reached. The generated text constitutes the initial draft defect report. In practice, code location markers are embedded in the generated text in a specific format to indicate the specific line number or code block range of a potential defect in the source code. Optionally, the fine-tuning data for the code understanding-specific adaptation layer includes code snippets collected from open-source code repositories and their corresponding defect fix submissions. This data is constructed into prompt-response pairs to train the model to learn code defect patterns. Optionally, after generating the initial draft defect report, the draft undergoes post-processing to extract structured defect entries, such as using regular expressions to match code location markers and parsing the descriptive text into defect type and context fields. It can be understood that the autoregressive text generation mechanism allows the model to generate coherent analytical text based on rich prompt context, and the introduction of code location markers enables precise tracing of defect locations, providing explicit input for subsequent validation steps.

[0022] In one embodiment of the invention, code path conditions corresponding to potential defect locations are parsed from an initial defect report draft. The initial defect report draft contains a description of the potential defect in natural language text, explicitly indicating the program state or code branch required to trigger the defect. The parsing process identifies conditional expressions by searching for keywords and pattern matches in the text. For example, if the initial defect report draft states "the defect occurs when variable x is negative," the parsing engine extracts the logical condition "x<0" as a code path condition. In a specific implementation, the code path condition is used as the starting point for constraints, and a dynamic symbolic execution engine is started. The dynamic symbolic execution engine loads the software source code to be analyzed and transforms the parsed code path conditions into initial path constraints in the symbolic execution state. For example, "x<0" is transformed into a constraint expression for the symbolic variable x and added to the constraint set of the constraint solver. In a specific implementation, the relevant code paths are symbolically executed. The dynamic symbolic execution engine starts from the code location containing the initial constraints, explores possible execution paths along the control flow graph, replaces specific input values ​​in the program with symbolic values, and executes each instruction symbolically, while recording the path constraint conditions accumulated during execution. In practice, path constraints are collected and attempted to be solved using a constraint solver. Path constraints are the logical conjunction of all branch conditions encountered during symbolic execution. The dynamic symbolic execution engine combines all accumulated conditions into a satisfiability modular theory formula and calls the backend constraint solver to solve this formula. The solvability determination of path constraints can be illustrated using a formalized representation: the path constraint formula. This can be defined as the conjunction of branch conditions: in: This represents a logical conjunction of all path constraints collected from the program entry point to potential defect points. The first symbol encountered during execution The logical expressions corresponding to each branch condition. Represents the total number of branch conditions encountered on the path from the starting point to the defect point, with the symbol […]. This represents a logical AND operation. If the constraint solver can assign values ​​to a set of valid, specific input values ​​such that the path constraint formula... If the path constraint is true, it proves that the path constraint is solvable. If the path constraint is solvable, it proves that there is a reachable code execution path to the potential defect location. The verification result confirms the existence of the defect, and the dynamic symbolic execution engine generates a specific test input case that enables the driver to actually execute to the defect point. If the path constraint is unsolvable, it is marked as an unreachable path warning, meaning that under the current program logic and initial constraints, there is no input that can cause the program to execute to the defect location indicated in the report. In some embodiments, the dynamic symbolic execution engine handles complex data structures during symbolic execution, such as modeling arrays and pointers as symbolic expressions to collect path constraints more accurately. In some embodiments, solving path constraints may involve nonlinear arithmetic or theoretical combinations, and the constraint solver selects the appropriate solution strategy based on the theory appearing in the formula. Optionally, when code path conditions involve external function calls or system environment interactions, the dynamic symbolic execution engine uses stub functions or models to simulate the behavior of these calls in order to continue collecting meaningful path constraints. Optionally, for unsolvable path constraints, the dynamic symbolic execution engine records the specific conditional branches that cause the constraint conflict and adds this information as contextual feedback to the unreachable path warning.

[0023] In one embodiment of the present invention, known defect patterns with the same defect type as those in the initial defect report draft are selected from a historical defect knowledge set. Each record in the historical defect knowledge set contains a defect type field, such as "null pointer dereference," "buffer overflow," or "resource leak." The initial defect report draft is also tagged with one or more defect types during generation. The selection process is completed through exact matching or hierarchical matching based on a predefined classification system. Records in the historical defect knowledge set whose defect type fields are the same as those in the current initial defect report draft are extracted to form a candidate known defect pattern set. The semantic similarity between the defect context described in the initial defect report draft and the defect context of each selected known defect pattern is calculated. The defect context includes code snippets, variable names, function calls, and natural language descriptions of the problem phenomenon near the defect location. The semantic similarity calculation first converts the two defect context texts into high-dimensional vector representations through a text embedding model, and then calculates the cosine similarity between the two vectors as the quantified value of the semantic similarity. A specific semantic similarity calculation formula can be expressed as: in: Defect context representing the initial defect report draft Defect context with a known defect pattern Semantic similarity score between them Defect context Vector representation obtained through text embedding model Defect context Vector representation obtained through text embedding model, symbols This represents the dot product operation of vectors. Representative vector The length of the mold, Representative vector The modulus length, calculation results `src` is a real number in the range [-1, 1], with values ​​closer to 1 indicating greater semantic similarity. The preset matching threshold is a configurable scalar value between 0 and 1. If the semantic similarity of a known defect pattern exceeds the preset matching threshold, the defect report is given a higher confidence level, and the remediation plan for the matched known defect pattern is appended to the report as reference information. In practice, all historical defect pattern records with similarity exceeding the preset matching threshold are sorted from highest to lowest similarity, and the remediation plans for one or more records with the highest ranking are extracted and appended to the end of the initial defect report draft in a structured manner for developers' reference. In some embodiments, the text embedding model uses a pre-trained model based on the Transformer architecture, which is fine-tuned on a mixed corpus of code and natural language to better understand code semantics. Optionally, when calculating semantic similarity, in addition to the overall context vector, a tree structure comparison is performed separately on the abstract syntax tree of the defect code fragment to obtain a structural similarity score. This score is then weighted and fused with the text vector similarity score to form the final semantic similarity. Optionally, for a comparison of specific data on historical defect pattern matching, please refer to Table 1: Table 1: Historical Defect Pattern Matching Verification Table In practice, the first step in verifying the scope of code change impact is to identify the variables, functions, or data structures involved in potential defect locations in the initial defect report draft. This is achieved by parsing the defect code locations marked in the initial defect report draft and indexing them into the abstract syntax tree of the software source code. This extracts all referenced or defined variable names, called function names, and accessed data structure names at that location, forming a set of code elements to be analyzed. Data flow graphs and control flow graphs are then used to analyze other code regions affected by the variables, functions, or data structures to determine the potential propagation range of the defect. Data flow graphs provide variable definition-use chains; starting from the variable involved in the defect point, all code locations directly or indirectly dependent on that variable can be found along the backward and forward slices of the data flow graph. Control flow graphs help analyze the potential impact range of the basic blocks containing these code locations in the program control flow, such as all statements under the same conditional branch or all iterations within the same loop body. The results of data flow analysis and control flow analysis are combined to obtain a set of source code lines or basic blocks that may be affected by the defect. Based on the importance of the code modules covered by the potential propagation scope and whether they involve critical business logic, the defect items in the initial defect report draft are assigned an impact severity level. The importance of the code modules is specified by a predefined module configuration file, which assigns importance weights to source code directories or modules. Critical business logic is identified by specific tags in the project architecture document or code annotations. The analysis process calculates the sum of the importance weights of the modules to which the affected lines of code belong, and combines this with the presence of critical business logic tags, mapping them to discrete impact severity levels through a predefined mapping rule.

[0024] In practical implementation, an example of a mapping rule for impact severity levels is as follows: if the potential propagation scope involves any code marked as critical business logic, the level is directly set to "high"; if it does not involve critical business logic, the weighted number of lines in the affected module is calculated; if it exceeds the threshold TH1, it is "high"; if it exceeds the threshold TH2 but is below TH1, it is "medium"; otherwise, it is "low". It can be understood that analysis based on data flow diagrams and control flow diagrams can objectively assess the potential cascading effects of a defect from the perspective of program dependencies. It can also be understood that combining module importance and critical business logic markings to assign impact severity levels allows the priority ranking to reflect the potential risks of defects at the business level. Optionally, when analyzing the potential propagation scope of a defect, if the involved variables have global scope or are frequently called public interface parameters, the analysis process will recursively trace their impact until a preset analysis depth is reached or all related compilation units are covered. Optionally, the importance weight of module configuration files can be dynamically adjusted based on the modification frequency of the code module, test coverage, or the number of historical failures, so that the assessment of impact severity levels better reflects the actual situation of the project.

[0025] See Figure 4 This is a bar chart showing the semantic similarity distribution of defect types, used to present the matching effect between different defect types and historical defect patterns in large-model-driven software defect detection. It visually demonstrates the high similarity between defect types such as "null pointer dereference" and "resource leak" and historical patterns, allowing for the direct reuse of mature remediation solutions and significantly shortening the defect remediation cycle. For defects such as "buffer overflow" and "logic error" with average similarity below the threshold, it suggests that teams need to add verification steps such as dynamic symbolic execution and manual code auditing to avoid misjudgments caused by over-reliance on historical experience. For highly similar defects, developers can directly refer to historical remediation solutions without starting from scratch, reducing the average remediation time by 30%-50%. By quantifying similarity scores, teams can avoid repeatedly verifying highly matched defects, focusing resources on analyzing low-match, high-risk defects and optimizing test resource allocation.

[0026] In one embodiment of the present invention, a path reachability weight is set for the verification result of dynamic symbolic execution path verification. The path reachability weight is a numerical measure assigned to the reachability conclusion output by the dynamic symbolic execution path verification. When the result of the dynamic symbolic execution path verification confirms the existence of a defect, the corresponding path reachability index is a positive number; when the result is an unreachable path warning, the index is zero or a low positive number. The path reachability weight, as a component weight in the multi-dimensional verification strategy, is used to adjust the contribution of path reachability to the defect reporting priority in subsequent weighted calculations. In a specific implementation, a pattern matching weight is set for the verification result of historical defect pattern matching verification. The pattern matching weight is determined based on the semantic similarity score obtained from historical defect pattern matching verification. When historical defect pattern matching verification finds that the semantic similarity of a known defect pattern exceeds a preset matching threshold, the verification result receives a higher pattern matching weight; otherwise, it receives a lower pattern matching weight. The pattern matching weight in the multi-dimensional verification strategy reflects the strength of the influence of the similarity between the known defect pattern and the current defect on the priority. In practical implementation, impact severity weights are assigned to the verification results of the code change impact scope verification. These impact severity weights correspond to the impact severity levels assigned in the code change impact scope verification, with different levels mapping to different numerical weights. For example, a high impact severity level is assigned a larger weight, a medium level a medium weight, and a low level a smaller weight. In the multi-dimensional verification strategy, the impact severity weights reflect the business importance of the defect's impact scope on priority. In practice, the path reachability, pattern matching degree, and impact severity level corresponding to each initial draft defect report are multiplied by their respective weights and then weighted and summed to calculate the priority score of the defect report. The priority score can be expressed by the formula: in: The priority score represents the defect report. Represents the path reachability weight. Numerical metrics representing path reachability verification results Represents the pattern matching weight. A numerical metric representing the pattern matching verification result. The weight represents the severity of the impact. Numerical indicators representing the severity levels of impact are used, with each weight being a positive real number. These numerical indicators are mapped from the corresponding verification results. All verified defect reports are sorted in descending order according to priority scores, generating a sorted defect list, which is then integrated into the final software defect detection report. The sorting process compares the priority scores of each defect report, placing those with higher scores at the top of the list, forming a descending order. The final software defect detection report structurally includes the sorted defect list, as well as the location, type, verification results, and reference information for each defect. In some embodiments, the path reachability weight is set in conjunction with the project's test coverage strategy. For code areas that are difficult to reach through testing, the path reachability weight can be appropriately increased to strengthen the role of reachability verification. In some embodiments, the pattern matching weight can be dynamically adjusted according to the distribution characteristics of defect types. For defect types that have historically recurred frequently, the pattern matching weight can be increased to highlight the value of known pattern references. Optionally, the impact severity weight can be set according to different project stages. For example, in the pre-release stage, the impact severity weight of defects involving critical business logic can be increased to prioritize high-risk items. Optionally, the mapping rules for numerical indicators can uniformly adopt linear proportions or piecewise functions to ensure comparability and computational simplicity between different verification dimensions. It can be understood that a reasonable configuration of path reachability weights, pattern matching weights, and impact severity weights enables the multi-dimensional verification strategy to reflect the technical reachability, historical pattern correlation, and business impact scope of defects in a balanced manner during priority calculation. It can also be understood that the weighted summation calculation method integrates the verification results of the three dimensions into a single ranking criterion, allowing the final software defect detection report to directly present the sequence of defects requiring priority processing.

[0027] In practice, incremental updates to the historical defect knowledge set are performed after the final software defect detection report is confirmed and fixed. The confirmation and fix process is completed by development or quality assurance personnel based on the defect location and description given in the final software defect detection report. Relevant personnel will submit commit records containing defect fixes in the version control system. The process involves collecting the actual defect information, related code context, and their fix patches confirmed in this detection. The actual defect information includes the defect type, defect location, and triggering conditions. The related code context is code text extracted from the software source code containing several lines before and after the defect location. The fix patches are code changes recorded in a difference format. The actual defect information, related code context, and fix patches are converted into a structured record format. The structured record format specifies field names and data types; for example, the defect type field is a string, the defect location field is a file path plus line number range, the code context field is a string, and the fix patch field is a string. During the conversion process, the collected unstructured or semi-structured content is filled into the corresponding fields to generate a single record. The newly generated structured records are merged with the existing historical defect knowledge set to form an updated historical defect knowledge set. The fusion operation appends the new records to the data storage structure of the original set and maintains the unique identifier of each record to avoid duplication. The updated historical defect knowledge set can be retrieved and matched in subsequent defect detection tasks, serving as a reference basis to enhance the verification of historical defect pattern matching.

[0028] In some embodiments, the structured record format can be expanded to include the defect discovery time, detection tool version, and fix submission identifier to trace the defect lifecycle in subsequent analysis. In some embodiments, the fusion process establishes an index structure for the historical defect knowledge set, such as an inverted index based on function signatures and file paths, to improve the efficiency of subsequent matching and filtering. Optionally, code context and fix patches can be normalized during the transformation of structured records, removing whitespace characters and comments unrelated to defects, making the records more compact and easier to compare. Optionally, a consistency check of the historical defect knowledge set can be triggered after fusion to check the integrity of record fields and unique identifier conflicts, ensuring that the set remains reliable in subsequent use. It can be understood that the incremental update mechanism enables the historical defect knowledge set to continuously expand as the project evolves, maintaining its relevance to the current code base.

[0029] See Figure 5This is a trend analysis chart of the incremental updates to the historical defect knowledge set, intuitively reflecting the relationship between defect record accumulation and indexing efficiency. The continuously increasing cumulative number of records proves that the defect detection system has the ability to effectively accumulate experience, forming a reusable defect knowledge base. The steady improvement in index matching efficiency directly reduces the time cost of subsequent defect detection and improves overall detection efficiency. Fluctuations in the number of newly added defect records can help determine the project iteration rhythm; for example, the peak in June can serve as a reference for pre-release risk warnings. By tracking the growth of the cumulative number of defect records, the achievements of the technical team in defect governance can be quantified, providing data support for subsequent algorithm optimization and model iteration. Combining the growth trend of defect records with indexing efficiency can help evaluate the input-output ratio of defect detection at different stages, providing data support for weight configuration in subsequent multi-dimensional verification strategies.

[0030] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A large-model-driven multi-dimensional intelligent detection method for software defects, characterized in that, The method includes: Perform static analysis on the software source code to generate an abstract syntax tree, control flow graph, and data flow graph set of the software source code; Receive historical software defect data records provided by an external database, and match and filter the historical software defect data records based on the file path and structure information of the software source code to form a set of historical defect knowledge related to the current software source code; Using the abstract syntax tree, control flow graph, and data flow graph set as input, and combining the historical defect knowledge set, a multi-level code semantic understanding prompt is constructed in the context window of the pre-trained large language model. The pre-trained large language model is used to process the multi-level code semantic understanding prompts to generate an initial draft defect report containing the potential defect location, defect type, and defect generation context. The initial defect report draft is verified for authenticity and prioritized using a multi-dimensional verification strategy, which includes dynamic symbolic execution path verification, historical defect pattern matching degree verification, and code change impact scope verification. Output the final software defect detection report after processing by the multi-dimensional verification strategy.

2. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The process of matching and filtering the historical software defect data records includes: Parse the software's historical defect data records and extract the source code file path, function signature, and defect-introducing code submission identifier associated with each historical defect record; Extract the signatures of all function definitions and their file paths from the currently analyzed software source code; Based on the function signature similarity algorithm, the similarity between each function signature in the current software source code and the function signature associated with the software's historical defect records is calculated. If the similarity of the function signature exceeds a preset threshold and the file path contains the function, then the software history defect record is determined to be related to the current function and is included in the history defect knowledge set.

3. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 2, characterized in that, The construction of multi-level code semantic understanding prompts includes: The multi-level code semantic understanding prompts include code structure description, control logic description, data dependency description, and associated historical defect pattern description; The structured hierarchical information, key node types, and variable declaration information of code blocks are extracted from the abstract syntax tree to form the code structure description; The branch decision conditions, loop structures, and jump relationships between basic blocks are extracted from the control flow graph to form the control logic description. The definitions, uses, and propagation chains of variables are extracted from the data flow graph to form the data dependency description; From the historical defect knowledge set, extract historical defect pattern descriptions related to the current analysis code. The historical defect pattern descriptions include defect code snippets, defect fix patches, and defect triggering conditions. According to the predefined template, the code structure description, control logic description, data dependency description, and associated historical defect pattern description are organized into a structured natural language sequence to form the multi-level code semantic understanding prompt.

4. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 3, characterized in that, The process of using the pre-trained large language model to handle the multi-level code semantic understanding prompts includes: The multi-level code semantic understanding prompts are used as input text sequences and fed into the pre-trained large language model; Activate the code understanding-specific adaptation layer in the pre-trained large language model. The code understanding-specific adaptation layer is obtained by fine-tuning the parameters using code corpus and defect repair on the basis of the general large language model. The autoregressive text generation mechanism of the pre-trained large language model generates coherent text containing code location markers, which is the initial defect report draft. The code location markers are used to indicate the specific line number or code block range of the potential defect in the source code.

5. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The dynamic symbol execution path verification includes: Parse the code path conditions corresponding to the potential defect locations from the initial defect report draft; Using the code path conditions as the starting point of the constraints, the dynamic symbolic execution engine is started to perform symbolic execution on the relevant code paths; During symbolic execution, path constraints are collected, and an attempt is made to solve the path constraints using a constraint solver. If the path constraint is solvable, it proves that there is a reachable code execution path at the potential defect location, and the verification result confirms that the defect actually exists; otherwise, it is marked as an unreachable path warning.

6. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The historical defect pattern matching degree verification includes: From the historical defect knowledge set, select known defect patterns that are the same type as the defect in the initial defect report draft; Calculate the semantic similarity between the defect context described in the initial defect report draft and the defect context of each selected known defect pattern; If the semantic similarity of a known defect pattern exceeds a preset matching threshold, the defect report is given a higher confidence level of authenticity, and the repair solution of the matched known defect pattern is added to the report as reference information.

7. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The verification of the scope of impact of the code change includes: Identify the variables, functions, or data structures involved in the potential defect locations in the initial defect report draft; Based on the data flow graph and control flow graph, analyze other code regions affected by the variables, functions or data structures to determine the potential propagation range of the defect; Based on the importance of the code modules covered by the potential propagation scope and whether they involve critical business logic, the severity level of the defects in the initial defect report draft is assigned.

8. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The multi-dimensional verification strategy for authenticating and prioritizing the draft initial defect report includes: Set path reachability weights for the verification results of the path verification of the dynamic symbol; Set pattern matching weights for the verification results of the historical defect pattern matching verification; Set an impact severity weight for the verification results of the scope of impact verification of the code change; The priority score of each initial defect report draft is calculated by multiplying its path reachability, pattern matching degree, and impact severity level by their respective weights and then summing them by weight. All verified defect reports are sorted in descending order according to the priority scores to generate a sorted defect list, which is then integrated into the final software defect detection report.

9. The large-model-driven multi-dimensional intelligent detection method for software defects as described in claim 1, characterized in that, The method also includes incremental updates to the historical defect knowledge set: After the final software defect detection report is confirmed and fixed, collect the actual defect information, related code context and its fix patch confirmed in this detection; The actual defect information, related code context, and their fixes are converted into a structured record format. The newly generated structured records are merged with the existing historical defect knowledge set to form an updated historical defect knowledge set, which is used for subsequent defect detection tasks.

10. A large-model-driven multi-dimensional intelligent detection device for software defects, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the large model-driven multi-dimensional intelligent detection method for software defects as described in any one of claims 1 to 9.

Images