Control method, device and storage medium for medical software defect positioning

Abstract

The application discloses a medical software defect positioning control method and device and a storage medium, relates to the technical field of medical software testing, and comprises the following steps: determining a defect running data set in the software running process by running a failure test case; performing node-by-node feature comparison between the defect running data set and a health benchmark feature set to identify a candidate defect node set; performing cross-domain correlation reasoning on the candidate defect node set according to a data flow direction dependency graph to obtain a defect root cause positioning conclusion; and calculating the comprehensive confidence scores of each root cause node and sorting the comprehensive confidence scores based on the defect root cause positioning conclusion and confidence evaluation dimension weight to obtain a defect positioning report.

Description

Technical Field

[0001] This application relates to the field of medical software testing technology, and in particular to a control method, device and storage medium for locating defects in medical software. Background Technology

[0002] In the testing and defect tracing scenarios of medical AI-assisted diagnostic software, the ability to accurately determine the source of faults and quickly locate defects is directly related to testing efficiency and R&D progress.

[0003] In related technologies, functional black-box testing methods are used to test medical AI-assisted diagnostic software by comparing the final output results. This method can only determine defects by comparing the overall output, and engineers need to conduct multiple rounds of collaborative investigation to determine the location of defects. It is difficult to adapt to the testing scenario of hybrid architecture software that combines code and model, resulting in low efficiency in software defect localization.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a control method, device, and storage medium for locating defects in medical software, aiming to solve the technical problem of low efficiency in software defect location.

[0006] To achieve the above objectives, this application proposes a control method for locating defects in medical software, the method comprising: By running failure test cases, a defective runtime dataset, including code execution characteristics and neural network activation characteristics, is determined during software operation. The defective runtime dataset is compared with the health benchmark feature set node by node to identify abnormal modules in the code domain and abnormal layers in the model domain, and a candidate defective node set is obtained by association. Based on the data flow dependency graph between the code module and the neural network layer, cross-domain association reasoning is performed on the candidate defect node set to obtain the defect root cause localization conclusion. Based on the defect root cause localization conclusions and the confidence evaluation dimension weights, the comprehensive confidence score of each root cause node is calculated and sorted to obtain the defect localization report.

[0007] In one embodiment, the failure test cases are loaded into the medical auxiliary diagnostic software under test, and the instrumentation probes at the code module entrance and exit and the feature capture hooks of each layer of the neural network are activated to construct a dual-domain acquisition link; Through the dual-domain acquisition link, the running feature data of each code module and the activation tensor statistical features of each layer of the neural network are obtained, and the dual-domain original running dataset is obtained by organizing it according to the time sequence. Based on the time series reference, the original dual-domain running dataset is subjected to node-by-node time series alignment and matching to remove invalid and redundant data, thereby obtaining valid dual-domain running data. The valid runtime data of the two domains is encapsulated according to the chronological order and domain category, and associated with the identification information of the corresponding failure test cases to obtain the defect runtime dataset.

[0008] In one embodiment, the identification information associated within the defect running dataset is used as a retrieval index to match the baseline feature range and anomaly judgment threshold of the corresponding node from the health baseline feature set of the dual-domain defect feature knowledge base, thereby constructing a comparison baseline set. Based on the aforementioned set of comparison benchmarks, the deviation of the code module's running features from the corresponding benchmarks and the similarity of the neural network layer activation features from the corresponding benchmarks are calculated respectively, and the node anomaly deviation quantification results are obtained by organizing them. Based on the anomaly determination threshold of each node, the abnormal deviation quantification results of the nodes are verified and screened node by node to determine the abnormal nodes whose deviation exceeds the deviation threshold or whose similarity is lower than the similarity threshold. Based on the identification information corresponding to the abnormal nodes, code domain abnormal module groups and model domain abnormal hierarchy groups are generated respectively. The code domain anomaly module group and the model domain anomaly hierarchy group are associated and sorted according to the order of data flow, and the anomaly severity level of each node is marked, and the candidate defect node set is obtained by integration.

[0009] In one embodiment, the node abnormal deviation quantization result is mapped and bound to the deviation threshold and similarity threshold corresponding to each node in the abnormal judgment threshold to obtain a node verification dataset; The nodes in the node verification dataset are judged based on the deviation magnitude of their running features and the similarity of their activation features, and nodes whose deviation magnitude exceeds a deviation threshold or whose similarity is lower than a similarity threshold are marked to obtain abnormal initial screening nodes; Based on the continuity of characteristic changes of adjacent nodes upstream and downstream of the initial screening node for anomalies, false anomaly nodes caused by instantaneous fluctuations in data collection are removed, resulting in the verified initial screening nodes for anomalies. The reviewed anomaly screening nodes are classified and grouped according to the code domain and model domain attributes to which the nodes belong, and the anomaly trigger type and anomaly level of the nodes are marked to obtain the anomaly nodes.

[0010] In one embodiment, the candidate defect node set is mapped to the data flow dependency graph between the code module and the neural network layer to locate the topological position of the abnormal node in the global data flow link and generate a data flow dependency subgraph including the abnormal marker. Based on the data flow direction of the data flow dependency subgraph, the abnormal propagation path is traced in reverse to identify the abnormal initiation node and the progressive propagation nodes, and the data causal relationship between the abnormal nodes is determined. Based on the cross-domain connectivity attributes of the abnormal propagation path and the domain distribution characteristics of the abnormal node, the defect classification judgment rule is matched to determine the root cause type of the defect corresponding to the abnormal node. Based on the upstream and downstream positions of the abnormal node in the transmission link, the core root cause node under the root cause type is determined, and the defect root cause localization conclusion is generated by combining the data causal relationship.

[0011] In one embodiment, the abnormal deviation magnitude, abnormal propagation link level, and cross-domain association matching strength in the defect root cause localization conclusion are mapped and bound with the corresponding confidence evaluation dimension weights to obtain a node confidence calculation set. Based on the node confidence calculation set, the confidence scores of each root cause node are obtained by weighted summation according to the weight coefficients corresponding to the evaluation dimensions. The confidence scores are sorted from high to low and associated with the abnormal feature fragments, data flow propagation paths and domain affiliation information corresponding to the root cause nodes to obtain an ordered list of root cause nodes. The ordered root cause node list is structured and integrated according to a preset report framework, and the defect source domain classification, root cause severity level labeling, and repair direction guidance are added to obtain the defect location report.

[0012] In one embodiment, after deploying the dual-domain acquisition probe, all gold-labeled correct test cases are run, and code execution data and network layer activation data of each node are collected to obtain the original dataset of dual-domain healthy operation. Statistical analysis is performed on the original dataset of dual-domain health operation to calculate the normal distribution range and dynamic judgment threshold of the operation indicators of each node, and to generate a set of node-level health baseline indicators. Using the node-level health baseline beacon set as a benchmark, quantifiable feature footprints of typical logical faults in the code domain are extracted to construct a code domain defect signature library. Using the node-level health baseline landmark set as a benchmark, quantifiable feature footprints of typical inference anomalies in the model domain are extracted to construct a model domain defect signature library. The node-level health baseline beacon set, the code domain defect signature library, and the model domain defect signature library are associated and encapsulated to obtain a dual-domain defect feature knowledge base.

[0013] In one embodiment, the defect location report is manually reviewed to determine the root cause of the defect and the repair conclusion, and the corresponding dual-domain feature footprint in the defect location report is associated to generate a defect pattern sample; The defect pattern samples are matched with the existing signatures in the dual-domain defect feature knowledge base to filter out target defect patterns that have not been included. Set a unique feature signature for the target defect pattern, associate it with the corresponding repair scheme, and adjust the weight of the signature in the dual-domain defect feature knowledge base to obtain the updated dual-domain defect feature knowledge base. Based on the updated dual-domain defect feature knowledge base, the defect location and judgment rules are optimized, which in turn guides the code repair and model tuning of the medical software, resulting in an iteratively optimized medical software.

[0014] Furthermore, to achieve the above objectives, this application also proposes a control device for locating medical software defects. The control device for locating medical software defects includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the control method for locating medical software defects as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the control method for locating medical software defects as described above.

[0016] This application provides a control method for defect localization in medical software. The method includes determining a defective runtime dataset containing code execution features and neural network activation features during software operation by running failure test cases; comparing the defective runtime dataset with a health benchmark feature set node by node to identify abnormal modules in the code domain and abnormal layers in the model domain, and obtaining a candidate defect node set; then, based on the data flow dependency graph between the code modules and neural network layers, performing cross-domain association reasoning on the candidate defect node set to obtain a defect root cause localization conclusion; finally, calculating the comprehensive confidence score of each root cause node based on the defect root cause localization conclusion and the confidence evaluation dimension weights, and ranking them to obtain a defect localization report. This method solves the technical problems of difficulty in quickly and accurately defining the source of defects between the code domain and the model domain when software testing fails in a hybrid architecture of medical AI-assisted diagnostic software, the cumbersome manual investigation process, and the high localization cost. It improves the automation and accuracy of defect localization, shortens the defect investigation cycle, and provides efficient and reliable technical support for the quality assurance and iterative optimization of medical AI software. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first embodiment of the control method for locating defects in medical software according to this application; Figure 2 This is the overall flowchart of this application; Figure 3 This is a schematic diagram of the workflow of the dual-domain anomaly detection engine in this application; Figure 4 This is a schematic diagram illustrating the dependency relationship between the code and model data in this application. Figure 5 This is a heatmap showing the anomaly propagation in the model domain of this application. Figure 6 A flowchart illustrating the seventh embodiment of the control method for locating defects in medical software according to this application; Figure 7 A flowchart illustrating the eighth embodiment of the control method for locating defects in medical software according to this application; Figure 8 This is a schematic diagram of the control device for locating defects in the medical software of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] In related technologies, functional black-box testing methods are used to test medical AI-assisted diagnostic software by comparing the final output results. This method can only determine defects by comparing the overall output, and engineers need to conduct multiple rounds of collaborative investigation to determine the location of defects. It is difficult to adapt to the testing scenario of hybrid architecture software that combines code and model, resulting in low efficiency in software defect localization.

[0023] This application provides a solution: First, by running failure test cases, a defective runtime dataset including code execution characteristics and neural network activation characteristics is determined during software operation. Then, the defective runtime dataset is compared node by node with the health benchmark feature set to identify abnormal modules in the code domain and abnormal layers in the model domain, and a candidate defect node set is obtained. Next, based on the data flow dependency graph between the code module and the neural network layer, cross-domain association reasoning is performed on the candidate defect node set to obtain the defect root cause localization conclusion. Finally, based on the defect root cause localization conclusion and the confidence evaluation dimension weight, the comprehensive confidence score of each root cause node is calculated and ranked to obtain a defect localization report.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a control device for locating defects in medical software, etc. The following description uses a control device for locating defects in medical software as an example to illustrate this embodiment and the subsequent embodiments.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] This application provides a control method for locating defects in medical software, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the control method for locating defects in medical software according to this application.

[0027] In this embodiment, the control method for locating defects in medical software includes steps S10 to S40: Step S10: By running failure test cases, determine the defect running dataset, which includes code execution characteristics and neural network activation characteristics, during the software operation process.

[0028] Failure test cases refer to a set of test samples whose output does not meet the gold standard and are used to trigger the reproduction of software defects. Code execution characteristics are quantitative indicators describing the running state of a code module, such as module execution time, input and output parameter value range, exception error indicators, memory usage fluctuations, and function call stack depth. Neural network activation characteristics are quantitative indicators describing the inference state of each layer of a neural network, such as the mean of the layer activation tensor, the dispersion of activation value distribution, the proportion of response regions in the feature map, neuron activation rate, and output tensor deviation. A defect execution dataset refers to a set of dual-domain abnormal execution characteristics that cover the complete software execution flow and are time-aligned.

[0029] In this embodiment, the execution and data collection process of the aforementioned failure test cases can be triggered in four ways. First, full regression triggering: after a software version iteration is completed, the system automatically schedules a full set of failure test cases for batch reproduction and data collection to cover all potential defects introduced by the version update. Second, single-case reproduction triggering: when online maintenance reports diagnostic anomalies in specific scenarios, technicians upload corresponding failure test cases. Upon receiving this, the system initiates precise single-case reproduction and feature collection to pinpoint online feedback issues. Third, defect regression triggering: after the software completes defect repair, the corresponding historical failure test cases are automatically run, and runtime data is collected synchronously to verify the effectiveness of the repair and support defect closed-loop verification. Fourth, boundary pressure triggering: when the system detects that the software is under extreme operating scenarios such as boundary input or high concurrency pressure, the corresponding boundary failure test cases are automatically loaded and data collection is initiated to uncover hidden defects under extreme conditions.

[0030] Once the medical software defect localization system receives the execution instruction, it begins to schedule the execution of failure test cases and simultaneously starts the collection of runtime characteristics in the code domain and model domain.

[0031] For example, there are two methods for collecting the defect runtime dataset. The first is synchronous collection at fixed points across the entire domain. Before the defect collection task officially starts, collection probes are pre-deployed at the entry and exit points of all code modules and the output of each layer of the neural network. After the failure test cases start running, all probes are synchronously triggered to collect data according to a unified timing benchmark, completely recording the full runtime characteristics of each fixed point. After the software has been fully executed, all point data are aggregated to generate the defect runtime dataset. This method has fixed collection points, high data integrity, and no risk of omissions. It can provide full-dimensional raw data support for subsequent defect comparison and is suitable for full-scale defect detection scenarios in conventional versions. The second method is dynamic point-adaptive acquisition. First, based on the type of failure test case, high-risk defect areas and modules are predicted. High-precision acquisition probes are deployed at the predicted high-risk points, while low-precision sampling probes are deployed at other low-risk points. During the execution of the failure test case, if a preliminary abnormal signal is detected at a low-risk point, the acquisition precision and sampling frequency of that point and its upstream and downstream related points are automatically upgraded, dynamically supplementing the acquisition of fine-grained features. After execution, all point data are integrated to generate a defect execution dataset. This method can dynamically allocate acquisition resources according to defect risk, ensuring the accuracy of abnormal data while reducing the amount of invalid data acquisition, improving acquisition efficiency and data validity, and adapting to rapid defect localization scenarios in large-scale software.

[0032] Once the original dual-domain runtime data is obtained, a defect runtime dataset can be generated based on the following methods.

[0033] In one alternative approach, the collected raw dual-domain data is directly concatenated chronologically and associated with the identification information of the corresponding failure test cases to form the defect runtime dataset. This method offers high data fidelity, no information loss, simple processing logic, and is suitable for detailed defect analysis scenarios with high requirements for data integrity.

[0034] In another alternative approach, the collected raw dual-domain data is first cleaned, deduplicated, and time-series aligned to remove invalid null values ​​and redundant fragments. Cross-domain time-series matching is then performed according to the correspondence between code execution flow and model inference flow. Finally, the data is structured and encapsulated according to the node dimension to generate a standardized defect runtime dataset. This method offers strong data standardization, a low proportion of invalid information, and can be directly used in subsequent feature comparison stages, thereby improving the processing efficiency of subsequent defect identification.

[0035] In an exemplary scheme for determining a defect runtime dataset, the set of failure test cases to be run is first loaded. The input format and gold standard annotation integrity of each test case are verified, and invalid test cases with abnormal formats are removed. Then, the acquisition probe initialization is initiated, runtime injection is performed on the code domain instrumentation probes, and the model domain feature capture hooks are mounted at the execution layer. The connectivity and acquisition availability of all probes are verified. Next, the full-process execution of the failure test cases is initiated, synchronously triggering all acquisition probes to sample data at a unified timestamp, and the raw runtime feature data of each point is cached in real time. After the test cases are executed, data validity verification is performed, and abnormal segments with sampling interruptions or missing data are removed. Then, cross-domain temporal alignment is performed according to the execution order of code modules and the inference order of neural network layers. The corresponding failure test case numbers and defect type labels are associated, finally generating a structured defect runtime dataset for subsequent node feature comparison and anomaly identification.

[0036] Step S20: Compare the defective running dataset with the healthy benchmark feature set node by node to identify the abnormal modules in the code domain and the abnormal layers in the model domain, and obtain a set of candidate defective nodes.

[0037] The health baseline feature set refers to a benchmark reference set constructed based on correct test cases of the gold standard, containing the normal operating feature range of each node and anomaly judgment rules. Node-by-node feature comparison refers to the process of matching and verifying defective operating features with baseline features item by item, using the collected nodes as the smallest unit. Anomaly modules in the code domain refer to code functional units whose operating features deviate from the normal baseline range. Anomaly layers in the model domain refer to neural network layers whose activation features deviate from the normal baseline range. The candidate defect node set refers to the set of anomaly nodes formed by integrating all code modules and network layers initially judged as anomalies according to their correlation relationships.

[0038] In this embodiment, the above-mentioned node-by-node feature comparison process can be initiated in three modes. The first is a full-node traversal comparison mode, which performs a full benchmark comparison on all collected nodes in the defect runtime dataset, indiscriminately covering all code modules and network layers, suitable for scenarios involving comprehensive defect screening. The second is a domain-specific targeted comparison mode, which performs node comparison only on the code domain or model domain based on defect prediction information, narrowing the comparison scope, suitable for scenarios involving targeted location of known defect domains. The third is a link-first comparison mode, which prioritizes comparing nodes along the core business data flow path and then gradually expands to surrounding related nodes, suitable for scenarios involving rapid location of core business faults.

[0039] After the defect identification module obtains the defect running dataset, it retrieves the corresponding health benchmark feature set and starts the node-by-node feature comparison process.

[0040] For example, there are two implementation methods for node-by-node feature comparison. The first is static threshold hard judgment comparison. Before the comparison process officially starts, the preset fixed anomaly judgment threshold of each node in the healthy benchmark feature set is directly retrieved. The feature values ​​of the corresponding nodes in the defective running dataset are compared with the fixed threshold one by one. Nodes whose feature values ​​exceed the threshold range are directly marked as abnormal nodes. This method has simple calculation logic, fast comparison speed, clear and controllable judgment rules, and is suitable for conventional defect identification scenarios with stable feature fluctuation patterns and clear boundaries. The second is dynamic distribution fitting comparison. First, the normal feature distribution model of each node in the healthy benchmark feature set is extracted. Then, the feature samples of the corresponding nodes in the defective running dataset are substituted into the distribution model to calculate the goodness of fit. The degree of anomaly is determined according to the confidence of the feature samples in the normal distribution. Nodes with confidence scores lower than the preset standard are marked as abnormal nodes. This method can adapt to complex running scenarios where features have normal fluctuations, avoids misjudgment by fixed thresholds, has higher anomaly identification accuracy, and is suitable for software defect identification scenarios with complex running environments and large feature fluctuation ranges.

[0041] After obtaining the full node anomaly determination results, a candidate defect node set can be generated based on the following method.

[0042] In one alternative approach, all code modules marked as abnormal are directly aggregated with the network layer and categorized according to their domains to generate a set of candidate defect nodes. This method has a simple generation logic, completely preserves all abnormal nodes, avoids missing potential defects, and is suitable for scenarios involving comprehensive defect investigation.

[0043] In another alternative approach, all nodes marked as abnormal are first subjected to correlation verification to remove isolated, sporadic abnormal nodes without upstream or downstream connections. Then, the remaining abnormal nodes are associated and bound according to data flow relationships, and the severity level of each node is labeled to generate a set of candidate defect nodes with correlations. This method can filter out invalid sporadic anomalies, strengthen the correlation attributes between nodes, provide more accurate input for subsequent root cause reasoning, and adapt to the precise location of complex defects.

[0044] In an exemplary scheme for determining a candidate defect node set, a healthy baseline feature set is first loaded, and the baseline feature intervals, distribution parameters, and judgment rules corresponding to each node are extracted to construct a node-level comparison baseline mapping table. Then, the defect running dataset is split according to node identifiers and matched one-to-one with the nodes in the comparison baseline mapping table. Next, node-by-node feature comparison is performed. For code domain nodes, the deviation of the running feature values ​​from the baseline interval is calculated; for model domain nodes, the fitting confidence of the activation features with the baseline distribution is calculated, and the anomaly quantification value of each node is recorded simultaneously. Then, anomaly node initial screening is performed, extracting nodes whose deviation exceeds the baseline interval or whose fitting confidence is lower than the judgment standard, forming a code domain anomaly module list and a model domain anomaly layer list, respectively. Next, anomaly node validity verification is performed, checking the continuity of feature changes in upstream and downstream nodes of each anomaly node, and eliminating transient fluctuation anomaly nodes without transmission correlation. Finally, the valid anomaly nodes are associated and sorted according to the data flow order, and the anomaly level and domain attribute of each node are labeled, integrating them to generate a candidate defect node set for subsequent cross-domain association inference and root cause localization.

[0045] Step S30: Based on the data flow dependency graph between the code module and the neural network layer, perform cross-domain association reasoning on the candidate defect node set to obtain the defect root cause localization conclusion.

[0046] A data flow dependency graph is a topological graph depicting the data input / output transmission relationships between code modules, network layers, and between code and models. Cross-domain association reasoning refers to the analytical process of tracing anomaly propagation paths and determining defect root causes by combining the data dependency relationships between nodes in two domains. Defect root cause localization conclusions refer to the localization results that include the defect root cause node, the domain to which the defect belongs, and the anomaly propagation path.

[0047] In this embodiment, the aforementioned cross-domain correlation reasoning can be carried out using three reasoning strategies. The first is a reverse tracing reasoning strategy, which starts from the downstream output anomaly node and traces the anomaly's origin backward along the data flow; this is used for defect localization scenarios where the output result clearly indicates an anomaly. The second is a forward propagation reasoning strategy, which starts from the upstream input node and traces the anomaly's propagation path forward along the data flow; this is used for locating cascading defects triggered by input anomalies. The third is a bidirectional linkage reasoning strategy, which starts from both the upstream input node and the downstream output node and matches the anomaly propagation link bidirectionally along the data flow; this is used for rapidly locating complex cascading defects.

[0048] Once the root cause reasoning module obtains the set of candidate defect nodes, it retrieves the data flow dependency graph and initiates the cross-domain association reasoning process.

[0049] For example, cross-domain correlation reasoning can be implemented in two ways. The first is rule-matching reasoning. Before the reasoning process officially starts, anomaly propagation rules and cross-domain correlation judgment rules corresponding to different defect types are pre-configured. After locating the topological positions of all candidate defect nodes in the graph, the anomaly propagation links are sorted along the data flow direction. The link features are matched with the preset rules to directly determine the root cause node and defect type. This method has clear reasoning logic, fast judgment speed, and strong rule interpretability, making it suitable for rapid location scenarios of known defect patterns. The second is propagation probability reasoning. First, the anomaly propagation probability between each anomaly node is calculated based on the data flow dependency graph to construct an anomaly propagation probability matrix. Then, combined with the anomaly severity of each node, the probability value of each node as a root cause node is calculated through a probability propagation algorithm. The node with the highest probability is determined as the core root cause node, and the anomaly propagation path is deduced simultaneously. This method can quantify the root cause probability of a node, is suitable for locating complex defects with multiple nodes and cross-domain coupled defects, and can effectively identify deeply hidden indirect root causes.

[0050] Once the root cause node determination is completed, the defect root cause localization conclusion can be generated based on the following methods.

[0051] In one alternative approach, the core root cause nodes and defect domain information obtained through reasoning are directly integrated to generate a defect root cause localization conclusion. This method provides concise and clear conclusions, fast output speed, and is suitable for lightweight localization needs requiring rapid troubleshooting.

[0052] In another optional approach, in addition to identifying the core root cause node and the defect's domain, the complete anomaly propagation chain is simultaneously analyzed. The anomaly transmission relationship and impact degree of each node in the chain are marked, and the defect type determination results are supplemented, forming a complete defect root cause localization conclusion that includes the root cause node, propagation path, and defect type. This method provides complete and highly interpretable conclusions, offering comprehensive reference for subsequent remediation and adapting to the deep localization needs of complex defects.

[0053] In an exemplary scheme for obtaining a defect root cause localization conclusion, the data flow dependency graph between the code module and the neural network layer is first loaded. All abnormal nodes in the candidate defect node set are mapped to their corresponding topological positions in the graph, generating a local dependency subgraph with anomaly markers. Then, the local dependency subgraph is traversed in reverse along the data flow direction to identify the upstream and downstream dependencies between all abnormal nodes, marking the necessary and branch nodes for anomaly propagation. Next, cross-domain association determination is performed to identify cross-domain connection nodes where anomalies propagate from the code domain to the model domain or from the model domain to the code domain, determining the initial triggering domain of the defect. Then, combining the anomaly severity level and topological position of each node, the root cause contribution of each node is calculated, and the node with the highest contribution is selected as the core root cause node. Finally, the core root cause node information, the defect's domain, the anomaly propagation link, and the defect type determination results are integrated to generate a complete defect root cause localization conclusion, which is used for subsequent confidence scoring and report generation.

[0054] Step S40: Based on the defect root cause localization conclusion and the confidence evaluation dimension weights, calculate and sort the comprehensive confidence score of each root cause node to obtain the defect localization report.

[0055] The confidence level evaluation dimension weights refer to the weight coefficients used to measure the degree of influence of each evaluation dimension on the confidence level of the defect. The comprehensive confidence score is a quantitative score calculated by integrating multiple dimensions, characterizing the reliability of the root cause determination results. The defect location report is a structured output document that includes defect location results, confidence level information, and the basis for the determination.

[0056] In this embodiment, the aforementioned confidence scoring and report generation can be performed through three output modes. The first is the standard scoring mode, which uses general evaluation dimension weights and report templates to generate results, suitable for typical defect localization scenarios. The second is the customized scoring mode, which adjusts the evaluation dimension weights according to business needs and customizes the report display content, suitable for specific defect localization scenarios within specific business lines. The third is the minimalist output mode, which only outputs the root cause node and confidence score, without generating a complete report, suitable for rapid result callback scenarios in automated pipelines.

[0057] After the report generation module obtains the root cause localization conclusion, it retrieves the weights of the confidence evaluation dimensions and initiates the comprehensive confidence scoring process.

[0058] For example, there are two ways to implement the comprehensive confidence score. The first is linear weighted scoring. Before the scoring process officially starts, three core evaluation dimensions—abnormal deviation magnitude, transmission link level, and cross-domain correlation strength—and their corresponding weight coefficients are defined. The quantitative values ​​of the corresponding dimensions for each root cause node are extracted, standardized and normalized, and then weighted and summed to directly obtain the comprehensive confidence score of each root cause node. This method has a simple calculation logic, the scoring results are intuitive and interpretable, and the weight adjustment is flexible, making it suitable for conventional defect confidence assessment scenarios. The second is hierarchical fuzzy scoring. First, a hierarchical evaluation system containing first-level dimensions and second-level sub-dimensions is constructed. The weights of each level are determined by combining the confidence evaluation dimension weights. Then, the confidence membership degree of each sub-dimension is calculated through a fuzzy membership function, and the comprehensive confidence score of each root cause node is obtained by aggregating upwards layer by layer. This method can adapt to complex scenarios with many evaluation dimensions and fuzzy judgment boundaries. The scoring results are more in line with the complex characteristics of actual defects, and the confidence assessment accuracy is higher, making it suitable for high-complexity and highly coupled defect assessment scenarios.

[0059] Once the confidence scores for all root cause nodes have been calculated, a defect location report can be generated based on the following method.

[0060] In one alternative approach, root cause nodes are sorted by confidence score and then directly populated into a pre-defined standardized report template to generate a defect location report. This method offers fast generation speed, a unified and standardized report format, and is suitable for standardized output scenarios involving batch defect location.

[0061] In another alternative approach, root cause nodes are first sorted by confidence level. Then, the abnormal feature evidence, transmission path diagram, defect type description, and remediation suggestions corresponding to each node are simultaneously correlated and matched. This information is then populated into a report template to generate a defect location report containing complete judgment criteria and reference suggestions. This method provides complete and practical information, directly supporting defect remediation work and is suitable for in-depth defect location scenarios for R&D personnel.

[0062] In an exemplary solution for obtaining a defect location report, a pre-configured confidence evaluation dimension weight table is first loaded, and weight coefficients for three core dimensions—abnormal deviation magnitude, transmission link level, and cross-domain correlation strength—are extracted. Then, the quantified values ​​corresponding to each root cause node are extracted from the defect root cause location conclusion, and standardized and normalized processing is performed to eliminate dimensional differences between dimensions. Next, the scores of each dimension are weighted and summed according to the corresponding weight coefficients to calculate the comprehensive confidence score for each root cause node. The validity of the score results is simultaneously verified, and abnormal scores are removed. Then, all root cause nodes are sorted from high to low according to their comprehensive confidence scores to generate an ordered list of root cause nodes. Next, a standardized report template is retrieved, and the ordered list of root cause nodes, the domain information of each node, the basis for anomaly judgment, and the transmission link information are filled into the corresponding modules one by one. An overall description of the defect and reference repair directions are added, and finally, a structured defect location report is generated and output.

[0063] Further, please refer to Figure 2 , Figure 2 This is the overall flowchart of this application. After the medical software defect localization process is initiated, the first step is to execute program instrumentation and model-level hook deployment. This deployment work is divided into two parts and carried out simultaneously: instrumentation of module entry and exit points is completed in the code domain, and forward hooks are deployed after each network layer in the model domain. After probe deployment, the step of building a dual-domain defect feature knowledge base is executed, forming a code domain defect signature library and a model domain defect signature library respectively. Next, the step of collecting baseline vector datasets is executed, running all correct test cases and performing baseline statistics to obtain a standard baseline vector dataset. Then, the defect triggering test step is executed, running failed test cases and collecting corresponding defect execution data. Afterwards, the dual-domain anomaly detection engine collaborative analysis step is initiated, simultaneously conducting analysis through three dimensions: dimension one (code domain anomaly localization), dimension two (model domain anomaly localization), and dimension three (cross-domain collaborative association), completing multi-dimensional anomaly association analysis. Following this, the defect root cause confidence calculation and report output step is executed, generating and outputting standardized defect localization results. Finally, the knowledge base incremental learning and closed-loop optimization step is executed, completing the iterative update of defect knowledge and ending the process.

[0064] Second Embodiment This embodiment provides an exemplary scheme for determining a defective runtime dataset. In this example, failure test cases are first loaded into the medical auxiliary diagnostic software under test and dual-domain acquisition probes are activated to construct a dual-domain acquisition link. Then, the raw runtime data of the two domains is obtained through the acquisition link and organized according to time sequence. Subsequently, time sequence alignment matching and invalid data removal are performed. Finally, data encapsulation and test case identification association are completed to obtain the defective runtime dataset. Step S10 includes steps A11 to A14: Step A11: Load the failure test cases into the medical auxiliary diagnostic software under test, and activate the instrumentation probes at the code module entrance and exit and the feature capture hooks of each layer of the neural network to construct a dual-domain acquisition link.

[0065] Step A12: Through the dual-domain acquisition link, obtain the running feature data of each code module and the activation tensor statistical features of each layer of the neural network, and organize them according to the time sequence to obtain the dual-domain original running dataset.

[0066] Step A13: Perform node-by-node time-series alignment matching on the original dual-domain running dataset based on the time-series benchmark, remove invalid and redundant data, and obtain valid dual-domain running data.

[0067] Step A14: Encapsulate the valid running data of the two domains according to the chronological order and domain category, and associate it with the identification information of the corresponding failure test cases to obtain the defect running dataset.

[0068] Instrumentation probes are data acquisition units deployed at the entry and exit points of code modules to non-intrusively collect module runtime status data. Feature capture hooks are data acquisition units attached to the output ends of each layer of the neural network to capture layer inference activation features. The dual-domain acquisition link is a parallel acquisition path with unified temporal synchronization capabilities, composed of code domain instrumentation probes and model domain feature capture hooks. Runtime feature data is a set of quantitative indicators describing the runtime status of code modules, such as module execution time, input and output parameter value range, exception error indicators, memory usage fluctuation values, and function call stack depth. Activation tensor statistical features are a set of quantitative indicators describing the distribution characteristics of inference outputs of each layer of the neural network, such as the layer activation tensor mean, activation value distribution dispersion, feature map response region ratio, neuron activation rate, and output tensor deviation value. The temporal reference is a standard time reference system used to unify the timestamps of dual-domain data and is the core basis for achieving cross-domain data alignment.

[0069] In this example, when constructing a dual-domain acquisition link to initiate data acquisition, a fixed-point deployment method covering the entire domain can be used as a reference. Acquisition probes are pre-deployed at all code module entry / exit points and at each layer of the neural network. Once failure test cases are loaded, all probes are activated uniformly, constructing a dual-domain acquisition link with full coverage. Alternatively, a dynamic deployment method based on risk prediction can be used. First, based on the type of failure test cases, the modules and levels with high defect incidence are predicted. High-precision acquisition probes are deployed only at high-risk points, and low-precision sampling probes are deployed at low-risk points. Once failure test cases are loaded, the corresponding probes are activated hierarchically, constructing a dual-domain acquisition link with resources allocated on demand, thus completing the construction of the acquisition link.

[0070] After establishing the dual-domain data acquisition pipeline, the data acquisition process for dual-domain runtime data is initiated. The pipeline synchronously acquires runtime characteristic data of each code module and activation tensor statistical features of each layer of the neural network. This data is then organized according to the chronological order of acquisition to obtain the original dual-domain runtime dataset. Subsequently, using a unified temporal benchmark, node-by-node temporal alignment and matching are performed on the original dual-domain runtime dataset. Corresponding node data in the code domain and model domain are time-stamped and bound together. Redundant data, such as invalid null values ​​and duplicate sampling fragments generated during the acquisition process, are removed to obtain temporally consistent valid dual-domain runtime data. Finally, the valid dual-domain runtime data is structurally encapsulated according to the temporal order and the category attributes of the code and model domains. The unique identifier information of the corresponding failure test cases is synchronously associated, resulting in a standardized defect runtime dataset. This layered acquisition, alignment, and encapsulation process improves the temporal consistency and data standardization of the defect runtime dataset, preventing deviations in subsequent defect identification due to data misalignment or invalid redundancy.

[0071] For example, there are two ways to generate a defect runtime dataset through a dual-domain acquisition link. The first is a synchronous serial full-process acquisition and processing. After the failure test cases are loaded, all acquisition probes are activated synchronously to start data acquisition. After the software has completely executed the test cases and all raw data has been acquired, timing alignment, invalid data removal, and structured encapsulation operations are performed uniformly. Specifically, the loading of failure test cases and probe activation are completed first, and the runtime characteristic data of the code domain and model domain are collected synchronously throughout the process. After the test cases are executed and all probes stop acquiring data, the raw data is initially organized into a dual-domain raw runtime dataset according to timing. Then, a unified timing benchmark is imported, and timing alignment and matching of code domain and model domain data are performed node by node. The integrity of the data at each node is verified, and invalid and redundant data fragments are removed to obtain valid dual-domain runtime data. Finally, data encapsulation is performed according to domain classification and timing order, and the defect runtime dataset is generated after associating it with failure test case identifiers. This method employs a serial execution logic for data acquisition and processing, ensuring that the acquisition process does not interfere with the software's operational flow. During the data processing stage, all original data can be called up for global verification, resulting in high data integrity and alignment accuracy. This provides high-quality, standardized input for subsequent defect analysis and is suitable for the refined defect localization scenarios of small-scale software.

[0072] The second approach is asynchronous pipelined parallel data acquisition and processing. Simultaneously with the failure test cases starting and the acquisition probes beginning data collection, a background data preprocessing pipeline is launched. Completed data segments are processed in real-time, without waiting for the full data acquisition to complete. Specifically, after the failure test cases are loaded and the probes are activated, software operation and data acquisition continue. Each completed code module and corresponding network layer execution sends the acquired data to the preprocessing pipeline. The preprocessing pipeline performs time stamping and initial deduplication on the segmented data in real-time. Once half of the full data acquisition is complete, time alignment matching and invalid data removal for the completed segments are initiated simultaneously. The acquisition and processing stages proceed in parallel via the pipeline. After the full data acquisition is complete, the remaining segments are processed and the entire dataset is encapsulated, allowing for rapid association with failure test case identifiers to generate a defective runtime dataset. This method employs parallel execution logic for data acquisition and processing pipelines. It compresses the overall processing time through segmented real-time preprocessing, making full use of the idle time of software operation to complete data processing. This shortens the total time from test case initiation to dataset output, making it suitable for batch defect testing and rapid localization scenarios in large-scale software.

[0073] Further, please refer to Figure 3 , Figure 3 This is a schematic diagram of the workflow of the dual-domain anomaly detection engine in this application. The collaborative analysis process of the dual-domain anomaly detection engine proceeds in parallel along three dimensions. Dimension 1 is code domain anomaly localization. After inputting code instrumentation data from the defect execution data, it compares the execution time, anomaly information, and input and output hash values ​​module by module, marking modules that exceed three times the standard deviation (3σ) threshold or have anomaly throwing, generating a candidate anomaly set (L_code) for the code domain. Dimension 2 is model domain anomaly localization. After inputting model layer hook data from the defect execution data, it compares the relative entropy (KL divergence), cosine similarity, and activation sparsity layer by layer, generating an anomaly propagation heatmap and locating the anomaly initiation layer (L_start). Then, through the contribution backpropagation chain, i.e., the integral gradient and hierarchical correlation propagation (LRP) method, it generates a candidate anomaly set (L_model) for the model domain. Dimension three focuses on cross-domain collaborative association. After inputting the candidate anomaly sets for the code domain, model domain, and dependency graph, the graph is traversed to find directed paths from the code domain to the model domain and to determine if such paths exist. If a directed path exists, it is identified as a high-confidence collaborative defect; otherwise, independent verification is performed, and the defect is assigned to either the code or model domain. The final output includes the location of the candidate defect and the strength of the cross-domain association. Finally, the results from all three dimensions are combined, integrating the code domain candidate anomaly set, model domain candidate anomaly set, cross-domain matching relationships, and anomaly propagation depth to obtain a complete collaborative analysis output.

[0074] Third Embodiment This embodiment provides an exemplary scheme for determining a candidate defect node set. In this example, the identification information of the defect running dataset is first used as an index to match the corresponding benchmark parameters from the healthy benchmark feature set to construct a comparison benchmark set. Then, the feature deviation magnitude and similarity of the dual-domain nodes are calculated to obtain the abnormal deviation quantification result. Subsequently, abnormal nodes are verified and filtered out node by node and grouped by domain. Finally, the nodes are associated, sorted, and labeled with the abnormality level according to the data flow order, and integrated to obtain the candidate defect node set. Step S20 includes steps B11 to B15: Step B11: Using the identification information associated within the defect running dataset as a retrieval index, match the baseline feature range and anomaly judgment threshold of the corresponding node from the health baseline feature set of the dual-domain defect feature knowledge base to construct a comparison baseline set.

[0075] Step B12: Based on the comparison benchmark set, calculate the deviation of the code module running features from the corresponding benchmark and the similarity of the neural network layer activation features from the corresponding benchmark, and compile the node abnormal deviation quantification results.

[0076] Step B13: Based on the anomaly determination threshold of each node, perform node-by-node verification and screening of the abnormal deviation quantification results of the nodes to determine the abnormal nodes whose deviation exceeds the deviation threshold or whose similarity is lower than the similarity threshold.

[0077] Step B14: Based on the identification information corresponding to the abnormal node, generate code domain abnormal module group and model domain abnormal hierarchy group respectively.

[0078] Step B15: Sort the code domain anomaly module group and the model domain anomaly hierarchy group according to the order of data flow, and mark the anomaly severity level of each node to obtain the candidate defect node set.

[0079] The benchmark set refers to the set of benchmark parameters extracted from the healthy benchmark feature set and corresponding one-to-one with the nodes of the current defective running dataset. It is the core reference for node anomaly determination. The benchmark feature range refers to the reasonable fluctuation range of each node's feature parameters under normal operating conditions. Examples include the normal execution time range of a code module, the normal memory usage range, the normal function call stack depth range, the normal activation value distribution range of a neural network layer, the normal proportion range of feature responses, and the normal range of neuron activation rates. The anomaly determination threshold is a critical value used to define whether node features deviate from the normal state. It includes two types: deviation threshold and similarity threshold. The deviation threshold is used to determine the maximum allowable deviation of code running features, and the similarity threshold is used to determine the minimum allowable similarity of model activation features. The deviation magnitude refers to the degree of deviation between the actual running features of the code module and the benchmark feature range; a larger deviation indicates a higher degree of anomaly in the module's running state. The similarity refers to the degree of matching between the actual activation features of the neural network layer and the benchmark features; a lower similarity indicates a higher degree of anomaly in the network layer's inference state. The node anomaly deviation quantification result is the summary set of deviation magnitude and similarity quantification values ​​for all nodes, and it is the direct input for anomaly node screening. The candidate defect node set refers to the set of abnormal nodes that have been filtered by anomaly judgment, sorted according to data flow relationship, and labeled with anomaly level. It is the core input for subsequent cross-domain root cause reasoning.

[0080] In this example, when constructing a comparison benchmark set to prepare for anomaly comparison, a full-node benchmark matching approach can be used. The identifier information of all nodes in the defect runtime dataset is used as a retrieval index, and the benchmark feature ranges and anomaly judgment thresholds of the corresponding nodes are fully matched from the healthy benchmark feature set to construct a comparison benchmark set that completely covers all nodes. Alternatively, a risk priority hierarchical matching approach can be used. First, the range of high-risk nodes is predicted based on the defect type of the failure test cases. High-precision benchmark parameters and refined judgment thresholds are matched preferentially to high-risk nodes, while conventional benchmark parameters and general judgment thresholds are matched to low-risk nodes. A hierarchical comparison benchmark set is constructed as needed to complete the construction of the comparison benchmark.

[0081] After constructing the benchmark set, the node anomaly deviation quantization calculation process is initiated. Based on the corresponding parameters in the benchmark set, the deviation magnitude of the runtime features of each code module from the benchmark interval and the similarity between the activation features of each neural network layer and the benchmark features are calculated. The quantization results of all nodes are organized and summarized according to the node identifier to obtain the node anomaly deviation quantization results. Subsequently, based on the anomaly judgment threshold corresponding to each node, the node anomaly deviation quantization results are checked and filtered node by node. Nodes whose deviation magnitude exceeds the corresponding deviation threshold or whose similarity is lower than the corresponding similarity threshold are identified as anomaly nodes. Then, according to the domain attribute to which the anomaly node's identifier information belongs, the anomaly nodes are classified into code domain anomaly module groups and model domain anomaly hierarchy groups. Finally, according to the data flow sequence of the software operation, all abnormal nodes in the code domain abnormal module group and the model domain abnormal hierarchy group are cross-domain correlated and sorted. At the same time, the corresponding abnormality severity level is marked according to the deviation degree of each node. All information is integrated to finally obtain a structured candidate defect node set. In this way, through hierarchical benchmark matching, quantitative calculation, verification screening and correlation sorting, the accuracy and correlation of abnormal node identification are improved, and the root cause location bias caused by isolated judgment is avoided.

[0082] For example, there are two ways to generate a candidate defect node set by filtering the results of node anomaly deviation quantification. The first is a sequential node-by-node verification and filtering. Following the order of nodes in the data link, the anomaly deviation quantification result of each node is extracted sequentially from the upstream input node to the downstream output node, and compared item by item with the anomaly judgment threshold corresponding to that node. After each node's threshold comparison is completed, it is simultaneously determined whether the node meets the anomaly judgment condition. If it does, the node is marked as an anomaly node and temporarily stored in the anomaly group of the corresponding domain; if it does not meet the condition, the node is skipped and the next node is processed. After all nodes have completed sequential verification and judgment, the anomaly node groups of the two domains are summarized, and association sorting and anomaly level labeling are performed according to the data flow order to generate a candidate defect node set. This method uses sequential node-by-node judgment and real-time grouping logic. By verifying sequentially according to the data flow order, the transmission trend of anomalies along the link can be observed simultaneously. The judgment process has strong traceability and is suitable for defect location scenarios with small node scale and requiring refined verification.

[0083] The second method is a dual-domain parallel clustering screening. First, the quantification results of node anomalies are split into code domain and model domain, generating two independent subsets of quantification results for each domain. Parallel anomaly clustering analysis is then initiated on both subsets. For the code domain subset, clustering is performed using deviation magnitude as a feature dimension, grouping nodes with deviation magnitudes significantly higher than the overall distribution into anomaly node groups. For the model domain subset, clustering is performed using similarity as a feature dimension, grouping nodes with similarity significantly lower than the overall distribution into anomaly node groups. After dual-domain clustering, the resulting anomaly nodes are simultaneously verified to meet corresponding threshold requirements, eliminating boundary misjudgments and generating code domain anomaly module groups and model domain anomaly hierarchy groups. Then, based on data flow dependencies, cross-domain association ranking and level labeling are performed on the two groups of anomaly nodes, integrating them to generate a candidate defect node set. This method employs a logic that combines dual-domain parallel clustering with threshold verification. It quickly identifies abnormal clustering areas through pre-clustering, reduces the amount of invalid computation in node-by-node comparison, and the parallel processing mode can improve the screening efficiency in large-scale node scenarios, making it suitable for defect localization scenarios in large-scale medical software with a large number of nodes and complex structures.

[0084] Further, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the data dependency relationship between the code and model in this application. It shows the complete data processing chain of an AI-assisted gastroscopy diagnostic software, illustrating the data flow dependency between the code domain and the model domain, as well as the anomaly propagation path: Data first enters the gastroscopy image decoding module developed in C++ to complete image decoding and output the raw pixel matrix. The raw pixel matrix is ​​then fed into the illumination correction module developed in Python to perform illumination compensation correction and output the corrected image. The corrected image is then sent to the size normalization module developed in Python to perform resolution unification processing and output a standardized image of 224×224. The standardized image enters the first convolutional layer, i.e., the model input layer, to complete low-level feature extraction, and is then passed to the second network layer for further processing and output of a feature map. The feature map continues to be passed down to the third network layer, i.e., the anomaly initiation layer, which is the initial triggering layer for defects and anomalies, and outputs a feature map after processing. The feature map is input into the fully connected layer, i.e., the output probability layer, to complete classification inference and output probability values. Finally, the probability values ​​are fed into the post-processing module, and after threshold judgment logic, the final diagnostic result is output.

[0085] Fourth embodiment This embodiment provides an exemplary scheme for determining abnormal nodes. In this example, the abnormal deviation quantification results of nodes are first mapped and bound to the deviation threshold and similarity threshold corresponding to each node to generate a node verification dataset. Then, a two-dimensional judgment of the deviation magnitude of running features and the similarity of activation features is carried out simultaneously, and abnormal nodes are initially screened. Subsequently, pseudo-abnormal nodes caused by collection fluctuations are eliminated based on the continuity of feature changes of upstream and downstream adjacent nodes. Finally, abnormal nodes are classified and collected according to domain attributes and labeled with the type and level of abnormal triggering, resulting in accurately verified abnormal nodes. Step B13 includes steps C11 to C14: Step C11: Map and bind the node abnormal deviation quantization result with the deviation threshold and similarity threshold corresponding to each node in the abnormal judgment threshold to obtain the node verification dataset.

[0086] Step C12: Determine the deviation magnitude of the running features and the similarity of the activation features of the nodes in the node verification dataset, and mark the nodes whose deviation magnitude exceeds the deviation threshold or whose similarity is lower than the similarity threshold to obtain the abnormal initial screening nodes.

[0087] Step C13: Based on the continuity of characteristic changes of adjacent nodes upstream and downstream of the initial screening node for anomalies, eliminate pseudo-anomalies caused by instantaneous fluctuations in data collection, and obtain the verified initial screening nodes for anomalies.

[0088] Step C14: Classify and group the reviewed abnormal initial screening nodes according to the code domain and model domain attributes to which the nodes belong, and label the abnormal trigger type and abnormal level of the nodes to obtain the abnormal nodes.

[0089] The node verification dataset is a set of verification parameters formed by associating and binding the abnormal deviation quantization values ​​of nodes with corresponding judgment thresholds. It is the direct processing object for abnormal node judgment. The deviation threshold is a critical value that defines whether the code module's running characteristics are abnormal. Exceeding this threshold indicates that the module's running state deviates from the normal range, such as execution time deviating from the threshold, memory usage deviating from the threshold, or parameter value deviating from the threshold. The similarity threshold is a critical value that defines whether the activation features of a neural network layer are abnormal. Below this threshold, it indicates that the network layer's inference state deviates from the normal pattern, such as activation distribution similarity threshold, feature response similarity threshold, and tensor statistical similarity threshold. The initial abnormal screening nodes are nodes initially marked as abnormal after the first round of threshold judgment, including genuine abnormal nodes and pseudo-abnormal nodes caused by data acquisition fluctuations. Pseudo-abnormal nodes are nodes whose feature values ​​temporarily deviate from the threshold due to instantaneous data acquisition fluctuations or data sampling errors, but which do not actually have real defects; these are misjudged nodes that need to be removed. Anomaly trigger types are defect categories categorized based on the anomaly's behavior. Examples include execution timeout anomalies, parameter out-of-bounds anomalies, and memory overflow anomalies in the code domain; and activation drift anomalies, feature sparsity anomalies, and output bias anomalies in the model domain. Anomaly levels are graded indicators representing the severity of a node's anomaly, typically divided into three levels: minor, moderate, and severe, used to guide the prioritization of subsequent root cause analysis.

[0090] In this example, when mapping and binding thresholds to quantization results to obtain a node verification dataset, a one-to-one matching approach can be used, binding each node's abnormal deviation from the quantization result to its specific deviation threshold and similarity threshold one by one to construct a node verification dataset covering all nodes. Alternatively, a domain-based batch mapping approach can be used, first splitting the quantization results into two subsets according to the code domain and the model domain, batch matching the corresponding domain's threshold parameter groups for each subset, and then integrating them to form a node verification dataset, thereby completing the binding and construction of the verification data.

[0091] After constructing the node verification dataset, an anomaly screening process is initiated. For each node in the dataset, a deviation magnitude judgment and activation feature similarity judgment are performed simultaneously. If either the deviation magnitude exceeds a threshold or the similarity is below a threshold, the node is marked as an anomaly. Subsequently, the data flow dependency is retrieved, and the feature change trends of upstream and downstream adjacent nodes of each anomaly are examined to determine if the anomaly has propagation continuity. If a node deviates from the threshold but its upstream and downstream nodes are in a normal state with no continuous anomaly propagation features, it is judged as a pseudo-anomaly node caused by instantaneous fluctuations in data collection and is removed. Nodes with propagation continuity are retained, resulting in the verified anomaly screening nodes. Finally, the verified nodes are categorized and aggregated according to their code domain and model domain attributes. Simultaneously, the anomaly trigger type and anomaly level of each node are determined based on the deviation magnitude and labeled accordingly. Ultimately, accurate anomaly nodes that have undergone double verification are obtained. This two-stage judgment mechanism, combining threshold screening and continuity verification, reduces the false positive rate caused by data collection fluctuations and improves the accuracy of anomaly node identification.

[0092] For example, there are two implementation methods for generating abnormal nodes through two-level judgment. The first is a serial, node-by-node progressive verification. Following the upstream and downstream order of nodes in the data flow, the verification data of each node is extracted sequentially from upstream to downstream. First, a threshold judgment is performed to mark initial anomalies. Then, the characteristic states of adjacent upstream and downstream nodes are checked simultaneously to verify the continuity of anomaly propagation. After each node's threshold judgment is completed, if it is judged to be normal, it is skipped directly. If it is marked as an initial screening anomaly, a continuity review is performed. If the propagation continuity is confirmed, it is retained; if it is judged to be a false anomaly, it is discarded. Simultaneously, the initial labeling of the anomaly type and level is completed. After all nodes have completed successive verification and review, the final abnormal nodes are obtained by classifying and aggregating them according to domain. This method uses a serial, progressive, node-by-node judgment and real-time review logic. The verification process is consistent with the data flow propagation direction, allowing for synchronous tracking of the anomaly propagation path. Single-node judgment is complete and traceable, making it suitable for scenarios with small node size and requiring fine-grained defect localization through point-by-point verification.

[0093] The second method is domain-specific parallel clustering verification. First, the node verification dataset is split into two independent verification subsets: the code domain and the model domain. Parallel threshold screening and clustering analysis are initiated simultaneously on both subsets. For the code domain subset, clustering is performed based on deviation magnitude, selecting nodes with deviations exceeding the threshold to form a preliminary screening group. Then, the continuity of upstream and downstream features of nodes within this group is verified based on module call relationships, eliminating isolated pseudo-anomaly nodes. For the model domain subset, clustering is performed based on similarity, selecting nodes with similarity below the threshold to form a preliminary screening group. Then, the continuity of upstream and downstream features of nodes within this group is verified based on network layer inference links, eliminating isolated pseudo-anomaly nodes. After dual-domain verification, all valid anomaly nodes are uniformly labeled with anomaly trigger type and level, and the final anomaly nodes are obtained by domain classification and aggregation. This method employs a logic that combines domain-specific parallel clustering with continuous verification. By using pre-clustering, the computational load of the initial screening is significantly reduced, and the parallel processing mode significantly improves the verification efficiency of large-scale nodes. At the same time, it relies on the transmission of continuous verification to ensure the accuracy of the judgment, making it suitable for large-scale medical software defect localization scenarios with a large number of nodes and complex structures.

[0094] Further, please refer to Figure 5 , Figure 5 This is a heatmap of anomaly propagation in the model domain of this application. The heatmap uses bar charts to visually represent the distribution of anomalies at each network layer. The vertical axis uses relative entropy, or KL divergence, as the anomaly indicator; a higher value indicates a higher degree of anomaly in the corresponding network layer. The horizontal axis represents the model layers, including the first convolutional layer, the second layer, the third layer, the fourth layer, and the fully connected layer. The bar chart shows that the first convolutional layer has the lowest anomaly level, the second layer shows a slight increase, the third layer is the anomaly initiation layer (the first layer to exhibit severe anomalies in the inference chain and a candidate for root cause of model defects), the fourth layer reaches its peak anomaly level, and the fully connected layer shows a decrease in anomaly level, clearly demonstrating the trend of anomaly propagation from the initiation layer along the inference direction.

[0095] Fifth Embodiment This embodiment provides an exemplary scheme for determining the root cause of a defect. In this example, the candidate defect node set is first mapped to the data flow dependency graph of the code module and the neural network layer to locate the topological position of the abnormal node, generating a data flow dependency subgraph with anomaly markers. Then, the abnormal propagation path is traced backward along the data flow and the data causal relationship between nodes is sorted out. Subsequently, the cross-domain connectivity attribute of the abnormal propagation path and the node domain distribution characteristics are combined to match the defect classification judgment rules to determine the root cause type. Finally, the core root cause node is locked based on the upstream and downstream position of the node in the propagation link, generating the root cause of the defect. Step S30 includes steps D11~D14: Step D11: Map the candidate defect node set to the data flow dependency graph between the code module and the neural network layer, locate the topological position of the abnormal node in the global data flow link, and generate a data flow dependency subgraph including the abnormal marker.

[0096] Step D12: Based on the data flow direction of the data flow dependency subgraph, trace the abnormal propagation path in reverse, identify the abnormal starting node and the nodes that propagate step by step, and determine the data causal relationship between the abnormal nodes.

[0097] Step D13: Based on the cross-domain connectivity attribute of the abnormal propagation path and the domain distribution characteristics of the abnormal node, match the defect classification judgment rule to determine the root cause type of the defect corresponding to the abnormal node.

[0098] Step D14: Based on the upstream and downstream positions of the abnormal node in the transmission link, determine the core root cause node under the root cause type, and generate the defect root cause localization conclusion by combining the data causal relationship.

[0099] The data flow dependency graph is a topological network depicting the data input-output transmission relationships between code modules, neural network layers, and across code and model domains. It serves as the core reference for tracing anomaly propagation paths. The data flow dependency subgraph is a local topological subgraph extracted from the global graph, containing all candidate defect nodes and their upstream and downstream related nodes. It is the direct object of root cause reasoning. The anomaly propagation path is the link of nodes along the data flow path from the starting node to the downstream node, providing the core clues for locating the root cause of defects. The data causal relationship is the logical association between anomaly nodes caused by data transmission, i.e., the correspondence that an anomaly in an upstream node leads to a chain of anomalies in downstream nodes. The cross-domain connectivity attribute is a characteristic that characterizes whether the anomaly propagation path simultaneously covers both the code domain and the model domain, used to determine whether a defect is of the cross-domain coupling type. The root cause type is a defect category classified according to the source and scope of defect triggering, such as single-domain logic defects in the code domain, single-domain reasoning defects in the model domain, and cross-domain coupling defects between code and model. The core root cause node is the initial source node that triggers the anomaly in the anomaly propagation path and is the core target of defect repair. The defect root cause localization conclusion is a complete localization result that includes the core root cause node, the defect root cause type, the anomaly propagation path, and the causal relationship of the data. It is the core input for subsequent confidence calculation and report generation.

[0100] In this example, when mapping the candidate defect node set to generate a data flow dependency subgraph, it can be done using a full node topology mapping approach. This involves mapping each abnormal node in the candidate defect node set to the global data flow dependency graph, marking the topological position of each node, and then extracting a local graph covering all abnormal nodes and their upstream and downstream first-level related nodes to generate a data flow dependency subgraph with anomaly markers. Alternatively, a core link-oriented extraction approach can be used. First, the downstream output abnormal node is located, and the core business transmission link is extracted in reverse along the data flow. Only candidate defect nodes are mapped to the scope of this core link graph, generating a data flow dependency subgraph focusing on the core transmission path. This completes the topology location of abnormal nodes and the construction of the subgraph.

[0101] After constructing the data flow dependency subgraph, a reverse tracing process for the anomaly propagation path is initiated. Following the data flow direction of the subgraph, the process traces back step-by-step from the downstream output to the upstream input, identifying the starting node of the anomaly and the intermediate nodes in its propagation, and clarifying the causal relationships between each anomaly node. Subsequently, based on the identified anomaly propagation path, it is determined whether it simultaneously connects the code domain and the model domain. Combining the domain distribution characteristics of the anomaly nodes, pre-defined defect classification rules are matched to determine the root cause type of the current defect. Finally, based on the upstream and downstream positions of each anomaly node in the propagation chain, the upstream anomaly starting node is identified as the core root cause node for that root cause type. Combining the complete data causal relationships and propagation path information, the final defect root cause localization conclusion is generated. This hierarchical reasoning logic of topological mapping, reverse tracing, and classification clarifies the anomaly propagation network and causal relationships, improving the accuracy and interpretability of root cause localization.

[0102] For example, there are two ways to generate defect root cause localization conclusions through data flow dependency subgraph reasoning. The first is reverse node-by-node serial tracing reasoning. Starting from the downstream output anomaly node of the data flow dependency subgraph, it traverses adjacent nodes upstream in the reverse direction of the data flow, verifying the transmission correlation of anomalies node by node. After verifying the anomaly correlation of each upstream node, if it is confirmed that the node's anomaly is the cause of the downstream node's anomaly, it is included in the anomaly transmission path, and the tracing continues upstream. If the upstream node has no anomaly characteristics, the tracing of the current branch is terminated, and the current node is marked as the anomaly starting node of that branch. After all branches have completed reverse tracing, all anomaly transmission paths are summarized, the data causal relationships between nodes are sorted out, and the defect classification judgment rules are matched with cross-domain connectivity attributes to determine the root cause type and lock the upstream core root cause node, generating a defect root cause localization conclusion. This method adopts reverse serial node-by-node tracing reasoning logic. The traversal process can completely trace the anomaly correlation of each transmission link. The reasoning path is clear and traceable, and it is suitable for single-domain or lightly coupled defect localization scenarios with small node scale and simple transmission links.

[0103] The second approach is bidirectional probabilistic parallel propagation inference. First, an anomaly propagation probability matrix is ​​constructed based on the data flow dependency subgraph. Simultaneously, forward anomaly propagation calculation and reverse root cause tracing calculation are initiated, advancing the inference process in parallel. Forward calculation starts from the upstream input node, calculating the propagation probability of anomalies spreading downstream from each node. Reverse calculation starts from the downstream output anomaly node, calculating the tracing probability of each node as an anomaly trigger. After bidirectional calculation, the probability results from both directions are fused to obtain the root cause contribution of each node, while simultaneously identifying the complete anomaly propagation path and the data causal relationship between nodes. Then, combining the cross-domain connectivity attributes of the path and the node domain distribution characteristics, the defect classification judgment rules are matched to determine the root cause type. The node with the highest root cause contribution is selected as the core root cause node, generating a defect root cause localization conclusion. This method employs bidirectional probabilistic fusion parallel inference logic, cross-validating the accuracy of the root cause through bidirectional calculation. It can effectively identify complex defects with multiple branches and cross-domain coupling. The parallel computing mode significantly improves the inference efficiency of complex links, making it suitable for cross-domain coupling defect localization scenarios with large node scale and complex propagation links.

[0104] Sixth Embodiment This embodiment provides an exemplary scheme for determining a defect location report. In this example, the three types of indicators in the defect root cause location conclusion—abnormal deviation magnitude, abnormal propagation link level, and cross-domain association matching strength—are first mapped and bound to the corresponding confidence evaluation dimensions and weights to generate a node confidence calculation set. Then, a weighted summation operation is performed based on the calculation set according to the weight coefficients corresponding to each evaluation dimension to obtain the confidence score result of each root cause node. Subsequently, the score results are sorted from high to low and associated with the abnormal feature fragments, data flow propagation paths, and domain affiliation information of each root cause node to generate an ordered root cause node list. Finally, the ordered root cause node list is structurally integrated according to a preset report framework to supplement the defect source domain classification, root cause severity level labeling, and repair direction guidance to obtain the defect location report. Step S40 includes steps E11~E14: Step E11: Bind the abnormal deviation magnitude, abnormal propagation link level, and cross-domain association matching strength in the defect root cause localization conclusion to the corresponding confidence evaluation dimension weight mapping to obtain the node confidence calculation set.

[0105] Step E12: Based on the node confidence calculation set, perform weighted summation according to the weight coefficients corresponding to the evaluation dimensions to obtain the confidence score results of each root cause node.

[0106] Step E13: Sort the confidence score results from high to low, and associate them with the abnormal feature fragments, data flow propagation paths and domain affiliation information corresponding to the root cause nodes to obtain an ordered list of root cause nodes.

[0107] Step E14: The ordered root cause node list is structured and integrated according to the preset report framework, and the defect source domain classification, root cause severity level labeling and repair direction guidance are added to obtain the defect location report.

[0108] Anomaly deviation magnitude is a quantitative indicator characterizing the degree of deviation between the actual operational characteristics of the root cause node and the normal baseline range. The larger the deviation, the higher the confidence level of the node's anomaly. Examples include deviations in code module execution time, memory usage, and parameter values; and deviations in neural network layer activation distribution, feature response, and tensor statistics. Anomaly propagation link hierarchy is a quantitative indicator characterizing the length of the propagation link from the root cause node to the final output anomaly node. The earlier the anomaly initiating node in the hierarchy, the higher its confidence level as a root cause. Examples include the upstream initiation level, midstream propagation level, and downstream performance level of the propagation link. Cross-domain association matching strength is a quantitative indicator characterizing the degree of data dependency matching between anomaly nodes in the code domain and model domain in cross-domain defect scenarios. The higher the matching strength, the higher the confidence level of the cross-domain root cause determination. Examples include data interface matching degree, propagation path connectivity, and anomaly timing fit. The node confidence calculation set is a set of calculation parameters formed by associating and binding the multi-dimensional evaluation indicators of each root cause node with their corresponding dimensional weights. It is the direct input for confidence score calculation. The confidence score is a weighted set of scores that quantify the credibility of the root cause determination; a higher score indicates a higher probability that the corresponding node is the true root cause. The ordered root cause node list is a list of root cause nodes sorted by confidence score and associated with complete anomaly evidence and path information; it is the core foundation for generating the final defect location report. The defect location report is a structured output document containing root cause ranking, defect classification, severity level, evidence chain, and remediation guidelines. It is the final delivery of the defect location process and directly supports software defect remediation and quality optimization. Defect source domain classification categorizes defects based on the domain to which they trigger, such as single-domain defects in the code domain, single-domain defects in the model domain, and cross-domain coupling defects between code and model. Remediation direction guidelines provide preliminary remediation reference directions for different defect types, such as code logic correction, model parameter tuning, cross-domain data interface adaptation, and anomaly boundary handling.

[0109] In this example, when mapping and binding evaluation metrics and dimension weights to obtain the node confidence calculation set, a one-to-one mapping approach can be used. This involves extracting three metrics for each root cause node: abnormal deviation magnitude, abnormal propagation chain level, and cross-domain association matching strength. These metrics are then bound one-to-one with the corresponding dimension coefficients in the pre-set confidence evaluation dimension weights to construct a node confidence calculation set covering all dimensions. Alternatively, a hierarchical weight dynamic mapping approach can be used. First, the weight priority of each dimension is adjusted according to the defect root cause type. For single-domain defect scenarios, the weight proportion of the abnormal deviation magnitude dimension is increased; for cross-domain coupling defect scenarios, the weight proportion of the cross-domain association matching strength dimension is increased. Then, these are mapped and bound to the metrics of the corresponding root cause nodes to generate a dynamic node confidence calculation set adapted to the defect type, thus completing the construction of the confidence calculation parameters.

[0110] After constructing the node confidence calculation set, the confidence score calculation process is initiated. Based on the various indicators and corresponding weight coefficients in the node confidence calculation set, a standardized weighted summation operation is performed to calculate the confidence score result for each root cause node. Subsequently, all root cause node confidence scores are sorted from highest to lowest. Simultaneously, each root cause node is associated with and matched with corresponding abnormal feature fragments, complete data flow propagation paths, and domain affiliation information to supplement the evidence supporting the root cause determination, generating a structured, ordered list of root cause nodes. Finally, the ordered list of root cause nodes is imported into a pre-defined report framework for structured integration. Classification and aggregation are completed according to the defect's domain, and the severity level of each root cause node is marked. At the same time, corresponding defect type repair direction guidance is matched, ultimately outputting a complete defect location report. This multi-dimensional quantitative scoring, evidence association, and structured output layered processing improves the readability and practicality of defect location results, providing clear guidance for subsequent defect repair.

[0111] For example, there are two ways to generate a defect location report using an ordered root cause node list. The first is a node-by-node refined serial generation. Following the priority order of the ordered root cause node list, starting with the root cause node with the highest confidence, each node is filled into the corresponding module of the report template. For each root cause node filled, details of the corresponding abnormal characteristics, the complete derivation process of the transmission path, detailed abnormal evidence, and targeted remediation suggestions are simultaneously added. The next node is processed only after the content of a single node is completed. After all root cause nodes are filled, an overall defect overview, domain distribution statistics, and comprehensive remediation priority suggestions are added to the report, ultimately generating a deep defect location report with a complete derivation chain. This method uses a node-by-node serial refined filling logic, resulting in a comprehensive and traceable report. The judgment criteria and remediation suggestions for each root cause are highly targeted, making it suitable for in-depth investigation and R&D remediation scenarios involving complex single-case defects.

[0112] The second method is template-based parallel batch generation. First, a pre-set standardized report template is loaded. The ordered root cause node list is split into four data modules: root cause basic information, abnormal evidence information, transmission path information, and classification and grading information. These four modules simultaneously initiate parallel template mapping and filling, batch-completing the information entry for all root cause nodes. After all modules are filled, defect source domain classification statistics, root cause severity level summaries, and general remediation direction guidelines are uniformly added. After performing report format and integrity checks, a standardized defect location report is generated. This method uses a multi-module parallel template filling logic, resulting in fast report generation, a unified and standardized format, and rapid output of standardized results. It is suitable for scenarios requiring batch report output, such as large-scale batch defect testing and version regression detection.

[0113] Furthermore, an exemplary scheme for cross-domain defect localization in lung nodule detection AI software is presented, using a real-world failure scenario of missed detection of dangerous nodules in CT images as a case study, to fully demonstrate the dual-domain collaborative defect localization process. In this embodiment, dual-domain instrumentation and hook deployment are pre-completed. Acquisition probes are implanted at the entry and exit points of the image normalization module in the code domain, and forward acquisition hooks are registered in the input layer, feature fusion layer, and other network layers in the model domain. Subsequently, baseline benchmark dataset acquisition is performed, calling 100 CT images that have been verified by the gold standard and correctly processed by the software to run and acquire full-link data. The baseline benchmarks are statistically obtained: the average execution time of the image normalization module is 5ms, and the average output activation value of the 15th layer feature fusion layer of the model is 0.5. When a missed detection defect localization requirement is triggered, the missed CT image is input to perform a defect trigger test, simultaneously acquiring real-time running data from both the code domain and the model domain to generate a defect execution dataset. Subsequently, dual-domain collaborative anomaly analysis is initiated. Through module-by-module comparison in the code domain dimension, it is found that the execution time of the image normalization module surges to 50ms, and the output data hash value does not appear in the baseline database; therefore, it is included in the candidate code defect location set. Through layer-by-layer comparison of the model domain dimensions, it was found that the activation tensor of the first input layer of the model had a similarity of only 0.6 with the baseline cosine. The anomaly propagation heatmap showed that this layer was the earliest anomaly initiation layer with significant anomalies, and it was included in the candidate model defect location set. Querying the code and model data flow dependency graph in the cross-domain collaborative association dimension confirmed the existence of a direct directed data transfer edge between the image normalization module and the model input layer, hitting the high-confidence collaborative defect judgment rule. Finally, the root cause confidence calculation and report generation were performed. The anomaly significance of the image normalization module reached 9 standard deviations and hit the cross-domain association rule, with a comprehensive confidence score of 98. The model input layer is located at the source of the anomaly propagation link, with a comprehensive confidence score of 95. The output defect location report determined this to be a high-confidence cross-domain collaborative defect, with the root cause being erroneous data output by the image normalization module, leading to the model receiving out-of-distribution input and ultimately causing missed nodule detection. The report also provided suggestions for focusing on the normalization algorithm logic for repair.

[0114] An exemplary scheme for locating multi-link transmission defects in early gastric cancer identification software is presented, using a real-world failure scenario of missed diagnosis of early gastric cancer lesions in gastroscopy images as a case study to demonstrate the complete localization process of multi-node cross-domain transmission defects. In this embodiment, the code domain of the tested AI-assisted early gastric cancer diagnosis software includes a gastroscopy image decoding module, an illumination correction module, a size normalization module, and a post-processing module. The model domain is a ResNet-50 classification network, with pre-complete instrumentation of all modules and deployment of hooks across all network layers. Subsequently, a baseline benchmark dataset is collected, calling 300 cases of gastroscopy images that have been confirmed by experts and whose software output is correct to run and collect data. The baseline benchmarks are statistically obtained: the average brightness of the output image from the illumination correction module is 120±15, the execution time is 5±1ms, and the mean L2 norm of the activation tensor in the third layer of the model is 45.2±3.1. When the requirement for locating early cancer missed diagnosis defects is triggered, an image of a gastric antral depression lesion with a positive gold standard is input to perform a defect trigger test. The software ultimately outputs a non-cancerous determination, constituting a failure, and simultaneously collects full-link data to generate a defect execution dataset. Subsequently, a dual-domain collaborative anomaly analysis was conducted. Module-by-module comparison at the code domain level revealed that the gastroscopy image decoding module's operating parameters were consistent with the baseline and normal. However, the illumination correction module's execution time reached 35ms, and its average output brightness was as low as 78, exceeding three standard deviations. This module was included in the candidate code defect location set. The size normalization module's anomaly was attributed to upstream propagation and was not included in the root cause candidate. Layer-by-layer comparison at the model domain level revealed that the first convolutional layer's activation state was normal, the second layer's similarity slightly decreased, and the third layer's cosine similarity dropped to 0.55 with a KL divergence of 1.2, indicating it was the anomaly initiation layer. Combined with backpropagation chain analysis of the integral gradient's contribution, the second and third layers were jointly included in the candidate model defect location set. Cross-domain collaborative association analysis traversed the data flow dependency graph, identifying a complete directed propagation path from the illumination correction module to the size normalization module, the model input layer, the second layer, and the third layer. This matched the high-confidence collaborative defect judgment rule, determining the defect to be a cross-domain propagation type defect caused by code preprocessing anomalies leading to deep feature collapse of the model. Finally, the confidence scores were calculated and the report was output. The overall confidence score of the illumination correction module was 98 points, and the overall confidence score of the third layer of the model was 94 points. The report also provided suggestions for optimizing the adaptive illumination correction algorithm on the code side and supplementing the model with low-light sample data to enhance the domain repair.

[0115] An exemplary scheme for incremental learning of a dual-domain defect knowledge base and closed-loop optimization of software is presented, using the defect repair scenarios of the aforementioned two types of medical AI software as a carrier to demonstrate the complete closed-loop process of knowledge base iteration and software optimization. In this embodiment, for the missed detection defect of the lung nodule detection software, after manual review and confirmation that the root cause is the incorrect processing of CT window width and window level by the image normalization algorithm, the system extracts the feature footprint of "abnormal output hash value of normalization module under specific input and sharp increase in execution time" from the corresponding defect execution dataset. This feature footprint is matched with the similarity of the existing signature execution features in the dual-domain defect feature knowledge base. After determining that it is a new defect pattern that has not been included, a unique exclusive feature signature is generated for it, and the corresponding repair scheme of window width and window level logic correction is associated with it and added to the code domain defect signature library. To address the missed diagnosis defect in early gastric cancer identification software, manual review confirmed that the root cause was the failure of the histogram equalization algorithm under low light conditions, leading to lesion contrast reversal. The system extracted a dual-domain combined feature footprint characterized by "average input brightness of the illumination correction module below 80, decreased output contrast, and KL divergence of the third layer of the downstream model greater than 1.0." After matching this with the signature in the knowledge base, it was identified as a new defect pattern. A unique feature signature was generated and associated with an adaptive illumination correction solution, which was then added to the code domain defect signature library. Simultaneously, based on historical matching frequencies, the matching weight of high-frequency defect signatures in the knowledge base was increased, resulting in an updated dual-domain defect feature knowledge base. After the knowledge base update, the defect location judgment rules and matching priorities were optimized based on the newly added defect pattern. Furthermore, the confirmed repair solution guided the corresponding software's code logic correction and model training optimization, ultimately resulting in an iteratively optimized medical AI software. This forms a complete closed loop of "defect location, manual review, knowledge base upgrade, and software optimization," continuously improving the software's operational stability and the accuracy of defect location.

[0116] Seventh Embodiment This embodiment provides an exemplary scheme for constructing a dual-domain defect feature knowledge base. In this example, a dual-domain acquisition probe is first deployed and all gold-labeled correct test cases are run to collect code execution data and network layer activation data from each node. This data is then organized to obtain a dual-domain healthy operation raw dataset. Statistical analysis is performed on the raw dataset to calculate the normal distribution range and dynamic judgment threshold of each node's operation indicators, generating a node-level healthy baseline beacon set. Subsequently, based on this baseline beacon set, quantifiable feature footprints of typical logical faults in the code domain and typical inference anomalies in the model domain are extracted, respectively. Correspondingly, a code domain defect signature library and a model domain defect signature library are constructed. Finally, the node-level healthy baseline beacon set and the dual-domain defect signature library are associated and encapsulated to obtain the dual-domain defect feature knowledge base. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the seventh embodiment of the control method for locating defects in medical software according to this application. Before step S10, steps F11-F15 are also included: Step F11: After deploying the dual-domain acquisition probe, run all gold-labeled correct test cases and collect the code execution data and network layer activation data of each node to obtain the original dataset of dual-domain healthy operation.

[0117] Step F12: Perform statistical analysis on the original dataset of dual-domain health operation, calculate the normal distribution range and dynamic judgment threshold of each node's operation indicators, and generate a set of node-level health baseline indicators.

[0118] Step F13: Using the node-level health baseline beacon set as a benchmark, extract quantifiable feature footprints of typical logical faults in the code domain and construct a code domain defect signature library.

[0119] Step F14: Using the set of node-level healthy baseline landmarks as a benchmark, extract quantifiable feature footprints of typical inference anomalies in the model domain and construct a model domain defect signature library.

[0120] Step F15: Associate and encapsulate the node-level health baseline beacon set, the code domain defect signature library, and the model domain defect signature library to obtain a dual-domain defect feature knowledge base.

[0121] Gold-labeled correct test cases refer to the set of test samples whose output results are completely consistent with the gold standard after being verified by professional standards and after the software runs. They serve as the standard input for building a healthy operating baseline. Examples include pathologically confirmed CT images of lung nodules, positive and negative endoscopic images confirmed by endoscopists, and accurately labeled medical image quality control samples. Dual-domain acquisition probes are a collective term for acquisition units deployed in the code domain and model domain respectively to collect operational status characteristics. They include code domain instrumentation probes and model domain forward hooks. The dual-domain healthy operating raw dataset is the set of unprocessed full-node code execution data and network layer activation data collected when the software runs correct test cases. It serves as the raw input for baseline statistical analysis. Examples include the execution time of each code module, input / output hash values, anomaly capture information, memory usage increment, and the mean, variance, sparsity, and tensor input / output shape of each network layer's activation tensor.

[0122] The node-level health baseline benchmark set is a set of distribution intervals and judgment thresholds for the normal operation indicators of each collected node, obtained through statistical analysis. It serves as the gold standard for determining whether a node's operating status is abnormal. Examples include the mean and three-standard-deviation interval of code module execution time, the normal value set of output hash values, the confidence interval of network layer activation values, and similarity judgment thresholds. Feature footprints are quantifiable feature combinations that uniquely identify a certain type of defect. They are a core component of defect signatures and are used to quickly match and identify defect types. Examples include feature combinations of code domain execution timeouts without exception throwing, feature patterns of continuously increasing memory usage without decline, and feature patterns of shallow activation values ​​in the model domain approaching zero and output probabilities consistently biased towards a single class.

[0123] The code domain defect signature library is a structured database storing the characteristic footprints, triggering conditions, and corresponding repair solutions for various code logic defects, covering typical code defect types such as execution timeouts, exception throwing, memory leaks, and data flow anomalies. The model domain defect signature library is a structured database storing the characteristic footprints, triggering conditions, and corresponding optimization solutions for various neural network inference defects, covering typical model defect types such as gradient vanishing, activation drift, output bias, and logic short circuits. The dual-domain defect feature knowledge base is a structured prior knowledge base for medical software with a hybrid code and model architecture. It comprises three parts: a health benchmark feature set, a code domain defect signature library, and a model domain defect signature library. These respectively store the benchmark parameters and judgment thresholds for normal software operation, quantifiable characteristic footprints and repair solutions for various code defects, and quantifiable characteristic footprints and optimization solutions for various model defects. It serves as the core reference for conducting anomaly feature comparison, defect type identification, and root cause localization, and supports incremental iterative updates to continuously improve the accuracy and coverage of defect localization.

[0124] In this example, when deploying probes and collecting the raw dataset for dual-domain health operation, the method of collecting data at fixed points across the entire domain can be used. After completing the instrumentation of all code modules and the deployment of network layer hooks, all gold-labeled correct test cases are run one by one, and the dual-domain runtime data of the full node corresponding to each test case is collected synchronously. The raw dataset for dual-domain health operation is obtained by summarizing the data for each test case. Alternatively, a parallel batch collection method can be used to split all gold-labeled correct test cases into two groups: one group for code domain data collection and the other group for model domain data collection. Batch test case execution and data collection are started simultaneously in both domains. After the dual-domain collection is completed, the data is matched and integrated according to the time sequence and test case identifier to obtain the raw dataset for dual-domain health operation, thus completing the collection of raw health operation data.

[0125] After collecting the original dataset for dual-domain healthy operation, a baseline statistical analysis process was initiated. Mathematical statistics were performed on the operational indicators of each node in the original dataset, calculating the normal distribution range and dynamic anomaly detection threshold for each indicator corresponding to each code module and each network layer, and generating a node-level health baseline graph set. Subsequently, using this baseline graph set as a reference, and combining historical defect cases and failure modes, quantifiable feature footprints corresponding to various typical logical failures in the code domain were extracted, constructing a structured code domain defect signature library. Simultaneously, using the baseline graph set as a benchmark, quantifiable feature footprints corresponding to various typical inference anomalies in the model domain were extracted, constructing a structured model domain defect signature library. Finally, the node-level health baseline graph set, the code domain defect signature library, and the model domain defect signature library were associated and bound according to node identifiers, and after unified encapsulation, a complete dual-domain defect feature knowledge base was obtained. Through layered processing of baseline construction, signature extraction, and integrated encapsulation, the standardization and data relevance of the knowledge base are ensured, providing a unified reference standard for subsequent defect localization.

[0126] For example, there are two ways to construct a dual-domain defect feature knowledge base using the original dataset. The first is a sequential, layered construction method, starting with the first correctly labeled test case. Each test case is run sequentially, and dual-domain data is collected. After each test case is completed, the statistical intermediate values ​​of each node are updated synchronously. Once all test cases have been run and collected, the normal distribution range and judgment threshold of each node are calculated, generating a set of node-level health baseline markers. Then, based on the completed baseline markers, code domain defect feature footprint extraction and signature library construction are performed sequentially, followed by model domain defect feature footprint extraction and signature library construction. After the signature libraries for both domains are completed, the three parts are associated and encapsulated to finally obtain the dual-domain defect feature knowledge base. This method uses a sequential, case-by-case statistical and layered construction logic. The processing is sequential, intermediate results are traceable, and statistical accuracy and data consistency are high. It is suitable for knowledge base construction scenarios with small test case sizes and the need for fine-grained control of baseline quality.

[0127] The second approach is domain-specific parallel batch construction. First, all correctly labeled test cases are divided into multiple batches according to a unified rule. Simultaneously, the baseline statistics task is split into two independent tasks: code domain baseline statistics and model domain baseline statistics. Both domains simultaneously initiate multiple batches of parallel data collection and statistical calculations, batch-completing the distribution range and judgment threshold calculations for all nodes, and synchronously generating a set of node-level health baseline markers. After the baseline marker set is generated, the defect feature footprint extraction and signature library construction tasks for both the code and model domains are started simultaneously. The signature library construction is completed in parallel across both domains. Finally, the association and encapsulation of the three parts are executed uniformly to obtain a dual-domain defect feature knowledge base. This method combines domain-specific parallelism with batch processing, significantly reducing the total time spent on knowledge base construction through parallel computing. The batch statistics mode can fully utilize computing resources and is suitable for large-scale medical software knowledge base construction scenarios with large test case sizes and numerous nodes.

[0128] Furthermore, the medical software defect localization process proceeds in seven steps. First, the dual-domain instrumentation and hook deployment steps are performed. Static and dynamic probes are implanted into the target under test before the software runs. Among them, code domain instrumentation targets traditional code written in C++ and Python. It is based on functional modules such as image preprocessing module, medical digital imaging and communication (DICOM) parsing module, post-processing logic module, and interface interaction module. Probe code is implanted at the entry and exit functions of each module to automatically collect input data hash value, output data hash value, module execution time in milliseconds, captured exception type and stack information, and memory increment before and after module execution. Dynamic tracing can be achieved through Python's sys.setprofile function. Model domain hook deployment targets neural network models loaded by deep learning frameworks such as TensorFlow (TF) and PyTorch (PT). After the forward propagation of each layer, including convolutional layers, fully connected layers, activation layers, and normalization layers, forward hook functions are registered to capture the layer output activation tensor, layer name, tensor input shape, and output shape after downsampling or extraction of statistical features. In PyTorch, hooks can be registered for all target layers using the `torch.nn.Module.register_forward_hook` method. The next step involves constructing a dual-domain defect feature knowledge base. An offline structured prior knowledge base is built. The code domain defect signature library uses a data structure containing defect ID, defect type, feature footprint, and triggering conditions. The feature footprint is a set of feature vectors associated with the data change patterns of instrumentation points, covering feature patterns corresponding to typical defects such as null pointer exceptions, infinite loop timeouts, and memory leaks. The model domain defect signature library uses the same data structure format. The feature footprint is a set of statistical patterns of model layer hook data, covering feature patterns corresponding to typical model defects such as hyperplane deviation, gradient vanishing, overfitting slicing, and logic short circuits. Next, the baseline vector dataset is collected. A set of test cases containing gold standard annotations and known to be correctly executed by the software is input. The software is run and all probes are activated. The collected data is aggregated and statistically analyzed. The code domain calculates the mean and standard deviation of execution time for each module, records the hash values ​​of the most frequently occurring input and output data, and records typical anomaly patterns. The model domain calculates the distribution confidence interval for the activation tensor statistical features of each layer. The above baseline data is stored as a baseline vector dataset, serving as the gold standard for subsequent comparisons. Then, the defect trigger test steps are executed. One or more failure test cases that fail verification and whose final software output does not conform to the gold standard are input. The same running and collection methods as baseline collection are used to generate the defect execution dataset.Next, a dual-domain collaborative anomaly analysis step is performed, conducting collaborative analysis across three dimensions. Dimension 1 is code domain anomaly localization, where code instrumentation data in the defect execution dataset is compared module-by-module with the baseline benchmark dataset. Execution times deviating from three standard deviations are marked as temporal anomalies, anomaly capture fields that are not empty are marked as anomaly throws, and input / output hash values ​​that have never appeared in the baseline are marked as data flow anomalies, ultimately generating a candidate set of code defect locations. Dimension 2 is model domain anomaly localization, where model layer hook data in the defect execution dataset is compared layer-by-layer with the baseline. The KL divergence and cosine similarity between the activation tensor of each layer and the baseline are calculated to generate an anomaly propagation heatmap. KL divergence greater than 0.5 or cosine similarity less than 0.85 are considered significant anomalies. The layer with the darkest color and earliest appearance is selected as the anomaly initiation layer. Then, the contribution of output layer errors to each layer's neurons is calculated using integral gradient and layer correlation propagation algorithms. The top few layers with the largest contributions are added to the candidate model defect location set, ultimately generating the candidate model defect location set and the anomaly initiation layer. Dimension three focuses on cross-domain collaborative association. A data dependency graph between code modules and model layers is constructed, with code modules and model layers as nodes and data input / output transmission relationships as directed edges. A collaborative inference engine executes three judgment criteria: if a direct directed path exists between a candidate code defect and a candidate model defect, it is judged as a high-confidence cross-domain collaborative defect; if only one domain has an anomaly and the corresponding link nodes in the other domain are normal, it is judged as a defect in the corresponding independent domain; if neither domain has anomalies but the final result is incorrect, a deep backtracking investigation of special cross-domain defects involving serialization and type conversion is triggered. The final output includes the candidate defect location and cross-domain association strength identifier, merging to obtain an integrated result containing the dual-domain candidate set, cross-domain matching relationship, and anomaly propagation depth. Next, the defect root cause confidence calculation and report generation steps are performed. Based on three evaluation dimensions—anomaly significance, anomaly propagation depth, and cross-domain collaborative matching strength—and their corresponding preset weights, a comprehensive confidence score is calculated for each candidate defect location, generating a structured defect location report including defect location, source domain affiliation, a comprehensive confidence score from zero to 100, key evidence fragments, and a suggested responsible party for remediation. Finally, the system performs incremental learning and closed-loop optimization steps for the knowledge base. After each defect location and manual confirmation and repair, the system extracts feature footprints from the defect execution dataset of this defect and performs similarity matching with existing signatures in the dual-domain defect feature knowledge base. If the similarity is lower than the set threshold, it is determined to be a new defect pattern. After confirmation by the test engineer, a unique signature is generated for this pattern and added to the knowledge base along with the defect type and repair plan. At the same time, the system automatically increases the weight of frequently matched signatures in the knowledge base, giving them higher priority in subsequent location analysis, thereby achieving continuous iterative optimization of defect location capabilities.

[0129] Eighth embodiment This embodiment provides an exemplary scheme for closed-loop iterative optimization of defect localization in medical software. In this example, the root cause and repair conclusion of the defect are first determined by manually reviewing the defect localization report. Defect pattern samples are then generated by associating them with corresponding dual-domain feature footprints. Next, the samples are matched with existing signatures in the dual-domain defect feature knowledge base based on feature similarity to filter out target defect patterns that are not yet included. Subsequently, a unique feature signature is set for the target defect pattern and associated with a corresponding repair plan. The weights of existing signatures in the knowledge base are adjusted synchronously to obtain an updated dual-domain defect feature knowledge base. Finally, the defect localization judgment rules are optimized based on the updated knowledge base, which in turn guides the code repair and model tuning of the medical software, resulting in an iteratively optimized medical software. Please refer to... Figure 7 , Figure 7 This is a flowchart illustrating the eighth embodiment of the control method for locating defects in medical software according to this application. Following step S40, steps G11-G14 are also included: Step G11: By manually reviewing the defect location report, determine the root cause of the defect and the repair conclusion, and associate the corresponding dual-domain feature footprints in the defect location report to generate a defect pattern sample.

[0130] Step G12: Perform feature similarity matching between the defect pattern sample and the existing signatures in the dual-domain defect feature knowledge base to filter out target defect patterns that have not been included.

[0131] Step G13: Set the exclusive feature signature of the target defect pattern, associate the repair scheme corresponding to the target defect pattern, and adjust the weight of the signature in the dual-domain defect feature knowledge base to obtain the updated dual-domain defect feature knowledge base.

[0132] Step G14: Based on the updated dual-domain defect feature knowledge base, optimize the defect location and judgment rules, and use them to guide the code repair and model tuning of the medical software, thereby obtaining the iteratively optimized medical software.

[0133] Defect pattern samples are standardized defect sample units formed by associating corresponding dual-domain abnormal feature footprints after the root cause and repair plan of defects have been manually verified and confirmed. They are the core input for incremental updates of the knowledge base. Dual-domain feature footprints are combinations of code domain execution features and model domain activation features that uniquely identify a certain type of defect. Examples include feature combinations such as code module execution timeouts accompanied by model input distribution shifts, null pointer anomalies accompanied by subsequent network layer activation values ​​returning to zero, and data type conversion anomalies accompanied by abnormal model output probabilities. Feature similarity matching is the process of calculating the degree of feature matching between the defect pattern to be matched and existing defect signatures; a higher similarity value indicates a higher degree of overlap in the defect patterns. Target defect patterns are new defect feature patterns that have not been included in the knowledge base, confirmed through similarity matching, and are the core objects for incremental knowledge base supplementation. Specific feature signatures are standardized feature vectors with unique identifiers generated for new defect patterns, used for rapid matching and identification in subsequent defect localization processes. The iteratively optimized medical software is a software version that has improved operational stability and defect localization capabilities after defect repair, algorithm tuning, and localization rule upgrades.

[0134] In this example, when extracting feature footprints to generate defect pattern samples, the method of structured extraction from reports can be referenced. The corresponding code domain instrumentation features and model domain activation features are extracted from the evidence fragment module of the defect location report, combined to form a dual-domain feature footprint. This footprint is then combined with the manually verified root cause and remediation conclusions to generate standardized defect pattern samples. Alternatively, a multi-report aggregation extraction method can be used to summarize multiple location reports of the same type of defect, extract common feature footprints from multiple samples, and integrate unified root cause conclusions and remediation solutions to generate defect pattern samples with generalizable representativeness, thus completing the construction of the defect pattern samples.

[0135] After constructing the defect pattern samples, a knowledge base similarity matching process is initiated. The defect pattern samples are compared one by one with all existing defect signatures in the dual-domain defect feature knowledge base to calculate feature similarity. Defect patterns with similarity below a preset inclusion threshold and not yet included in the knowledge base are selected and marked as target defect patterns. Subsequently, a unique feature signature is assigned to each target defect pattern, associated with the corresponding defect type, triggering conditions, and repair plan. Simultaneously, based on the historical matching frequency of existing signatures, the matching weight of each signature in the knowledge base is adjusted, increasing the matching priority of high-frequency defect signatures, resulting in an updated dual-domain defect feature knowledge base. Finally, based on the updated knowledge base, the defect localization judgment rules and matching logic are optimized in reverse. Furthermore, the repair conclusions guide the correction of the medical software's code logic and the tuning of neural network model parameters, completing the defect repair and localization capability upgrade, resulting in an iteratively optimized medical software. Through this closed-loop mechanism of incremental learning of the knowledge base and software quality upgrades, the accuracy of defect localization and the stability of software operation are continuously improved.

[0136] For example, there are two ways to implement knowledge base updates and software iterations using defect pattern samples. The first is a serial, sample-by-sample incremental update. Following the order of completion of defect location report reviews, defect pattern samples are extracted one by one and matched sequentially with existing signatures in the knowledge base. After each sample is matched, if it is determined to be an unrecorded target defect pattern, a unique feature signature is immediately generated and associated with a repair solution, and the signature weight of the corresponding domain is adjusted synchronously. After the knowledge base update for a single sample is completed, the location judgment rules for the corresponding defect type are updated synchronously to guide code repair or model optimization of the corresponding module, completing the closed-loop iteration step by step. This method uses a single-sample serial processing and real-time update logic. The update chain for each defect is independent and complete, enabling rapid implementation of single-defect repair and knowledge base iteration, adapting to scenarios involving scattered defect repairs and closed-loop optimization of single-case online issues.

[0137] The second method is batch clustering-based parallel update. First, all defect pattern samples within the same iteration cycle are collected. These samples are then clustered according to defect type and feature behavior, forming multiple clusters of similar defect samples. Next, parallel knowledge base similarity matching is initiated simultaneously for each sample cluster. Unrecorded target defect patterns in each group are batch-filtered, and corresponding category-specific feature signatures are uniformly generated and associated with integrated repair solutions. These are then batch-added to the database, and the signature weights of the entire database are adjusted to obtain an updated dual-domain defect feature knowledge base. Subsequently, defect location and judgment rules are batch-optimized based on the full update content, comprehensively guiding full code repair and model tuning, ultimately outputting the iteratively optimized medical software. This method employs batch clustering and parallel update logic. Pre-clustering reduces the computational load of repeated matching, and batch processing significantly improves the efficiency of multi-defect parallel iteration, making it suitable for optimization scenarios such as batch defect repair and full knowledge base upgrades after version iterations.

[0138] Furthermore, an exemplary implementation of a code- and model-based dual-domain collaborative defect localization method for medical AI-assisted diagnostic software can be applied to defect investigation scenarios for various hybrid architecture medical AI software, such as lung nodule CT detection and early gastroscopy cancer identification. In this example, the overall process proceeds in the following order: "dual-track probe deployment, baseline marker construction, defect triggering and collection, dual-domain collaborative analysis, confidence report output, and knowledge base incremental optimization": First, code-domain instrumentation and model-domain forward hooks are deployed in the software under test to build synchronous dual-track data collection capabilities. Then, healthy operation data is collected through correct test cases to generate a baseline marker dataset with dynamic judgment thresholds. Subsequently, defects are triggered through failed test cases, and abnormal data across the entire chain is collected. Next, joint analysis is conducted from three dimensions: code-domain anomaly localization, model-domain anomaly localization, and cross-domain collaborative association to identify candidate defect locations. Then, the comprehensive confidence of each defect is obtained through multi-dimensional weighted calculation, and a structured localization report is output. Finally, the defect knowledge base is updated through an incremental learning mechanism to achieve continuous iterative optimization of the localization capability.

[0139] Specifically, a dual-track data acquisition mechanism is established to complete dual-track instrumentation and hook deployment in both the code domain and the model domain. For medical AI-assisted diagnostic software composed of traditional business code and deep learning models, instrumentation points are deployed at the entry and exit functions of each functional module (including image decoding, preprocessing, post-processing logic, and interaction modules) written in C++ and Python within the code domain. Five types of runtime characteristics are collected: module execution time, input data hash value, output data hash value, exception capture information, and memory usage increment. Python code can achieve dynamic instrumentation tracking through the `sys.setprofile` function, while C++ code can achieve data acquisition through compile-time static instrumentation. In the model domain, for neural network models loaded by deep learning frameworks, forward hooks are registered after the forward propagation of each layer, including convolutional layers, fully connected layers, activation layers, and normalization layers. These hooks capture downsampled statistical features of the output activation tensors of that layer, specifically including mean, variance, maximum, minimum, and sparsity. Simultaneously, the input and output shapes of the tensors are recorded. Hook registration can be achieved using PyTorch's `register_forward_hook` method or TensorFlow's callback mechanism. This dual-track acquisition mechanism enables synchronized, fine-grained data acquisition from two heterogeneous subsystems—code and model—within a unified testing framework, providing a time-aligned, standardized data source for subsequent cross-domain collaborative analysis.

[0140] A baseline graph dataset is constructed, and a dynamic threshold is used to establish an anomaly detection benchmark. All test cases annotated with the gold standard and whose output results are completely correct after software execution are called. Through the aforementioned dual-track collection mechanism, test cases are run one by one, and full-node health operation data is collected. The collected full data is aggregated and statistically analyzed: for each module in the code domain, the mean and standard deviation of execution time are calculated, the most frequently occurring input / output hash value set is statistically analyzed, and typical anomaly patterns are recorded. For each layer in the model domain, the distribution range and confidence interval of the activation tensor statistical features are calculated. Finally, the mean ± 3 times the standard deviation is used as the dynamic anomaly detection threshold for each node, replacing the fixed threshold scheme. This adapts to the differences in normal operation fluctuations of different code modules and different network layers, avoiding false positives and false negatives caused by fixed thresholds. A node-level baseline graph dataset is generated as the gold standard for subsequent anomaly comparison.

[0141] Execute defect-triggered tests and collect defect execution datasets. Input one or more failure test cases that fail verification and whose final software output does not conform to the gold standard. Using the same running logic and collection rules as the baseline collection, synchronously collect real-time running data from the entire code domain and the entire model domain to generate a defect execution dataset, which is then sent to the subsequent dual-domain anomaly detection engine for analysis.

[0142] A dual-domain anomaly detection engine is launched, conducting collaborative analysis across three dimensions. Dimension 1 is code domain anomaly localization: code instrumentation data in the defect execution dataset is compared module-by-module with the baseline baseline dataset. If a module's execution time exceeds a dynamic threshold, it is marked as a temporal anomaly; if the anomaly capture field is not empty, it is marked as an anomaly throw; if the input / output hash value does not appear in the baseline set, it is marked as a data flow anomaly. Modules meeting any of these anomaly conditions are included in the candidate code defect location set. Dimension 2 is model domain anomaly localization: model layer hook data in the defect execution dataset is compared layer-by-layer with the baseline. The KL divergence and cosine similarity metrics between each layer's activation tensor and the baseline are calculated. An anomaly propagation heatmap is generated based on these metrics, and the layer with the highest heatmap value and earliest appearance in the data flow direction is identified as the anomaly initiation layer. Simultaneously, an integral gradient or layer correlation propagation algorithm is used to construct a backpropagation chain of contribution from the output layer to each intermediate layer. The contribution of the output error result to each layer's neurons is calculated, and the layers with the highest contribution are selected and included in the candidate model defect location set. Finally, the candidate model defect set and anomaly initiation layer identifiers are output. Dimension 3 focuses on cross-domain collaborative relationships: a pre-constructed dependency graph of code and model data is built. This graph uses code modules and neural network layers as nodes, and directed edges representing the input-output dependencies of data. Specifically, the output of the starting node of a directed edge directly serves as the input of the ending node. This includes two types of dependencies: code module output as model layer input and model layer output consumed by subsequent code modules. Combining the candidate sets output from the first two dimensions, the graph is traversed to find directed paths from candidate code defect locations to candidate model defect locations. If a complete connected directed path exists, it is identified as a high-confidence cross-domain collaborative defect, indicating that the defect was caused by abnormal propagation from the code domain to the model domain or vice versa. If there is no connected path between the two candidate sets, the candidate results for each domain are independently verified to distinguish between pure code domain defects and pure model domain defects. If both candidate sets are empty but the final software output is incorrect, a deep backtracking mechanism is triggered to investigate hidden cross-domain interface faults such as serialization errors, deserialization anomalies, and data type conversion deviations during cross-domain data transmission. This dimension integrates dual-domain analysis results from a data flow perspective, enabling the identification of hidden cross-domain defects that traditional single-domain testing tools cannot detect, such as model input distribution shifts caused by preprocessing anomalies.

[0143] A multi-dimensional confidence score is performed, and a structured defect location report is output. For all located candidate defect locations, a comprehensive confidence score for each candidate defect is obtained by weighting and summing three indicators: anomaly significance score, anomaly propagation depth score, and cross-domain collaborative matching strength score, using preset weighting coefficients. The anomaly significance score is calculated as the standard deviation of the indicator from the baseline in the code domain and as 1 minus cosine similarity in the model domain. The anomaly propagation depth score is determined based on the upstream and downstream positions of the candidate defect in the anomaly propagation chain; nodes closer to the anomaly source score higher. The cross-domain collaborative matching strength score is full when the defect matches a cross-domain collaborative rule; it is 0 for a single-domain independent defect. After scoring is completed, all candidate defects are sorted from high to low based on their overall confidence level, generating a structured defect location report. The report clearly marks the specific location, source domain, and overall confidence level of each defect on a 0-100 scale, and includes key evidence fragments, such as instrumentation data comparison results, model-level anomaly heatmaps, and data dependency path diagrams. It also provides suggestions on remediation directions and responsible roles for the corresponding defect types, enabling testing and development personnel to directly obtain actionable location results and reducing the time cost of manual investigation.

[0144] Closed-loop optimization is achieved through an incremental learning mechanism using a dual-domain defect feature knowledge base. A structured dual-domain defect feature knowledge base is pre-built, comprising a code-domain defect signature library and a model-domain defect signature library. The code-domain defect signature library includes quantifiable feature footprints, triggering conditions, and corresponding remediation schemes for typical code logic faults such as null pointer exceptions, infinite loop timeouts, memory leaks, and data flow anomalies. The model-domain defect signature library includes quantifiable feature footprints, triggering conditions, and corresponding tuning schemes for typical model inference anomalies such as hyperplane deviation, gradient vanishing, overfitting slicing, and logic short circuits. After each defect localization and manual verification of the root cause and remediation scheme, the system extracts the corresponding dual-domain feature footprints from the current defect execution dataset and matches them with the similarity of existing defect signature execution features in the knowledge base. If the similarity is lower than a preset threshold, it is identified as a novel defect pattern not yet included in the knowledge base. After confirmation, a standardized, unique defect signature is generated for it, and added to the knowledge base along with the defect type and remediation scheme. Simultaneously, the system dynamically adjusts the matching weight of each defect signature based on its historical matching frequency, prioritizing high-frequency defects. Through this incremental learning mechanism, the system can continuously adapt to new defect patterns. As the number of uses increases, the accuracy and recall rate of defect localization continue to improve, forming a complete closed loop of "defect localization, manual verification, knowledge base update, and capability optimization".

[0145] This application provides a control device for locating defects in medical software. The control device for locating defects in medical software includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the control method for locating defects in medical software as described in Embodiment 1 above.

[0146] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a control device suitable for implementing medical software defect localization in the embodiments of this application. Figure 8 The control device for locating medical software defects shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0147] like Figure 8 As shown, the control device for locating medical software defects may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the control device for locating medical software defects. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the control device for medical software defect localization to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a control device for medical software defect localization with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0148] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0149] The control device for locating medical software defects provided in this application employs the control method for locating medical software defects in the above embodiments, which can solve the technical problem of low efficiency in software defect location. Compared with the prior art, the beneficial effects of the control device for locating medical software defects provided in this application are the same as those of the control method for locating medical software defects provided in the above embodiments, and other technical features of the control device for locating medical software defects are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0150] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0151] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0152] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the control method for locating medical software defects in the above embodiments.

[0153] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0154] The aforementioned computer-readable storage medium may be included in the control device for locating medical software defects; or it may exist independently and not be assembled into the control device for locating medical software defects.

[0155] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a control device for medical software defect localization, the control device performs the following actions: It determines a defective runtime dataset, including code execution features and neural network activation features, during software operation by running failure test cases; it compares the defective runtime dataset with a health benchmark feature set node by node to identify abnormal modules in the code domain and abnormal layers in the model domain, and associates them to obtain a candidate defect node set; based on the data flow dependency graph between code modules and neural network layers, it performs cross-domain association reasoning on the candidate defect node set to obtain a defect root cause localization conclusion; and based on the defect root cause localization conclusion and the confidence evaluation dimension weights, it calculates and ranks the comprehensive confidence score of each root cause node to obtain a defect localization report.

[0156] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0158] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0159] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the control method for locating medical software defects described above, thereby solving the technical problem of low efficiency in software defect location. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method for locating medical software defects provided in the above embodiments, and will not be repeated here.

[0160] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A control method for locating defects in medical software, characterized in that, The method includes: By running failure test cases, a defective runtime dataset, including code execution characteristics and neural network activation characteristics, is determined during software operation. This includes: loading the failure test cases into the medical auxiliary diagnostic software under test, activating instrumentation probes at the code module entry and exit points and feature capture hooks at each layer of the neural network, and constructing a dual-domain acquisition link; obtaining the runtime characteristic data of each code module and the activation tensor statistical characteristics of each layer of the neural network through the dual-domain acquisition link, and organizing them according to time sequence to obtain the original dual-domain runtime dataset; performing node-by-node time sequence alignment and matching on the original dual-domain runtime dataset based on a time sequence benchmark, removing invalid and redundant data to obtain valid dual-domain runtime data; encapsulating the valid dual-domain runtime data according to time sequence and domain category, and associating it with the corresponding identification information of the failure test cases to obtain the defective runtime dataset. The defect execution dataset is compared node-by-node with the health benchmark feature set to identify abnormal modules in the code domain and abnormal layers in the model domain, and a candidate defect node set is obtained. This includes: using the associated identification information within the defect execution dataset as a retrieval index, matching the benchmark feature intervals and anomaly judgment thresholds of corresponding nodes from the health benchmark feature set of the dual-domain defect feature knowledge base to construct a comparison benchmark set; based on the comparison benchmark set, calculating the deviation magnitude of the code module execution features from the corresponding benchmark and the similarity between the neural network layer activation features and the corresponding benchmark, and organizing the node anomaly deviation quantification results; according to the anomaly judgment threshold of each node, the node anomaly deviation quantification results are verified and screened node-by-node to determine abnormal nodes whose deviation magnitude exceeds the deviation threshold or whose similarity is lower than the similarity threshold, including: mapping the node anomaly deviation quantification results to the deviation threshold and similarity threshold corresponding to each node in the anomaly judgment threshold. The process involves binding nodes to obtain a node verification dataset. The nodes in the verification dataset are then evaluated based on the deviation magnitude of their operational features and the similarity of their activation features. Nodes with deviation magnitudes exceeding a deviation threshold or similarity levels below a similarity threshold are identified, resulting in initial anomaly screening nodes. Based on the continuity of feature changes in upstream and downstream adjacent nodes of the initial anomaly screening nodes, pseudo-anomaly nodes caused by instantaneous fluctuations in data collection are removed, resulting in verified initial anomaly screening nodes. These verified nodes are then categorized and grouped according to their code domain and model domain attributes, and their anomaly trigger types and levels are labeled, resulting in the anomaly nodes. Based on the identification information corresponding to the anomaly nodes, code domain anomaly module groups and model domain anomaly hierarchy groups are generated. These groups are then associated and sorted according to the data flow sequence, and the anomaly severity level of each node is labeled, resulting in the candidate defect node set. Based on the data flow dependency graph between the code module and the neural network layer, cross-domain association reasoning is performed on the candidate defect node set to obtain the defect root cause localization conclusion. This includes: mapping the candidate defect node set to the data flow dependency graph between the code module and the neural network layer, locating the topological position of the abnormal node in the global data flow link, and generating a data flow dependency subgraph including anomaly markers; tracing the anomaly propagation path backwards according to the data flow direction of the data flow dependency subgraph, identifying the anomaly initiation node and the progressively propagating nodes, and determining the data causal relationship between the anomaly nodes; matching defect classification judgment rules based on the cross-domain connectivity attributes of the anomaly propagation path and the domain distribution characteristics of the anomaly nodes, and determining the root cause type of the defect corresponding to the anomaly node; determining the core root cause node under the root cause type based on the upstream and downstream positions of the anomaly node in the propagation link, and generating the defect root cause localization conclusion by combining the data causal relationship. Based on the defect root cause localization conclusions and the confidence evaluation dimension weights, the comprehensive confidence score of each root cause node is calculated and sorted to obtain the defect localization report.

2. The control method for locating defects in medical software as described in claim 1, characterized in that, The steps for calculating and ranking the comprehensive confidence score of each root cause node based on the defect root cause localization conclusion and the confidence evaluation dimension weights to obtain the defect localization report include: By mapping and binding the abnormal deviation magnitude, abnormal propagation link level, and cross-domain association matching strength in the defect root cause localization conclusion with the corresponding confidence evaluation dimension weight, a node confidence calculation set is obtained. Based on the node confidence calculation set, the confidence scores of each root cause node are obtained by weighted summation according to the weight coefficients corresponding to the evaluation dimensions. The confidence score results are sorted from high to low and associated with the abnormal feature fragments, data flow propagation paths and domain affiliation information corresponding to the root cause nodes to obtain an ordered list of root cause nodes. The ordered root cause node list is structured and integrated according to a preset report framework, and the defect source domain classification, root cause severity level labeling, and repair direction guidance are added to obtain the defect location report.

3. The control method for locating defects in medical software as described in claim 1, characterized in that, Before the step of determining the defect execution dataset, including code execution characteristics and neural network activation characteristics, during software operation by running failure test cases, the control method for medical software defect localization further includes: After deploying the dual-domain acquisition probe, all gold-labeled correct test cases were run, and code execution data and network layer activation data of each node were collected to obtain the original dataset of dual-domain healthy operation. Statistical analysis is performed on the original dataset of dual-domain health operation to calculate the normal distribution range and dynamic judgment threshold of the operation indicators of each node, and to generate a set of node-level health baseline indicators. Using the node-level health baseline beacon set as a benchmark, quantifiable feature footprints of typical logical faults in the code domain are extracted to construct a code domain defect signature library. Using the node-level health baseline landmark set as a benchmark, quantifiable feature footprints of typical inference anomalies in the model domain are extracted to construct a model domain defect signature library. The node-level health baseline beacon set, the code domain defect signature library, and the model domain defect signature library are associated and encapsulated to obtain a dual-domain defect feature knowledge base.

4. The control method for locating defects in medical software as described in claim 1, characterized in that, After the step of calculating and ranking the comprehensive confidence score of each root cause node based on the defect root cause localization conclusion and the confidence evaluation dimension weights to obtain the defect localization report, the control method for medical software defect localization further includes: By manually reviewing the defect location report, the root cause of the defect and the repair conclusion are determined, and the corresponding dual-domain feature footprints in the defect location report are associated to generate defect pattern samples. The defect pattern samples are matched with the existing signatures in the dual-domain defect feature knowledge base to filter out target defect patterns that have not been included. Set a unique feature signature for the target defect pattern, associate it with the corresponding repair scheme, and adjust the weight of the signature in the dual-domain defect feature knowledge base to obtain the updated dual-domain defect feature knowledge base. Based on the updated dual-domain defect feature knowledge base, the defect location and judgment rules are optimized, which in turn guides the code repair and model tuning of the medical software, resulting in an iteratively optimized medical software.

5. A control device for locating defects in medical software, characterized in that, The control device for locating medical software defects includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for locating medical software defects as described in any one of claims 1 to 4.

6. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the control method for locating medical software defects as described in any one of claims 1 to 4.

Images