Code defect identification method and system for multi-type feature association and propagation analysis

Abstract

The invention relates to a code defect identification method and system for multi-type feature association and propagation analysis, belongs to the technical field of software testing, and solves the problems of relatively low code defect identification efficiency and relatively small defect identification coverage in the prior art. The method comprises the steps that a software document is analyzed, and multi-type features are generated; generating feature nodes based on the multi-type features, and determining an association relationship between the feature nodes; analyzing the defect case set to generate defect form data; generating defect nodes based on the defect form data; determining an association relationship between the defect node and the feature node; backtracking from the defect node to the feature node by using the determined association relationship, and generating a defect propagation path; the generated defect propagation path is displayed on a software document reading page in an associated mode, judgment information returned by a user for the displayed defect propagation path is obtained, and a code defect recognition result is generated based on the judgment information. Therefore, the code defect identification efficiency is high, and the defect identification coverage range is large.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and system for identifying code defects through multi-type feature association and propagation analysis. Background Technology

[0002] With the exponential growth in the size and complexity of software systems and the increasing complexity of business logic, code defect identification has become a core aspect of ensuring quality and security in the modern software development lifecycle.

[0003] Traditional code defect detection methods can efficiently identify a large number of low-level, patterned errors, but they suffer from inefficiency and limited coverage. Too many false positives require manual review, analysis, and elimination, consuming significant time and effort. Furthermore, they may miss critical bugs or be largely ineffective against defects at the business logic level.

[0004] Therefore, there is an urgent need to propose new code defect identification technologies to improve the efficiency of code defect identification and expand the coverage of defect identification. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a code defect identification method and system for multi-type feature association and propagation analysis, in order to solve the problems of low identification efficiency and limited coverage of existing code defect identification methods.

[0006] On one hand, embodiments of the present invention provide a code defect identification method based on multi-type feature association and propagation analysis, including:

[0007] Parse software documentation to generate multiple types of features; generate feature nodes based on these features, and determine the relationships between feature nodes.

[0008] Analyze the defect case set to generate defect form data; generate defect nodes based on the defect form data; determine the association between defect nodes and feature nodes;

[0009] Using the established relationships, a defect propagation path is generated by tracing back from the defect node to the feature node.

[0010] The generated defect propagation path is displayed on the software documentation reading page. The user's judgment information returned regarding the displayed defect propagation path is obtained, and code defect identification results are generated based on the judgment information.

[0011] On the other hand, embodiments of the present invention provide a code defect identification system for multi-type feature association and propagation analysis.

[0012] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0013] 1. Integrating multiple types of features and combining knowledge graphs, large-scale model reasoning, and defect propagation analysis helps improve the efficiency of code defect identification and expand the coverage of defect identification.

[0014] 2. By structuring and organizing fragmented and scattered features, a feature node association link was established from code elements to business rules to defect forms; propagation impact analysis was realized, the reasoning logic is traceable, it can be traced back to the root cause of the problem, the scope of the problem's impact is clarified, and it is conducive to increasing the interpretability of the defect identification process.

[0015] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0016] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0017] Figure 1 This is a flowchart of a code defect identification method based on multi-type feature association and propagation analysis in an embodiment of the present invention;

[0018] Figure 2 This is a schematic diagram of the code defect identification system structure for multi-type feature association and propagation analysis in an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram illustrating the implementation of a code defect identification system based on multi-type feature association and propagation analysis in an embodiment of the present invention. Detailed Implementation

[0020] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0021] When conducting software testing on complex, large-scale engineering software code, the code project is typically obtained from a Git repository or IDE plugin. Software documents, including software requirements specifications (detailing business logic and development requirements) in Word / PDF format and design documents in UML / JSON format (detailing business logic), are then packaged and submitted to the software testing department for software testing and code defect identification. Naturally, the submitted software documents have already been evaluated, and the code project, software requirements specifications, and design documents exhibit good consistency at the business logic level.

[0022] Typically, a code project contains source code, developed using Unicode characters (supporting Chinese characters), and includes abundant function and logic comments. The source code contains numerous function definition statements and blocks (such as the main function and run function), function call statements, flow control statements, variable declaration statements, and class declaration statements. Different functions in a code project may have calling relationships, and the same function may be subject to recursive calls.

[0023] A specific embodiment of the present invention discloses a code defect identification method based on multi-type feature association and propagation analysis, such as... Figure 1 and Figure 2 As shown, it includes the following steps:

[0024] Parse software documentation to generate multiple types of features; generate feature nodes based on these features, and determine the relationships between feature nodes.

[0025] Analyze the defect case set to generate defect form data; generate defect nodes based on the defect form data; determine the association between defect nodes and feature nodes;

[0026] Using the established relationships, a defect propagation path is generated by tracing back from the defect node to the feature node.

[0027] The generated defect propagation path is displayed on the software documentation reading page. The user's judgment information returned regarding the displayed defect propagation path is obtained, and code defect identification results are generated based on the judgment information.

[0028] Compared with existing technologies, the code defect identification method based on multi-type feature association and propagation analysis provided in this embodiment extracts multi-type information from multiple dimensions such as syntax, semantics, business logic, and program execution to generate multi-type features, resulting in complete and comprehensive feature extraction. Based on these multi-type features, feature nodes are generated, the relationships between feature nodes are determined, defect case sets are parsed, and defect form data is generated. Defect nodes are generated based on the defect form data. The relationships between defect nodes and feature nodes are determined, structuring and organizing fragmented and scattered features to establish a feature node association link from code elements to business rules to defect forms. Using the determined relationships, a defect propagation path is generated by tracing back from the defect node to the feature node. This path is then displayed on the software documentation reading page, and the user's judgment information returned regarding the displayed path is obtained. Based on this judgment information, a code defect identification result is generated. The reasoning logic is traceable, leading to the root cause of the problem and clarifying the scope of its impact, which helps increase the interpretability of the defect identification process.

[0029] Compared with existing technologies, the code defect identification method with multi-type feature association and propagation analysis provided in this embodiment integrates knowledge graphs, large model reasoning and defect propagation analysis, which helps to improve the efficiency of code defect identification and expand the coverage of defect identification.

[0030] Specifically, the software documentation includes: code project, executable program, design document, and software requirements specification;

[0031] The multi-type features include: code syntax features, function semantic features, business logic features, and program execution features;

[0032] The code syntax features include function syntax features, variable features, control structure features, and syntax error marking features;

[0033] The semantic features of the function include explicit functional intent vectors and implicit functional intent vectors;

[0034] The program execution characteristics include dynamic program execution characteristics and virtual program execution characteristics;

[0035] The parsing software document generates multiple types of features, including:

[0036] Analyze the code project to generate function syntax features, variable features, and control structure features; obtain static error message text generated after the code reading tool compiles the source code and generate syntax error marker features;

[0037] Based on the function design specifications in the design document, analyze the function comments, variable names, and logical comments in the source code to generate explicit functional intent vectors; based on the function design specifications in the design document, perform contextual analysis on the source code to generate missing comments and implicit functional intent vectors.

[0038] Extract multiple business logics recorded in the software requirements specification, and break down each business logic into at least one functional intent description recorded in text form; based on the functional intent description, generate business logic features, wherein the business logic features are indexed by the business logic name and recorded in text form as at least one functional intent description;

[0039] For cases where the test environment for the source code can be set up and run, the executable program is run in the runnable test environment using a test case set to generate dynamic program execution characteristics; for cases where the test environment for the source code cannot be set up and run, a large model is used to virtually execute the software document to generate virtual program execution characteristics.

[0040] Specifically, the code project is analyzed to generate function syntax features, variable features, and control structure features, including:

[0041] Parse the source code to generate a syntax structure tree, in which each function, variable or class, control structure and other code element recorded in the source code is mapped to various types of nodes in the syntax structure tree and the relationships between the nodes; the mapping relationship of various code elements in the syntax structure tree includes: variables correspond to leaf nodes, functions and classes are internal nodes, and control structures are branch nodes;

[0042] From the various nodes and their relationships recorded in the syntax tree structure, function names and function call relationships are extracted to form multiple function syntax features indexed by function names. Each function syntax feature records the function name, the variable name or class name of the function call, the control structure name of the function call, and the function call relationship using an adjacency vector.

[0043] For example, if function A and function B have a calling relationship, but function A and function C do not have a calling relationship, then in the adjacency vector recorded by the function syntax feature indexed by function A, the adjacency state value corresponding to function B can be determined as 1, and the adjacency state value corresponding to function C can be determined as 0. Naturally, if a function has a recursive calling relationship, its adjacency state value is 1.

[0044] Naturally, the function syntax features corresponding to all functions recorded in the source code can be stored in a table with multiple rows and columns.

[0045] From the various nodes and their relationships recorded in the syntax tree structure, the variable name or class name, the type of the variable or class, the scope of the variable or class, and the initialization state of the variable or class are extracted to form multiple variable features indexed by the variable name. Each variable feature records the variable name or class name in text form, the type of the variable or class in text form, the scope of the variable or class as global or local in text form, the function or control structure in which the variable or class is located in text form, and the initialization state of the variable or class in numerical or text form.

[0046] Specifically, the initialization state of a variable or class is the value assigned to it when it is defined; if no value is assigned, the initialization state can be loaded as "Null", which is empty.

[0047] Naturally, all the variables or variable characteristics corresponding to classes recorded in the source code can be stored in a table with multiple rows and columns.

[0048] From the various nodes and their relationships recorded in the syntax tree structure, extract the function where the control structure is located, and the variables or classes processed by the control structure, forming multiple control structure features indexed by the control structure name. Each control structure feature records the control structure name in text form, the control structure type (conditional branch, loop structure, or exception handling) in text form, and the functions where the control structure is located and the variables or classes processed by the control structure in text form.

[0049] In particular, although exception handling is a special conditional branch, it is listed separately from conditional branches here. This makes it easier and more efficient to determine the defect propagation path, and also helps to increase the coverage of defect identification.

[0050] Naturally, all the control structure features recorded in the source code can be stored in a multi-row, multi-column table.

[0051] In some embodiments, from the various nodes and their relationships recorded in the syntax structure tree, a function syntax feature can be formed based on an internal node (corresponding to a function and a class). This function syntax feature is indexed by the function name func_A, and records the variables of the function call as param1 and param2 in text form. The control structure of the function call func_A can be further determined by combining other branch nodes (corresponding to control structures). The call relationship between the function func_A and other functions can be further determined by combining other internal nodes (corresponding to functions and classes), which will not be elaborated further.

[0052] Specifically, it parses software documentation and generates syntax error markers, including:

[0053] Obtain the static error message text generated after the code reading tool compiles the source code, and generate syntax error marker features.

[0054] Specifically, obtain the static error message text generated after the code reading tool compiles the source code, and generate syntax error marker features, including:

[0055] Obtain the static error message text generated after compiling the source code by a code reading tool (such as IEDA or VScode). Search for static error descriptions in the static error message text to generate multiple syntax error marker features. The syntax error marker features are indexed by static error type and recorded in text form. The static error type is recorded in text form, along with the associated function name, variable name, or class name. Among them, static error types include: function parameter mismatch and undefined variable reference.

[0056] Specifically, variables are recorded in variable declaration statements or function definition statements and blocks, while parameters are invoked by function call statements. Function definition statements record the function's input or output parameters; functions can be parameterless. For example, if a static error message search yields the static error description "The variable 'tmp' was passed to the main function call, but this variable is not defined," then the static error type "undefined variable reference" can be extracted, along with the variable associated with this static error type being the 'tmp' variable, and the associated function name being main.

[0057] Naturally, all the syntax error markers generated after compiling the source code can be stored in a multi-row, multi-column table.

[0058] Specifically, the extracted function syntax features, variable features, control structure features, and syntax error marker features can be combined into code syntax features, including:

[0059] Create a syntax data table to record the syntax features of the code. Each row in the syntax data table is indexed by the function name and sets the function syntax feature segment, variable feature segment, control structure feature segment, and syntax error flag feature segment.

[0060] The extracted function syntax features, variable features, control structure features, and syntax error marker features are populated into each row and column of the syntax data table using the function name as the index;

[0061] Among them, the function syntax feature segment in each line records the adjacency vector corresponding to the function name;

[0062] The variable feature section in each line is used to record the variable features of the variable or class recorded in the function definition section corresponding to the function name, including the variable name or class name, the type of the variable or class, the scope of the variable or class, the initialization state of the variable or class, and the control structure in which the variable or class is located within the current function definition section;

[0063] The control structure feature section in each line is used to record the control structure features of the control structure recorded in the function definition section corresponding to the function name, including the control structure name, control structure type, and variables or classes processed by the control structure.

[0064] The syntax error marker feature section in each line is used to record the syntax error marker features of the function definition section corresponding to the function name, including the static error type and the variable name or class name associated with the static error type.

[0065] Naturally, the function syntax features, variable features, control structure features, and syntax error marker features generated above are recorded in the syntax data table in the form of structured data. The syntax data table records the relationships between functions, between functions and variables or classes, between functions and control structures, and between control structures and variables. In the subsequent knowledge graph construction steps, these relationships can be quickly mapped to the relationships between feature nodes.

[0066] Specifically, this involves parsing software documentation and generating semantic features of functions, including:

[0067] By combining the function design specifications in the design document with the function comments, variable names, and logical comments in the source code, an explicit functional intent vector is generated.

[0068] By combining the function design specifications in the design document with the source code, a contextual analysis is performed to generate missing comments and implicit functional intent vectors.

[0069] Typically, function comments describe the entire function / method, while logic comments describe code blocks, algorithm steps, and complex logic. Function comments answer "what" and "why," while logic comments answer "how" and "why it's implemented this way." Function comments are primarily for users (such as developers who call the function), while logic comments are primarily for maintainers (such as developers who read and modify the code).

[0070] Specifically, by combining the function design specifications recorded in the design document with the function comments, variable names, and logical comments recorded in the source code, an explicit functional intent vector is generated, including:

[0071] The system retrieves function comments, variable names, and logical comments from the code project, as well as function design specifications (including inputs, outputs, function implementation, and constraints) from the design document, and converts them into Chinese text information, such as storing the Chinese text information in the form of a string array.

[0072] The extracted Chinese text information is analyzed using THULAC to segment and tag sentences (e.g., nouns, verbs, adjectives, auxiliary words, etc.), resulting in segmented sentences with tagging. The Spacy NLP library is then used to perform semantic role tagging and syntactic analysis on the segmented sentences. During semantic role tagging, each segment is further tagged with its semantic role (e.g., subject, predicate, object, attributive, adverbial, etc.) based on its part of speech, resulting in segmented sentences with tagging. During syntactic analysis, the segmented sentences with tagging are combined according to syntactic dependency relations to form complete semantic sentences, i.e., explicit function intent description text. This explicit function intent description text records the function name and multiple sentences or paragraphs describing the function's functional intent in text form.

[0073] The explicit function intent description text is processed using a word segmentation tool (such as THULAC) to generate an explicit function intent vector. The explicit function intent vector is indexed by the function name and records the function intent of the function with at least one word combination. Each word combination is a function intent element of the function, and the function intent vector reflects the function implemented by the function.

[0074] For example, if the definition of function A contains the function comment " / / verify user input and return encrypted results", then the extracted functional intent vector of function A will contain the phrase "user input verification data encryption" as the element representing this functional intent of function A. Naturally, the number of word segments included in each phrase combination varies with the complexity of the functional intent.

[0075] Specifically, the Tsinghua University Lexical Analyzer for Chinese (THULAC) is a Chinese natural language processing toolkit whose core function is Chinese lexical analysis. This comprehensive task mainly includes two sub-tasks: Chinese word segmentation, which divides a continuous sequence of Chinese text into individual words (word sequences); and part-of-speech tagging, which tags the part-of-speech (POS) of each segmented word.

[0076] Specifically, the source code is analyzed in context based on the function design specifications documented in the design document, generating missing comments and implicit functional intent vectors, including:

[0077] The inference analysis model obtains source code and design documents, such as by transmitting the source code and design documents to the inference analysis model; instructions are written for the inference analysis model to generate prompts for missing comments; the inference analysis model obtains the written prompts and performs contextual analysis on the source code in conjunction with the function design specifications recorded in the design document to generate missing comments. Thus, the missing comments originate from the function design specifications recorded in the design document but not in the function comments or logic comments in the source code.

[0078] Combined with the missing comments generated by the function design description recorded in the design document, Chinese text information in text form is formed, such as storing the Chinese text information in text form as a string array, and the implicit function functional intent description text is extracted. The implicit function functional intent description text records the function name and multiple statements or paragraphs used to describe the function's functional intent in text form.

[0079] The implicit function intent description text is processed using a word segmentation tool (such as THULAC) to generate an implicit function intent vector. The implicit function intent vector is indexed by the function name and records the function intent of the function using at least one word combination.

[0080] Specifically, extracting implicit function intent description text from missing annotations can refer to the steps described above for generating explicit function intent description text, and will not be repeated here.

[0081] For example, the "resource release dependency after function A call" is not recorded in the function comments of the source code. After performing a contextual analysis of the source code in conjunction with the function design specifications recorded in the design document, this missing comment can be generated, and a single element of the implicit functional intent vector of function A, namely "resource release after call", can be extracted from this missing comment.

[0082] Specifically, the large-scale inference analysis model uses Qwen version 2.5 or higher. Missing comments in text format generated based on the function design specifications in the design document can be appended to the source code.

[0083] Specifically, when using a word segmentation tool (such as THULAC) to process explicit or implicit function intent description text, if a step-by-step description is detected in the function intent description text, multiple word combinations are generated for the function based on the step-by-step description, and each of these multiple word combinations is recorded step by step as a single function intent element to record the function intent vector.

[0084] Specifically, step-by-step descriptions include step identifiers with sequential numbers, such as step 1, step 2, etc.; or textual descriptions used to indicate a sequential or parallel execution order, such as first, second, last, etc.

[0085] Specifically, explicit functional intent vectors and implicit functional intent vectors can be combined into functional semantic features, including:

[0086] Create a semantic data table to record the semantic features of the function. Each row in the semantic data table is indexed by the function name and has at least one word combination field.

[0087] The explicit functional intent vector and the implicit functional intent vector are populated into each row of the semantic data table using function names as indexes; wherein at least one word combination field in each row is used to record at least one word combination field recorded by the explicit functional intent vector and / or the implicit functional intent vector.

[0088] Naturally, the explicit and implicit functional intent vectors generated above are recorded in the semantic data table in the form of structured data. The semantic data table records at least one single functional intent element of the function, which can be quickly mapped to the association between the function and the functional intent in the subsequent knowledge graph construction.

[0089] Specifically, this involves parsing software documentation and generating business logic features, including:

[0090] Extract multiple business logics recorded in the software requirements specification, and break down each business logic into at least one functional intent description recorded in text form; based on the functional intent description, generate business logic features, wherein the business logic features are indexed by the business logic name and recorded in text form as at least one functional intent description.

[0091] Specifically, read the business requirement description recorded in the software requirements specification, extract multiple business logic names and specific function descriptions corresponding to each business logic name based on the business requirement description, the specific function description includes at least one function intent description, the function intent description reflects the description of the process steps and other functions required for the execution of the business logic;

[0092] Business logic features are generated based on multiple business logic names and the specific functional descriptions corresponding to each business logic name. The business logic features are indexed by the business logic name and record at least one functional intent description in text form.

[0093] Specifically, it also includes: creating a business logic data table to record business logic characteristics, wherein each row in the business logic data table is indexed by the business logic name, and at least one long text field in each row is used to record at least one functional intent description.

[0094] In some embodiments, an example of a business logic data table is as follows: The fields in row n are as follows: Business Logic A; Functional Intent Description 1; "User Input Authentication Data Encryption"; Functional Intent Description 2; "Public Key / Secondary Key Verification and Authentication".

[0095] Referring to the foregoing explanation, the functional intent descriptions in the business logic data and the functional intent vectors corresponding to each function in the aforementioned function semantic data are textual information obtained from the code documents and software requirements specifications after consistency verification. Therefore, the functional intent vectors corresponding to each function and the functional intent descriptions extracted from the business logic can be fuzzily matched and associated in the following steps.

[0096] The business logic data table generated above records the relationship between business logic and functional intent description in text form. In the subsequent knowledge graph construction, it can be quickly mapped to the relationship between business logic and functional intent, such as the relationship between business logic nodes and functional intent nodes, thereby forming the path from business logic nodes to function nodes.

[0097] Specifically, for cases where the source code can be tested in a feasible environment, test cases are used to run the executable program in that environment, generating dynamic program execution characteristics. For cases where the source code cannot be tested in a feasible environment, a large model is used to virtually execute the software documentation, generating virtual program execution characteristics, including:

[0098] Analyze the source code to determine whether the test environment for the source code can be set up and run, and whether the test environment for the source code cannot be set up and run.

[0099] Given that the test environment for the source code can be set up and run, a dynamic test case set is generated, a runnable test environment is set up, and an executable program is generated. The executable program is run in the runnable test environment using the generated dynamic test case set, and dynamic program execution characteristics are generated.

[0100] In cases where a test environment cannot be set up to run the source code, a large model is used to virtually execute the software document, generating virtual program execution characteristics.

[0101] Specifically, the generated dynamic test case set includes multiple test cases for various input types such as normal input, edge input, and / or abnormal input. These inputs are for a single function or multiple functions, for control structures within a function, or for the entire code project.

[0102] Naturally, the executable program is run in the built runnable test environment using the generated dynamic test case set. The output recorded in the execution result generated by running the executable program may be of various types, such as normal output or abnormal output.

[0103] Specifically, for cases where the test environment for the source code can be set up and run, the generated dynamic test case set is used to run the executable program in the set up runnable test environment, generating dynamic program execution characteristics, including:

[0104] Insert corresponding monitoring code into key points in the source code; these key points include function entry / exit points, branch nodes, and exception throwing points.

[0105] A runnable actual test environment is built for the source code after the monitoring code is inserted, in order to generate an executable program;

[0106] The executable program is run in a built, runnable, actual test environment using a dynamic test case set, and the program execution trajectory is recorded; wherein, the program execution trajectory records each execution result and the temporal relationship of each execution result; the execution results include various output types generated after executing various input types;

[0107] The program's execution trajectory records the execution results, matches the inputs with the corresponding outputs to form an input-output mapping relationship, and determines multiple sets of input-output mapping relationships with sequential relationships.

[0108] Multiple sets of input-output mapping relationships with sequential succession are combined according to the temporal relationship recorded in the program execution trajectory to form a state transition sequence. The state transition sequence includes a starting input, multiple intermediate outputs or intermediate inputs and a final output.

[0109] Dynamic program execution characteristics are generated by utilizing input-output mapping relationships and state transition sequences.

[0110] Specifically, in multiple input / output mapping relationships with a sequential relationship, the output of the previous input / output mapping relationship becomes the input of the next input / output mapping relationship. Therefore, the previous input / output mapping relationship and the next input / output mapping relationship have a sequential relationship. In multiple input / output mapping relationships with a sequential relationship, the input in the first input / output mapping relationship is the first input, the output in the last input / output mapping relationship is the last output, the input in neither the first nor the last input / output mapping relationship is an intermediate output or intermediate input, and the output in neither the first nor the last input / output mapping relationship is an intermediate output or intermediate input.

[0111] Specifically, dynamic program execution characteristics are generated using input-output mapping relationships and state transition sequences, including:

[0112] Create a program execution data table to record dynamic program execution characteristics. Each row in the program execution data table is indexed by the program execution characteristic number or the short abbreviation of the program execution characteristic and is set with at least one text field.

[0113] The input-output mapping relationship and state transition sequence are filled into each row of the program execution data table using the program execution feature number or short abbreviation of the program execution feature as an index;

[0114] In each row, at least one text field is used to record the input and output in the input-output mapping relationship, or to record the state transition sequence.

[0115] Specifically, in the input-output mapping relationship, the input is a variable or class and a state related to the business logic, and the output is a variable or class and a state related to the business logic.

[0116] Naturally, the program execution data generated above records the relationships between variables and between variables and business logic in text or number form. In the subsequent knowledge graph construction, it can be quickly mapped to the execution relationships between variables or class nodes and between variables or class nodes and business logic nodes.

[0117] In some embodiments, the program execution data table is exemplified as follows: the fields in the nth row include: program execution feature A; input 1; output 2; the fields in the (n+1)th row include: program execution feature B: input 1; output 2; output 3; ...; output N.

[0118] To address the issue of not being able to set up a test environment to run the source code, a large model is used to virtually execute the software document, generating virtual program execution characteristics, including:

[0119] Generate prompts indicating the virtual execution of the large model;

[0120] The large model reads the code from the obtained software requirements specification based on the obtained prompt words to execute the required specific test environment, constructs a virtual test environment corresponding to the specific test environment, and generates a set of virtual test cases;

[0121] The large model uses the generated set of virtual test cases to execute the source code in a constructed virtual test environment to simulate real execution in the working environment and records the virtual execution results;

[0122] The large model analyzes the virtual execution results, matching each input in the virtual test case set with each output in each virtual execution result to form an input-output mapping relationship;

[0123] Virtual program execution features are achieved by utilizing input-output mapping relationships.

[0124] Specifically, situations where the test environment for the source code cannot be set up and run include: receiving instructions from a host computer, or interacting with physical communication devices.

[0125] Specifically, the step of generating feature nodes based on multiple types of features and determining the association relationships between feature nodes includes:

[0126] The feature nodes include: function nodes, variable or class nodes, control structure nodes, and static error nodes;

[0127] Each function node is generated corresponding to each function recorded in the function syntax features. Each function node is indexed by the function name, and the attributes of the function node include the adjacency vector of the function.

[0128] Each variable or class whose variable characteristics are recorded will generate a corresponding variable or class node. The variable or class node is indexed by the variable name or class name. The attributes of the variable or class node include: the function or control structure in which the variable or class is located.

[0129] Each control structure recorded in the control structure characteristics is used to generate a corresponding control structure node. The control structure node is indexed by the control structure identifier. The attributes of the control structure node include: control structure type and the functions in which the control structure is located.

[0130] Static error nodes are generated corresponding to the syntax error marker features. Static error nodes are indexed by static error type. The attributes of static error nodes include: the function name or variable name recorded in the static error.

[0131] When the adjacency state value in the adjacency vector of a function node is 1, a call association is established between the two function nodes pointed to by the adjacency state value.

[0132] Based on the function or control structure where the variable or class corresponding to the variable or class node is located, establish a reference association between the variable or class node and the function node, and establish a reference association between the variable or class node and the control structure node;

[0133] Based on the function containing the control structure corresponding to the control structure node, establish a reference association between the control structure node and the function node;

[0134] Based on the function or variable recorded in the static error type corresponding to the static error node, establish a reference association between the static error node and the variable or class node, and establish a reference association between the static error node and the function node.

[0135] Specifically, when there are two static error types, two static error nodes are generated, each corresponding to one of the two static error types. Referring to the previous explanation, each static error type records multiple functions or variables.

[0136] The above steps involve generating function nodes by indexing the functions recorded in the function syntax features, generating variable or class nodes by indexing the variables or classes recorded in the variable features, and generating control structure nodes by indexing the control structure identifiers recorded in the control structure features. Static error nodes are generated by indexing the syntax error markers. Call associations are established between function nodes based on the adjacency vectors recorded in the function syntax features. Reference associations are established between variable or class nodes and function nodes, and between variable or class nodes and control structure nodes, based on the functions or control structures containing the variables or classes recorded in the variable features. Call associations are established between control structure nodes and function nodes by using the control structure type recorded in the control structure features as an attribute of the control structure nodes. Reference associations are also established between static error nodes and variable or class nodes, and between static error nodes and function nodes.

[0137] Based on the code syntax features, function nodes, variable or class nodes, control structure nodes, and static error nodes are generated. Various relationships are established between function nodes, variable or class nodes, control structure nodes, and static error nodes to complete the initial construction of the knowledge graph.

[0138] Specifically, the control structure type is recorded in the defect cause description in the defect form data. Subsequently, based on the control structure type, such as conditional branching, loop structure, or exception handling, a relationship can be established between the control structure node and the defect node.

[0139] Specifically, the step of generating feature nodes based on multiple types of features and determining the association relationships between feature nodes further includes:

[0140] At least one functional intent element of the functional intent vector of each function recorded in the semantic features of the function is used to generate a functional intent node. The functional intent node is indexed by the identifier of the functional intent element. The attributes of the functional intent node include: the function that implements the functional intent element.

[0141] Based on the function name of the implementing functional intent element recorded in the attribute of the functional intent node, an implementation association is established between the functional intent node and the function node.

[0142] Functional intent nodes are thus generated based on the semantic features of functions. As a new type of feature node, functional intent nodes can further enrich the node types within the knowledge graph. Establishing implementation associations between function nodes and functional intent nodes can further enrich the number of nodes and the relationships between them within the knowledge graph.

[0143] The process of generating feature nodes based on multiple feature types and determining the relationships between feature nodes further includes:

[0144] Each business logic recorded in the business logic feature is used to generate a corresponding business logic node. The business logic node is indexed by the business logic name. The attributes of the business logic node include: at least one functional intent description.

[0145] Based on the functional intent description recorded in the attributes of the business logic node, an implementation association is established between the business logic node and the functional intent node.

[0146] Business logic nodes are thus generated based on business logic characteristics. As a new type of feature node, business logic nodes can further enrich the node types within the knowledge graph. Establishing implementation associations between business logic nodes and functional intent nodes can further enrich the number of nodes and the relationships between them within the knowledge graph, thereby forming paths from business logic nodes to function nodes.

[0147] Specifically, the step of generating feature nodes based on multiple types of features and determining the association relationships between feature nodes further includes:

[0148] Obtain the input-output mapping relationship recorded in the program execution characteristics;

[0149] When the input in the input-output mapping relationship is a variable or class and the output is a state related to business logic, an execution association is established between the variable or class node corresponding to the input and the business logic node corresponding to the output.

[0150] When the input and output in the input-output mapping relationship are both states related to business logic, an execution association is established between the business logic node corresponding to the input and the business logic node corresponding to the output.

[0151] When the input and output are both variables or classes in the input-output mapping relationship, an execution association is established between the variable or class node corresponding to the input and the variable or class node corresponding to the output.

[0152] When the input in the input-output mapping relationship is a state related to business logic and the output is a variable or class, an execution association is established between the business logic node corresponding to the input and the variable or class node corresponding to the output.

[0153] By establishing implementation and execution associations between variable or class nodes and business logic nodes, between variable or class nodes, and between business logic nodes, the relationships between nodes within the knowledge graph can be further enriched, thereby forming paths from functional intent nodes to variable or class nodes and function nodes.

[0154] Specifically, the defect case set is parsed to generate defect format data; defect nodes are generated based on the defect format data, and the relationship between defect nodes and feature nodes is determined, including:

[0155] The defect case set is parsed to generate defect data indexed by defect name. This defect data records the defect name and the defect cause description in text format.

[0156] Defect nodes are generated based on defect type data. Each defect node is indexed by the defect name. The attributes of the defect node include: a description of the defect cause.

[0157] Based on the business logic recorded in the defect cause description of the defect node, establish a causal relationship between the defect node and the business logic node.

[0158] Based on the variable or class name, control structure name or type, function name, static error type, and functional intent element recorded in the defect cause description of the defect node, establish a causal relationship between the variable or class node, control structure node, function node, static error node, functional intent node, and defect node.

[0159] Specifically, the defect case set is a collection of defect cases accumulated over a long period of code defect identification work targeting the industry. It records a rich variety of defect names, corresponding defect cause descriptions, and historical data on code defects.

[0160] Specifically, code defects can be related to function definitions (e.g., duplicate definitions), variables or classes (e.g., duplicate definitions), control structures (e.g., if statements without else statements; loops without exit clauses; infinite loops), the function's intended purpose, or business logic. They can also be static errors such as "parameter mismatch" or "undefined reference." Accordingly, the defect description should include at least one of the following: variable or class name, control structure name or type, function name, static error type, business logic, and intended purpose element.

[0161] Generating a new type of node, namely defect nodes, in addition to feature nodes can further enrich the types and number of nodes in the knowledge graph. Establishing causal relationships between defect nodes and feature nodes such as business logic nodes, variable or class nodes, control structure nodes, function nodes, static error nodes, and functional intent nodes can further enrich the relationships between nodes in the knowledge graph, thereby forming paths from defect nodes to various feature nodes.

[0162] The relationships between the feature nodes and between each feature node and the defect node, as determined above, together with the feature nodes and defect nodes, form a node-relationship-node triple within the knowledge graph, which can be used as a defect knowledge graph for code defect identification.

[0163] Specifically, this also includes: storing the knowledge graph as a graph database, containing a node table with indexes (such as names or identifiers) and attributes for each node; and a relationship table with indexes (such as relationship numbers), starting and target nodes, edge weights, and relationship types for each relationship. Specifically, different relationships between the aforementioned nodes are treated as the same type of relationship without distinction.

[0164] Specifically, it also includes: traversing the graph database to generate a knowledge graph visualization view, in which nodes with relationships are connected by connecting lines, and feature nodes or defect nodes are scattered in local areas.

[0165] Specifically, the defect propagation path is generated by tracing back from the defect node to the feature node, including:

[0166] Starting from the defect node, the path of defect tracing is obtained by passing through business logic nodes, functional intent nodes, or static error nodes, and finally reaching function nodes, variable or class nodes, or control structure nodes.

[0167] Based on the defect tracing path, a defect propagation path is generated, starting from a function node, variable node, class node, or control structure node and ending at the defect node. The generated defect propagation path is recorded using a directed graph.

[0168] The above process traces the defect source path from the defect node, through business logic nodes, functional intent nodes, or static error nodes, to function nodes, variable or class nodes, or control structure nodes. The reasoning logic is traceable and can be traced back to the root cause of the problem.

[0169] Based on the source tracing paths of each defect, starting from function nodes, variable or class nodes, or control structure nodes, and ending at defect nodes, a directed graph is used to record the relationships between nodes, thus determining the propagation paths of each defect. This helps to increase the interpretability of the defect identification process.

[0170] Each defect propagation path typically contains multiple nodes and multiple edges connecting those nodes. In multiple defect propagation paths, a single starting point may correspond to multiple defect nodes as endpoints, and vice versa. Therefore, each defect propagation path has its own influence weight.

[0171] The historical code defect data records the cumulative number of occurrences of each combination of defect cause description and defect name in the aforementioned defect case set. Based on the cumulative number of occurrences of each combination of defect cause description and defect name recorded in the historical code defect data, the influence weight of each historical propagation path can be determined, and thus the edge weight of each edge can be determined.

[0172] Specifically, the rules for determining the influence weight include: the more times it occurs, the greater the influence weight of the propagation path; the influence weight can increase linearly or non-linearly relative to the number of occurrences; for example, if 100 occurrences are used as a benchmark, then the influence weight is determined to be 0.2 when it occurs 20 times.

[0173] The influence weights of the historical propagation paths are evenly distributed to each edge in the historical propagation paths as edge weights. If any edge is recorded in multiple historical propagation paths, the edge weights allocated to that edge from each historical propagation path are summed and assigned to that edge as the adjusted edge weight.

[0174] For example, if the historical propagation path 1 recorded in the code defect history data is: A—B—C—D—E, and the historical propagation path 2 is: A—C—D—F, then the edge C—D appears in both historical propagation path 1 and historical propagation path 2. The weight of the edge C—D after sorting comes from the influence weight of historical propagation path 1 and the influence weight of historical propagation path 2.

[0175] Specifically, it also includes: determining the edge weights of each edge in the defect propagation path based on historical edge weights, and summing the edge weights of each edge in the defect propagation path as the predicted weights of the defect propagation path;

[0176] At least one defect propagation path with a relatively high prediction weight will be associated and displayed on the software documentation reading page.

[0177] The above displays either the defect propagation path with the highest prediction weight or multiple defect propagation paths with relatively high prediction weights, thus highlighting the most likely potential defects. Naturally, the number of defect propagation paths displayed can be customized, such as 1, 2, or 3.

[0178] Specifically, after the defect propagation path is generated, each generated defect propagation path is associated with and displayed with each code element recorded in the code project;

[0179] Obtain the judgment information returned by the user for each defect propagation path shown, and generate code defect identification results based on the judgment information.

[0180] Specifically, the identified defect propagation paths are displayed at each variable or class, function or control structure in the source code. Specifically, each variable or class node recorded in the defect propagation path is located in the source code, each function node recorded in the defect propagation path is located in the source code, and each control structure node recorded in the defect propagation path is located in the source code.

[0181] When reading source code, users can judge whether potential defects (such as the defect name recorded in the defect node) exist and whether the defect propagation path is correct based on the displayed defect propagation path (which may also display the defect cause description of the defect node, the functional intent description of the business logic node, etc.), and generate judgment information for potential defects and propagation paths.

[0182] Obtain the judgment information returned by the user, and statistically analyze and display all code defect identification results, including at least one potential defect after user confirmation and the defect propagation path.

[0183] Specifically, this also includes updating the impact weights of defect propagation paths or historical edge weights based on user feedback.

[0184] Specifically, users rate the correctness of the currently displayed defect propagation path (1-10), generating an evaluation score. This score is used to further adjust the influence weight of the defect propagation path. If the evaluation score is less than 5, the weight is reduced by a preset percentage (e.g., -0.2); if the evaluation score is greater than 5, the weight is increased by a preset percentage (e.g., +0.2). After the influence weight of the defect propagation path is adjusted, it can be further added as a new historical propagation path to update the historical edge weights of each side.

[0185] Specifically, this also includes: when a user modifies the software documentation based on the code defect identification results, extracting the current modifications, determining the new defect propagation paths generated by the modified variables, classes, control structures, and functions, and displaying these new defect propagation paths on the modified software documentation reading page. In this way, code defect identification can be iteratively performed on software files, which helps improve the efficiency of code defect identification and expand the coverage of defect identification.

[0186] Specifically, when the variables, control structures, or functions corresponding to a potential defect identified at a certain point are modified, the system displays the new defect and its propagation path, including:

[0187] Based on the potential defects and propagation paths given by the variables, control structures, and functions before modification, if a defect is identified and modified, the system obtains the information of the selected currently modified variables, control structures, and functions, and provides the new corresponding defects and propagation paths generated by the modified variables, control structures, and functions, thus providing analysis and prompts for new defects after code modification.

[0188] Specifically, if a variable is modified, the variable feature segment of that variable in the syntax data table is modified, while the rest remains unchanged; if a control structure is modified, the control structure feature segment of that control structure in the syntax data table is modified, while the rest remains unchanged; if a function is modified, the function syntax feature segment of that function in the syntax data table and the data content (function intent vector) of that function in the function semantic feature table are modified, while the rest remains unchanged. Then, the relationships between the changed code syntax features and function semantic features are updated within the defect knowledge graph; referring to the defect propagation path generation steps described above, the modified potential defects and new defect propagation paths are obtained.

[0189] Specifically, this also includes: processing the semantic features and business logic features of functions, generating implicit relationships between functions, and implicit relationships between functions and business logic.

[0190] First, preprocessing word segmentation is performed on the function semantic features and business logic features. Referring to the previous explanation, the function semantic features have been segmented into functional intent elements in the form of word combinations; the business logic features are preprocessed into word segments, forming combinations of multiple words as the segmented business logic features.

[0191] Then, the embedding model (such as sentence-transformers) is used to vectorize the semantic features of the function and the business logic features after word segmentation, generating semantic feature vectors of the function and business logic feature vectors.

[0192] Then, the cosine similarity between the semantic feature vector of the function and the feature vector of the business logic is calculated to obtain the similarity matrix. Each element in the similarity matrix is ​​the cosine similarity between the two data vectors, which is used to indicate the similarity between the two data vectors.

[0193] Finally, the feature data vectors with a cosine similarity greater than a preset value (such as 0.8) are output and back-quantized into functional semantic features within functional semantic features and business logic features within business logic features.

[0194] Specifically, the following large model prompt words are written to achieve the above steps: obtain the input function semantic features and business logic features, rearrange and combine the text information in each feature data, vectorize each feature text data, compare the vectorized feature vector data, calculate the similarity between them, and for two feature vector data with a similarity greater than 0.8, output them in the form of feature text data and give the similarity calculation value between them.

[0195] Furthermore, if the similarity between two functional intent vectors within a function's semantic features is high (>0.8), then a latent association can be determined between the two functional intent vectors. Similarly, if the similarity between a function's semantic features and a business logic feature is high (>0.8), then a latent association can be determined between the constructed function's semantic features and the business logic feature.

[0196] Naturally, referring to the aforementioned steps, for two functional intent vectors with implicit relationships, implicit relationships can be established between the functional intent nodes corresponding to each functional intent vector or between the function nodes corresponding to each functional intent vector, and updated in the knowledge graph, which will not be elaborated further.

[0197] Naturally, referring to the aforementioned steps, for function semantic features and business logic features with implicit relationships, implicit relationships can be established between the functional intent nodes corresponding to the function semantic features or between the function nodes and the business logic nodes corresponding to the business logic features, and updated to the knowledge graph, which will not be elaborated further.

[0198] A specific embodiment of the present invention discloses a code defect identification system based on multi-type feature association and propagation analysis, such as... Figure 2 As shown, it includes:

[0199] The feature node generation and association module is used to parse software documents, generate multiple types of features, generate feature nodes based on multiple types of features, and determine the association relationships between feature nodes.

[0200] The defect node generation and association module is used to parse the defect case set, generate defect form data, generate defect nodes based on the defect form data, and determine the association relationship between defect nodes and feature nodes.

[0201] The defect propagation analysis module is used to generate a defect propagation path by tracing back from the defect node to the feature node using the established relationships.

[0202] The code defect identification module is used to associate and display the generated defect propagation path on the software documentation reading page, obtain the judgment information returned by the user regarding the displayed defect propagation path, and generate code defect identification results based on the judgment information.

[0203] A specific embodiment of the present invention discloses a code defect identification system based on multi-type feature association and propagation analysis, such as... Figure 3 As shown. This system adopts a B / S architecture and includes:

[0204] The resource layer includes the operating system, distributed computing framework, file storage, and graph database; the operating system and distributed computing framework are the basic hardware and software resources, the file storage is used for software documentation files, and the graph database realizes the storage and display of knowledge graphs.

[0205] The data layer generates data such as acquired software code, requirements / design documents, business domain knowledge, defect knowledge graphs, and defect issues.

[0206] The system layer adopts a modular design, divided into six core modules: data acquisition, feature processing, knowledge graph, large-scale model application, propagation analysis, and user interaction. The data acquisition module includes upload parsing and API interface; the feature processing module includes code syntax features, function semantic features, business logic features, and program execution features; the knowledge graph module includes node construction and graph association; the large-scale model reasoning module includes implicit association mining and virtual execution enhancement; the propagation analysis module includes propagation path tracing and iterative propagation analysis; and the user interaction module includes defect result display and defect problem output.

[0207] The service layer provides application services including code defect identification, defect tracking and location, hidden defect identification, and code defect mapping.

[0208] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0209] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A code defect identification method based on multi-type feature association and propagation analysis, characterized in that, include: Parse software documentation and generate multiple types of features; Feature nodes are generated based on multiple feature types. Determine the relationships between feature nodes; Analyze the defect case set and generate defect format data; Defect nodes are generated based on defect-form data. Determine the relationship between defect nodes and feature nodes; Using the established relationships, a defect propagation path is generated by tracing back from the defect node to the feature node. The generated defect propagation path is displayed on the software documentation reading page. The user's judgment information returned regarding the displayed defect propagation path is obtained, and code defect identification results are generated based on the judgment information.

2. The method as described in claim 1, characterized in that, The software documentation includes: code project, executable program, design document, and software requirements specification; The multi-type features include: code syntax features, function semantic features, business logic features, and program execution features; The code syntax features include function syntax features, variable features, control structure features, and syntax error marking features; The semantic features of the function include explicit functional intent vectors and implicit functional intent vectors; The business logic features are indexed by the business logic name and recorded in text form as at least one functional intent description. The program execution characteristics include dynamic program execution characteristics and virtual program execution characteristics.

3. The method as described in claim 2, characterized in that, The parsing software document generates multiple types of features, including: Analyze the code project to generate function syntax features, variable features, and control structure features; obtain static error message text generated after the code reading tool compiles the source code and generate syntax error marker features; Based on the function design specifications in the design document, analyze the function comments, variable names, and logical comments in the source code to generate explicit functional intent vectors; based on the function design specifications in the design document, perform contextual analysis on the source code to generate missing comments and implicit functional intent vectors.

4. The method as described in claim 2, characterized in that, The parsing software document generates multiple types of features, including: Extract multiple business logics recorded in the software requirements specification, and break down each business logic into at least one functional intent description recorded in text form; based on the functional intent description, generate business logic features, wherein the business logic features are indexed by the business logic name and recorded in text form as at least one functional intent description; For cases where the test environment for the source code can be set up and run, the executable program is run in the runnable test environment using a test case set to generate dynamic program execution characteristics; for cases where the test environment for the source code cannot be set up and run, a large model is used to virtually execute the software document to generate virtual program execution characteristics.

5. The method as described in claim 1, characterized in that, The generation of feature nodes based on multiple feature types Determine the relationships between feature nodes, including: The feature nodes include: function nodes, variable or class nodes, control structure nodes, and static error nodes; Each function node is generated corresponding to each function recorded in the function syntax features. Each function node is indexed by the function name, and the attributes of the function node include the adjacency vector of the function. Each variable or class whose variable characteristics are recorded will generate a corresponding variable or class node. The variable or class node is indexed by the variable name or class name. The attributes of the variable or class node include: the function or control structure in which the variable or class is located. Each control structure recorded in the control structure characteristics is used to generate a corresponding control structure node. The control structure node is indexed by the control structure identifier. The attributes of the control structure node include: control structure type and the functions in which the control structure is located. Static error nodes are generated corresponding to the syntax error marker features. Static error nodes are indexed by static error type. The attributes of static error nodes include: the function name or variable name recorded in the static error. When the adjacency state value in the adjacency vector of a function node is 1, a call association is established between the two function nodes pointed to by the adjacency state value. Based on the function or control structure where the variable or class corresponding to the variable or class node is located, establish a reference association between the variable or class node and the function node, and establish a reference association between the variable or class node and the control structure node; Based on the function containing the control structure corresponding to the control structure node, establish a reference association between the control structure node and the function node; Based on the function or variable recorded in the static error type corresponding to the static error node, establish a reference association between the static error node and the variable or class node, and establish a reference association between the static error node and the function node.

6. The method as described in claim 5, characterized in that, The generation of feature nodes based on multiple feature types Determining the relationships between feature nodes also includes: The feature node also includes: a functional intent node; At least one functional intent element of each functional intent vector recorded in the semantic features of the function is used to generate a functional intent node. The functional intent node is indexed by the functional intent vector. The attributes of the functional intent node include: the function that implements the functional intent vector. Based on the function name that implements the functional intent vector recorded in the attributes of the functional intent node, an implementation association is established between the functional intent node and the function node. The feature nodes also include: business logic nodes; Each business logic recorded in the business logic feature is used to generate a corresponding business logic node. The business logic node is indexed by the business logic name. The attributes of the business logic node include: at least one functional intent description. Based on the functional intent description recorded in the attributes of the business logic node, an implementation association is established between the business logic node and the functional intent node.

7. The method as described in claim 6, characterized in that, The generation of feature nodes based on multiple feature types Determining the relationships between feature nodes also includes: Obtain the input-output mapping relationship recorded in the program execution characteristics; When the input in the input-output mapping relationship is a variable or class and the output is a state related to business logic, an execution association is established between the variable or class node corresponding to the input and the business logic node corresponding to the output. When the input and output in the input-output mapping relationship are both states related to business logic, an execution association is established between the business logic node corresponding to the input and the business logic node corresponding to the output. When the input and output are both variables or classes in the input-output mapping relationship, an execution association is established between the variable or class node corresponding to the input and the variable or class node corresponding to the output. When the input in the input-output mapping relationship is a state related to business logic and the output is a variable or class, an execution association is established between the business logic node corresponding to the input and the variable or class node corresponding to the output.

8. The method as described in claim 7, characterized in that, Also includes: The defect case set is parsed to generate defect data indexed by defect name. The defect data records the defect name and the defect cause description in text form. Defect nodes are generated based on defect type data. Each defect node is indexed by the defect name. The attributes of the defect node include: a description of the defect cause. Based on the business logic recorded in the defect cause description of the defect node, establish a causal relationship between the defect node and the business logic node. Based on the variable or class name, control structure name or type, function name, static error type, and functional intent element recorded in the defect cause description of the defect node, establish a causal relationship between the variable or class node, control structure node, function node, static error node, functional intent node, and defect node.

9. The method as described in claim 8, characterized in that, The step of generating a defect propagation path by tracing back from the defect node to the feature node using the determined association relationship includes: Starting from the defect node, the path of defect tracing is obtained by passing through business logic nodes, functional intent nodes, or static error nodes, and finally reaching function nodes, variable or class nodes, or control structure nodes. Based on the defect tracing path, a defect propagation path is generated, starting from a function node, variable node, class node, or control structure node and ending at a defect node. The generated defect propagation path is recorded using a directed graph. Accordingly, based on historical data of code defects, historical propagation paths and their impact weights are generated; The influence weight of the historical propagation path is evenly distributed to each edge in the historical propagation path as the edge weight; if any edge is recorded in multiple historical propagation paths, the edge weights distributed to the edge multiple times are accumulated and assigned to the edge as the historical edge weight. The edge weights in the defect propagation path are determined based on the historical edge weights, and the edge weights of each edge in the defect propagation path are summed up to obtain the predicted weight of the defect propagation path. At least one defect propagation path with a relatively high prediction weight will be associated and displayed on the software documentation reading page.

10. A code defect identification system based on multi-type feature association and propagation analysis, characterized in that, include: The feature node generation and association module is used to parse software documents and generate multiple types of features; Feature nodes are generated based on multiple feature types. Determine the relationships between feature nodes; The defect node generation and association module is used to parse the defect case set and generate defect format data; Defect nodes are generated based on defect-form data. Determine the relationship between defect nodes and feature nodes; The defect propagation analysis module is used to generate a defect propagation path by tracing back from the defect node to the feature node using the established relationships. The code defect identification module is used to associate and display the generated defect propagation path on the software documentation reading page, obtain the judgment information returned by the user regarding the displayed defect propagation path, and generate code defect identification results based on the judgment information.

Images