A software defect diagnosis method and system based on a knowledge graph and a medium

Abstract

The application discloses a kind of software defect diagnosis method, system and medium based on knowledge graph, comprising the following steps: collecting code analysis, running log, test, version change and historical defect data, and constructing the trusted software defect knowledge graph comprising source mapping relationship, evidence entity node confidence and relationship edge confidence;The target defect evidence set and the trusted software defect knowledge graph are input into the improved CompGCN software defect correlation diagnosis model, and the forward, reverse and self-connection messages are subjected to trusted weighting and double-gated propagation, to obtain the candidate root cause entity set and root cause matching score;Version constraint diagnosis subgraph is generated, multi-hop reasoning is carried out in combination with code dependency, event timing and defect propagation direction, cascading abnormalities are identified and candidate root cause entities are corrected, and root cause entity ranking results, defect positioning results and diagnosis reports are output, to improve the accuracy of software defect root cause diagnosis and code positioning.

Description

Technical Field

[0001] This invention relates to the field of software defect analysis and intelligent diagnosis technology, specifically to a software defect diagnosis method, system, and medium based on knowledge graphs. Background Technology

[0002] As software systems grow in scale, the internal module call relationships, data dependencies, control dependencies, and version evolution relationships become increasingly complex. Anomalies generated during software operation often involve multiple functions, code statements, and execution stages. Software defects not only manifest as abnormal runtime logs, failed test cases, or exception stack traces, but can also propagate downstream along code call chains and data dependency chains, generating multiple interconnected anomalies. Therefore, it is difficult to accurately distinguish between the root cause of a defect and cascading anomalies based solely on a single log record, a single test result, or local code characteristics.

[0003] Existing software defect diagnosis methods typically employ static code analysis, dynamic log analysis, test result comparison, or machine learning classification. Static code analysis can identify potential code risks but struggles to reflect the actual operational state of the software. Log analysis relies on pre-defined rules and keywords, making it prone to misjudgments when faced with changes in log format, missing anomaly information, or multiple similar defect symptoms. While machine learning-based diagnostic methods can extract data features, they usually transform data from different sources into relatively independent feature vectors, making it difficult to fully express the multiple relationships between software entities, defect symptoms, runtime events, version changes, and historical remediation measures.

[0004] Some existing technologies employ knowledge graphs to organize software defect knowledge, describing the relationships between software modules, functions, anomalies, and defect causes through entities and relations. However, evidence from different sources varies in completeness, generation time, software version, and reliability. Existing knowledge graph diagnostic methods typically apply the same weight to different pieces of evidence and relations, making it easy for low-reliability logs, outdated version data, or accidental co-occurrences to interfere with diagnostic results. Furthermore, traditional graph neural networks often fail to adequately consider software version compatibility and the code scope corresponding to the target defect when propagating relational messages, allowing information from other versions or irrelevant code regions to be propagated to the current diagnostic target.

[0005] Therefore, how to provide a software defect diagnosis method, system, and medium based on knowledge graphs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose a software defect diagnosis method, system, and medium based on knowledge graphs. This invention constructs a reliable software defect knowledge graph by processing code analysis data, runtime log data, test data, version change data, and historical defect data of the target software. This graph includes source mapping relationships, evidence entity node confidence, and relationship edge confidence. An improved CompGCN software defect association diagnosis model is used to generate positive entity relationship combination messages, reverse entity relationship combination messages, and self-connected messages. Weighting is applied based on message confidence weights, and dual gating propagation of version context and code scope is performed in conjunction with the target software version and the target defect-related software entity set. Furthermore, a version constraint diagnosis subgraph is generated, and multi-hop reasoning is performed based on code dependencies, event sequence, and defect propagation direction. Path diagnosis scores, defect symptom coverage, propagation direction consistency, and cross-source path support consistency are calculated. Cascading anomalies are identified and candidate root cause entities are corrected. Finally, root cause entity ranking results, defect location results, and defect diagnosis reports are obtained, thereby improving the accuracy of defect root cause diagnosis, code location positioning, and diagnostic path interpretation in complex software environments.

[0007] A software defect diagnosis method, system, and medium based on knowledge graphs according to embodiments of the present invention include the following steps:

[0008] S1. Collect code analysis, runtime logs, test data, version change data, and historical defect data of the target software. After processing by time, entity, and version identifiers, obtain two types of defect evidence sets, the target software version, and the time when the target defect occurred.

[0009] S2. Based on the two types of defect evidence sets, establish software, defect, and evidence entities and the relationships between entities, construct a credible software defect knowledge graph, and obtain the set of software entities associated with the target defect;

[0010] S3. Input the target defect evidence set and the trusted software defect knowledge graph into the improved CompGCN software defect association diagnosis model, perform trusted weighting and dual-gated propagation on the three types of messages, and obtain the candidate root cause entity set and root cause matching score.

[0011] S4. Determine the scope of diagnosis propagation based on the target defect evidence set, target software version, target defect associated software entity set, and candidate root cause entity set, and generate a version-constrained diagnostic subgraph.

[0012] S5. In the version constraint diagnostic subgraph, multi-hop reasoning is performed by combining code dependencies, event timing and defect propagation direction to obtain candidate diagnostic paths, path diagnostic scores, defect symptom coverage and propagation direction consistency.

[0013] S6. Calculate cross-source path support consistency, identify cascade anomalies and correct candidate root cause entities based on the evaluation results of each path, and obtain root cause entity ranking results and defect location results.

[0014] S7. Generate a defect diagnosis report based on the root cause entity sorting results, defect location results, and candidate diagnosis paths; receive the diagnosis confirmation results; and update the trusted software defect knowledge graph.

[0015] Optionally, step S2 includes the following steps:

[0016] S21. Construct software modules, classes, functions, and code statements as software entity nodes, and construct defect symptoms, defect causes, and remediation measures as defect entity nodes.

[0017] S22. Construct evidence entity nodes from static analysis results, abnormal running events, failed test cases, and version change records, and establish relationship edges between each entity node;

[0018] S23. Relationship edges include invocation, inclusion, data dependency, control dependency, execution, test coverage, modification, triggering, propagation, attribution, and repair relationship edges;

[0019] S24. Based on the code, event, version, and defect identifier, establish the source mapping relationship between each source of evidence and entity nodes and relation edges;

[0020] S25. Map the evidence in the target defect evidence set to the corresponding software entity nodes according to the source mapping relationship to obtain the set of software entities associated with the target defect;

[0021] S26. Calculate the confidence level of the evidence entity nodes and the confidence level of the relation edges, and write the corresponding confidence levels into the evidence entity nodes and relation edges to form a trusted software defect knowledge graph.

[0022] Optionally, step S3 includes the following steps:

[0023] S31. Generate initial representations of entity nodes based on their type, code, evidence, time, and version attributes, and generate initial representations of relation edges based on relation type and propagation direction.

[0024] S32. Generate forward entity relationship combination messages and reverse entity relationship combination messages through entity relationship combination operators, and generate self-connection messages based on the initial representation of entity nodes;

[0025] S33. Determine the confidence of nodes and relation edges corresponding to forward and reverse messages based on the source mapping relationship, and aggregate the source evidence confidence of the corresponding entities to determine the trust weight of self-connected messages;

[0026] S34. Based on the target software version, the set of software entities associated with the target defect, and the message trust weight, perform dual gating of version context and code scope on the three types of messages;

[0027] S35. Generate a target defect association representation by aggregating gating associated messages, calculate the degree of matching between the representation and the defect cause entity representation, and obtain the candidate root cause entity set and root cause matching score.

[0028] Optionally, step S34 includes the following steps:

[0029] S341. Determine the software version corresponding to the message based on the source mapping relationship and the version identifier of the entity involved in the message, and calculate the version compatibility coefficient in combination with the target software version;

[0030] S342. Based on the source mapping relationship and the entity relationships in the trusted software defect knowledge graph, determine the software entities that are directly involved or indirectly related to various messages;

[0031] S343. Calculate the code scope association coefficient based on the call reachability, data dependency, and control dependency between the associated software entities and the set of associated software entities of the target defect;

[0032] S344, combined with version compatibility coefficient, code scope correlation coefficient and message trust weight, yields the propagation gating coefficients for forward, reverse and self-connected messages;

[0033] S345. Adjust the propagation strength of forward, reverse and self-connected messages using the propagation gating coefficient to form a set of gated associated messages.

[0034] Optionally, step S4 includes the following steps:

[0035] S41. Take the defect symptom entity, abnormal operation event entity and failed test case entity corresponding to the target defect as the diagnostic starting entity, and take the candidate root cause entity as the diagnostic target entity.

[0036] S42. Extend the neighborhood from the diagnostic starting entity along the call, data dependency, control dependency, execution, modification, trigger, propagation and attribution relationships to the diagnostic target entity;

[0037] S43. Calculate the cumulative confidence based on the confidence of nodes and relation edges in the extended path, and determine the diagnostic propagation boundary based on the code dependency reachability between related software entities;

[0038] S44. Delete entity nodes and relation edges that exceed the diagnostic propagation boundary or are incompatible with the target software version, retain the relevant association structure, and generate a version constraint diagnostic subgraph.

[0039] Optionally, step S5 includes the following steps:

[0040] S51. Search the version constraint diagnostic subgraph for multi-hop association paths from the diagnostic starting entity to the candidate root cause entity to form an initial diagnostic path set.

[0041] S52. Compare the code calls, data dependencies, control dependencies, and defect propagation directions in the paths, calculate the degree of consistency in propagation directions, and delete paths with opposite propagation directions;

[0042] S53. Based on the occurrence time of abnormal running events, test failures, code modifications, and target defects, delete the initial diagnostic paths that do not meet the event sequence constraints;

[0043] S54. Calculate the cumulative confidence of the path based on the confidence of nodes and relation edges in the path, and calculate the path length attenuation and defect symptom coverage based on the path hop count and the symptom entity coverage ratio.

[0044] S55. The candidate diagnostic path and path diagnostic score are obtained by combining the cumulative confidence of the fusion path, the root cause matching score, the path length attenuation degree, the coverage of defect symptoms, and the consistency of the propagation direction.

[0045] Optionally, step S6 includes the following steps:

[0046] S61. Calculate the basic diagnostic score of the candidate root cause entity based on the root cause matching score of the candidate root cause entity and the path diagnostic score of its corresponding candidate diagnostic path.

[0047] S62. Compare the software entities, software versions, and propagation directions associated with the candidate root cause entities, and classify the candidate root cause entities with incompatible versions or opposite propagation directions into root cause conflict groups.

[0048] S63. Extract four types of source evidence from candidate diagnostic paths based on the source mapping relationship, form a subset of path evidence, and calculate cross-source path support consistency.

[0049] S64. Identify cascade anomalies based on the consistency of cross-source path support, the degree of coverage of defective symptoms, and the degree of consistency of propagation direction, and correct the basic diagnostic scores within the root cause conflict group.

[0050] S65. Sort the candidate root cause entities according to the corrected diagnostic scores, and determine the defect location results of software modules, functions or code statements based on the highest score path corresponding to the first-ranked entity.

[0051] Optionally, S64 includes the following steps:

[0052] S641. Extract supporting evidence for the current candidate root cause entity and conflicting evidence pointing to other candidate root cause entities from the path evidence subset.

[0053] S642. Calculate the corresponding diagnostic score increment and decrement based on the consistency of cross-source pathway support, the degree of independence of evidence sources, the degree of coverage of defective symptoms, and the degree of consistency of propagation direction.

[0054] S643. Identify cascading abnormal entities based on the code dependency direction and defect propagation order between the software entities associated with the candidate root cause entities and their downstream abnormal entities.

[0055] S644. Calculate the cascading anomaly suppression amount based on the path hop count and relation edge confidence between related software entities, and obtain the corrected diagnostic score by combining the diagnostic score increment and decrement.

[0056] A software defect diagnosis system based on knowledge graphs according to an embodiment of the present invention is characterized by comprising the following modules:

[0057] The evidence processing module is used to process the target software's code analysis, runtime logs, tests, version changes, and historical defect data to obtain two types of defect evidence sets, the target software version, and the time when the target defect occurred.

[0058] The knowledge graph construction module is used to establish source mapping relationships, calculate the confidence of nodes and relationship edges, construct a trustworthy software defect knowledge graph, and generate a set of software entities associated with the target defect.

[0059] The correlation diagnosis module is used to generate three types of messages through the improved CompGCN software defect correlation diagnosis model, and perform trusted weighting and dual-gated propagation to obtain the candidate root cause entity set and root cause matching score.

[0060] The diagnostic subgraph generation module is used to generate a version-constrained diagnostic subgraph based on the target defect evidence set, the target software version, the target defect associated software entity set, and the candidate root cause entity set.

[0061] The path reasoning module is used to perform multi-hop reasoning by combining code dependencies, event timing and defect propagation direction to obtain candidate diagnostic paths and corresponding path evaluation results;

[0062] The conflict correction module is used to calculate cross-source path support consistency, identify cascading anomalies, and correct candidate root cause entities, thereby obtaining root cause entity ranking results and defect location results.

[0063] The diagnostic output module is used to generate defect diagnostic reports, receive diagnostic confirmation results, and update the trusted software defect knowledge graph based on the diagnostic confirmation results.

[0064] A storage medium, characterized in that it stores executable instructions for being read by a computer processor to perform the method of any one of claims 1 to 8.

[0065] The beneficial effects of this invention are: by uniformly processing code analysis data, runtime log data, test data, version change data, and historical defect data, this invention constructs multiple relationship associations between software entities, defect entities, and evidence entities, enabling software modules, functions, code statements, abnormal runtime events, failed test cases, defect symptoms, and defect causes to be analyzed in association within the same knowledge graph, thus avoiding the problem that a single data source cannot fully reflect the formation and propagation process of defects.

[0066] This invention establishes source mapping relationships between evidence from various sources, entity nodes, and relational edges, and calculates the confidence levels of evidence entity nodes and relational edges. This enables the differentiation of differences in the completeness, generation time, version, and source reliability of different pieces of evidence, reducing the interference of missing evidence, expired evidence, and accidental associations on diagnostic results, and improving the accuracy and traceability of the trusted software defect knowledge graph.

[0067] This invention employs an improved CompGCN software defect association diagnosis model, which performs trusted weighting on positive entity relationship combination messages, negative entity relationship combination messages, and self-connection messages. It also implements dual gating of version context and code scope by combining the target software version and the set of software entities associated with the target defect. This suppresses the propagation of information from incompatible software versions and irrelevant code regions, retains entities and relationship features strongly associated with the target defect, and improves the reliability of candidate root cause entity identification.

[0068] This invention generates a version constraint diagnostic subgraph based on the target defect evidence set, target software version, set of software entities associated with the target defect, and candidate root cause entity set. It then performs multi-hop inference by combining code dependencies, event sequence, and defect propagation direction. By calculating the path diagnostic score based on the cumulative confidence of the comprehensive path, root cause matching score, path length decay, defect symptom coverage, and consistency of propagation direction, it can eliminate invalid paths that violate software execution logic and temporal order, thereby improving the accuracy of defect propagation path analysis and code location.

[0069] This invention supports consistency across cross-source paths by calculating static analysis evidence, runtime log evidence, test evidence, and version change evidence. It corrects conflicting candidate root cause entities and identifies cascading anomalies based on code dependency direction and defect propagation order, avoiding the misidentification of downstream anomalies as defect root causes. Finally, it generates a defect diagnosis report containing root cause entity ranking results, defect location results, and candidate diagnostic paths, enabling diagnostic results to be traced back to corresponding evidence, software entities, and propagation relationships. Furthermore, it allows for continuous updating of the trusted software defect knowledge graph based on diagnostic confirmation results. Attached Figure Description

[0070] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0071] Figure 1 This is a flowchart of a software defect diagnosis method, system, and medium based on knowledge graphs proposed in this invention;

[0072] Figure 2 This is a flowchart of the improved CompGCN software defect association diagnosis model proposed in this invention.

[0073] Figure 3 This invention presents a software entity dependency topology and anomaly heatmap.

[0074] Figure 4 This is the relationship strength matrix diagram proposed in this invention;

[0075] Figure 5 This is a diagram showing the candidate root cause ranking results proposed in this invention;

[0076] Figure 6 This is a timeline curve of abnormal propagation proposed in this invention. Detailed Implementation

[0077] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0078] refer to Figures 1-6 A software defect diagnosis method, system, and medium based on knowledge graphs, comprising the following steps:

[0079] S1. Collect code analysis, runtime logs, test data, version change data, and historical defect data of the target software. After processing by time, entity, and version identifiers, obtain two types of defect evidence sets, the target software version, and the time when the target defect occurred.

[0080] S2. Based on the two types of defect evidence sets, establish software, defect, and evidence entities and the relationships between entities, construct a credible software defect knowledge graph, and obtain the set of software entities associated with the target defect;

[0081] S3. Input the target defect evidence set and the trusted software defect knowledge graph into the improved CompGCN software defect association diagnosis model, perform trusted weighting and dual-gated propagation on the three types of messages, and obtain the candidate root cause entity set and root cause matching score.

[0082] S4. Determine the scope of diagnosis propagation based on the target defect evidence set, target software version, target defect associated software entity set, and candidate root cause entity set, and generate a version-constrained diagnostic subgraph.

[0083] S5. In the version constraint diagnostic subgraph, multi-hop reasoning is performed by combining code dependencies, event timing and defect propagation direction to obtain candidate diagnostic paths, path diagnostic scores, defect symptom coverage and propagation direction consistency.

[0084] S6. Calculate cross-source path support consistency, identify cascade anomalies and correct candidate root cause entities based on the evaluation results of each path, and obtain root cause entity ranking results and defect location results.

[0085] S7. Generate a defect diagnosis report based on the root cause entity sorting results, defect location results, and candidate diagnosis paths; receive the diagnosis confirmation results; and update the trusted software defect knowledge graph.

[0086] In this embodiment, S1 includes:

[0087] Collect code analysis data, runtime log data, test data, version change data, and historical defect data of the target software.

[0088] Code analysis data includes software module names, class names, function names, code statement locations, function call relationships, data dependencies, control dependencies, variable definition locations, variable usage locations, conditional branch locations, and exception handling locations. Code analysis data can be obtained using abstract syntax tree analysis tools, call graph analysis tools, control flow analysis tools, and data flow analysis tools.

[0089] For software developed using Java, class files, method declarations, method calls, conditional statements, exception handling, and variable assignment statements can be parsed. For software developed using C, C++, Python, or other languages, the corresponding language's syntax analysis tools can be used to generate structured code analysis data. This implementation method does not limit the target software's development language.

[0090] Operation log data includes log occurrence time, log level, request identifier, thread identifier, exception type, exception stack trace, log template, call location, execution status, and runtime context. For distributed software, service identifier, instance identifier, call chain identifier, and node timestamp can also be collected.

[0091] Log records belonging to the same execution process are grouped into a runtime event sequence based on request identifier, thread identifier, or call chain identifier. The runtime event sequence is arranged according to the occurrence time and is used to reflect the function execution order and exception propagation order before and after the target defect occurs.

[0092] Test data includes test case identifiers, test inputs, expected results, actual results, test execution time, software entities covered by the test, assertion failure locations, and test failure information. Software entities covered by the test include software modules, classes, functions, and code statements.

[0093] Version change data includes software version identifier, branch identifier, parent version identifier, version generation time, code commit history, file modification history, function modification history, code statement change history, and developer commit notes. Version change data is used to determine whether current evidence is applicable to the target software version and whether historical defect knowledge can be transferred to the current version.

[0094] Historical defect data includes historical defect symptoms, historical anomalies, historical failed test cases, historical defect causes, historical defect code locations, historical diagnostic paths, historical remediation measures, and regression test results. Historical defect data prioritizes defect records that have undergone root cause identification, code repair, and regression verification.

[0095] The collected data undergoes format standardization, duplicate data cleanup, invalid field removal, and identifier conversion. Code file paths are uniformly converted to standard paths, function names are uniformly converted to fully qualified names including namespace, class name, and function name, log times are uniformly converted to the same time base, and version numbers are uniformly converted to comparable version identifiers.

[0096] Abnormal runtime events are identified based on log templates, exception stack traces, and call locations. An abnormal runtime event must include at least the exception type, occurrence time, corresponding software entity, and software version. When multiple log records describe the same exception, they are merged into a single abnormal runtime event, while retaining the source identifiers of each original log record.

[0097] Time-align code analysis data, runtime log data, test data, and version change data. Set a data extraction time window centered on the target defect occurrence time, and retain runtime logs and test records within the time window. Code commit times earlier than the target software build time, and whose modifications exist in the target software version's version change records, can be included in the target defect evidence set.

[0098] The time of occurrence of the target defect can be determined by the time the critical exception log first appears, the time the failed test case ends, or the time the business failure status is first generated. When multiple times exist simultaneously, the time that allows for the earliest confirmation of the target defect's occurrence is taken as the target defect occurrence time, while other times are retained as supplementary evidence.

[0099] Configure unique entity identifiers for software modules, classes, functions, code statements, abnormal runtime events, failed test cases, version change records, defect symptoms, defect causes, and remediation measures.

[0100] Software entity identifiers are formed by combining software version identifier, file path, class name, function name, and code location; abnormal event identifiers are formed by combining request identifier, exception type, and occurrence time; test case identifiers are formed by combining test project identifier and test case number; and defect entity identifiers are formed by combining defect category, defect description, and historical confirmation records.

[0101] The target defect evidence set consists of static analysis results, abnormal runtime events, failed test cases, and version change records corresponding to the current target defect. The historical defect evidence set consists of historical defect records that have completed root cause identification and remediation verification, along with their associated evidence.

[0102] The target software version is determined based on the current deployment package, build history, or runtime environment information. This target software version is used for subsequent version compatibility checks and the generation of version constraint diagnostic subgraphs.

[0103] In this embodiment, the target defect evidence set includes order creation failure test cases, inventory deduction exception logs, null pointer exception stack traces, static analysis results of the inventory verification function, and target version code commit records. The time of occurrence of the target defect is determined to be the time when the order creation failure log first appears.

[0104] In this embodiment, S2 includes:

[0105] Software entity nodes, defect entity nodes, and evidence entity nodes are constructed based on the target defect evidence set and the historical defect evidence set.

[0106] Software entity nodes include software module nodes, class nodes, function nodes, and code statement nodes. Defect entity nodes include defect symptom nodes, defect cause nodes, and remediation measure nodes. Evidence entity nodes include static analysis result nodes, abnormal runtime event nodes, failed test case nodes, and version change record nodes.

[0107] When the same software entity has different implementations in different software versions, corresponding software entity nodes are created for each version, and the inheritance or modification relationship between entities is recorded using version relationships to avoid directly merging the code states in different versions.

[0108] Establish relational edges between entity nodes. Establish containment relationships between software modules and classes, between classes and functions, between functions, and between code statements.

[0109] An execution relationship edge is established between abnormal runtime events and their corresponding functions or code statements; a test coverage relationship edge is established between failed test cases and the covered software entities; and a modification relationship edge is established between version change records and the modified software entities.

[0110] Triggering relationships are established between abnormal operation events and defect symptoms; propagation relationships are established between defect symptoms; attribution relationships are established between defect symptoms and defect causes; and repair relationships are established between defect causes and repair measures.

[0111] Each relation edge must record at least the relation type, propagation direction, corresponding software version, source evidence identifier, and establishment time. For calls, data dependencies, control dependencies, executions, propagations, and attribution relations with clear directions, both the forward relation and the reverse tracing direction must be recorded.

[0112] A source mapping relationship is established based on code entity identifiers, event identifiers, version identifiers, and defect identifiers. The source mapping relationship records the correspondence between raw data and evidence entity nodes, software entity nodes, defect entity nodes, and relational edges.

[0113] For example, function names and lines of code in the exception stack are mapped to corresponding function nodes and code statement nodes, failed test cases are mapped to the software entity nodes they cover, version change records are mapped to the modified software entity nodes, and historical repair records are mapped to the corresponding defect cause nodes and repair measure nodes.

[0114] Based on the source mapping relationship, each piece of evidence in the target defect evidence set is mapped to the corresponding software entity node, forming a set of software entities associated with the target defect.

[0115] The set of software entities associated with the target defect can include software entities directly pointed to by the exception stack, software entities covered by failed test cases, software entities executed within the target time window, and software entities involved in recent version changes.

[0116] For each evidence entity node, the confidence level of the evidence entity node is calculated. The calculation process comprehensively considers the completeness of the evidence fields, the time of evidence generation, the version of the evidence, the reliability of the evidence source, and the degree of mutual support between evidence from different sources.

[0117] The completeness of evidence fields is determined based on the effective proportion of necessary fields. Necessary fields for abnormal operation events may include exception type, occurrence time, call location, and software version; necessary fields for failed test cases may include test input, failure status, coverage location, and execution time; necessary fields for version change records may include version identifier, modification location, and commit time.

[0118] The closer the time of evidence production is to the time of occurrence of the target defect, the higher its timeliness level. When the software version of the evidence is the same as the target software version, the version applicability level is set to the highest; when the evidence comes from a directly preceding compatible version of the target software version, the applicability level is reduced by one level; as the version distance continues to increase, the applicability level decreases step by step; when the evidence comes from an incompatible branch or an obsolete version, the lowest applicability level is used.

[0119] The reliability of evidence sources is determined based on the stability of data collection tools, the accuracy of historical parsing, and whether the evidence has been manually verified. Structured records directly generated by compilers or testing frameworks can be assigned a higher reliability level, while free text logs with unstable formats or many missing fields should be assigned a lower reliability level.

[0120] The degree of mutual support among evidence from different sources is determined by whether static analysis results, runtime logs, test results, and version change records all point to the same software entity, adjacent software entities, or the same defect symptom. When multiple independent pieces of evidence jointly support the same entity, the confidence level of the evidence entity node is increased; when there is a significant conflict between pieces of evidence, the corresponding confidence level is decreased.

[0121] All evaluation results are uniformly converted to the same numerical range, and then fused according to preset weights to form the confidence level of the evidence entity nodes. Completeness, version applicability, and source reliability can be set as the main evaluation items, while the degree of mutual support between evidence from different sources is used as an enhancement item.

[0122] For each relation edge, calculate the relation edge confidence score. The relation edge confidence score comprehensively considers the confidence score of the evidence entity node of the source evidence corresponding to the relation edge, the frequency of relation occurrence, the degree of consistency of relation direction, and the degree of causal support.

[0123] The frequency of a relationship is determined by the number of times the same relationship appears in code analysis, log call chains, or test coverage records. The consistency of the relationship's direction is determined by whether the direction of the relationship's edges is consistent with the code execution order, data transfer order, and exception propagation order. The degree of causal support is determined by whether the relationship appears in a confirmed historical defect path and whether it is supported by evidence from multiple sources.

[0124] When the same relation edge is supported by evidence from multiple sources, the confidence of the relation edge is calculated after deduplication of the source evidence to avoid the same log record being counted repeatedly after being parsed multiple times.

[0125] The confidence level of each evidence entity node is written to its corresponding entity node, and the confidence level of each relation edge is written to its corresponding relation edge, thus forming a trusted software defect knowledge graph. The trusted software defect knowledge graph simultaneously records entity type, relation type, source mapping relationship, software version, occurrence time, and confidence level information.

[0126] In this embodiment, S3 includes:

[0127] The target defect evidence set and the trusted software defect knowledge graph are input into the improved CompGCN software defect association diagnosis model.

[0128] Before performing the current target defect diagnosis, an improved CompGCN software defect association diagnosis model is trained using a historical defect evidence set. The training samples consist of historical defect cases that have already undergone root cause identification, code repair, and regression testing.

[0129] Each training sample includes evidence entity nodes, software entity nodes, defect entity nodes, relation edges, confidence of evidence entity nodes, confidence of relation edges, and software version information corresponding to historical defects.

[0130] Confirmed defect cause entities are designated as positive samples. Other defect cause entities belonging to the same defect category as positive samples but not confirmed, or those with similar defect symptoms but corresponding to different code locations or located in the same diagnostic subgraph, are designated as negative samples.

[0131] During training, the root cause entity ranking task and the graph relation reconstruction task are performed simultaneously. The root cause entity ranking task enables confirmed defect cause entities to obtain higher matching scores than negative samples; the graph relation reconstruction task enables the model to maintain its ability to express the relationships between software entities, evidence entities, and defect entities.

[0132] Historical defect cases are divided into training and validation sets. The model updates its parameters on the training set and evaluates root cause ranking accuracy, defect localization accuracy, and candidate path effectiveness on the validation set. Training stops when the validation results no longer improve after several consecutive training epochs, and the model parameters with better validation results are saved.

[0133] The model first generates an initial representation of the entity nodes based on the entity node type and the code attribute, evidence attribute, time attribute, and version attribute of each entity node.

[0134] The code attributes of software entity nodes include module level, class level, function type, code location, and number of calls; the evidence attributes of evidence entity nodes include evidence source, evidence type, and confidence level of the evidence entity node; the time attribute includes the relative interval between the time the evidence was generated and the time the target defect occurred; the version attribute includes the software version to which the entity belongs and its relationship with the target software version.

[0135] Different types of attributes are encoded separately, then concatenated and mapped to a unified dimension to form the initial representation of entity nodes. For entity nodes that do not have a certain attribute, the default identifier for the corresponding attribute is used, and meaningless numerical values ​​are not used for filling.

[0136] Initial representations of relation edges are generated based on relation type and propagation direction. Call relations, data dependency relations, control dependency relations, execution relations, test coverage relations, modification relations, trigger relations, propagation relations, attribution relations, and repair relations are each encoded using independent relation type codes.

[0137] Directional codes are set for the forward propagation direction and the reverse tracing direction, enabling the model to distinguish between different message propagation processes: tracing the defect cause from the defect symptoms and analyzing downstream anomalies from the defect cause.

[0138] The entity relationship combination method is selected based on the relationship type. In this implementation, calling relationships, data dependency relationships, control dependency relationships, execution relationships, propagation relationships, and attribution relationships are combined using vector difference combination, which can preserve directional differences; inclusion relationships, test coverage relationships, modification relationships, and repair relationships are combined element-wise.

[0139] When propagating forward along the relationship edge, the initial representation of the source entity node is combined with the representation of the corresponding relationship edge to form a forward entity-relationship combination message. When tracing backward along the relationship edge, the initial representation of the target entity node is combined with the reverse relationship representation to form a reverse entity-relationship combination message.

[0140] Self-connected messages are generated based on the initial representation of each entity node. These messages are used to preserve the attributes of software entities, evidentiary entities, or defective entities, preventing excessive weakening of the entity's information after multiple layers of propagation.

[0141] Based on the source mapping relationship, the confidence levels of the evidence entity nodes and relationship edges corresponding to the combined messages of positive and negative entity relationships are determined. After unifying the two types of confidence levels to the same numerical range, they are weighted and fused to form the message credibility weight for the corresponding message.

[0142] For messages directly supported by evidence of current target defects, the confidence level of the evidence entity nodes from the current source evidence is prioritized. For messages supported only by historical defect evidence, the confidence level of historical source evidence is used, with attenuation applied based on software version differences.

[0143] When the entity corresponding to the self-connected message has evidence of the current target defect source, the message credibility weight is determined by the weighted average of the confidence levels of the current source evidence; when only historical source evidence is available, the credibility weight is determined by the confidence level of the historical source evidence and the version applicability level.

[0144] When an entity lacks direct source evidence, the average confidence level of the edges directly connected to that entity is used as the credibility weight for the self-join message. When an entity lacks both source evidence and valid edges, a preset minimum credibility weight is used to prevent unsubstantiated entities from gaining excessive influence during propagation.

[0145] After each layer of message propagation is completed, the relation edge representation is updated using relation transformation parameters. The updated relation edge representation is used to generate the next layer of forward entity relation combination messages and reverse entity relation combination messages, enabling the entity representation and relation representation to be updated together, thus preserving the multi-relation joint learning features of the CompGCN model.

[0146] The software version corresponding to each message is determined based on the source mapping relationship and the version identifier of the entities involved in the message. When a message involves multiple software versions, the software version directly corresponding to the source evidence of the message is given priority; if it cannot be directly determined, it is determined based on the versions of the software entities at both ends of the message and the versions of the relationship edges.

[0147] The degree of version compatibility is determined based on the inheritance relationship, branching relationship, and change distance between the software version corresponding to the message and the target software version.

[0148] When the software version corresponding to the message is the same as the target software version, it is set to the highest compatibility level; when the message comes from a directly preceding compatible version, it is set to a relatively high compatibility level; with each additional version change distance, the compatibility level decreases; when the message comes from an incompatible branch or an obsolete version, it is set to the lowest compatibility level.

[0149] Based on the source mapping relationship and the inter-entity relationships in the trusted software defect knowledge graph, the software entities directly involved or indirectly related to various types of messages are identified. For evidence entity messages, software entities connected through execution relationships, test coverage relationships, or modification relationships are identified as associated software entities; for defect entity messages, software entities connected through attribution relationships or propagation relationships are identified as associated software entities.

[0150] Calculate the reachability, data dependency, and control dependency between associated software entities and the set of associated software entities of the target defect. Direct calls, direct data dependencies, or direct control dependencies are assigned a high association level; indirect associations are progressively reduced based on the shortest path hop count; when the maximum propagation hop count is exceeded, the code scope association level is set to the lowest.

[0151] In this implementation, the maximum number of propagation hops can be set to five. For smaller software applications, this can be reduced to three or four hops; for distributed software with complex call relationships, the number can be appropriately increased based on the validation set results.

[0152] The propagation gating coefficient is formed by integrating message trust weight, version compatibility, and code scope correlation. A high propagation gating coefficient results in a high propagation gating coefficient when all three factors are high; conversely, a low propagation gating coefficient suppresses any one of them.

[0153] By using propagation gating coefficients to adjust the propagation strength of forward entity relationship combination messages, reverse entity relationship combination messages, and self-join messages, a set of gated association messages is formed.

[0154] The received gated association messages are aggregated according to the entity nodes to generate updated entity node representations. After completing one layer of message aggregation, the relationship edge representations are updated simultaneously, and the message propagation proceeds to the next layer.

[0155] In this embodiment, the number of graph convolutional propagation layers can be set to three. Three-layer propagation can cover the multi-hop relationships between defect symptoms, abnormal operation events, software entities, and defect causes, while avoiding the spread of irrelevant information due to too many layers.

[0156] Weighted aggregation is performed on the entity nodes corresponding to the target defect evidence and the software entity nodes in the set of software entities associated with the target defect to generate a target defect association representation.

[0157] The target defect association representation is matched with the defect cause entity representation in the trusted software defect knowledge graph to generate a root cause matching score. The higher the root cause matching score, the better the defect cause entity matches the current target defect evidence and related code structure.

[0158] Based on the root cause matching score, the entities that rank highest in terms of defect cause are retained to form a candidate root cause entity set. This implementation can retain the top five defect cause entities; when there are fewer than five entities that meet the diagnostic criteria, only the entities that meet the criteria are retained.

[0159] In this embodiment, S4 includes:

[0160] The defect symptom entities, abnormal operation event entities, and failed test case entities corresponding to the target defect evidence set are identified as the diagnostic starting entities, and the candidate root cause entities are identified as the diagnostic target entities.

[0161] The diagnostic scope is expanded from the starting entity to the target entity along the call relationship, data dependency relationship, control dependency relationship, execution relationship, modification relationship, trigger relationship, propagation relationship and attribution relationship.

[0162] Each expansion record adds an entity node, relation edge, expansion direction, software version, and path hop count, forming the expanded entity and expansion path.

[0163] The cumulative confidence score of the extended path is calculated based on the confidence scores of the evidence entity nodes and relation edges in the extended path. During the calculation, duplicate evidence from the same source is first removed, and then the confidence scores of each item in the path are unified to the same range.

[0164] To prevent longer paths from being excessively weakened by continuous accumulation, the cumulative confidence can be determined based on the average level of all valid confidence in the path, while additional restrictions can be imposed on key relationship edges with significantly low confidence.

[0165] The diagnostic propagation boundary is determined based on the code dependency reachability between the software entities corresponding to or associated with the extended entity and the set of software entities associated with the target defect.

[0166] When the cumulative confidence of the extension path is lower than the propagation condition, the set of software entities associated with the target defect is unreachable, the version of the extension entity is incompatible with the version of the target software, or the extension path exceeds the maximum number of propagation hops, the extension will stop in that direction.

[0167] In this embodiment, the cumulative confidence level of the extended path can be set to no less than 0.45, and the maximum propagation hop count can be set to five hops. In practical applications, this can be adjusted based on the path recall rate and invalid path ratio in the validation set.

[0168] Remove entity nodes and relation edges that exceed the diagnostic propagation boundary, are incompatible with the target software version, or lack valid source evidence.

[0169] The association structure of the software entities in the set of software entities associated with the starting entity of the diagnosis, the target defect, and the diagnosis target entity is preserved to form a version constraint diagnosis subgraph.

[0170] The version constraint diagnostic sub-diagram corresponding to the order creation failure case includes the failure test case, order creation failure symptoms, abnormal inventory deduction event, order creation function, inventory verification function, inventory deduction function, corresponding code statements, and inventory verification logic defects.

[0171] Legacy inventory processing functions that are incompatible with the target version, software entities that have no calls or dependencies on the order creation process, and random log associations with low cumulative confidence were excluded.

[0172] In this embodiment, S5 includes:

[0173] Search the version constraint diagnostic subgraph for multi-hop association paths from the diagnostic starting entity to the candidate root cause entity to form an initial set of diagnostic paths.

[0174] Path search can employ a priority search method based on cumulative confidence scores. Each time, paths with higher cumulative confidence scores and compatibility with the target software version are expanded first, while restricting the path from repeatedly traversing the same entity node to avoid forming circular paths.

[0175] Compare the code call direction, data dependency direction, control dependency direction, and defect propagation direction in the initial diagnostic path.

[0176] The number of valid relation edges with consistent propagation direction and the total number of relation edges with determinable direction are counted, and the ratio of the two is used as the degree of consistency in propagation direction. When there are no relation edges with determinable direction in a path, the path is not directly determined as a directional conflict, but the degree of consistency in propagation direction is set to an intermediate level.

[0177] Delete the corresponding path when it contains a relationship that is opposite to the order of code calls, opposite to the direction of data transmission, or when the direction of defect propagation clearly contradicts the order in which exceptions occur.

[0178] Event timing verification is performed based on the occurrence time of abnormal operation events, test failure times, code modification times, and the occurrence time of target defects.

[0179] Code modification time should be earlier than the target software version generation time; abnormal operation events should be within the time window corresponding to the occurrence time of the target defect; the occurrence time of upstream abnormality should not be later than the downstream abnormality caused by it; the test failure time should have a reasonable correspondence with the time of related abnormal operation events.

[0180] Initial diagnostic paths that do not meet event timing constraints are deleted. Paths lacking explicit timing information but with highly reliable code dependencies are not directly deleted, but their timing support level is reduced.

[0181] The cumulative confidence score of a path is calculated based on the confidence scores of the evidence entity nodes and relation edges in the retained path. During the calculation, duplicate evidence from similar sources is deduplicated to prevent the same log or test result from being reused repeatedly in a single path.

[0182] The path length decay is calculated based on the number of hops. The fewer the path hops, the greater the decay; as the number of hops increases, the decay decreases progressively. Paths exceeding the maximum number of hops are excluded from further calculations.

[0183] The degree of defect symptom coverage is calculated based on the number of target defect symptom entities covered by the candidate diagnostic path and the total number of target defect symptom entities. The more valid defect symptoms covered by the path, the higher the degree of defect symptom coverage.

[0184] The cumulative confidence score of the path, the root cause matching score, the path length decay, the coverage of defect symptoms, and the consistency of the propagation direction are all converted to the same range.

[0185] Weights are assigned based on the importance of each indicator. Root cause matching score and cumulative path confidence are given higher weights, defect symptom coverage and consistency of propagation direction are given the next highest weights, and path length decay is used to suppress excessively long paths.

[0186] The various indicators are weighted and integrated to form a path diagnosis score. The higher the path diagnosis score, the more closely the path matches the actual propagation process of the target defect in terms of evidence reliability, root cause relevance, symptom coverage, propagation direction, and path length.

[0187] Paths are sorted according to their diagnostic scores, and those that meet the path selection criteria are retained as candidate diagnostic paths. This implementation can retain the top ten paths by diagnostic score and ensure that each candidate root cause entity retains at least one valid path.

[0188] At the same time, the path diagnosis score, defect symptom coverage, and consistency of propagation direction corresponding to each candidate diagnostic path are retained for use in candidate root cause conflict correction.

[0189] In this embodiment, S6 includes:

[0190] The basic diagnostic score of each candidate root cause entity is calculated based on its root cause matching score and the path diagnostic score of its corresponding candidate diagnostic path.

[0191] When a candidate root cause entity corresponds to multiple candidate diagnostic paths, the highest path diagnostic score is used first, and the basic diagnostic score is determined by combining the average support of other effective paths, so as to avoid a single random high-scoring path dominating the results.

[0192] Compare the software entities, software versions, and propagation directions associated with the candidate root cause entities through the candidate diagnostic paths.

[0193] Candidate root cause entities that are associated with the same software entity but correspond to incompatible software versions are classified into a root cause conflict group; candidate root cause entities that are located in the same code dependency chain but have opposite propagation directions are classified into a root cause conflict group; candidate root cause entities that provide mutually exclusive causes for the same defect symptom can also be classified into a root cause conflict group.

[0194] Based on the source mapping relationship, static analysis evidence, runtime log evidence, test evidence, and version change evidence are extracted from the candidate diagnostic paths to form corresponding path evidence subsets.

[0195] When calculating cross-source path support consistency, we determine whether the evidence for each type of path points to the same candidate root cause entity, whether it is associated with the same or adjacent software entity, whether the occurrence time satisfies the propagation order, and whether the corresponding path direction is consistent.

[0196] The more conditions are met, the higher the consistency of cross-source evidence support. When evidence from a certain source is missing, it is considered insufficient in terms of evidence completeness and is not directly identified as conflicting evidence.

[0197] For each candidate root cause entity within the root cause conflict group, extract supporting evidence for the current candidate root cause entity and conflict evidence pointing to other candidate root cause entities from the path evidence subset.

[0198] Evidence from the same source is counted only once under the same candidate root cause entity. When the same evidence appears repeatedly through multiple paths, deduplication is performed based on the source mapping relationship.

[0199] The diagnostic score increment is calculated based on the consistency of cross-source pathway support, the independence of evidence sources, the coverage of defective symptoms, and the consistency of propagation direction. When multiple independent pieces of evidence jointly support the diagnosis and are consistent in direction, the candidate root cause entity score is increased.

[0200] The diagnostic score reduction is calculated based on the number of conflicting pieces of evidence, the confidence level of the conflicting evidence, and the degree of version incompatibility. When the conflicting evidence comes from a highly credible independent source, the reduction is greater than that for evidence from a low-credibility or duplicate source.

[0201] Cascaded anomalies are identified based on the code dependency direction and defect propagation order between the software entities associated with the candidate root cause entity and the software entities associated with the downstream defect symptom entity or abnormal operation event entity.

[0202] When identifying a downstream anomaly as a cascading anomaly entity, the following conditions must be met simultaneously: there is a valid call, data dependency, or control dependency path between the downstream anomaly and the candidate root cause entity; the downstream anomaly occurred no earlier than the upstream anomaly; the downstream anomaly lacks independent, highly credible root cause evidence; and the support level of the path corresponding to the downstream anomaly is significantly reduced after removing the upstream defect-related path.

[0203] Exceptions that are only located downstream of code dependencies but have independent, highly credible root cause evidence are not considered cascaded exceptions, thus avoiding errors that suppress other independent defects that occur concurrently.

[0204] The cascading anomaly suppression amount is calculated based on the path hop count, relation edge confidence, and consistency of propagation direction between the software entities associated with the candidate root cause entity and the cascading anomaly entity.

[0205] The farther the cascade anomaly is from the upstream defect and the more clearly defined the dependency path, the higher the degree of suppression of its diagnostic score as an independent root cause. The degree of suppression decreases when there are low-confidence edges in the path or when the propagation direction is uncertain.

[0206] The diagnostic score increment is added to the base diagnostic score, and the diagnostic score reduction and cascade abnormality suppression are subtracted to obtain the corrected diagnostic score.

[0207] The corrected diagnostic scores are limited to a uniform and valid range to prevent results from exceeding the comparable range due to score increases or decreases. Maximum values ​​can be set for increments, and upper limits can be set for cascaded anomaly suppression to ensure that the correction process does not completely cover the basic diagnostic information.

[0208] Candidate root cause entities are sorted according to the corrected diagnostic scores to form the root cause entity sorting results.

[0209] Select the top-ranked candidate root cause entity and determine the candidate diagnostic path with the highest path diagnostic score corresponding to this candidate root cause entity. Traverse upstream along the defect propagation direction within this path to identify the software entities directly associated with the top-ranked candidate root cause entity.

[0210] Defect localization is determined in the order of code statements, functions, classes, and software modules. If a specific code statement can be located, that code statement is used as the defect localization result; if a code statement cannot be located, the corresponding function is located; if there is insufficient information about the function, the defect is located at the class or software module.

[0211] When multiple software entities at the same level meet the conditions simultaneously, they are sorted according to the confidence of the corresponding relationship edge, the score of the candidate diagnostic path, and the number of times they are covered by evidence from different sources. The software entity with the highest ranking is selected as the defect localization result.

[0212] In the case of order creation failure, the empty inventory query result is a downstream cascading exception caused by a flaw in the inventory verification logic. This exception occurs downstream of the inventory verification and deduction processes, later than the inconsistency in inventory status, and lacks independent, highly credible root cause evidence.

[0213] After cascading anomaly suppression, the diagnostic scores of candidate root causes corresponding to inventory query anomalies decreased, while the inventory verification logic defect maintained the highest corrected diagnostic score. The defect location result was the concurrent inventory judgment code statement in the inventory verification function.

[0214] In this embodiment, S7 includes:

[0215] A defect diagnosis report is generated based on the root cause entity sorting results, defect location results, and candidate diagnostic paths.

[0216] The defect diagnosis report includes the target software version, the time of occurrence of the target defect, the symptoms of the target defect, the root cause entity ranking, the root cause matching score, the corrected diagnosis score, the defect code location, the candidate diagnosis path, the path diagnosis score, the source of evidence, the consistency of cross-source path support, the cascading abnormal entities, and the recommended remediation measures.

[0217] Based on the remediation relationship between the top-ranked candidate root cause entity and the remediation measure entity, applicable remediation measures are extracted from the historical defect evidence set.

[0218] When the software version corresponding to the fix is ​​compatible with the target software version, the fix is ​​directly written into the defect diagnosis report; when the versions are incompatible, only the processing logic corresponding to the fix is ​​extracted, and the developers are prompted to perform version adaptation.

[0219] In the case of order creation failure, the defect diagnosis report records the target defect as order creation failure, the optimal root cause as a defect in the inventory verification logic, the defect location result as the concurrent judgment code statement in the inventory verification function, and the recommended remediation measures as adding an inventory lock mechanism and establishing consistency control between inventory verification and inventory deduction.

[0220] Receive diagnostic confirmation results submitted by developers or testers based on defect diagnostic reports. Diagnostic confirmation results include root cause confirmation status, code location confirmation status, path validity status, actual remediation measures, and regression test results.

[0221] Only when the root cause is identified, the code is fixed, and regression testing is passed will the diagnosis result be written into the Trusted Software Defect Knowledge Graph as evidence of a confirmed historical defect.

[0222] When the diagnosis confirms the result is correct, increase the confidence level of the corresponding defect cause entity, software entity, and relation edges in the effective diagnostic path. The confidence level is adjusted step by step, increasing gradually only after the same entity or relation has been confirmed multiple times by independent cases, to avoid over-reinforcement caused by a single confirmation.

[0223] When a diagnosis confirms an error, the confidence level of the corresponding candidate root cause entity association and candidate diagnostic path is reduced, and the reason for the error is recorded. A single error feedback does not directly delete the entity node or relationship edge.

[0224] Each update retains the confidence level prior to the update, the update time, the confirming personnel, and the corresponding regression test records. When subsequent evidence conflicts with existing diagnostic results, the evidence records of different versions are retained, and the confidence levels of evidence entity nodes and relation edges are recalculated.

[0225] The updated trusted software defect knowledge graph is used for the diagnosis of software defects in subsequent versions of the same or compatible software.

[0226] The software defect diagnosis system corresponding to this embodiment includes an evidence processing module, a knowledge graph construction module, an association diagnosis module, a diagnosis subgraph generation module, a path reasoning module, a conflict correction module, and a diagnosis output module.

[0227] The evidence processing module is used to perform data collection, time alignment, entity identification, and version identification processing. The knowledge graph construction module is used to establish entity nodes, relationship edges, source mapping relationships, and confidence information.

[0228] The correlation diagnosis module is used to perform message generation, trusted weighting, relation representation updates, and dual gating of version context and code scope for implementing the improved CompGCN software defect correlation diagnosis model.

[0229] The diagnostic subgraph generation module determines the diagnostic propagation boundary and generates a version-constrained diagnostic subgraph. The path reasoning module generates candidate diagnostic paths and path evaluation results. The conflict correction module calculates cross-source path support consistency, identifies cascading anomalies, and corrects candidate root cause entities. The diagnostic output module generates a defect diagnostic report, receives diagnostic confirmation results, and updates the trusted software defect knowledge graph.

[0230] Each module can be deployed on the same server, or separately on a code analysis server, log processing server, knowledge graph server, and defect diagnosis server, and exchange target defect evidence sets, knowledge graph data, candidate diagnostic paths, and diagnostic results through data interfaces.

[0231] This embodiment also provides a storage medium. The storage medium can be a hard disk, solid-state drive, read-only memory, random access memory, flash memory, or other media capable of storing executable instructions. When the executable instructions are read and executed by a computer processor, the above-described software defect diagnosis method is implemented.

[0232] Example 1: To verify the feasibility of this invention in practice, it was applied to a microservice software system that includes user management, order processing, inventory management, message processing, access control, price calculation, and configuration management functions. The software comprises 18 service modules, 286 classes, and 842 functions, and has three consecutive versions: 3.2.0, 3.2.1, and 3.3.0. The following verification data are simulated verification data, used only to illustrate the implementation process and technical effects of this invention, and do not represent actual production data from a specific enterprise.

[0233] The source code static analysis results, runtime logs, exception stack traces, test execution results, version commit records, and historical defect records of the target software were collected. Version 3.3.0 was identified as the target software version, and the time when the exception first occurred in the test environment was taken as the target defect occurrence time. Time alignment and entity identification were performed according to function identifiers, event identifiers, version identifiers, and defect identifiers to form a target defect evidence set and a historical defect evidence set. The target defect evidence set contains 8 sets of defect evidence to be diagnosed, and the historical defect evidence set contains 320 confirmed defect records.

[0234] A trusted software defect knowledge graph is constructed based on two types of defect evidence sets. Software modules, classes, functions, and code statements are constructed as software entity nodes; defect symptoms, defect causes, and remediation measures are constructed as defect entity nodes; and static analysis results, abnormal runtime events, failed test cases, and version change records are constructed as evidence entity nodes. Simultaneously, edges representing call, inclusion, data dependency, control dependency, execution, test coverage, modification, triggering, propagation, attribution, and remediation relationships are established. The constructed knowledge graph contains 1146 software entity nodes, 238 defect entity nodes, 1376 evidence entity nodes, and 8964 relationship edges.

[0235] Based on the source mapping relationship, the evidence in the target defect evidence set is mapped to the corresponding software entity nodes, resulting in a set of software entities associated with the target defect. The confidence level of the evidence entity node is determined by a fusion of the completeness of the evidence fields, the time of evidence generation, the version to which the evidence belongs, the reliability of the evidence source, and the degree of cross-source mutual support; the confidence level of the relationship edge is determined by a fusion of the confidence level of the evidence entity node of the corresponding source evidence, the frequency of relationship occurrence, the degree of directional consistency, and the degree of causal support. In this embodiment, evidence with an evidence entity node confidence level below 0.40 is considered low-confidence evidence, retaining its source identifier but reducing its propagation weight; relationship edges with a relationship edge confidence level below 0.35 are excluded from the diagnostic propagation scope.

[0236] The target defect evidence set and the trusted software defect knowledge graph are input into the improved CompGCN software defect association diagnostic model. The model generates forward entity relationship combination messages, reverse entity relationship combination messages, and self-connected messages based on the initial representations of entity nodes and relationship edges, and determines the message trust weights of each type of message through source mapping relationships. The model adopts a three-layer relationship propagation structure, with the entity representation dimension set to 128 and the number of candidate root cause entities retained set to 5. Model parameters can be pre-trained or initialized using historical defect evidence sets; this embodiment does not limit the specific training method.

[0237] Dual gating of version context and code scope is implemented for all types of messages. Version context gating calculates a version compatibility coefficient based on the inheritance relationship, branching relationship, and change distance between the message's corresponding software version and the target software version; the version compatibility coefficient is set to 1.00 for messages of the same version, 0.85 for adjacent inherited versions, 0.65 for messages on the same branch with a version interval, and 0.20 for incompatible branches. Code scope gating calculates a code scope correlation coefficient based on the call reachability, data dependency, and control dependency between the associated software entities and the set of software entities associated with the target defect. The version compatibility coefficient, code scope correlation coefficient, and message trust weight are merged into a propagation gating coefficient to adjust the propagation strength of the three types of messages, resulting in the target defect association representation, candidate root cause entity set, and root cause matching score.

[0238] The diagnostic starting entities are the defect symptom entities, abnormal operation event entities, and failed test case entities corresponding to the target defect evidence set, and the neighborhood expansion is performed using candidate root cause entities as diagnostic target entities. The cumulative confidence score is calculated based on the confidence scores of evidence entity nodes and relation edges in the expansion path, and the diagnostic propagation boundary is determined by combining the code dependency reachability between related software entities. Entity nodes and relation edges with a cumulative confidence score below 0.45, incompatible with the target software version, or exceeding 5 hops are deleted, generating a version constraint diagnostic subgraph.

[0239] The version constraint diagnostic subgraph searches for multi-hop related paths, compares code call direction, data dependency direction, control dependency direction, and defect propagation direction, and calculates the consistency of propagation direction. Then, paths that do not meet the event sequence constraints are excluded based on the occurrence time of abnormal runtime events, test failure times, code modification times, and the occurrence time of the target defect. The cumulative confidence of the path is calculated based on the confidence of evidence entity nodes and relation edges in the path. The path length decay is calculated based on the number of hops. The defect symptom coverage is calculated based on the ratio of the number of defect symptom entities covered by the path to the total number of target defect symptom entities. All results are then combined to obtain the path diagnostic score.

[0240] For candidate root cause entities that correspond to incompatible software versions or have opposite propagation directions on the same dependency, root cause conflict groups are established. Static analysis evidence, runtime log evidence, test evidence, and version change evidence are extracted from candidate diagnostic paths based on source mapping relationships, and cross-source path support consistency is calculated. Cascaded abnormal entities are identified by combining defect symptom coverage and propagation direction consistency, cascaded abnormality suppression is calculated, and the basic diagnostic scores of candidate root cause entities are corrected, ultimately forming root cause entity ranking results and defect location results.

[0241] Table 1. Simulation and verification results of software defect diagnosis

[0242] Defect 1 The order status is empty after payment. Order status transition function Payment service module Order status transition function 0.93 Defect 2 Inventory update deadlock Inventory lock acquisition function Inventory lock acquisition function Inventory lock acquisition function 0.91 Defect 3 User cache deserialization failed. User cache deserialization function User information retrieval function User cache deserialization function 0.88 Defect 4 Permission test cases continue to fail Permission rule judgment function Permission rule judgment function Permission rule judgment function 0.95 Defect 5 Repeated message consumption and continuous alerts Message reentry queue function Message consumption processing function Message reentry queue function 0.86 Defect 6 Discount price calculation error Discount Price Calculation Function Promotion processing module Price Calculation 0.76 Defect 7 Task state concurrent coverage Task status update function Task status update function Task status update function 0.90 Defect 8 Parameters lost after configuration merging Configure merge function Configure merge function Configure merge function 0.84

[0243] As shown in Table 1, the comparative method located manually confirmed root causes in four groups of defects: defects 2, 4, 7, and 8, with a function-level accurate location rate of 50.0%. In defects 1, 3, 5, and 6, the comparative method was affected by downstream abnormal logs, call entry points, or cross-version association information, and misjudged the abnormal propagation nodes as root causes.

[0244] The method of this invention located manually confirmed root cause functions in defects 1, 2, 3, 4, 5, 7, and 8, achieving a function-level accuracy rate of 87.5%. In defect 6, the candidate diagnostic path was located to the price calculation class containing manually confirmed root causes, but due to the low level of support between static analysis evidence and operational log evidence, it ultimately did not converge further to the discounted price calculation function; therefore, this group of results belongs to class-level localization. Thus, it is evident that the method of this invention can limit the defect scope to the function or class containing the manually confirmed root cause in all eight groups of defects.

[0245] Defects 1, 3, and 5 all exhibit significant downstream anomalies. The improved CompGCN software defect correlation diagnostic model reduces the propagation intensity of low-trust log messages through message trust weighting and identifies cascading abnormal entities based on code dependency direction and defect propagation order. This allows the order status transition function, user cache deserialization function, and message reentry queue function to obtain higher corrected diagnostic scores, avoiding misidentification of the payment service module, user information retrieval function, and message consumption processing function as the root cause of the defects.

[0246] Defects 3 and 6 involve version change data. Version context gating suppresses historical relationship messages that are incompatible with the target software version, and code scope gating further reduces messages of software entities that are unreachable or weakly dependent on the set of software entities associated with the target defect. Therefore, cross-version historical defects do not directly overwrite the diagnostic results of the current version. The diagnostic scores of each group ranged from 0.76 to 0.95, with an average of 0.88, indicating that multi-source evidence can provide relatively stable common support for the main candidate root causes.

[0247] The above simulation verification shows that the present invention, through a trusted software defect knowledge graph, trusted weighting of three types of messages, dual gating of version context and code scope, multi-hop path reasoning, and candidate root cause conflict correction, can reduce the interference of low-confidence evidence, irrelevant code regions, cross-version information, and cascading anomalies on diagnostic results, and generate candidate diagnostic paths traceable to evidence entity nodes, relation edges, and software entities. The data in the table is only used to illustrate the feasibility of the technical solution of the present invention and does not constitute a limitation on the actual diagnostic accuracy or the scale of applicable software.

[0248] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A software defect diagnosis method based on knowledge graphs, characterized in that, Includes the following steps: S1. Collect code analysis, runtime logs, test data, version change data, and historical defect data of the target software. After processing by time, entity, and version identifiers, obtain two types of defect evidence sets, the target software version, and the time when the target defect occurred. S2. Based on the two types of defect evidence sets, establish software, defect, and evidence entities and the relationships between entities, construct a credible software defect knowledge graph, and obtain the set of software entities associated with the target defect; S3. Input the target defect evidence set and the trusted software defect knowledge graph into the improved CompGCN software defect association diagnosis model, perform trusted weighting and dual-gated propagation on the three types of messages, and obtain the candidate root cause entity set and root cause matching score. S4. Determine the scope of diagnosis propagation based on the target defect evidence set, target software version, target defect associated software entity set, and candidate root cause entity set, and generate a version-constrained diagnostic subgraph. S5. In the version constraint diagnostic subgraph, multi-hop reasoning is performed by combining code dependencies, event timing and defect propagation direction to obtain candidate diagnostic paths, path diagnostic scores, defect symptom coverage and propagation direction consistency. S6. Calculate cross-source path support consistency, identify cascade anomalies and correct candidate root cause entities based on the evaluation results of each path, and obtain root cause entity ranking results and defect location results. S7. Generate a defect diagnosis report based on the root cause entity sorting results, defect location results, and candidate diagnosis paths; receive the diagnosis confirmation results; and update the trusted software defect knowledge graph.

2. The software defect diagnosis method based on knowledge graphs according to claim 1, characterized in that, S2 includes the following steps: S21. Construct software modules, classes, functions, and code statements as software entity nodes, and construct defect symptoms, defect causes, and remediation measures as defect entity nodes. S22. Construct evidence entity nodes from static analysis results, abnormal running events, failed test cases, and version change records, and establish relationship edges between each entity node; S23. Relationship edges include invocation, inclusion, data dependency, control dependency, execution, test coverage, modification, triggering, propagation, attribution, and repair relationship edges; S24. Based on the code, event, version, and defect identifier, establish the source mapping relationship between each source of evidence and entity nodes and relation edges; S25. Map the evidence in the target defect evidence set to the corresponding software entity nodes according to the source mapping relationship to obtain the set of software entities associated with the target defect; S26. Calculate the confidence level of the evidence entity nodes and the confidence level of the relation edges, and write the corresponding confidence levels into the evidence entity nodes and relation edges to form a trusted software defect knowledge graph.

3. The software defect diagnosis method based on knowledge graphs according to claim 1, characterized in that, S3 includes the following steps: S31. Generate initial representations of entity nodes based on their type, code, evidence, time, and version attributes, and generate initial representations of relation edges based on relation type and propagation direction. S32. Generate forward entity relationship combination messages and reverse entity relationship combination messages through entity relationship combination operators, and generate self-connection messages based on the initial representation of entity nodes; S33. Determine the confidence of nodes and relation edges corresponding to forward and reverse messages based on the source mapping relationship, and aggregate the source evidence confidence of the corresponding entities to determine the trust weight of self-connected messages; S34. Based on the target software version, the set of software entities associated with the target defect, and the message trust weight, perform dual gating of version context and code scope on the three types of messages; S35. Generate a target defect association representation by aggregating gating associated messages, calculate the degree of matching between the representation and the defect cause entity representation, and obtain the candidate root cause entity set and root cause matching score.

4. The software defect diagnosis method based on knowledge graphs according to claim 3, characterized in that, S34 includes the following steps: S341. Determine the software version corresponding to the message based on the source mapping relationship and the version identifier of the entity involved in the message, and calculate the version compatibility coefficient in combination with the target software version; S342. Based on the source mapping relationship and the entity relationships in the trusted software defect knowledge graph, determine the software entities that are directly involved or indirectly related to various messages; S343. Calculate the code scope association coefficient based on the call reachability, data dependency, and control dependency between the associated software entities and the set of associated software entities of the target defect; S344, combined with version compatibility coefficient, code scope correlation coefficient and message trust weight, yields the propagation gating coefficients for forward, reverse and self-connected messages; S345. Adjust the propagation strength of forward, reverse and self-connected messages using the propagation gating coefficient to form a set of gated associated messages.

5. The software defect diagnosis method based on knowledge graphs according to claim 1, characterized in that, S4 includes the following steps: S41. Take the defect symptom entity, abnormal operation event entity and failed test case entity corresponding to the target defect as the diagnostic starting entity, and take the candidate root cause entity as the diagnostic target entity. S42. Extend the neighborhood from the diagnostic starting entity along the call, data dependency, control dependency, execution, modification, trigger, propagation and attribution relationships to the diagnostic target entity; S43. Calculate the cumulative confidence based on the confidence of nodes and relation edges in the extended path, and determine the diagnostic propagation boundary based on the code dependency reachability between related software entities; S44. Delete entity nodes and relation edges that exceed the diagnostic propagation boundary or are incompatible with the target software version, retain the relevant association structure, and generate a version constraint diagnostic subgraph.

6. The software defect diagnosis method based on knowledge graphs according to claim 1, characterized in that, S5 includes the following steps: S51. Search the version constraint diagnostic subgraph for multi-hop association paths from the diagnostic starting entity to the candidate root cause entity to form an initial diagnostic path set. S52. Compare the code calls, data dependencies, control dependencies, and defect propagation directions in the paths, calculate the degree of consistency in propagation directions, and delete paths with opposite propagation directions; S53. Based on the occurrence time of abnormal running events, test failures, code modifications, and target defects, delete the initial diagnostic paths that do not meet the event sequence constraints; S54. Calculate the cumulative confidence of the path based on the confidence of nodes and relation edges in the path, and calculate the path length attenuation and defect symptom coverage based on the path hop count and the symptom entity coverage ratio. S55. The candidate diagnostic path and path diagnostic score are obtained by combining the cumulative confidence of the fusion path, the root cause matching score, the path length attenuation degree, the coverage of defect symptoms, and the consistency of the propagation direction.

7. The software defect diagnosis method based on knowledge graphs according to claim 1, characterized in that, S6 includes the following steps: S61. Calculate the basic diagnostic score of the candidate root cause entity based on the root cause matching score of the candidate root cause entity and the path diagnostic score of its corresponding candidate diagnostic path. S62. Compare the software entities, software versions, and propagation directions associated with the candidate root cause entities, and classify the candidate root cause entities with incompatible versions or opposite propagation directions into root cause conflict groups. S63. Extract four types of source evidence from candidate diagnostic paths based on the source mapping relationship, form a subset of path evidence, and calculate cross-source path support consistency. S64. Identify cascade anomalies based on the consistency of cross-source path support, the degree of coverage of defective symptoms, and the degree of consistency of propagation direction, and correct the basic diagnostic scores within the root cause conflict group. S65. Sort the candidate root cause entities according to the corrected diagnostic scores, and determine the defect location results of software modules, functions or code statements based on the highest score path corresponding to the first-ranked entity.

8. The software defect diagnosis method based on knowledge graphs according to claim 7, characterized in that, S64 includes the following steps: S641. Extract supporting evidence for the current candidate root cause entity and conflicting evidence pointing to other candidate root cause entities from the path evidence subset. S642. Calculate the corresponding diagnostic score increment and decrement based on the consistency of cross-source pathway support, the degree of independence of evidence sources, the degree of coverage of defective symptoms, and the degree of consistency of propagation direction. S643. Identify cascading abnormal entities based on the code dependency direction and defect propagation order between the software entities associated with the candidate root cause entities and their downstream abnormal entities. S644. Calculate the cascading anomaly suppression amount based on the path hop count and relation edge confidence between related software entities, and obtain the corrected diagnostic score by combining the diagnostic score increment and decrement.

9. A software defect diagnosis system based on knowledge graphs, characterized in that, A software defect diagnosis method based on knowledge graphs as described in any one of claims 1 to 8, characterized in that it comprises the following modules: The evidence processing module is used to process the target software's code analysis, runtime logs, tests, version changes, and historical defect data to obtain two types of defect evidence sets, the target software version, and the time when the target defect occurred. The knowledge graph construction module is used to establish source mapping relationships, calculate the confidence of nodes and relationship edges, construct a trustworthy software defect knowledge graph, and generate a set of software entities associated with the target defect. The correlation diagnosis module is used to generate three types of messages through the improved CompGCN software defect correlation diagnosis model, and perform trusted weighting and dual-gated propagation to obtain the candidate root cause entity set and root cause matching score; The diagnostic subgraph generation module is used to generate a version-constrained diagnostic subgraph based on the target defect evidence set, the target software version, the target defect associated software entity set, and the candidate root cause entity set. The path reasoning module is used to perform multi-hop reasoning by combining code dependencies, event timing and defect propagation direction to obtain candidate diagnostic paths and corresponding path evaluation results; The conflict correction module is used to calculate cross-source path support consistency, identify cascading anomalies, and correct candidate root cause entities, thereby obtaining root cause entity ranking results and defect location results. The diagnostic output module is used to generate defect diagnostic reports, receive diagnostic confirmation results, and update the trusted software defect knowledge graph based on the diagnostic confirmation results.

10. A storage medium, characterized in that, The medium stores executable instructions for being read by a computer's processor to perform the method of any one of claims 1 to 8.

Images