Application software code defect automatic detection method and system based on artificial intelligence

Abstract

The invention relates to the technical field of artificial intelligence, and discloses an application software code defect automatic detection method and system based on artificial intelligence, and the method comprises the steps: obtaining a source code of to-be-detected application software, and carrying out the deep structure semantic coding of the source code, and obtaining a code semantic feature vector; performing context weight distribution on the code semantic feature vector to obtain weighted context aggregation representation; performing defect feature collaborative analysis on the weighted context aggregation representation to obtain defect types and position information; performing semantic association traversal on the defect type based on a preset defect knowledge graph to obtain an association repair information group; performing logic priority arrangement on the repair strategies in the associated repair information group to obtain a defect repair suggestion sequence; generating a code defect detection report according to the defect type, the position information and the defect repair suggestion sequence; the code defect detection efficiency can be improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an automatic detection method and system for application software code defects based on artificial intelligence. Background Technology

[0002] In the field of application software code defect detection, traditional detection methods rely primarily on manual review. Limited by human resources and varying levels of expertise, this not only results in lengthy detection cycles but also struggles to comprehensively cover potential defects across large-scale codebases. Furthermore, human reviewers often lack the ability to analyze deep logical connections within the code, leading to missed or incorrect detections. This not only prolongs software development cycles and increases the cost of later defect remediation but can also negatively impact the stability and security of the software after deployment due to undetected defects. Overall, the detection effectiveness falls short of the demands of efficient development.

[0003] While some existing automated code defect detection tools can replace manual operations to a certain extent, they still have significant shortcomings. Most of these tools rely solely on preset rules to identify surface-level syntax defects, failing to deeply understand the structural semantics and functional logic of the code, and exhibiting weak ability to identify logical defects at the semantic level. Furthermore, after detection, they typically only output the defect type and location information, lacking a direct matching repair strategy. This requires significant manual effort to search and filter suitable repair solutions, leading to a disconnect between the detection and repair processes. Consequently, they cannot effectively improve the overall efficiency of code defect handling and are ill-suited to the current demands for high efficiency in software development. Therefore, improving the efficiency of code defect detection has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides an automatic detection method and system for application software code defects based on artificial intelligence, in order to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides an automatic detection method for application software code defects based on artificial intelligence, comprising:

[0006] S1. Obtain the source code of the application software to be detected, and perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code;

[0007] S2. Assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector;

[0008] S3. Perform defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation;

[0009] S4. Based on the preset defect knowledge graph, perform semantic association traversal on the defect type to obtain the associated repair information group of the source code;

[0010] S5. Logically prioritize the repair strategies in the associated repair information group to obtain the defect repair suggestion sequence of the source code;

[0011] S6. Generate a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence.

[0012] In a preferred embodiment, the step of acquiring the source code of the application software to be detected and performing deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code includes:

[0013] Perform syntax analysis on the source code to obtain an abstract syntax tree of the source code;

[0014] Perform syntactic topology parsing on the abstract syntax tree to obtain the syntax nodes and syntactic dependencies of the abstract syntax tree;

[0015] The grammar node is semantically embedded to obtain the node semantic vector of the grammar node;

[0016] Based on the syntactic dependencies, the node semantic vectors are aggregated using structure awareness to obtain the code semantic feature vectors of the node semantic vectors.

[0017] In a preferred embodiment, the step of assigning context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector includes:

[0018] The code semantic feature vector is segmented to obtain the context feature fragment of the code semantic feature vector;

[0019] The importance weights of the context feature segments are calculated to obtain the attention weights of the context feature segments. The calculation formula for the attention weights is as follows:

[0020] ;

[0021] In the formula, For the first Attention weights for each context feature segment, The query vector is generated by a linear transformation of the current context feature fragment to be weighted. For the first The key vector of each context feature segment, For the first The key vector of each context feature segment, The total number of the context feature fragments, The relevance score between the query vector and the key vector. It is an exponential function. The exponential operation is performed on the correlation score;

[0022] Based on the attention weights, the context feature segments are weighted and fused to obtain the context-aware features of the context feature segments;

[0023] The context-aware features are fused to obtain a weighted context aggregation table of the code semantic feature vector.

[0024] In a preferred embodiment, the step of weighted fusion of the context feature segments based on the attention weights to obtain the context-aware features of the context feature segments includes:

[0025] Based on the attention weights, the context feature segments are weighted by importance to obtain the importance features of the context feature segments;

[0026] The importance features are reconstructed in feature space to obtain the semantically enhanced features of the context feature fragments;

[0027] The semantic enhancement features are integrated with the context to obtain the context-aware features of the context feature fragment.

[0028] In a preferred embodiment, the step of performing defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation includes:

[0029] The weighted context aggregation representation is deconstructed to obtain the defect feature components of the weighted context aggregation representation;

[0030] The correlation of the defect feature components is compared to obtain the synergistic relationship of the defect feature components;

[0031] Based on the aforementioned collaborative relationship, the defect feature components are comprehensively determined to obtain the defect type and location information represented by the weighted context aggregation.

[0032] In a preferred embodiment, the step of semantically associating the defect types based on a preset defect knowledge graph to obtain the associated repair information group of the source code includes:

[0033] The preset defect knowledge graph is matched with the defect type to obtain the target node of the defect type;

[0034] Perform semantic association edge traversal on the target node to obtain the associated nodes of the target node;

[0035] The associated nodes are repaired and their knowledge is reconstructed to obtain the repair information of the associated nodes;

[0036] The repair information is combined and arranged to obtain the associated repair information group of the source code.

[0037] In a preferred embodiment, the step of performing semantic association edge traversal on the target node to obtain the associated nodes of the target node includes:

[0038] Perform topological analysis on the target node to obtain the semantic relationship edges of the target node;

[0039] Perform multi-hop retrieval on the semantic relationship edges to obtain the potential associated node set of the semantic relationship edges;

[0040] Semantic optimization is performed on the set of potential associated nodes to obtain the associated nodes of the target node.

[0041] In a preferred embodiment, the step of logically prioritizing the repair strategies in the associated repair information group to obtain the defect repair suggestion sequence for the source code includes:

[0042] The urgency of defect repair is assessed for the repair strategies in the associated repair information group to obtain the urgency level of the repair strategies;

[0043] Based on the defect type and the location information, the urgency level is corrected by context association to obtain the priority score of the repair strategy;

[0044] Based on the priority score, the repair strategy is prioritized and scheduled to obtain a sequence of defect repair suggestions for the source code.

[0045] In a preferred embodiment, generating the code defect detection report of the source code based on the defect type, the location information, and the defect repair suggestion sequence includes:

[0046] Heterogeneous data fusion is performed on the defect type, the location information, and the defect repair suggestion sequence to obtain a structured defect data object of the source code;

[0047] The structured defect data object is formatted and encapsulated to obtain a preliminary detection report of the source code;

[0048] The preliminary detection report is enhanced with visualization to obtain the code defect detection report of the source code.

[0049] To address the above problems, the present invention also provides an automatic detection system for application software code defects based on artificial intelligence, the system comprising:

[0050] The source code semantic encoding module is used to acquire the source code of the application software to be detected, and to perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code.

[0051] The context attention aggregation module is used to assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector;

[0052] A multi-feature collaborative defect detection module is used to perform collaborative analysis of defect features on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation;

[0053] The knowledge graph semantic retrieval module is used to perform semantic association traversal on the defect type based on a preset defect knowledge graph to obtain the associated repair information group of the source code;

[0054] The intelligent sorting module for repair strategies is used to logically prioritize the repair strategies in the associated repair information group to obtain a sequence of defect repair suggestions for the source code.

[0055] The automatic report generation module is used to generate a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. This invention performs deep structural semantic encoding on the source code, combined with syntax topology parsing and structure-aware aggregation, to accurately extract complete semantic feature vectors that fit the code logic. Then, through context weight allocation, it strengthens the representation of key features by relying on the attention mechanism. Subsequent defect feature collaborative analysis can accurately identify defect types and locations based on high-quality weighted context aggregation representation, significantly improving the accuracy and comprehensiveness of code defect detection, ensuring the accuracy of defect localization, and reducing detection bias caused by insufficient feature extraction.

[0058] 2. This invention rapidly acquires associated repair information groups based on a defect knowledge graph, generates an ordered sequence of defect repair suggestions through logical priority arrangement, and can automatically integrate defect information and repair suggestions to generate a detection report, achieving efficient connection between detection and repair processes, greatly improving the coherence and efficiency of code defect handling, helping to quickly advance defect repair work, and effectively ensuring the quality and progress of application software development. Attached Figure Description

[0059] Figure 1 A flowchart illustrating an automatic detection method for application software code defects based on artificial intelligence, provided in an embodiment of the present invention;

[0060] Figure 2 A functional block diagram of an application software code defect automatic detection system based on artificial intelligence is provided in an embodiment of the present invention;

[0061] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0062] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0063] This application provides an automatic detection method for application software code defects based on artificial intelligence. The execution subject of this automatic detection method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the automatic detection method for application software code defects based on artificial intelligence can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0064] Reference Figure 1 The diagram shown is a flowchart illustrating an automatic detection method for application software code defects based on artificial intelligence, according to an embodiment of the present invention. In this embodiment, the automatic detection method for application software code defects based on artificial intelligence includes:

[0065] S1. Obtain the source code of the application software to be detected, and perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code;

[0066] In this embodiment of the invention, the step of obtaining the source code of the application software to be detected and performing deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code includes:

[0067] Perform syntax analysis on the source code to obtain an abstract syntax tree of the source code;

[0068] Perform syntactic topology parsing on the abstract syntax tree to obtain the syntax nodes and syntactic dependencies of the abstract syntax tree;

[0069] The grammar node is semantically embedded to obtain the node semantic vector of the grammar node;

[0070] Based on the syntactic dependencies, the node semantic vectors are aggregated using structure awareness to obtain the code semantic feature vectors of the node semantic vectors.

[0071] Specifically, when performing syntax analysis on source code, the process begins by scanning all character sequences line by line according to the fixed syntax rules of the programming language to which the source code belongs. This process accurately identifies basic syntax units such as keywords, identifiers, constants, operators, and delimiters. Then, by comparing the results with the syntax specifications of the programming language, the process determines whether the combination of these basic syntax units conforms to the syntax requirements, thus establishing the overall syntax structure of the source code. Subsequently, this syntax structure is transformed into a tree-like data structure, where each node corresponds to a syntax component of the source code, such as a function definition, variable declaration, or expression. Finally, the abstract syntax tree of the source code is obtained.

[0072] Furthermore, when performing syntactic topology parsing on the abstract syntax tree to obtain syntax nodes, firstly, every node in the abstract syntax tree is fully traversed to ensure that no node in the tree structure is missed; then, based on the syntactic component definition of the programming language to which the source code belongs, the syntactic component type corresponding to each traversed node is determined one by one, such as determining whether the node is a function node, variable node, or loop statement node; through the above operations, the syntactic component type of all nodes is finally determined, and the syntax nodes of the abstract syntax tree are obtained.

[0073] Furthermore, when performing syntactic topology parsing on the abstract syntax tree to obtain syntactic dependencies, the association logic between different nodes is analyzed one by one for the identified syntax nodes. For example, it is analyzed whether the function node calls the variable node and whether the loop statement node contains the condition judgment node. Then, the association logic obtained from these analyses is systematically recorded to ensure that each association is clear and traceable. By recording these association logics, the syntactic dependencies of the abstract syntax tree are finally obtained.

[0074] Furthermore, in the first step of semantic embedding representation of syntax nodes, we first delve into the specific semantic meaning of each syntax node in the source code, such as clarifying the data type of the variable corresponding to the variable node and its scope of action in the code; at the same time, we analyze the actual functional role of the syntax node, such as determining the specific business function implemented by the function node, the meaning of the parameters and the data requirements; through this process, we can fully grasp the semantic and functional information of each syntax node.

[0075] Furthermore, when performing semantic embedding representation on grammatical nodes to obtain node semantic vectors, the semantic and functional information of the grammatical nodes obtained in the previous step is first transformed into a set of numerical values ​​with a fixed order to ensure that each semantic information has a corresponding numerical mapping; then, this set of numerical values ​​is combined into a vector form, which can accurately reflect the unique semantic features of the grammatical nodes; through the above transformation and combination, the node semantic vector of the grammatical nodes is finally obtained.

[0076] Furthermore, in the first step of the structure-aware aggregation of node semantic vectors based on syntactic dependencies, the acquired syntactic dependencies are first examined to identify which node semantic vectors have related relationships. For example, the semantic vectors of all variable nodes that have call dependencies with the same function node are selected. Then, these related node semantic vectors are classified separately to prepare for subsequent integration operations. Through filtering and classification, a set of related node semantic vectors to be integrated is obtained.

[0077] Furthermore, when performing structure-aware aggregation of node semantic vectors based on syntactic dependencies to obtain code semantic feature vectors, the categorized related node semantic vectors are first integrated according to the logical order and degree of association in the syntactic dependencies to ensure that the integration order conforms to the logical structure of the code. During the integration process, the feature information of each node semantic vector itself, as well as the structural association information between different node semantic vectors, are retained simultaneously to avoid the loss of key information. Through integration and information retention, a vector that can comprehensively reflect the overall syntactic structure and semantic information of the source code is finally formed. This vector is the code semantic feature vector of the node semantic vector.

[0078] In summary, the above process starts with the source code of the application software to be tested. First, the source code is transformed into an abstract syntax tree through syntax analysis. Then, operations are carried out around the abstract syntax tree. First, the syntax nodes are parsed to obtain the syntax nodes, and then the syntax dependencies are analyzed to determine them. Next, for the syntax nodes, their semantic and functional information is mined and then transformed into node semantic vectors. After that, based on the syntax dependencies, the node semantic vectors that are classified and associated are first screened and then integrated in a logical order while retaining key information, and finally the code semantic feature vector is obtained.

[0079] In summary, the entire process is tightly integrated, with each step yielding a clear output. All operations revolve around accurately extracting the source code's structure and semantic information, ensuring that the final code semantic feature vector can completely and accurately reflect the core information of the source code, providing reliable feature support for subsequent code defect detection.

[0080] S2. Assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector;

[0081] In this embodiment of the invention, the step of assigning context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector includes:

[0082] The code semantic feature vector is segmented to obtain the context feature fragment of the code semantic feature vector;

[0083] The importance weights of the context feature segments are calculated to obtain the attention weights of the context feature segments. The calculation formula for the attention weights is as follows:

[0084] ;

[0085] In the formula, For the first Attention weights for each context feature segment, The query vector is generated by a linear transformation of the current context feature fragment to be weighted. For the first The key vector of each context feature segment, For the first The key vector of each context feature segment, The total number of the context feature fragments, The relevance score between the query vector and the key vector. It is an exponential function. The exponential operation is performed on the correlation score;

[0086] Based on the attention weights, the context feature segments are weighted and fused to obtain the context-aware features of the context feature segments;

[0087] The context-aware features are fused to obtain a weighted context aggregation table of the code semantic feature vector.

[0088] The step of weighted fusion of the context feature segments based on the attention weights to obtain context-aware features of the context feature segments includes:

[0089] Based on the attention weights, the context feature segments are weighted by importance to obtain the importance features of the context feature segments;

[0090] The importance features are reconstructed in feature space to obtain the semantically enhanced features of the context feature fragments;

[0091] The semantic enhancement features are integrated with the context to obtain the context-aware features of the context feature fragment.

[0092] Specifically, when dividing the code semantic feature vector, the logical structural units of the source code, such as function blocks, statement segments, variable declaration blocks, etc., correspond to the feature information of different dimensions in the code semantic feature vector. The feature dimensions related to the same logical structural unit in the feature vector are grouped together, and each group of feature dimensions constitutes a segment. Through this division method of matching feature dimensions according to logical units, the context feature segment of the code semantic feature vector is finally obtained.

[0093] Furthermore, when calculating the importance weight of the context feature segments, the degree of correlation between the code logic unit corresponding to each context feature segment and the defect detection is first analyzed. For example, context feature segments containing variable initialization, condition judgment logic, and loop control flow are more correlated with code defects. Then, based on the strength of this correlation, a specific formula is used to calculate the attention weight accurately.

[0094] Furthermore, the sources of the parameters in the formula used to calculate the attention weights are as follows: The source is the result obtained by calculating relevant data using this formula, and its corresponding product is the first... Attention weights for each context feature fragment, which are used for subsequent weighted fusion of context feature fragments; The source is the current context feature fragment to be weighted, which comes from the feature division of the code semantic feature vector in the previous step. The semantic feature information is transformed into a query vector by linear transformation according to fixed rules. The source is the first Each context feature segment is used to extract core feature information and transform it into a key vector. Then from the first Generated in the same way in each context feature fragment; The source is the total number of context feature segments obtained after feature segmentation; The source is the query vector The semantic feature similarity is compared with the key vector, and the similarity is converted into a relevance score; The source is the exponential function in mathematics, which is obtained by performing exponential operations on correlation scores according to fixed rules. .

[0095] Furthermore, the significance of this formula lies in: first through Obtain the relevance score between the key vector and the query vector for each context feature fragment, and then... The relevance scores are exponentially calculated to enhance the score differences between different segments; then the exponential calculation results corresponding to all context feature segments are summed to obtain a total; finally, the exponential calculation result of each segment is divided by the total to achieve normalization, so that the final attention weight can accurately reflect the degree of correlation between the segment and the current segment to be weighted. The closer the correlation, the higher the weight, providing a quantitative basis for subsequent weighted fusion.

[0096] Furthermore, the trend of the formula is as follows: when the relevance score of the key vector of a certain segment to the query vector increases, the proportion of its exponential operation result in the sum increases, and the corresponding attention weight increases accordingly; when the relevance scores of other segments generally increase or the total number of segments increases, the proportion of the exponential operation result of a specific segment decreases, and its attention weight decreases; and no matter how the total number of segments changes, the sum of the attention weights of all segments is always one, maintaining a normalized stable state. The attention weight of the context feature segment is finally obtained through the above calculation.

[0097] Furthermore, when performing weighted fusion of the context feature segments based on the attention weights, the feature information of each context feature segment is first associated with the corresponding attention weight. Then, during the fusion process, the feature information of segments with higher attention weights occupies a higher proportion in the overall fusion result. That is, the feature of segments with higher weight values ​​has a greater impact on the fusion result. Through this fusion method of allocating contribution according to weights, the context-aware features of the context feature segments are finally obtained.

[0098] Furthermore, when performing feature fusion on the context-aware features, all context-aware features are first arranged in order according to the logical structure units in the source code. Then, during the integration process, key information related to code semantics in each feature is retained, while duplicate information between different features is eliminated. This ensures that the integrated features not only reflect the semantic characteristics of each segment but also reflect the overall logical relationship of the code. Through this orderly integration and redundancy elimination operation, the weighted context aggregation representation of the code semantic feature vector is finally obtained.

[0099] Specifically, when weighting the context feature segments based on the attention weights, each context feature segment is first mapped one-to-one with its corresponding attention weight to clarify the relationship between the attention weight value of each segment and its own feature information. Then, the proportion of segment feature information is adjusted according to the attention weight. Context feature segments with high attention weights have their core semantic information related to code defect detection preserved and highlighted. Context feature segments with low weights have their proportion of non-core semantic information reduced accordingly to avoid non-core information interfering with key semantics. Through this operation of adjusting the proportion of feature information according to weight, the importance features of the context feature segments are finally obtained.

[0100] Furthermore, in the first step of reconstructing the feature space for the aforementioned important features, each dimension of the important features is analyzed one by one. By combining the semantic logic of the source code, the specific semantic content carried by each dimension is clarified. For example, some dimensions correspond to the data type semantics of variables in the code, some dimensions correspond to the execution logic semantics of loop statements, and some dimensions correspond to the parameter matching semantics of function calls. Through this precise correspondence between dimensions and semantics, the semantic positioning of the important features is completed, laying the foundation for subsequent feature space optimization.

[0101] Furthermore, when reconstructing the feature space of the importance features to obtain semantically enhanced features, based on the semantic localization results of the previous step, semantic dimensions closely related to code defect detection are selected, such as dimensions involving variable initialization and the legality of condition judgments. The representation range of these dimensions in the feature space is expanded, making the semantic information they carry more prominent. At the same time, semantic dimensions that are less related to defect detection, such as dimensions corresponding to code comments, are compressed to reduce their proportion in the feature space and reduce redundant information interference. Through this dimension optimization operation, the semantically enhanced features of the context feature fragment are finally obtained.

[0102] Furthermore, in the first step of context integration of the semantic enhancement features, the writing logic and execution flow of the source code are traced back to determine the position and order of the code segment corresponding to each semantic enhancement feature in the overall code. For example, the semantic enhancement features corresponding to function definitions are determined first, and the semantic enhancement features corresponding to function calls are determined later. All semantic enhancement features are arranged in an orderly manner according to the logical order of actual code execution to ensure that the integration direction is consistent with the code logic.

[0103] Furthermore, in the second step of context integration of the semantic enhancement features, the semantic relationships between adjacent features are analyzed one by one after the ordered semantic enhancement features are arranged. For example, the semantics of the declaration of function parameters in the previous feature and the semantics of the use of the same parameter in the next feature are analyzed to clarify the parameter passing relationship between the two. Another example is that the semantics of setting loop conditions in the previous feature and the semantics of execution within the loop body in the next feature are analyzed to clarify the logical control relationship between the two and to fully record the semantic relationships between these adjacent features.

[0104] Furthermore, when performing context integration on the semantic enhancement features to obtain context-aware features, the semantic relationships between adjacent features recorded in the previous step are incorporated into the integration process. While retaining the unique key semantics of each semantic enhancement feature, the semantic information of adjacent features is connected through the relationship, so that the integration result can reflect both the core semantics of a single feature and the logical coherence between multiple features, forming an overall feature that conforms to the actual semantic logic of the code, and finally obtaining the context-aware features of the context feature fragment.

[0105] In summary, the above process starts with the semantic feature vector of the code, and proceeds sequentially to obtain context feature fragments by dividing them into logical units, obtain attention weights through multi-step refinement operations, obtain context-aware features by weight fusion, and obtain a weighted context aggregation representation by orderly integration of the aware features. Each step revolves around strengthening the contextual relevance of the code semantics. The refined application of the formula ensures the accuracy of the weight calculation, and ultimately enables the weighted context aggregation representation to accurately reflect the semantic logic and key features of the code, providing a reliable foundation for subsequent collaborative analysis of defect features.

[0106] In summary, the above process starts with contextual feature fragments, first obtaining importance features through attention weighting; then, semantic localization and dimensionality optimization are used to reconstruct the feature space, generating semantically enhanced features; finally, logical sorting, association analysis, and semantic fusion are used to achieve context integration, resulting in context-aware features. Each detailed step revolves around "strengthening key semantics and aligning with code logic," with specific operational procedures and clear outputs, ensuring that context-aware features accurately carry the core semantics and logical connections of the code, providing a high-quality feature foundation for the subsequent generation of weighted context aggregation representations.

[0107] S3. Perform defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation;

[0108] In this embodiment of the invention, the step of performing defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation includes:

[0109] The weighted context aggregation representation is deconstructed to obtain the defect feature components of the weighted context aggregation representation;

[0110] The correlation of the defect feature components is compared to obtain the synergistic relationship of the defect feature components;

[0111] Based on the aforementioned collaborative relationship, the defect feature components are comprehensively determined to obtain the defect type and location information represented by the weighted context aggregation.

[0112] Specifically, when deconstructing the weighted context aggregation representation, the weighted context aggregation representation is first split into different feature dimensions according to the semantic logic of the code it carries. Each feature dimension corresponds to a specific functional module or logical segment in the source code. Then, the semantic connotation of each feature dimension is analyzed one by one, and feature dimensions related to code defects are selected, such as feature dimensions related to undefined variables, missing logical branches, and memory leaks. These selected feature dimensions related to defects are classified and integrated. Each set of classified features is a defect feature component. Through this operation of splitting, filtering, and classifying according to semantic logic, the defect feature components of the weighted context aggregation representation are finally obtained.

[0113] Furthermore, when performing correlation comparison on the defect feature components, the semantic description of each defect feature component is first reviewed one by one to clarify the defect-related semantic direction represented by each component. For example, the semantic direction of a certain defect feature component is "the variable was declared but not assigned a value", while the semantic direction of another component is "the unassigned variable was called". This ensures that the semantic connotation of each component is clear and unambiguous, laying the foundation for subsequent comparison.

[0114] Furthermore, after clarifying the semantics of each defect feature component, the core dimension of correlation comparison is determined. This dimension focuses on the logical execution flow of the code and the feature association node, that is, to determine whether different defect feature components correspond to the same logical link or the same key element in the source code, so as to avoid invalid comparisons that are divorced from the actual logic of the code and ensure that the comparison direction is consistent with the logical root cause of the code defect.

[0115] Furthermore, based on the determined comparison dimensions, the related nodes of each defect feature component in the source code logic flow are analyzed. For example, it is checked whether the "unassigned variable after declaration" component and the "unassigned variable is called" component point to the same variable, or whether the "function does not return a value" component and the "function return value is used" component correspond to the same function call relationship, so as to accurately locate the potential related points between different components.

[0116] Furthermore, the association strength of different defect feature components is determined based on the matching of associated nodes. If two components correspond to the same variable and have a sequential dependency relationship in the logical flow, such as the "unassigned variable after declaration" component being first and the "unassigned variable being called" component being later, then the association strength between the two is determined to be high. If the associated nodes corresponding to the components have no direct logical intersection, then the association strength is determined to be low. By determining the association strength of all components, the collaborative relationship of the defect feature components is finally obtained.

[0117] Furthermore, when making a comprehensive judgment on the defect feature components based on the collaborative relationship, defect feature components with high correlation strength are first grouped together to form multiple defect feature groups. Each defect feature group corresponds to a continuous logic in the source code that has potential defect risks, ensuring that defect-related features in the same logic link are centrally integrated to avoid missed judgments caused by decentralized judgment.

[0118] Furthermore, a pre-defined defect type standard library is retrieved. This standard library stores feature group templates for various known code defects. Each template contains a typical combination of defect features for the corresponding defect type, and each template is marked with the core feature identifier of the defect type, providing a clear basis for defect type matching.

[0119] Furthermore, each defect feature group is compared one by one with the feature group templates in the defect type standard library. If all the features of a certain defect feature group completely match the core feature identifier of a certain template, and the logical relationship between the features is consistent with the template, then the defect type corresponding to the defect feature group is determined, ensuring the accuracy of defect type determination.

[0120] Furthermore, while determining the defect type, the specific location of the defect in the source code is located based on the logical segment position of each component in the defect feature group. For example, if a component corresponds to the variable declaration statement on line N in a function definition, and another component corresponds to the variable call statement on line M in the same function, then the defect location is determined to be the logical interval from line N to line M in that function. Finally, the defect type and location information represented by the weighted context aggregation are obtained.

[0121] In summary, the above process begins with the feature deconstruction of weighted context aggregation representation, clarifies the semantics, correlations, and synergy strength of defect feature components through multi-step refinement operations, and then completes defect type matching and location positioning based on synergy grouping and standard library. Each step revolves around "accurately extracting defect correlation features and clarifying defect attributes and locations." The operation process is specific and the output is clear, ensuring that the core information of code defects can be accurately identified, providing accurate defect basis for subsequent acquisition of related repair information based on defect knowledge graph.

[0122] S4. Based on the preset defect knowledge graph, perform semantic association traversal on the defect type to obtain the associated repair information group of the source code;

[0123] In this embodiment of the invention, the step of performing semantic association traversal on the defect type based on a preset defect knowledge graph to obtain the associated repair information group of the source code includes:

[0124] The preset defect knowledge graph is matched with the defect type to obtain the target node of the defect type;

[0125] Perform semantic association edge traversal on the target node to obtain the associated nodes of the target node;

[0126] The associated nodes are repaired and their knowledge is reconstructed to obtain the repair information of the associated nodes;

[0127] The repair information is combined and arranged to obtain the associated repair information group of the source code.

[0128] The step of performing semantic association edge traversal on the target node to obtain the associated nodes of the target node includes:

[0129] Perform topological analysis on the target node to obtain the semantic relationship edges of the target node;

[0130] Perform multi-hop retrieval on the semantic relationship edges to obtain the potential associated node set of the semantic relationship edges;

[0131] Semantic optimization is performed on the set of potential associated nodes to obtain the associated nodes of the target node.

[0132] Specifically, when matching the preset defect knowledge graph with the defect type, the node structure of the preset defect knowledge graph is first defined. Each node in the graph corresponds to a known code defect type, and the node attributes include information such as defect type name, typical features, common triggering scenarios, and associated impact range. Then, the core information of the currently obtained defect type is extracted, including the defect type name and key features. Next, the extracted core information is compared one by one with the attributes of all nodes in the defect knowledge graph. When the "defect type name" and "key features" of a certain node completely match the core information of the current defect type, the node is the node corresponding to the current defect type. Through the above comparison operation, the target node of the defect type is finally obtained.

[0133] Furthermore, before traversing the semantic association edges of the target node, the types of semantic association edges in the defect knowledge graph are first clarified. These association edges are used to connect different nodes, and the types include "repair scheme pointing edge", "similar defect association edge", "repair tool recommendation edge", etc. Among them, "repair scheme pointing edge" is an association edge type that is directly related to obtaining repair information.

[0134] Furthermore, after determining the type of associated edge to be traversed first, starting from the target node, we trace along all the "repair scheme pointing edges". Each "repair scheme pointing edge" is connected to a node at the other end. We record all the nodes connected to the target node through the "repair scheme pointing edges" and temporarily form a set of nodes to be filtered.

[0135] Furthermore, the content of the temporarily stored set of nodes to be screened is validated to check whether the stored content of each node is related to the repair. If the node stores repair-related information such as repair strategies and operation steps, the node is retained; if the node stores non-repair-related information such as defect statistics and historical occurrence frequency, the node is removed. Through the screening operation, the associated nodes of the target node are finally obtained.

[0136] Furthermore, when reconstructing the repair knowledge of the associated nodes, the information storage logic of each associated node is first analyzed. The repair-related knowledge is stored in the associated nodes in a hierarchical manner of "repair strategy - operation steps - verification method - risk avoidance". Each level contains specific textual description information. Then, information is extracted from the associated nodes in this hierarchical order. For example, "initialize the pointer and then call" is extracted from the "repair strategy" level, and "add an assignment statement after the pointer declaration and check whether the pointer is null before calling" is extracted from the "operation steps" level.

[0137] Furthermore, after extracting the information, semantic consistency is checked to see if there are semantic conflicts between different levels of information. If there are conflicts, the "supplementary explanation" field stored in the associated node is retrieved for correction to ensure that the "repair strategy" can be implemented through the "operation steps" and the "verification method" can correspond to the effect verification of the "repair strategy". At the same time, ambiguous information is supplemented with specific content.

[0138] Furthermore, the verified and corrected information is organized into structured content. Each associated node corresponds to a complete repair document containing "repair strategy - operation steps - verification method - risk avoidance". This document is the repair information corresponding to the associated node. By operating on all associated nodes, the repair information of the associated node is finally obtained.

[0139] Furthermore, when combining and arranging the repair information, the content of the repair information of all related nodes is first compared. If the repair information of different related nodes is completely duplicated, one copy is retained and the remaining duplicate information is removed to avoid information redundancy.

[0140] Furthermore, the repair information is prioritized based on its degree of matching with the current defect type. The matching degree is determined by whether the repair information is specific to the triggering scenario of the current defect. Repair information with a higher degree of matching is ranked higher.

[0141] Furthermore, the sorted repair information is grouped by functional category into core repair strategy group, auxiliary repair suggestion group, and repair verification scheme group, so that each group of information focuses on a specific repair link; finally, all the grouped repair information is integrated into a complete information set, which contains all the effective repair content for the current source code defect, and finally the associated repair information group of the source code is obtained.

[0142] Specifically, when performing topological analysis on the target node, the topological position of the target node in the defect knowledge graph is first determined, that is, the connection layout between the node and other nodes. Then, all directly connected edges of the target node are sorted out. Each edge is labeled with connection type and connection strength. Connection type includes repair scheme association, similar defect association, trigger condition association, etc. Connection strength reflects the closeness of the relationship between nodes. Next, the type identifier and connection pointing information of these edges are extracted, and invalid connections are eliminated. Invalid connections include non-semantic related edges such as test mark edges and historical record edges. The remaining valid connection edges are classified by type. These classified valid connection edges are the semantic relationship edges of the target node. Through the above operations, the semantic relationship edges of the target node are finally obtained.

[0143] Furthermore, when performing multi-hop retrieval on the semantic relationship edges, the selection criteria for the retrieval path are first clarified. The retrieval path should focus on content related to the repair information. From the various types of semantic relationship edges, edge types directly related to the repair, such as repair scheme association edges and solution recommendation edges, are selected. These edge types are determined as the designated paths for this multi-hop retrieval to ensure that the retrieval direction always revolves around obtaining repair-related nodes.

[0144] Furthermore, starting from the target node, the first-hop search is performed along the determined repair-related edge types. Each repair-related edge connects to a node at the other end. The nodes connected by these edges are examined one by one to confirm whether the nodes belong to the nodes that effectively store information in the defect knowledge graph. The nodes that meet the requirements are recorded, and these recorded nodes are the first-hop potential related nodes.

[0145] Furthermore, after completing the first hop search, the semantic relationship edges associated with each new starting point node are examined again, and the repair-related edge types are also filtered out. The search continues along these edges until the next node is reached. This node is recorded as the second hop potential associated node, ensuring that each hop search continues the repair-related path direction.

[0146] Furthermore, following the retrieval method from the starting point to the new node described above, subsequent retrieval operations are performed sequentially to continuously extend the retrieval scope until the retrieval covers nodes that have an indirect repair association with the target node, i.e., no new repair-related nodes can be obtained through extended retrieval. At this point, all potential associated nodes obtained through multi-hop retrieval, including the first hop, second hop, and subsequent hops, are collected and integrated to form a complete node set, ultimately yielding the potential associated node set of the semantic relationship edge.

[0147] Furthermore, when performing semantic optimization on the set of potential associated nodes, the core semantic tags are first extracted for each potential associated node. The core semantic tags are a high-level summary of the node's stored content and can directly reflect the core information of the node. For example, tags describing null pointer repair steps and tags describing memory leak solutions, etc., to ensure that the core semantics of each node can be clearly reflected through tags.

[0148] Furthermore, the core features of the defect type corresponding to the target node are obtained. The core features include the key manifestation of the defect and the direction of the repair needs. The core semantic tags of each potential related node are compared with these core features of the defect type one by one to determine the degree of association between the two. If the association between the tag content and the core feature meets the preset association degree standard, such as the tag containing the key name of the defect type or directly corresponding to the repair action, the potential related node is retained.

[0149] Furthermore, for potential associated nodes whose association with the core features of the label and the defect type does not meet the preset standards, such as label content pointing to repair information of other types of defects, or having no direct association with the current defect type, these nodes are directly removed from the potential associated nodes to reduce the interference of irrelevant nodes on subsequent operations.

[0150] Furthermore, for the potential associated nodes retained after label comparison, check the multi-hop paths between them and the target node one by one, and check whether each intermediate node in the path is a repair-related node. If the intermediate node stores repair auxiliary information and repair verification content, etc., which are related to repair, the path is determined to have a valid semantic connection. If the intermediate node contains non-repair-related content, the path connection is determined to be invalid and the node is removed.

[0151] Furthermore, after path semantic connection checks, all nodes with valid path connections are retained, and these nodes are integrated and identified as nodes closely related to the target node and capable of providing effective repair information, thus obtaining the associated nodes of the target node.

[0152] In summary, the above process begins with a pre-defined defect knowledge graph, accurately locating the target node corresponding to the defect type through node matching; then, through edge filtering and traversal, it identifies the related nodes for repair; next, it extracts, verifies, and reconstructs the repair knowledge of the related nodes to obtain accurate and complete repair information; finally, through deduplication, sorting, and grouping, it combines the repair information into related repair information groups. Each step revolves around "obtaining accurate and comprehensive repair information," with specific operational procedures and clear outputs, ensuring that the related repair information groups can provide a reliable basis for subsequent priority scheduling of repair strategies.

[0153] In summary, the above process begins with the topological analysis of the target node, extracting semantic relationship edges by clearly defining the topological location and extracting effective connections. Next, it involves filtering and summarizing multi-hop search paths to form a set of potential related nodes. Finally, it extracts semantic tags, compares the relevance, checks path connectivity, and filters out the related nodes. Each step revolves around accurately acquiring related nodes relevant to defect repair. The operational process is specific and the outputs are clear, ensuring that related nodes provide an effective source of information for subsequent knowledge reconstruction for repair.

[0154] S5. Logically prioritize the repair strategies in the associated repair information group to obtain the defect repair suggestion sequence of the source code;

[0155] In this embodiment of the invention, the step of logically prioritizing the repair strategies in the associated repair information group to obtain the defect repair suggestion sequence of the source code includes:

[0156] The urgency of defect repair is assessed for the repair strategies in the associated repair information group to obtain the urgency level of the repair strategies;

[0157] Based on the defect type and the location information, the urgency level is corrected by context association to obtain the priority score of the repair strategy;

[0158] Based on the priority score, the repair strategy is prioritized and scheduled to obtain a sequence of defect repair suggestions for the source code.

[0159] Specifically, when assessing the urgency of defect repair for the repair strategies in the associated repair information group, the core dimensions of the assessment are first determined, including the scope of defect impact, the probability of defect triggering, and the complexity of repair operations. The scope of defect impact for each repair strategy is analyzed: if the defect causes the core functionality of the source code to fail, the scope of impact is considered broad; if it only affects non-core functionality, the scope of impact is considered narrow. The probability of defect triggering is analyzed: if the defect can be triggered in normal usage scenarios, the probability of triggering is considered high; if it is only triggered in extreme special scenarios, the probability of triggering is considered low. The complexity of repair operations is analyzed: if the repair only requires adjusting a small number of code snippets and does not depend on other modifications, the complexity is considered low; if it requires modifying multiple modules of code and coordinating other functions, the complexity is considered high. Combining the results of the three dimensions, if the scope of impact is broad, the probability of triggering is high, and the complexity is low, the urgency level is considered high; if the scope of impact is narrow, the probability of triggering is low, and the complexity is high, the urgency level is considered low; otherwise, it is considered medium. Through the above assessment operations, the urgency level of the repair strategy is finally obtained.

[0160] Furthermore, before making context-related corrections to the urgency level based on the defect type, the severity classification criteria for the defect type should be clarified. Fatal defect types refer to defect types that directly cause program crashes, data loss, or system unresponsiveness. Severe defect types refer to defect types that cause functional abnormalities but do not cause program crashes. General defect types refer to defect types that only affect code readability and do not affect program functionality. By clarifying the classification criteria, a clear basis for judgment is provided for subsequent corrections.

[0161] Furthermore, the original urgency level is revised based on the classified defect types. If the original urgency level is medium and the corresponding defect type is a critical defect, the assessment result corresponding to the original urgency level needs to be adjusted upwards because critical defects can quickly cause program malfunctions. This makes the revised level more in line with the actual need for urgent repair of critical defects. If the original urgency level is medium and the corresponding defect type is a general defect, the assessment result corresponding to the original urgency level needs to be adjusted downwards because general defects have no substantial impact on program operation. This avoids over-prioritizing the repair of non-urgent defects. Through this targeted revision, the numerical basis corresponding to the urgency level is initially adjusted.

[0162] Furthermore, before supplementing and correcting the initially adjusted urgency level based on the location information, the module division criteria of the source code should be clarified. Core modules refer to modules that support the core business functions of the source code. The normal operation of these modules directly determines whether the overall function of the program is available. Non-core modules refer to modules that provide auxiliary support for the program. Failure of these modules only affects local auxiliary functions and will not directly interfere with the operation of the core business. By clarifying the module division, the specific judgment dimensions for location information correction can be determined.

[0163] Furthermore, the initial urgency level is supplemented and corrected based on the module to which the defect is located. If the defect is located in a core module, even if the initial urgency level is medium, it needs to be adjusted upwards again, because defects in core modules can quickly spread to other related modules, causing overall program malfunction. If the defect is located in a non-core module, even if the initial urgency level is medium, it can be adjusted downwards appropriately, because defects in non-core modules have limited interference with the overall program operation. By supplementing and correcting the location information, the numerical basis corresponding to the urgency level is further optimized.

[0164] Furthermore, when converting the urgency level after correction based on defect type and location information into a priority score, a correspondence between the level and the base score is first established. It is clarified that the level determined to be high urgency after correction corresponds to a high base score, medium urgency corresponds to a medium base score, and low urgency corresponds to a low base score. Moreover, the base score ranges of different levels do not overlap, ensuring that the score can clearly distinguish the priority differences of different levels.

[0165] Furthermore, the base score is fine-tuned based on the adjustment range during the correction process. If a repair strategy undergoes two upward adjustments due to a critical defect type and its location in a core module, it indicates that its repair urgency is extremely high, and the base score needs to be further increased within the high-score range to place it at the forefront among high-priority repair strategies. If a repair strategy undergoes two downward adjustments due to a general defect type and its location in a non-core module, it indicates that its repair urgency is low, and the base score needs to be further reduced within the low-score range to avoid occupying high-priority repair resources. Through the operation of base score plus fine-tuning, the priority score of the repair strategy is finally obtained.

[0166] Furthermore, when performing preliminary priority scheduling of the repair strategies based on the priority scores, the priority scores of all repair strategies are compared horizontally and arranged in descending order of scores. The repair strategy with the highest score is placed at the beginning of the scheduling sequence, followed by the next highest score, until all repair strategies are initially sorted to form a preliminary scheduling sequence.

[0167] Furthermore, dependency checks are performed on the repair strategies in the initial scheduling sequence. The code modification scope of each repair strategy is analyzed one by one. If the code segment that repair strategy A needs to modify is a code segment that repair strategy B has already modified or needs to modify first, that is, the execution of A must be based on the completion of B, then it is determined that A depends on B. For repair strategies with such dependencies, the repair strategy that is depended on is moved before the repair strategy that depends on it, to ensure that when A is executed later, B has completed the relevant code modification and avoids code modification conflicts.

[0168] Furthermore, after completing the dependency adjustment, the final scheduling sequence is checked again to see if there are any missing dependencies or sorting logic conflicts. If it is found that two repair strategies still have unresolved dependency issues, the order is adjusted again according to the principle of "the dependent strategy takes precedence". If no logical conflicts are found, it is confirmed that the scheduling sequence conforms to the sequential logic of repair operations and can guide developers to perform repairs in an orderly manner. Through the above scheduling operations, the defect repair suggestion sequence of the source code is finally obtained.

[0169] In summary, the above process starts with the remediation strategy in the associated remediation information group. First, the urgency level is determined through multi-dimensional assessment. Then, the urgency level is revised twice by combining the defect type classification criteria and the location information definition module. The revised level is converted into a priority score with fine-tuning. Finally, priority scheduling is completed through preliminary sorting, dependency verification, and conflict correction to form a defect remediation suggestion sequence. Each step revolves around "precisely sorting remediation strategies and prioritizing critical defects." The operation process is specific and the output is clear, ensuring that the defect remediation suggestion sequence can guide developers to complete source code defect remediation efficiently and systematically, improving the targeting and efficiency of the remediation work.

[0170] S6. Generate a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence.

[0171] In this embodiment of the invention, generating a code defect detection report of the source code based on the defect type, the location information, and the defect repair suggestion sequence includes:

[0172] Heterogeneous data fusion is performed on the defect type, the location information, and the defect repair suggestion sequence to obtain a structured defect data object of the source code;

[0173] The structured defect data object is formatted and encapsulated to obtain a preliminary detection report of the source code;

[0174] The preliminary detection report is enhanced with visualization to obtain the code defect detection report of the source code.

[0175] Specifically, when performing heterogeneous data fusion on the defect type, the location information, and the defect repair suggestion sequence, the structural characteristics of the three types of data are first clarified: the defect type is text-descriptive data, such as null pointer exceptions and missing logical branches; the location information is code-location data, such as variable declaration segments in user login functions under core business modules; and the defect repair suggestion sequence is ordered strategy data, such as pointer initialization, pre-call verification, and function verification. Next, a unified fusion framework is determined, designed with a three-layer structure: a defect basic information layer, a defect location layer, and a repair scheme layer, each layer corresponding to a type of heterogeneous data. Then, the defect type is filled into the defect basic information layer, clearly marking the defect type; the location information is filled into the defect location layer, recording the module to which the defect belongs and the specific code segment; and the defect repair suggestion sequence is filled into the repair scheme layer in sequence, marking repair step one and repair step two. Finally, the correlation between the three layers of data is verified to ensure that the code segment corresponding to the location information is consistent with the triggering scenario of the defect type, and that the repair suggestion sequence can effectively solve the problem for the defect type and location information. Through the above fusion operation, the structured defect data object of the source code is finally obtained.

[0176] Furthermore, before formatting and encapsulating the structured defect data object, a fixed structure template for the preliminary detection report is determined. The template includes five parts: report title, defect overview, defect details, repair suggestions, and report description. Each part has a clear content positioning. The report title is uniformly set as "Preliminary Detection Report of Source Code Defects" to ensure that the title intuitively reflects the purpose of the report.

[0177] Furthermore, the content of the structured defect data object is filled in according to the template structure. In the defect overview column, the defect type is filled in, and a brief description of the defect's impact on the source code is provided, such as the possibility of the program crashing after startup and affecting the operation of core functions. In the defect details column, the location information is filled in, and the role of the location in the source code is explained, such as the user login function being the core business entry point, and an exception in the variable declaration section directly blocking the login process. In the repair suggestion column, the defect repair suggestion sequence is filled in sequentially, and an operation description is provided for each repair step, such as repair step one initializing pointers: add an assignment statement after the pointer declaration statement to assign a valid memory address. In the report description column, the data source is marked, such as the data coming from code semantic analysis and defect knowledge graph matching, to ensure that the report content is traceable.

[0178] Furthermore, the format of the preliminary inspection report is standardized, with fixed font and font size for the text, and separators used to distinguish each column. The defect overview, defect details, and repair suggestion columns are highlighted with bold headings, and each step in the repair suggestion sequence is marked with a bullet point to ensure a clear report structure and easy reading. Finally, the completeness of the report content is checked to confirm that no data is missing, such as defect type or location information, unambiguous wording, and accurate and unambiguous description of repair steps. Through the above encapsulation operation, the preliminary inspection report of the source code is finally obtained.

[0179] Furthermore, when enhancing the visualization of the preliminary inspection report, the visualization element types are first determined, including three core elements: defect location diagram, repair priority flowchart, and defect impact range diagram. Each element corresponds to key information in the report.

[0180] Furthermore, the design of the defect location diagram is based on the module hierarchy of the source code, drawing a module structure diagram, such as the core business module under the overall architecture, the user login function under the core business module, and the variable declaration section under the user login function. The location of the defect is marked with a special color, such as using a red block to mark the variable declaration section. Text annotations are added next to the diagram to explain that the red mark is the specific location of the defect, corresponding to the content in the defect details column of the report, so that the defect location is intuitively identifiable.

[0181] Furthermore, the design presents the repair priority flowchart in a way that uses the steps of the defect repair suggestion sequence as nodes, connecting each node with arrows to form a flowchart. The nodes are arranged in the repair order, such as the initialization pointer arrow pointing to the pre-call verification, and the pre-call verification arrow pointing to the functional verification. The priority of each step is marked next to each node, such as high priority: initialization pointer, which is the basis for subsequent steps. The flowchart order is consistent with the steps in the report repair suggestion column, and the priority marking is based on the defect impact range.

[0182] Furthermore, the presentation of the defect impact scope diagram is designed by using the functional modules of the source code as units to draw a functional relationship diagram. For example, the user login module is connected to the data encryption module, and the data encryption module is connected to the database storage module. The modules affected by the defect are marked with dashed boxes, such as circling the user login module and the data encryption module with dashed boxes. Below the diagram, it is explained that the modules within the dashed boxes may experience functional abnormalities due to the defect and require special attention. The three visualization elements are embedded next to the corresponding columns in the preliminary inspection report: the defect location diagram is embedded to the right of the defect details column, the repair priority flowchart is embedded below the repair suggestion column, and the defect impact scope diagram is embedded below the defect overview column.

[0183] Furthermore, verify the consistency between the visual elements and the report text content to ensure that the position of the diagram markers, process nodes, and scope of influence completely match the text description without any information conflicts; adjust the size and layout of the visual elements to avoid obscuring the text content and ensure the overall layout of the report is coordinated; through the above visualization enhancement operations, the code defect detection report of the source code is finally obtained.

[0184] In summary, the above process begins with the fusion of three types of heterogeneous defect data, forming a structured defect data object through a unified framework. Then, a preliminary detection report is encapsulated through fixed template filling and standardized formatting. Finally, multiple visualization elements are designed and embedded into the report to enhance its visualization. Each step revolves around clearly presenting defect information and providing convenient guidance for repair operations. The operational process is specific and the deliverables are clear, ensuring that the code defect detection report provides developers with comprehensive, intuitive, and usable defect repair guidance, thereby improving the efficiency of code defect handling.

[0185] like Figure 2 The diagram shown is a functional block diagram of an application software code defect automatic detection system based on artificial intelligence, provided in an embodiment of the present invention.

[0186] The AI-based application software code defect automatic detection system 100 described in this invention can be installed in an electronic device. Depending on the functions implemented, the AI-based application software code defect automatic detection system 100 may include a source code semantic encoding module 101, a context attention aggregation module 102, a multi-feature collaborative defect detection module 103, a knowledge graph semantic retrieval module 104, a repair strategy intelligent ranking module 105, and a detection report automatic generation module 106. The modules described in this invention can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, stored in the memory of the electronic device.

[0187] In this embodiment, the functions of each module / unit are as follows:

[0188] The source code semantic encoding module 101 is used to acquire the source code of the application software to be detected, and to perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code.

[0189] The context attention aggregation module 102 is used to assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector.

[0190] The multi-feature collaborative defect detection module 103 is used to perform defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation.

[0191] The knowledge graph semantic retrieval module 104 is used to perform semantic association traversal on the defect type based on a preset defect knowledge graph to obtain the associated repair information group of the source code.

[0192] The intelligent sorting module 105 for repair strategies is used to logically prioritize the repair strategies in the associated repair information group to obtain a sequence of defect repair suggestions for the source code.

[0193] The automatic report generation module 106 is used to generate a code defect detection report of the source code based on the defect type, the location information, and the defect repair suggestion sequence.

[0194] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0195] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0196] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0197] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0198] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0199] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions 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 solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An automatic detection method for application software code defects based on artificial intelligence, characterized in that, The method includes: S1. Obtain the source code of the application software to be detected, and perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code; S2. Assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector; S3. Perform defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation; S4. Based on the preset defect knowledge graph, perform semantic association traversal on the defect type to obtain the associated repair information group of the source code; S5. Logically prioritize the repair strategies in the associated repair information group to obtain the defect repair suggestion sequence of the source code; S6. Generate a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence.

2. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The process of acquiring the source code of the application software to be detected and performing deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code includes: Perform syntax analysis on the source code to obtain an abstract syntax tree of the source code; Perform syntactic topology parsing on the abstract syntax tree to obtain the syntax nodes and syntactic dependencies of the abstract syntax tree; The grammar node is semantically embedded to obtain the node semantic vector of the grammar node; Based on the syntactic dependencies, the node semantic vectors are aggregated using structure awareness to obtain the code semantic feature vectors of the node semantic vectors.

3. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The step of assigning context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector includes: The code semantic feature vector is segmented to obtain the context feature fragment of the code semantic feature vector; The importance weights of the context feature segments are calculated to obtain the attention weights of the context feature segments. The calculation formula for the attention weights is as follows: ； In the formula, For the first Attention weights for each context feature segment, The query vector is generated by a linear transformation of the current context feature fragment to be weighted. For the first The key vector of each context feature segment, For the first The key vector of each context feature segment, The total number of the context feature fragments, The relevance score between the query vector and the key vector. It is an exponential function. The exponential operation is performed on the correlation score; Based on the attention weights, the context feature segments are weighted and fused to obtain the context-aware features of the context feature segments; The context-aware features are fused to obtain a weighted context aggregation table of the code semantic feature vector.

4. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 3, characterized in that, The step of weighted fusion of the context feature segments based on the attention weights to obtain context-aware features of the context feature segments includes: Based on the attention weights, the context feature segments are weighted by importance to obtain the importance features of the context feature segments; The importance features are reconstructed in feature space to obtain the semantically enhanced features of the context feature fragments; The semantic enhancement features are integrated with the context to obtain the context-aware features of the context feature fragment.

5. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The step of performing defect feature collaborative analysis on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation includes: The weighted context aggregation representation is deconstructed to obtain the defect feature components of the weighted context aggregation representation; The correlation of the defect feature components is compared to obtain the synergistic relationship of the defect feature components; Based on the aforementioned collaborative relationship, the defect feature components are comprehensively determined to obtain the defect type and location information represented by the weighted context aggregation.

6. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The semantic association traversal of the defect types based on the preset defect knowledge graph yields the associated repair information group of the source code, including: The preset defect knowledge graph is matched with the defect type to obtain the target node of the defect type; Perform semantic association edge traversal on the target node to obtain the associated nodes of the target node; The associated nodes are repaired and their knowledge is reconstructed to obtain the repair information of the associated nodes; The repair information is combined and arranged to obtain the associated repair information group of the source code.

7. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 6, characterized in that, The step of performing semantic association edge traversal on the target node to obtain the associated nodes of the target node includes: Perform topological analysis on the target node to obtain the semantic relationship edges of the target node; Perform multi-hop retrieval on the semantic relationship edges to obtain the potential associated node set of the semantic relationship edges; Semantic optimization is performed on the set of potential associated nodes to obtain the associated nodes of the target node.

8. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The step of logically prioritizing the repair strategies in the associated repair information group to obtain a sequence of defect repair suggestions for the source code includes: The urgency of defect repair is assessed for the repair strategies in the associated repair information group to obtain the urgency level of the repair strategies; Based on the defect type and the location information, the urgency level is corrected by context association to obtain the priority score of the repair strategy; Based on the priority score, the repair strategy is prioritized and scheduled to obtain a sequence of defect repair suggestions for the source code.

9. The method for automatic detection of application software code defects based on artificial intelligence as described in claim 1, characterized in that, The step of generating a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence includes: Heterogeneous data fusion is performed on the defect type, the location information, and the defect repair suggestion sequence to obtain a structured defect data object of the source code; The structured defect data object is formatted and encapsulated to obtain a preliminary detection report of the source code; The preliminary detection report is enhanced with visualization to obtain the code defect detection report of the source code.

10. An automatic detection system for application software code defects based on artificial intelligence, characterized in that, The system includes: The source code semantic encoding module is used to acquire the source code of the application software to be detected, and to perform deep structural semantic encoding on the source code to obtain the code semantic feature vector of the source code. The context attention aggregation module is used to assign context weights to the code semantic feature vector to obtain a weighted context aggregation representation of the code semantic feature vector; A multi-feature collaborative defect detection module is used to perform collaborative analysis of defect features on the weighted context aggregation representation to obtain the defect type and location information of the weighted context aggregation representation; The knowledge graph semantic retrieval module is used to perform semantic association traversal on the defect type based on a preset defect knowledge graph to obtain the associated repair information group of the source code; The intelligent sorting module for repair strategies is used to logically prioritize the repair strategies in the associated repair information group to obtain a sequence of defect repair suggestions for the source code. The automatic report generation module is used to generate a code defect detection report for the source code based on the defect type, the location information, and the defect repair suggestion sequence.

Images