A method and apparatus for locating defects in a digital product

Abstract

The application discloses a defect positioning method and device for a digital product. The method comprises the following steps: based on multi-source data of the digital product, an abnormal code feature set is constructed; semantic alignment is performed based on a target natural language and the abnormal code feature set to obtain a defect positioning result; and a corresponding defect analysis report is generated based on the defect positioning result. The method uses the semantic alignment result to realize mapping and alignment of the target natural language and the code feature, provides a favorable reference for detection of a defect code of the digital product, and makes the defect positioning result of the digital product more accurate and reliable.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to a method and apparatus for locating defects in digital products. Background Technology

[0002] Software systems inevitably accumulate numerous defects during long-term operation and maintenance. These defects not only affect software reliability and performance but can also lead to serious economic losses and even endanger personal safety and property. Statistics show that software maintenance and debugging costs account for 50% to 80% of total software development costs, with defect location and repair being the most time-consuming and difficult aspects. Currently, developers primarily rely on manual methods for defect debugging, which is inefficient, error-prone, and unsuitable for the needs of large-scale software systems. Summary of the Invention

[0003] This application provides a method and apparatus for locating defects in digital products, with the aim of locating defects in digital products.

[0004] To achieve the above objectives, this application provides the following technical solution:

[0005] A method for defect localization in digital products includes:

[0006] Based on multi-source data from digital products, construct an anomaly code feature set;

[0007] Defect localization results are obtained by semantically aligning the target natural language with the feature set of the abnormal code; the target natural language includes text used to describe defects in digital products; the defect localization results are used to characterize defect codes that match the defects in digital products.

[0008] Based on the defect location results, a corresponding defect analysis report is generated.

[0009] A defect location device for a digital product, comprising:

[0010] The multi-source data feature module is used to construct anomaly code feature sets based on multi-source data from digital products.

[0011] The intelligent defect localization module performs semantic alignment between the target natural language and the abnormal code feature set to obtain defect localization results. The target natural language includes text used to describe defects in digital products, and the defect localization results are used to characterize defect codes that match the defects in digital products. Based on the defect localization results, a corresponding defect analysis report is generated.

[0012] A storage medium comprising a stored program, wherein the program is executed by a processor to perform the defect location method for the digital product.

[0013] An electronic device includes: a processor, a memory, and a bus; the processor and the memory are connected via the bus.

[0014] The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the defect location method for the digital product.

[0015] The technical solution provided in this application constructs an abnormal code feature set based on multi-source data of digital products; performs semantic alignment between the target natural language and the abnormal code feature set to obtain defect location results; and generates a corresponding defect analysis report based on the defect location results. This method utilizes the semantic alignment results to achieve mapping alignment between the target natural language and code features, providing a valuable reference for detecting defective codes in digital products and making the defect location results of digital products more accurate and reliable. Attached Figure Description

[0016] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a first flowchart illustrating a method for locating defects in a digital product, as provided in an embodiment of this application.

[0018] Figure 2 This is a second flowchart illustrating a method for locating defects in a digital product, as provided in an embodiment of this application.

[0019] Figure 3 A schematic diagram of the third process of a defect location method for a digital product provided in an embodiment of this application;

[0020] Figure 4 A schematic diagram of the fourth process of a defect location method for digital products provided in an embodiment of this application;

[0021] Figure 5 A fifth flowchart illustrating a defect location method for digital products provided in an embodiment of this application;

[0022] Figure 6 A sixth flowchart illustrating a defect location method for digital products provided in an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of the architecture of a defect location device for a digital product provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0026] like Figure 1 The diagram shown is a first flowchart of a defect location method for a digital product provided in an embodiment of this application, including the following steps.

[0027] S101: Construct an anomaly code feature set based on multi-source data from digital products.

[0028] The exception code feature set includes multiple exception code features.

[0029] In some examples, digital products include, but are not limited to, application software, system software, etc.

[0030] Optionally, the implementation process for constructing anomaly code feature sets based on multi-source data from digital products can be found in [reference needed]. Figure 2 The steps are shown.

[0031] S102: Semantic alignment is performed based on the target natural language and the feature set of the abnormal code to obtain the defect localization result.

[0032] The target natural language includes text used to describe defects in digital products; the defect location results are used to characterize defect codes that match the defects in digital products.

[0033] In some examples, the text used to describe defects in digital products includes, but is not limited to, problem descriptions and error messages for historical defect cases.

[0034] It is understandable that the target natural language belongs to natural language, while the exception code of digital products belongs to programming language. By semantically aligning the target natural language with the exception code feature set, a semantic correspondence between the target natural language and the exception code features can be established, providing favorable support for defect localization of digital products.

[0035] Optionally, the implementation process for obtaining defect localization results by semantic alignment based on the target natural language and the feature set of the abnormal code can be found in [reference needed]. Figure 3 The steps are shown.

[0036] S103: Generate a corresponding defect analysis report based on the defect location results.

[0037] The defect analysis report includes a chain of evidence for locating the defect and a visualization report for developers.

[0038] Optionally, after determining the defect location results of the digital product, proactive repair can also be carried out based on these defect location results. The implementation process of this proactive repair can be found in [link to documentation]. Figure 5 The steps are shown.

[0039] Optionally, the target model can be optimized based on the defect location results and human opinions on the target repair patch; the target model includes a large model for semantic alignment of the target natural language and abnormal code feature sets, as well as for generating repair patches.

[0040] The processes shown in S101-S103 above utilize semantic alignment results to achieve mapping alignment between target natural language and code features, providing a useful reference for detecting defective codes in digital products, and making the defect location results of digital products more accurate and reliable.

[0041] like Figure 2 The diagram shown is a second flowchart of a defect location method for digital products provided in an embodiment of this application, which includes the following steps.

[0042] S201: Determine the multi-source data for digital products.

[0043] The multi-source data includes source code in different programming languages, as well as runtime data in different operating environments.

[0044] In some examples, connections can be pre-established with multiple data sources, each using a different programming language and operating environment, to obtain multi-source data on digital products from various data sources.

[0045] S202: Determine the static analysis results based on source code in different programming languages.

[0046] The static analysis results include multiple nodes and the relationships between them. Nodes are used to represent the corresponding code.

[0047] In some examples, the static analysis results include an abstract syntax tree, a control flow graph, and a program dependency graph; the abstract syntax tree includes multiple nodes of the syntactic structure of the digital product, the control flow graph includes the control dependencies between the nodes, and the program dependency graph includes the data dependencies between the nodes.

[0048] In some examples, the types of code include, but are not limited to, interfaces, data structures, functions, variables, lines of code, code segments, tokens, etc.

[0049] In some examples, static analysis results can be obtained by parsing the source code of different programming languages.

[0050] S203: Determine the dynamic analysis results based on operational data under different operating environments.

[0051] The dynamic analysis results include exception codes.

[0052] In some examples, runtime data under different operating environments can be preprocessed, and then dynamic analysis results can be determined based on the preprocessed runtime data.

[0053] S204: Based on the exception code and the relationships between the nodes, identify at least one exception node.

[0054] Specifically, by using abstract syntax trees, control flow graphs, and program dependency graphs, nodes associated with the nodes corresponding to the exception code are identified as exception nodes.

[0055] S205: Structure the exception code corresponding to each exception node to obtain the exception code feature set.

[0056] Among these measures, exception codes are structured, and this structuring method includes, but is not limited to, vectorization.

[0057] In some examples, after obtaining the exception code signature set, the exception code signature set can be saved to a specified database.

[0058] The processes shown in S201-S205 above can utilize multi-source data from digital products to obtain static and dynamic analysis results. Based on these results, an abnormal code feature set can be further obtained, providing effective data support for subsequent defect localization.

[0059] like Figure 3The diagram shown is a third flowchart of a defect location method for digital products provided in an embodiment of this application, which includes the following steps.

[0060] S301: Determine the corresponding semantic vector features based on the target natural language.

[0061] One approach is to perform semantic recognition on the target natural language and then vectorize the results of the semantic recognition to determine the corresponding semantic vector features.

[0062] S302: Calculate the semantic alignment between the semantic vector features and each exception code feature in the exception code feature set.

[0063] The calculation process for the semantic alignment between the semantic vector feature Vt and the abnormal code feature Vc can be found in formula (1):

[0064] (1).

[0065] In formula (1), sim(Vt, Vc) represents the cosine similarity between semantic vector feature Vt and anomalous code feature Vc, A crs (Vt, Vc) represents the cross-attention weights of semantic vector feature Vt and abnormal code feature Vc, D str (c) represents the structural importance of the exception code c corresponding to the exception code feature Vc, and H(c) represents the historical defect density entropy of the exception code c. and These are the preset fusion parameters.

[0066] S303: Filter target exception code features from the exception code feature set based on semantic alignment.

[0067] In this process, the abnormal code features can be sorted in descending order of semantic alignment to obtain an abnormal code feature sequence. The first k abnormal code features in the abnormal code feature sequence are identified as target abnormal code features, where k is a positive integer.

[0068] S304: Determine the defect location result based on the exception code corresponding to the target exception code characteristics.

[0069] Among them, different numbers can be set for the exception codes corresponding to different target exception code characteristics to distinguish them.

[0070] In some examples, the processes shown in S301-S304 can be implemented with the help of a large model. By leveraging the semantic understanding capabilities of the large model, combined with the question type and context shown in the target natural language, appropriate prompts can be generated to guide the large model to identify the semantic mapping relationship between semantic vector features and various abnormal code features, i.e., semantic alignment.

[0071] Optionally, the process of determining the defect localization result based on the exception code corresponding to the target exception code characteristics can be found in [reference needed]. Figure 4 The steps are shown.

[0072] The processes shown in S301-S304 above can filter target abnormal code features from the abnormal code feature set based on the semantic alignment between semantic vector features and each abnormal code feature, so as to determine the defect location.

[0073] like Figure 4 The diagram shown is a fourth flowchart of a defect location method for digital products provided in an embodiment of this application, which includes the following steps.

[0074] S401: If there are multiple target exception code features, calculate the confidence level of each target exception code feature.

[0075] The calculation process for the confidence level of the target abnormal code features can be found in formula (2):

[0076] (2).

[0077] In formula (2), w represents the confidence level of the target anomalous code feature a at the t-th iteration, N(a) represents the set of nodes adjacent to the anomalous node corresponding to the target anomalous code feature a in the program dependency graph, and w aj E represents the evidence propagation weight from anomalous node j to anomalous node a. s (a) represents the static evidence strength of the target anomalous code feature a, E d (a) represents the dynamic evidence strength of the target anomalous code feature a. These are preset static weight parameters. b is the preset dynamic weight parameter. a For the bias term of the target exception code feature a, This represents the sigmoid function.

[0078] In some examples, the strength of static evidence can be determined based on the results of static analysis, while the strength of dynamic evidence can be determined based on the results of dynamic analysis.

[0079] S402: Based on the confidence level, select valid exception code features from the exception code features of each target.

[0080] Among them, the target abnormal code features with the highest confidence level or the target abnormal code features with a confidence level that meets a specified threshold can be identified as valid abnormal code features.

[0081] S403: Determine the defect location result based on the exception code corresponding to the valid exception code characteristics.

[0082] Among them, the exception codes determined based on the confidence level can effectively improve the accuracy of defect location results.

[0083] The processes shown in S401-S403 above can filter valid abnormal code features based on the confidence level of the target abnormal code features, thereby improving the accuracy of defect location results.

[0084] like Figure 5 The diagram shown is a fifth flowchart of a defect location method for digital products provided in an embodiment of this application, which includes the following steps.

[0085] S501: Based on the defect location results, generate multiple repair patches.

[0086] Among them, a pre-trained code generation model can be invoked to generate multiple repair patches by combining the defect location results with the corresponding context.

[0087] S502: Generate test case sets for each patch and execute the test case sets to obtain the corresponding test execution results.

[0088] Among them, preset test case templates can be used to generate test case sets for each patch.

[0089] S503: Based on the test execution results of each patch, select the target patch from the patches.

[0090] Based on the test results of each patch, the repair effect of each patch can be determined, thereby selecting the target patch with the best repair effect.

[0091] It should be noted that the effectiveness of the fix can be determined based on the side effects the fix patch brings to the digital product; the greater the side effects, the worse the fix. Optionally, the implementation process of selecting the target fix patch from among the various fix patches based on the test execution results can be found in [link to documentation]. Figure 6 The steps are shown.

[0092] S504: Repair digital products using target repair patches.

[0093] The processes shown in S501-S504 above can determine the corresponding target repair patch through the defect location results, so as to realize intelligent repair of digital products.

[0094] like Figure 6 The diagram shown is a sixth flowchart of a defect location method for digital products provided in this application, which includes the following steps.

[0095] S601: For each patch, multiple execution paths are obtained based on the test execution results of the patch.

[0096] The execution path represents the process involved in the operation of a digital product repair patch.

[0097] S602: Determine the regression risk of the fix based on various execution paths.

[0098] Among them, regression risk characterization repair patches have side effects on digital products.

[0099] In some examples, the calculation process of the regression risk R(p, a) of the repair patch can be found in formula (3):

[0100] (3).

[0101] In formula (3), This represents all execution paths related to node a shown in the defect localization results, where P(path) represents the historical execution probability of execution path path. This represents the expected system behavior metric after applying patch p to the execution path. This represents the expected system behavior indicator after the patch p is not applied to the execution path. C represents the confidence correction factor for the execution path, and C represents the confidence distribution of the execution path.

[0102] S603: Select target fix patches from among the various fix patches based on their regression risk.

[0103] Among them, the patch with the lowest regression risk can be selected and marked as the target patch.

[0104] The processes shown in S601-S603 above can utilize the multiple execution paths of the patch to determine the regression risk of the patch, and then select a suitable target patch based on the regression risk.

[0105] like Figure 7 The diagram shown is an architectural schematic of a defect location device for a digital product provided in an embodiment of this application, which includes the following modules.

[0106] The multi-source data feature module 100 is used to construct an anomaly code feature set based on multi-source data of digital products.

[0107] Optionally, the multi-source data feature module 100 is specifically used for: determining multi-source data of digital products; multi-source data includes source code in different programming languages ​​and runtime data in different operating environments; determining static analysis results based on the source code in different programming languages; static analysis results include multiple nodes and the relationships between each node, with nodes used to represent the corresponding code; determining dynamic analysis results based on runtime data in different operating environments; dynamic analysis results include abnormal codes; determining at least one abnormal node based on the abnormal code and the relationships between each node; and structuring the abnormal code corresponding to each abnormal node to obtain an abnormal code feature set.

[0108] In some examples, the function of the multi-source data feature module 100 can be summarized as: collecting raw data from multiple data sources and constructing structured feature representations.

[0109] In a possible implementation, the multi-source data feature module 100 can be further divided into a multi-source data acquisition unit, a static semantic representation construction unit, and a dynamic behavior feature extraction unit. The multi-source data acquisition unit is used to connect to various data sources and perform incremental acquisition. The static semantic representation construction unit is used to construct a static semantic representation of the source code and manage its version. The dynamic behavior feature extraction unit is used to extract dynamic behavior features from the running data.

[0110] For example, the multi-source data acquisition unit includes a data source connector, an event serialization processor, and a data quality monitor. The data source connector is used to establish a connection with an external system and acquire raw data (i.e., source code and runtime data). The event serialization processor is used to uniformly sort and convert the events from different data sources according to time order. The data quality monitor is used to detect data quality problems and de-identify sensitive information.

[0111] For example, the static semantic representation building unit includes a multilingual parser, a semantic graph builder, and an incremental cache manager. The multilingual parser is used to support the parsing of source code in multiple programming languages ​​and convert it into a unified intermediate representation, generate an abstract syntax tree structure, and process macros and preprocessing directives. The semantic graph builder is used to analyze the execution flow of the program, generate a control flow graph to represent control dependencies, identify data dependencies in the program to construct a program dependency graph, and convert the code into semantic vectors. The incremental cache manager is used to cache the analyzed code and semantic vectors and perform incremental updates and version management.

[0112] For example, the dynamic behavior feature extraction unit includes a runtime data collector, an exception analysis processor, and a code mapping processor. The runtime data collector is used to obtain crash stacks, performance sampling data, and test execution traces from the application performance monitoring system. The exception analysis processor is used to convert raw memory addresses and function pointers into readable function names and code location information, cluster and group the collected exceptions and errors to identify similar failure patterns and count the frequency of exceptions, while recording and analyzing function call relationships to calculate the heat and frequency of call paths. The code mapping processor is used to establish a precise mapping relationship between exception stack frames and each node in the abstract syntax tree, and perform consistency correction in different runtime environments.

[0113] The intelligent defect localization module 200 is used to perform semantic alignment based on the target natural language and the feature set of the abnormal code to obtain defect localization results; the target natural language includes text used to describe the defects of digital products; the defect localization results are used to characterize the defect codes that match the defects of digital products; and based on the defect localization results, a corresponding defect analysis report is generated.

[0114] Optionally, the intelligent defect localization module 200 is specifically used for: determining the corresponding semantic vector features based on the target natural language; calculating the semantic alignment between the semantic vector features and each abnormal code feature in the abnormal code feature set; filtering target abnormal code features from the abnormal code feature set according to the semantic alignment; and determining the defect localization result based on the abnormal code corresponding to the target abnormal code features.

[0115] Optionally, the intelligent defect localization module 200 is specifically used for: if there are multiple target abnormal code features, calculating the confidence level of each target abnormal code feature; based on the confidence level, filtering out valid abnormal code features from each target abnormal code feature; and determining the defect localization result based on the abnormal code corresponding to the valid abnormal code feature.

[0116] In a possible implementation, the intelligent defect localization module 200 can be further subdivided into a cross-modal semantic alignment unit, a multi-granularity localization reasoning unit, and an interpretability analysis unit. The cross-modal semantic alignment unit is used to encode the defect description text into semantic vector features and perform cross-modal retrieval and alignment with the abnormal code features in the static semantic representation and dynamic behavior features. The multi-granularity localization reasoning unit performs layer-by-layer refinement of localization based on the semantic alignment result and combines static analysis and dynamic evidence to perform reasoning to obtain periodic demerits for defects. The interpretability analysis unit is used to generate a localization evidence chain and a visualization report for developers.

[0117] For example, the cross-modal semantic alignment unit includes a text encoder, a vector retrieval processor, and an alignment path tracker. The text encoder converts the target natural language into semantic vector features and generates appropriate prompts based on the question type and context to guide the large model to map keyword descriptions in the target natural language to specific code interfaces, variables, and data structures. The vector retrieval processor uses a vector retrieval engine to efficiently search anomaly code feature library containing static semantic representations and dynamic behavioral features, calculates the semantic alignment degree between semantic vector features and anomaly code features to determine the target anomaly code features, and the alignment path tracker records the correspondence between keywords and target anomaly code features and generates interpretable semantic alignment results.

[0118] For example, the multi-granularity localization reasoning unit includes a hierarchical reasoning controller, an evidence fusion processor, and a confidence evaluator. The hierarchical reasoning controller is used to coordinate the layer-by-layer refinement of the localization process and extract relevant target abnormal code features based on the abnormal location and data dependencies. The evidence fusion processor is used to analyze the control flow graph and program dependency graph to identify code paths and data dependencies that may lead to defects, and integrate dynamic evidence with static analysis results for comprehensive reasoning. The confidence evaluator is used to calculate the confidence distribution of each target abnormal code feature and handle the uncertainty of defect localization.

[0119] For example, the interpretability analysis unit includes an evidence chain extractor, an explanation generator, and an interactive feedback interface. The evidence chain extractor is used to extract supporting evidence from the defect location results and organize it into a complete reasoning chain from the problem description to the defect location. The explanation generator is used to convert the technical defect location results into text descriptions that are easy for developers to understand, display function call relationships, and highlight the corresponding positions of text and code. The interactive feedback interface is used to receive verification, correction, and supplementary opinions from developers on the location results.

[0120] The intelligent repair verification module 300 is used to: generate multiple repair patches based on defect location results; generate test case sets for each repair patch and execute the test case sets to obtain corresponding test execution results; select target repair patches from each repair patch based on the test execution results of each repair patch; and repair digital products using the target repair patches.

[0121] Optionally, the intelligent repair verification module 300 is specifically used for: obtaining multiple execution paths based on the test execution results of each repair patch; the execution path represents the process involved in the digital product running the repair patch; determining the regression risk of the repair patch based on the various execution paths; the regression risk represents the side effects of the repair patch on the digital product; and selecting the target repair patch from each repair patch according to the regression risk of each repair patch.

[0122] In some examples, the role of the intelligent repair verification module 300 can be summarized as: generating diverse repair candidates and performing test verification.

[0123] In a possible implementation, the intelligent repair verification module 300 can be further divided into a multi-strategy patch generation unit, an automated test generation and execution unit, and a multi-dimensional quality assessment and ranking unit. The multi-strategy patch generation unit is used to generate structured repair patches. The automated test generation and execution unit is used to generate a set of test cases for verification of the repair patches and execute existing test suites to perform test case testing. The multi-dimensional quality assessment and ranking unit is used to perform static and dynamic multi-dimensional evaluation of each repair patch and generate recommended solutions (i.e., target repair patches) by ranking them according to the comprehensive trust score.

[0124] For example, the multidimensional quality assessment and ranking unit includes a multidimensional assessment processor, a risk predictor, and a ranking optimizer. The multidimensional assessment processor determines whether the patch has fixed the defect and has not introduced new errors based on the test execution results, and assesses the impact of the patch on system performance. The risk predictor is used to predict the side effects and regression risks that the patch may have on other modules and functions. The ranking optimizer integrates the assessment results of each dimension, ranks the patches according to the comprehensive trust score, and generates a recommended solution that includes a remediation plan, reasons for change, verification steps, and rollback strategy.

[0125] For example, the multi-strategy patch generation unit includes a multi-source patch generator, a mutation optimizer, and a patch normalization processor. The multi-source patch generator uses a pre-trained code generation model to generate repair patches based on the defect location and context. At the same time, it maintains a repair template library for common defect patterns, identifies applicable repair templates through pattern matching, and applies corresponding code transformation rules. The mutation optimizer automatically generates code snippets that meet the requirements based on test cases and specifications, and generates diverse repair patches by performing structured mutation operations on existing code. The patch normalization processor is used to ensure that the generated repair patches conform to the project's coding specifications and style.

[0126] For example, the automated test generation and execution unit includes an intelligent test generator, a containerized execution environment, and a test result analyzer. The intelligent test generator performs symbolic analysis on the program to explore different execution paths and generates test inputs that can cover these paths. The containerized execution environment is used to run test suites to avoid impacting the production environment and supports multiple runtime environment configurations. It compares the test execution results of the original code and the patch to detect regression issues and behavioral differences. The test result analyzer is used to statistically analyze test pass and failure states, calculate code coverage changes, record detailed execution logs, and handle test timeouts and resource limitation issues.

[0127] The continuous improvement integration module 400 is used to optimize the target model based on defect location results and human opinions on the target repair patch; the target model includes a large model for semantic alignment of the target natural language and abnormal code feature sets, as well as for generating repair patches.

[0128] In some examples, the role of the continuous improvement integration module 400 can be summarized as: collecting feedback to optimize the model and integrating it into the development process.

[0129] In a possible implementation, the continuous improvement integration module 400 can be further subdivided into a human-machine collaborative feedback unit, an effect evaluation and benchmark management unit, and a model evolution and engineering integration unit. The human-machine collaborative feedback unit is used to collect human opinions from developers on the positioning results and repair suggestions, such as adoption decisions, review comments, and actual effect feedback, and to build a corresponding labeled dataset. The effect evaluation and benchmark management unit is used to establish an evaluation benchmark dataset and continuously monitor key indicators such as positioning accuracy and repair adoption rate. The model evolution and engineering integration unit continuously optimizes the large model and evaluator based on feedback data and evaluation results and achieves automated deployment.

[0130] For example, the human-machine collaborative feedback unit includes a feedback interface, a status listener, and a feedback data processor. The feedback interface provides a convenient feedback entry point for developers to evaluate the location and repair suggestions, displays detailed information on the location and repair, and collects developers' adoption decisions and modification opinions. The status listener automatically monitors the code review process and status changes such as merging, rejecting, and modifying pull requests through a hook mechanism, and collects rollback event records and subsequent abnormal data in the production environment. The feedback data processor collects and integrates feedback information from various channels, including review comments, and performs noise reduction processing on the collected feedback, identifies invalid feedback and abnormal data.

[0131] For example, the performance evaluation and benchmark management unit includes a benchmark dataset builder, an indicator monitoring processor, and an evaluation report generator. The benchmark dataset builder is used to select typical cases from historical location and repair data to build an evaluation benchmark dataset containing multiple defect types and project characteristics. The indicator monitoring processor continuously monitors the key performance indicators of the system and records the trend of indicator changes over time. The evaluation report generator integrates various evaluation data to generate performance indicator reports and system capability evaluation results, and provides improvement priority suggestions and a visual dashboard to support decision-making.

[0132] For example, the model evolution and engineering integration unit includes a model update processor, an integration deployment controller, and an audit manager. The model update processor performs small-sample fine-tuning and continuous optimization of the large model and evaluator based on labeled datasets, adopts an experience replay mechanism to prevent catastrophic amnesia, manages different versions of the model, records the configuration parameters and performance indicators of each update, and provides model rollback functionality. The integration deployment controller is responsible for deeply integrating the system with the continuous integration and continuous delivery pipeline and the integrated development environment, realizing the creation of automated pull requests, canary releases, and canary deployments. The audit manager fully records the approval process, change content, deployment time, and triggering information of model updates.

[0133] In summary, by integrating large-scale model semantic analysis with multi-source data features, this device can achieve multi-granularity defect localization, accurately locating defects at different levels such as expressions, variables, and functions in the code. This represents a significant advantage over existing methods that can only locate defects at the file or line level. The cross-modal semantic alignment mechanism enables effective correspondence between natural language problem descriptions and code features, fully utilizing the semantic understanding capabilities of the large model to make the localization results more accurate and reliable. Furthermore, the multi-source patch generation unit not only utilizes a pre-trained code generation model but also quickly locates applicable repair templates through defect pattern matching. Simultaneously, it employs structured mutation operations to generate diverse repair candidates, overcoming the limitations of traditional single-template-based methods.

[0134] This application also provides a defect localization system for digital products. The various modules and units shown in the defect localization device of this system, exemplified by a recommendation system of a large internet company, include a Java backend service module, a Python data processing module, and a C++ performance optimization module, with a total code size of approximately 8.5 million lines. This defect localization system adopts a microservice architecture, is deployed on a Kubernetes cluster, uses Prometheus for performance monitoring, and GitLab as the version control system. Specifically, the operation process of this defect localization system includes the following steps.

[0135] (1) The system first collects data from four different data sources. The first data source is the source code repository, which uses the Tree-sitter parser instead of ANTLR to incrementally process file changes and supports 14 languages ​​including Java, Python, and C++, generating a unified intermediate representation. For the Java part, a depth-first traversal of AST nodes is used to construct a program dependency graph containing method calls, variable dependencies, and class inheritance relationships; for the Python part, dataflow analysis is used to supplement dynamic features; for the C++ part, pointer analysis is used to identify memory-related defects. The second data source is the version control system, which crawls commit logs from GitLab every day, processing an average of 2000+ commits, and automatically extracts defect repair information using keyword matching and regular expressions with an accuracy of 92%. The third data source is the runtime monitoring system, which collects crash stacks, performance sampling data, and call chains from the Prometheus and Jaeger distributed tracing systems, processing approximately 50,000 events per second. The fourth data source is the user feedback system, which includes a problem log and user complaint logs.

[0136] (2) Data acquisition is followed by quality processing. The data source connector establishes connections with each system, employs connection pool management, and supports reconnection after disconnection. The event serialization processor sorts multi-source events by timestamp, handles out-of-order and delayed messages, and achieves a throughput of 100MB / s. The data quality monitor detects data integrity, consistency, and outliers, and performs desensitization processing on sensitive information, achieving a desensitization rate of 100%.

[0137] (3) The static semantic representation building unit maintains a 10GB semantic vector cache library. The multilingual parser extracts key nodes from the AST nodes of each file at three levels, converting them into 512-dimensional semantic vectors. The semantic graph builder identifies data dependencies and control dependencies in the program. For the data flow processing pipeline of the recommendation system, the generated dependency graph contains nearly 6,000 nodes. The incremental cache manager uses a Redis cluster to store the analyzed code and semantic vectors, supports version management, and only needs to reprocess the changed parts when the code is updated, achieving an average cache hit rate of 87%.

[0138] (4) The dynamic behavior feature extraction unit collects performance sampling data from Prometheus, complete function call chains from Jaeger, and crash stacks from Sentry. The runtime data collector processes approximately 430 million performance data points daily, identifying key hot functions and abnormal call paths. The anomaly analysis processor converts raw hexadecimal memory addresses into readable function names and code locations using symbolic resolution technology, achieving an accuracy of 99.8%. The system clusters anomalies from the past 6 months, identifying 128 similar failure modes, with the highest failure mode occurring 12,500 times per month. The code mapping processor establishes a precise mapping between anomaly stack frames and AST nodes, handling address offsets caused by different compilation optimization levels (-O0 to -O3) to ensure cross-environment consistency.

[0139] (5) The cross-modal semantic alignment unit uses the DistilBERT model for text encoding, compressing the model size to 40% of the original and reducing the inference latency from 285ms to 95ms. The text encoder converts the problem description "the recommendation list is empty" into a 512-dimensional semantic vector and automatically generates prompt words according to the problem type, such as emphasizing "abnormal symptoms" and "scope of impact" for defect reports. The vector retrieval processor uses the Faiss vector retrieval library for efficient retrieval and uses the IVF-PQ indexing scheme, achieving a retrieval speed of 15,000 times / second. The system calculates the similarity between the semantic vector features and 6,000 code vectors, considering the fusion of three dimensions: cross-attention weight, structural importance, and historical defect density. For a defect "homepage recommendation data loading timeout", the system filters out the top 10 suspicious files from 8.5 million lines of code within 0.45 seconds. The alignment path tracker records the complete inference chain of "loading timeout" → "data acquisition module" → "Redis timeout exception" → "anomaly capture defect".

[0140] (6) The multi-granularity localization reasoning unit adopts a hierarchical reasoning architecture. The first layer starts at the file level and expands the region based on the reference relationship between files, averaging 3 related files. The second layer refines to the function level, using call graphs and data flow analysis to select 2 high-risk functions from 6 candidate functions. The third layer further refines to the line-of-code level, identifying specific conditional statements or assignment statements. The fourth layer reaches the token level, locating specific variables or operators, achieving a fine-grained localization rate of 78%. The evidence fusion processor combines static analysis and dynamic evidence, with a weighting ratio of 4:6. The confidence evaluator converges through 3-5 rounds of iteration, finally outputting the confidence distribution of the defect location. Nodes with a confidence level higher than 60% are output as localization results, with an average of 2.8 candidate locations output.

[0141] (7) The evidence chain extractor of the interpretability analysis unit organizes the reasoning chain from the problem description to the defect location, containing an average of 5-7 reasoning steps. The explanation generator converts these steps into text descriptions that are easy for developers to understand, such as "In line 847 of the Redis connection exception handling function handler_redis_error, there is a lack of check on the connection pool status, which causes subsequent requests to reuse closed connections." The system automatically generates a visual report, including code snippet highlighting, call stack display, and key data flow annotations. The interactive feedback interface is integrated into the IDE plugin, allowing developers to directly verify, correct, and supplement the location results.

[0142] (8) The multi-strategy patch generation unit adopts a dual-path strategy. The first path uses a pre-trained CodeT5 model for code generation. The model has 220 million parameters and has been fine-tuned for the defect types of the recommendation system. It achieves a BLEU score of 45 on the internal dataset. The system generates repair code based on the defect location and context code, generating an average of 3.5 initial candidates for a single defect. The second path maintains a repair template library for 128 common defect patterns, including null pointer checks, resource leak prevention, and improved exception handling, with a pattern matching accuracy of 89%. For the defect "Redis connection timeout not handled", the system can directly apply the "add retry logic and timeout exception capture" template. The mutation optimizer performs structured mutations on the code, including condition modification, loop adjustment, and variable replacement. Each initial candidate generates 2-4 mutated versions, ultimately forming an average of 9.2 repair candidates. The patch normalization processor checks the code format and naming conventions to ensure compliance with the project's Google JavaStyleGuide or PEP8 specifications, with a 98% pass rate for specification checks.

[0143] (9) The automated test generation and execution unit adopts symbolic execution technology and uses the KLEE tool to explore the path. For a function containing conditional statements, the system can generate 10-15 test cases to cover different execution paths, improving the average code coverage by 12%. The containerized execution environment uses Docker containers to run tests, supporting multiple running configurations (such as different Redis service versions 2.8, 3.2, and 5.0), with strong isolation and repeatability. The system compares the test execution results of the original code and the patch code to detect regression problems with an accuracy of 96%. The test result analyzer statistically analyzes test failure status, calculates changes in code coverage, records execution logs, and handles test timeouts and resource limitation issues.

[0144] (10) The multidimensional quality assessment and ranking unit performed a comprehensive patch evaluation. The multidimensional assessment processor checked whether the patch fixed the target defect without introducing new errors, and evaluated the impact of the patch on system performance, with an average performance impact in the range of -1% to 2%. The risk predictor predicted the side effect risk of the patch, using a random forest model. The input features included eight features such as the criticality score of the repair location, the cyclomatic complexity of the involved code, and the frequency of historical defects. The model accuracy was 88%. The ranking optimizer integrated the evaluation results of each dimension, ranked them according to the comprehensive trust score, and generated recommended solutions that included a repair plan, reasons for change, verification steps, and rollback strategies. The system ranked the patches according to their scores, and the final recommended patches were adopted by developers at a rate of 76%.

[0145] (11) The feedback interaction interface of the human-machine collaborative feedback unit is integrated into GitLab's MR (Merge Request) review process. The system automatically adds comments to the localization and remediation suggestions in each MR, displaying localization evidence, patch comparisons, and risk assessments. Developers can provide feedback on adoption decisions through interface buttons, with an adoption rate of 67%. The status listener monitors MR merge, rejection, and modification events with an accuracy rate of 98%. The system also monitors the build and deployment status of the CI / CD pipeline, recording whether patches fail during testing, with a sensitivity of 92%. Production environment monitoring, through integration with the APM system, detects whether performance degradation or abnormal increases occur after deployment, with a rollback event capture rate of 90%.

[0146] (12) The Performance Evaluation and Benchmark Management Unit established evaluation benchmarks and selected 520 typical cases from 3,500 defects over the past two years to construct a benchmark dataset covering 128 defect types. The Metrics Monitoring Processor continuously monitors six key metrics: defect location accuracy, repair success rate, repair adoption rate, average processing time, cost per defect, and regression defect rate. The system generates weekly performance reports and provides suggestions for improvement priorities.

[0147] (13) The Model Evolution and Engineering Integration Unit performs a fine-tuning iteration monthly. Fine-tuning is based on 150-300 labeled feedback cases, using a learning rate of 1e-5 and gradient accumulation to prevent catastrophic forgetting. The system manages 15 historical model versions, recording the parameters, training data volume, and performance metrics of each version. The effectiveness of the new model is verified through A / B testing. The accuracy of the new model must be at least 2% higher than the old model before it can be deployed. Currently, the cumulative improvement is 12%. The integrated deployment controller is integrated with the Kubernetes cluster. When the new model is verified, a canary release plan is automatically created, first verifying it on 10% of the traffic, and gradually expanding to 50% and 100%. The audit manager fully records the entire process of 78 model updates over 8 months, including the updater, update time, training data, performance changes, and deployment results.

[0148] In summary, this digital product defect location system can replace manual inspection and realize defect location and repair of digital products.

[0149] This application also provides a computer-readable storage medium including a stored program, wherein the program executes the defect location method for digital products provided in this application.

[0150] This application also provides an electronic device, including a processor, a memory, and a bus. The processor and the memory are connected via the bus. The memory is used to store a program, and the processor is used to run the program. During program execution, the defect location method for digital products provided in this application is implemented.

[0151] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0152] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for defect localization in digital products, characterized in that, include: Based on multi-source data from digital products, construct an anomaly code feature set; Defect localization results are obtained by semantically aligning the target natural language with the feature set of the abnormal code; the target natural language includes text used to describe defects in digital products. The defect location results are used to characterize the defect codes that match the defects of the digital product; Based on the defect location results, a corresponding defect analysis report is generated.

2. The method according to claim 1, characterized in that, Based on multi-source data from digital products, an anomaly code feature set is constructed, including: Identify multi-source data for digital products; the multi-source data includes source code in different programming languages ​​and runtime data under different operating environments; Based on the source code of the different programming languages, the static analysis results are determined; the static analysis results include multiple nodes and the relationships between each node, and the nodes are used to represent the corresponding code; Based on the operational data under the different operating environments, dynamic analysis results are determined; the dynamic analysis results include exception codes. Based on the aforementioned abnormal code and the relationships between the nodes, at least one abnormal node is identified. The exception code corresponding to each exception node is structured to obtain an exception code feature set.

3. The method according to claim 1, characterized in that, Semantic alignment is performed between the target natural language and the abnormal code feature set to obtain defect localization results, including: Based on the target natural language, determine the corresponding semantic vector features; Calculate the semantic alignment between the semantic vector features and each abnormal code feature in the abnormal code feature set; Based on the semantic alignment, target abnormal code features are filtered from the abnormal code feature set; Based on the abnormal code corresponding to the characteristics of the target abnormal code, the defect location result is determined.

4. The method according to claim 3, characterized in that, Based on the anomaly code corresponding to the target anomaly code characteristics, the defect localization result is determined, including: If there are multiple target anomaly code features, calculate the confidence level of each target anomaly code feature; Based on the confidence level, select valid abnormal code features from each of the target abnormal code features; Based on the exception codes corresponding to the valid exception code features, the defect location result is determined.

5. The method according to claim 1, characterized in that, The method further includes: Based on the defect location results, multiple repair patches are generated; Generate test case sets for each of the aforementioned fixes and execute the test case sets to obtain the corresponding test execution results; Based on the test execution results of each of the aforementioned fix patches, a target fix patch is selected from the aforementioned fix patches; The digital product is repaired using the target repair patch.

6. The method according to claim 5, characterized in that, Based on the results of each test execution, target fix patches are selected from each fix patch, including: For each patch, multiple execution paths are obtained based on the test execution results of the patch; the execution path represents the process involved in the digital product running the patch. Based on the various execution paths, a regression risk score is determined for the fix; the regression risk score is used to quantify the side effects of the fix on the digital product. Based on the regression risk score, target repair patches are selected from each of the repair patches.

7. The method according to claim 5, characterized in that, The method further includes: Based on the defect location results and the human opinions on the target repair patch, the target model is optimized; the target model includes a large model for semantic alignment of the target natural language with the abnormal code feature set and for generating the repair patch.

8. A defect location device for digital products, characterized in that, include: The multi-source data feature module is used to construct anomaly code feature sets based on multi-source data from digital products. The intelligent defect localization module performs semantic alignment between the target natural language and the abnormal code feature set to obtain defect localization results. The target natural language includes text used to describe defects in digital products, and the defect localization results are used to characterize defect codes that match the defects in digital products. Based on the defect location results, a corresponding defect analysis report is generated.

9. A storage medium, characterized in that, The storage medium includes a stored program, wherein the program is executed by a processor to perform the defect location method of any one of claims 1-7 for the digital product.

10. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory are connected via the bus; The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the defect location method of any one of claims 1-7 for digital products.

Images