A software test defect positioning method, device and electronic equipment

Abstract

The application relates to the technical field of software test defect positioning, and discloses a software test defect positioning method, a software test defect positioning device and electronic equipment, the method comprising the following steps: obtaining software source code to be tested and a test failure case, intercepting defect-related cross-file code segments according to a failure case execution path, generating a context segment set with hierarchical marks by hierarchical abstraction, obtaining multi-granularity semantic representation by three-level granular fusion coding of words, sentences and functions, reconstructing cross-file dependency relationships between the code segments by using a graph attention mechanism and generating reconstructed semantic vectors, and finally performing multi-round matching of the vectors and historical defect feature vectors in a defect pattern reinforcement knowledge base, so as to determine defect positioning in the code. The application solves the problem that traditional defect positioning technology is limited by context length, missing structural semantics and lack of evolution ability, and is difficult to cope with modern large and complex software systems.

Description

Technical Field

[0001] This invention relates to the field of software testing defect localization technology, specifically to a software testing defect localization method, apparatus, and electronic device. Background Technology

[0002] Defect localization in software testing is one of the core challenges in software engineering, aiming to quickly and accurately identify the root causes of code failures. With the explosive growth in the complexity of software systems, traditional methods relying on manual code review or static analysis are no longer sufficient.

[0003] Traditional methods primarily follow two paradigms: one is spectrum-based defect localization, which calculates suspicion scores by statistically analyzing the correlation between lines of code covered by test cases and the success / failure of test case execution (e.g., Tarantula, Ochiai algorithms). This is essentially statistical analysis with limited understanding of code semantics. The other is methods based on early deep learning models, which typically input the entire source code text of a function or file directly into the model (e.g., RNN, CNN, or early Transformers), relying on the model's sequence modeling capabilities to learn features from the text. These methods generally face two major bottlenecks: First, they typically use a single function or file as the processing unit, making it difficult to effectively model long-term dependencies across files (e.g., global state modifications, cross-module anomaly propagation). Second, when the code context length exceeds the window limit of the pre-trained model (e.g., exceeding 512 or 1024 terms), simple truncation or segmentation is usually employed, leading to the loss or fragmentation of key contextual information, severely limiting the model's ability to understand complex defect chains.

[0004] Therefore, there is an urgent need for a software testing defect localization method to address the problem that traditional defect localization techniques are limited by context length, lack of structural semantics, and lack of evolutionary capabilities, making them unable to cope with modern large-scale and complex software systems. Summary of the Invention

[0005] This invention provides a software testing defect localization method, apparatus, and electronic device to address the problem that traditional defect localization techniques are limited by context length, lack of structural semantics, and lack of evolutionary capabilities, making them difficult to handle modern large-scale and complex software systems.

[0006] In a first aspect, the present invention provides a method for locating software testing defects, the method comprising: The process involves acquiring the source code and failed test cases of the software under test, and extracting cross-file code segments related to defects from the source code based on the execution paths of the failed test cases. These cross-file code segments are then abstracted hierarchically to generate a set of context segments carrying hierarchical tags. At the lexical level, the context segment set is lexical symbol embedding is performed to obtain lexical embedding vectors for each statement. At the statement level, the structural information of the program control flow graph is fused with the lexical embedding vectors to obtain a statement-level fused semantic representation. At the function level, the cross-file call chain features are fused with the statement-level fused semantic representation to obtain a function-level fused semantic representation. Based on the statement-level and function-level fused semantic representations, a graph attention mechanism is used to reconstruct the cross-file dependencies between code segments and generate reconstructed semantic vectors. These reconstructed semantic vectors are then matched multiple times with historical defect feature vectors in a defect pattern reinforcement knowledge base. The defect location in the reconstructed semantic vectors is determined based on the matching results.

[0007] The software testing defect localization method provided by this invention first precisely extracts defect-related cross-file code fragments based on the execution path of failed test cases, eliminating irrelevant code interference and focusing on the core defect-related code scope. Then, it performs hierarchical abstraction on these code fragments to form a well-organized hierarchical context set, enabling subsequent semantic encoding processes to identify feature attributes at different abstraction levels. This avoids the loss of key contextual information caused by simple code truncation. Subsequently, through a three-level progressive multi-granularity semantic encoding of terms, statements, and functions, it comprehensively captures the basic lexical structure, program control flow, and multi-level semantic information of cross-file calls, avoiding the one-sided semantic understanding of single-granularity encoding. Furthermore, it uses a graph attention mechanism to reconstruct cross-file dependencies that are easily lost during code slicing, resulting in a reconstructed semantic vector that fully carries the code semantics and real dependency associations. Finally, it combines historical defect features from a defect pattern-enhanced knowledge base to complete multi-round matching and localization to achieve accurate defect localization. This method not only solves the problems of traditional defect localization methods, such as difficulty in handling cross-file code and easy loss of dependencies, but also improves the targeting of localization through multi-granular semantic modeling and historical defect feature matching. At the same time, it reduces the unnecessary computational overhead by accurately narrowing the scope of code analysis in the early stage, and finally achieves more accurate and efficient software defect localization in complex cross-file scenarios.

[0008] In one alternative implementation, hierarchical abstraction is performed on code snippets across files to generate a set of context snippets carrying hierarchical tags, including: Save the signature information of all functions and key control flow nodes in the cross-file code snippets to obtain the first-level abstract snippet; extract and retain the data flow dependencies in the cross-file code snippets to obtain the second-level abstract snippet, which is determined based on the data dependency graph; compress and replace loop bodies and nested structures exceeding the threshold in the cross-file code snippets with abstract symbols, retaining the core structural semantic features to obtain the third-level abstract snippet; based on the first-level, second-level, and third-level abstract snippets, generate a set of context snippets carrying hierarchical tags.

[0009] The software testing defect localization method provided by this invention performs three-level differentiated abstraction on cross-file code segments and adds hierarchical tags. It retains function signatures and key control flow nodes, extracts data flow dependencies corresponding to data dependency graphs, and compresses redundant loops and nested structures. This not only removes redundant code structures but also fully preserves the core control flow, data flow, and function association features of the program, avoiding the loss of key program logic due to simple and crude code truncation. Furthermore, hierarchical abstraction reduces code complexity and information redundancy, preventing feature confusion in subsequent semantic encoding due to excessive code size. Moreover, hierarchical tags enable subsequent multi-granular semantic fusion processes to accurately identify feature attributes at different abstraction levels, improving the accuracy and stability of code semantic extraction.

[0010] In one optional implementation, based on statement-level fused semantic representation and function-level fused semantic representation, a graph attention mechanism is used to reconstruct cross-file dependencies between code segments and generate reconstructed semantic vectors, including: A code dependency graph to be repaired is constructed, which includes several nodes. Nodes represent either statement-level fusion semantic representations or function-level fusion semantic representations of code segments. Based on the graph attention mechanism, attention coefficients between nodes in the code dependency graph are calculated, and the weights of long-distance cross-file dependencies between nodes are adjusted according to the attention coefficients. The cross-file dependencies between code segments are reconstructed based on the weighted code dependency graph, and the reconstructed cross-file dependencies are fused with the statement-level fusion semantic representations and function-level fusion semantic representations to generate reconstructed semantic vectors.

[0011] The software testing defect localization method provided by this invention constructs a code dependency graph that integrates statement-level and function-level semantics, transforming multi-granular code semantics into structured graph node features. It then utilizes a graph attention mechanism to calculate attention coefficients between nodes and corrects the weights of long-distance dependencies across files. This effectively addresses the issues of weakened long-distance dependencies and unreasonable weight allocation during the initial code extraction and abstraction process, restoring the true program dependency logic between code fragments. Furthermore, based on the corrected weighted dependency graph, a complete cross-file dependency relationship is reconstructed and fused with the two-level semantic representation to generate a reconstructed semantic vector. This ensures that the final feature vector retains both the multi-granular semantic information of the code itself and integrates the accurately restored structured dependency relationships, avoiding the feature loss problem caused by relying solely on semantic features while ignoring code structural relationships. This provides more complete semantic information that better reflects the actual program execution logic.

[0012] In one optional implementation, the reconstructed semantic vector is matched with historical defect feature vectors in the defect pattern reinforcement knowledge base in multiple rounds, including: The code structure features in the reconstructed semantic vector are matched with the code structure features in the historical defect feature vector to obtain the structure matching score of the first round of matching; the data flow dependency features in the reconstructed semantic vector are aligned and matched with the abnormal data flow features in the historical defect feature vector to obtain the abnormal matching score of the second round of matching; the constraints in the reconstructed semantic vector are verified and matched with the constraints in the historical defect feature vector to obtain the constraint matching score of the third round of matching.

[0013] The software testing defect localization method provided by this invention breaks down the matching process into three independent dimensions: code structure, data flow dependencies, and constraints. Each dimension is matched separately and a corresponding score is obtained. This decomposes the overall feature comparison into a comparison of key, subdivided features related to defects, avoiding the problems of overlooking local defect features or being interfered with by irrelevant features in a single overall matching process. Simultaneously, the three rounds of independent matching comprehensively uncover the correlations between features, preventing potential defects from being missed due to the lack of prominence of features in a single dimension, thus effectively improving the accuracy of defect identification.

[0014] In one optional implementation, determining the defect location in the reconstructed semantic vector based on the matching result includes: If the matching score for this round exceeds the dynamic threshold, the Generative Adversarial Network (GAN) is activated to perform feature decoding and location mapping on the reconstructed semantic vector and the matched historical defect feature vector, generating a defect location hint vector for this round. The defect location hint vector includes defect location information and defect type identifier. If the matching score is less than or equal to the dynamic threshold, it is determined that there is no suspected defect in the current code segment, and no defect location hint vector is generated for this round.

[0015] The software testing defect localization method provided by this invention uses a dynamic threshold to differentiate the matching score in each round, which can adapt to the differences in different code segments and feature dimensions, avoiding the false negatives or missed positives that are easily caused by fixed thresholds. When the score exceeds the threshold, an adversarial generative network is triggered to complete feature decoding and location mapping, directly generating a prompt vector containing the defect location and defect type. When the score does not reach the threshold, it is directly determined that there is no suspected defect and the generation of prompt vector is terminated. This not only ensures the sensitivity of suspected defect identification, but also improves the reliability of the localization results through precise filtering, and makes the defect localization output directly applicable to engineering.

[0016] In one alternative implementation, the method further includes: Output the defect location hint vector to the development end to obtain verification feedback; if the verification feedback is a false positive of the defect location hint vector, extract the semantic fingerprint and control flow features of the false positive code segment, and update the negative sample filter of the defect pattern reinforcement knowledge base; if the verification feedback is a false negative of the defect location hint vector, return to the step of performing hierarchical abstraction of cross-file code segments to generate a set of context segments with hierarchical tags, trace back the information loss nodes in the hierarchical abstraction process, and expand the dependency capture range of dynamic code slices.

[0017] The software testing defect localization method provided by this invention forms a closed-loop optimization mechanism by introducing verification feedback from the development end. For the localization results of false positives, corresponding code features are extracted and the negative sample filter is updated. This allows the defect knowledge base to gradually eliminate normal code features that are prone to misjudgment, reducing subsequent repeated false positives from the source. For missed positives, the method traces back to the hierarchical abstraction stage and expands the scope of dependency capture. This can specifically make up for the information loss in the early code slicing and abstraction process, strengthen the capture capability of cross-file dependencies, and enable the entire defect localization process to continuously self-correct, gradually reducing the probability of false positives and missed positives, and improving the stability and accuracy of defect localization in long-term use.

[0018] Secondly, the present invention provides a software testing defect localization device, the device comprising: The code snippet acquisition module is used to acquire the source code and test failure cases of the software under test, and extract cross-file code snippets related to defects from the source code of the software under test based on the execution path of the test failure cases. The hierarchical abstraction module is used to perform hierarchical abstraction of code snippets across files, generating a set of context snippets carrying hierarchical tags; The multi-granularity semantic coding module is used to embed lexical symbols into the context fragment set at the lexical level to obtain the lexical embedding vector of each statement, fuse the structural information of the program control flow graph with the lexical embedding vector at the statement level to obtain the statement-level fused semantic representation, and fuse the cross-file call chain features with the statement-level fused semantic representation at the function level to obtain the function-level fused semantic representation. The semantic reconstruction module is used to reconstruct cross-file dependencies between code segments based on statement-level and function-level fused semantic representations, and to generate reconstructed semantic vectors using graph attention mechanisms. The defect localization module is used to perform multiple rounds of matching between the reconstructed semantic vector and the historical defect feature vector in the defect pattern reinforcement knowledge base, and determine the defect localization in the reconstructed semantic vector based on the matching results.

[0019] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the software testing defect localization method of the first aspect or any corresponding embodiment described above.

[0020] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the software testing defect localization method of the first aspect or any corresponding embodiment described above.

[0021] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the software testing defect localization method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a software testing defect localization method according to an embodiment of the present invention; Figure 3 This is a structural block diagram of a software testing defect location device according to an embodiment of the present invention; Figure 4This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0026] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0027] As an optional application scenario of this invention, the specific application environment architecture or specific hardware architecture on which the software testing defect localization method depends is described here. For example... Figure 1 As shown, the architecture system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0028] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0029] According to an embodiment of the present invention, a method for locating software testing defects is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] This embodiment provides a method for locating software testing defects, which can be used on the aforementioned mobile terminals, such as mobile phones and tablets. Figure 2 This is a flowchart of a software testing defect localization method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the source code and test failure cases of the software under test, and extract cross-file code segments related to defects from the source code of the software under test according to the execution path of the test failure cases.

[0031] In one optional embodiment, the source code of the software under test and the test failure cases are used to extract cross-file related code segments according to the actual execution path of the test failure cases. Based on the actual trajectory of program execution, code content related to defects is filtered to obtain cross-file code segments that are scattered in different files and have an impact on defects.

[0032] Step S202: Perform hierarchical abstraction on cross-file code snippets to generate a set of context snippets carrying hierarchical tags.

[0033] In one optional embodiment, by performing structured hierarchical abstraction on code fragments, redundant and complex code parts are reasonably compressed while preserving the core semantics and structural information of the program. At the same time, tags are added to the abstraction results at different levels to generate a set of context fragments with hierarchical tags.

[0034] Step S203: At the lexical level, lexical symbol embedding is performed on the context fragment set to obtain the lexical embedding vector of each statement. At the statement level, the structural information of the program control flow graph is fused with the lexical embedding vector to obtain the statement-level fused semantic representation. At the function level, the cross-file call chain features are fused with the statement-level fused semantic representation to obtain the function-level fused semantic representation.

[0035] In one alternative embodiment, a set of context fragments is input into a pre-trained code language model to perform multi-granular semantic encoding: embedding lexical symbols at the token level, fusing control flow graph structure information at the statement level, and injecting cross-file call chain features at the function level; Token-level lexical embedding involves inputting context fragments into a pre-trained code language model. First, token-level semantic encoding is performed. At this stage, each token in the source code, such as variable names, operators, and keywords, is converted into an embedding vector by the pre-trained language model. The semantic information of each token is embedded into a fixed-dimensional vector space, enabling the model to capture the basic structure of the language. At this level, there's no need to handle cross-file dependencies or complex control flow structures; the focus is solely on providing a basic semantic representation for each token. Furthermore, after the token-level embedding is completed, statement-level processing begins, fusing the program's control flow graph (CFG) structure information with the token embedding of each statement. Control flow information parsed from the program dependency graph (PDG), such as loops and conditional branches, is injected as additional structural information into the statement-level representation. This information fusion can be implemented using graph neural networks (GNNs) or graph attention mechanisms (GATs) to help the model understand the execution dependencies and control flow relationships between different statements. Through this fusion, the model can simultaneously understand the basic syntactic structure and execution logic of the code at the statement level, enhancing its ability to understand complex program structures. Furthermore, at the function level, cross-file call chain features are introduced, embedding the abstract information of the cross-file code snippets from step S201, particularly the cross-file function call chain information, into the representation of each function. Due to the complexity of the program, function calls often involve cross-file operations; therefore, the model needs to identify and effectively represent these cross-file dependencies. At this layer, a cross-file function call chain graph is constructed to represent the call relationships between different functions, and this information is injected into the representation of each function. Specifically, for each function... The embedding of its cross-file call chain is calculated and combined with the semantic representation of the function itself to form the final function representation as follows: Let the function There are cross-file call relationships among multiple files. There are pairs in the middle If the function is called, then the function The embedding is represented by the following formula:

[0036] in: Representation function The final embedding; Representation function The semantic embedding itself usually comes from the language model; Represents a file AND function The embedded call chain information reflects the call relationships across files; It represents the number of cross-file calls.

[0037] Step S204: Based on statement-level fused semantic representation and function-level fused semantic representation, the cross-file dependency relationship between each code segment is reconstructed using a graph attention mechanism, and a reconstructed semantic vector is generated.

[0038] In one optional embodiment, based on the fusion of statement-level and function-level semantic representations, cross-file dependencies are reconstructed and reconstructed semantic vectors are generated by using a graph attention mechanism. This repairs long-distance cross-file dependencies that were truncated or lost during the earlier code slicing and abstraction processes and generates reconstructed semantic vectors.

[0039] Step S205 involves performing multiple rounds of matching between the reconstructed semantic vector and the historical defect feature vector in the defect pattern reinforcement knowledge base, and determining the defect location in the reconstructed semantic vector based on the matching results.

[0040] In one optional embodiment, the historical defect feature patterns accumulated in the knowledge base are used as a reference. The reconstructed semantic vector is matched and compared with the historical defect feature vector in the defect pattern reinforcement knowledge base in multiple dimensions to identify the similarity between the semantic features of the current code segment to be tested and the historical defect features. Finally, the defect location in the reconstructed semantic vector is determined based on the matching results.

[0041] The software testing defect localization method provided in this embodiment first accurately extracts defect-related cross-file code fragments based on the execution path of failed test cases, eliminating irrelevant code interference and focusing on the core defect-related code scope. Then, it performs hierarchical abstraction on these code fragments to form a well-organized hierarchical context set, enabling subsequent semantic encoding processes to identify feature attributes at different abstraction levels. This avoids the loss of key contextual information caused by simple code truncation. Subsequently, through a three-level progressive multi-granularity semantic encoding of terms, statements, and functions, it comprehensively captures the basic lexical structure, program control flow, and multi-level semantic information of cross-file calls, avoiding the one-sided semantic understanding of single-granularity encoding. Furthermore, it uses a graph attention mechanism to reconstruct cross-file dependencies that are easily lost during code slicing, resulting in a reconstructed semantic vector that fully carries the code semantics and real dependency associations. Finally, it combines historical defect features from a defect pattern-enhanced knowledge base to complete multi-round matching and localization to achieve accurate defect localization. This method not only solves the problems of traditional defect localization methods, such as difficulty in handling cross-file code and easy loss of dependencies, but also improves the targeting of localization through multi-granular semantic modeling and historical defect feature matching. At the same time, it reduces the unnecessary computational overhead by accurately narrowing the scope of code analysis in the early stage, and finally achieves more accurate and efficient software defect localization in complex cross-file scenarios.

[0042] In some optional implementations, step S202 above includes: Step a1: Save the signature information of all functions in the cross-file code snippet and the key control flow nodes in the cross-file code snippet to obtain the first-level abstract snippet.

[0043] In an optional embodiment, the signature information of all functions across the file code segment and key control flow nodes in the code, such as branches (if), loops (for, while), etc., are preserved. The signature of each function is represented as follows:

[0044] in, The function name. For input parameters, This is the return type. Key control flow nodes describe the program's execution path and can help with subsequent analysis of control flow dependencies.

[0045] Step a2: Extract and retain the data flow dependencies in the cross-file code snippets to obtain the second-level abstract snippet. The data flow dependencies are determined based on the data dependency graph.

[0046] In one alternative embodiment, data flow dependencies across file code snippets are extracted and preserved. These data flow dependencies can be modeled using a Data Dependency Graph (DDG) to represent the data transfer relationships between variables. Assume there are two variables... and ,if The value depends on This indicates the existence of a data flow dependency, denoted as: .

[0047] Step a3: Compress and replace loop bodies and nested structures that exceed the threshold in cross-file code snippets with abstract symbols, while preserving the semantic features of the core structure, to obtain the third-level abstract snippet.

[0048] In one alternative embodiment, loops and nested structures exceeding a preset threshold in cross-file code snippets are compressed and replaced, and compressed into abstract symbols. For example, nested loops or deeply nested structures might be represented as symbols such as "LOOP1" or "LOOP2" to avoid introducing excessive complexity into long code snippets. The compression of nested structures is represented as follows:

[0049] in, For loop body, The nesting depth.

[0050] Step a4: Based on the first-level abstract fragment, the second-level abstract fragment, and the third-level abstract fragment, generate a set of context fragments carrying hierarchical tags.

[0051] In an optional embodiment, after the above three-layer abstraction process, a set of context fragments carrying hierarchical tags is obtained, and it is ensured that the total length does not exceed the context window limit of the pre-trained language model.

[0052] The software testing defect localization method provided in this embodiment performs three-level differentiated abstraction on cross-file code segments and adds hierarchical tags. It retains function signatures and key control flow nodes, extracts data flow dependencies corresponding to data dependency graphs, and compresses redundant loops and nested structures. This not only removes redundant code structures but also fully preserves the core control flow, data flow, and function association features of the program, avoiding the loss of key program logic due to simple and crude code truncation. Furthermore, hierarchical abstraction reduces code complexity and information redundancy, preventing feature confusion in subsequent semantic encoding due to excessive code size. Moreover, hierarchical tags enable subsequent multi-granular semantic fusion processes to accurately identify feature attributes at different abstraction levels, improving the accuracy and stability of code semantic extraction.

[0053] In some optional implementations, step S204 above includes: Step b1: Construct the dependency graph of the code to be repaired.

[0054] In one optional embodiment, the code dependency graph includes several nodes, which are used to represent the statement-level fused semantic representation of code fragments, or the function-level fused semantic representation of code fragments.

[0055] Step b2: Based on the graph attention mechanism, calculate the attention coefficients between nodes in the code dependency graph, and adjust the weights of long-distance cross-file dependencies between nodes according to the attention coefficients.

[0056] In one optional embodiment, the graph attention mechanism can automatically calculate attention weights based on the relationships between nodes, strengthening connections with strong dependencies and suppressing irrelevant connections. During the reconstruction of cross-file dependencies, the graph attention mechanism assigns different attention weights to each code snippet or function and modifies the dependencies. Consider two nodes (code snippets). and There are dependencies between them. The graph attention mechanism weights these relationships by calculating attention coefficients, which are calculated as follows:

[0057] in, and These are nodes and The original feature vector; It is a learnable shared weight matrix that performs a linear transformation on the features of each node to extract high-level features; | represents a vector concatenation operation, which combines the transformed node features. and Connect them into a combined vector; It is a learnable attention vector, whose transpose is multiplied by the concatenated vector to obtain a scalar score; It is a non-linear activation function that introduces a small negative slope to handle negative values ​​in the score; The function maps the score to a positive number; the summation term in the denominator For nodes All neighboring nodes (include The indexed scores of each node are summed to achieve normalization, ultimately ensuring that all neighboring nodes are normal to each other. The sum of attention coefficients is 1, which is achieved through learnable parameters. and The model dynamically evaluates the correlation strength between features of nodes and uses normalization to obtain standardized attention weights, thereby allowing the model to focus more on important dependencies when aggregating information.

[0058] Step b3: Reconstruct the cross-file dependencies between code segments based on the code dependency graph after weight correction, and fuse the reconstructed cross-file dependencies with the statement-level fusion semantic representation and the function-level fusion semantic representation to generate a reconstructed semantic vector.

[0059] In one optional embodiment, based on the code dependency graph with corrected weights, the true cross-file dependency relationships between code segments that were weakened or lost during the previous code extraction and layered abstraction process can be accurately restored. The corrected weights clarify the importance of the dependency relationships between different code nodes, making the reconstructed dependency relationships fit the actual running logic of the program. By fusing this complete cross-file dependency relationship with the extracted statement-level and function-level fusion semantic representations, the multi-granular semantic features of the code and the structured dependency relationships can be deeply bound together, ultimately generating a reconstructed semantic vector.

[0060] The software testing defect localization method provided in this embodiment constructs a code dependency graph that integrates statement-level and function-level semantics. This transforms multi-granularity code semantics into structured graph node features. Then, a graph attention mechanism is used to calculate attention coefficients between nodes and correct long-distance cross-file dependency weights. This effectively addresses the issues of weakened long-distance cross-file dependencies and unreasonable weight allocation during the initial code extraction and abstraction process, restoring the true program dependency logic between code fragments. Furthermore, based on the corrected weighted relationship graph, a complete cross-file dependency relationship is reconstructed and fused with the two-level semantic representation to generate a reconstructed semantic vector. This ensures that the final feature vector retains both the multi-granularity semantic information of the code itself and integrates the accurately restored structured dependency relationships. This avoids the feature loss problem caused by relying solely on semantic features while ignoring code structural relationships, providing more complete semantic information that better reflects the actual program execution logic.

[0061] In some optional implementations, step S205 above involves performing multiple rounds of matching between the reconstructed semantic vector and the historical defect feature vector in the defect pattern reinforcement knowledge base, including: Step c1 involves performing similarity matching between the code structure features in the reconstructed semantic vector and the code structure features in the historical defect feature vector to obtain the structure matching score for the first round of matching.

[0062] In one optional embodiment, the defect pattern reinforcement knowledge base contains code feature maps and remediation solutions for multiple historical defects, covering common defect types such as memory leaks, concurrency races, and boundary exceptions. Each defect pattern in the knowledge base includes related code snippets, exception characteristics, triggering conditions, and remediation methods.

[0063] The code structure features in the reconstructed semantic vector are matched with the code structure features in the historical defect feature vector. By analyzing the code structure, such as the control flow graph (CFG) and abstract syntax tree (AST), similar structures to historical defects can be found, and the structure matching score of the first round of matching is calculated. This score is used to represent the degree of similarity of the code structure, and defect patterns with high matching scores will be filtered out.

[0064] Step c2 involves aligning and matching the data flow dependency features in the reconstructed semantic vector with the abnormal data flow features in the historical defect feature vector to obtain the abnormal matching score for the second round of matching.

[0065] In one optional embodiment, the data flow dependency features in the reconstructed semantic vector are aligned and matched with the abnormal data flow features in the historical defect feature vector. The abnormal data flow features include uninitialized variables, data races, etc. The abnormal matching score of the second round of matching is calculated. This score is used to evaluate the similarity between the data flow anomalies in the current test case and the historical defects.

[0066] Step c3 involves verifying and matching the constraints in the reconstructed semantic vector with the constraints in the historical defect feature vector to obtain the constraint matching score for the third round of matching.

[0067] In one optional embodiment, constraints include variable lifetimes, function call order, etc. Verifying the matching between constraints in the reconstructed semantic vector and constraints in the historical defect feature vector can accurately verify whether the current defect conforms to the constraints of known defects using contextual information such as global variables, local variables, and function call order. A constraint matching score is calculated for the third round of matching; this score confirms whether the current defect conforms to the contextual conditions of historical defects.

[0068] The software testing defect localization method provided in this embodiment breaks down the matching process into three independent dimensions: code structure, data flow dependencies, and constraints. Each dimension is matched separately and a corresponding score is obtained. The overall feature comparison is decomposed into a comparison of key, subdivided features related to defects, avoiding the problems of overlooking local defect features or being interfered with by irrelevant features in a single overall matching process. Simultaneously, the three rounds of independent matching can comprehensively uncover the correlation clues between features, preventing potential defects from being missed due to the lack of prominence of features in a single dimension, effectively improving the accuracy of defect identification.

[0069] In some optional implementations, step S205 above, which determines the location of defects in the reconstructed semantic vector based on the matching results, includes: Step d1: Determine whether the matching score for this round exceeds the dynamic threshold.

[0070] In one optional embodiment, each round of matching generates a matching score, and it is determined whether the matching score for this round exceeds a dynamic threshold. The dynamic threshold is a judgment threshold for each round of matching, adaptive to the current code scenario, and its size is automatically adjusted based on the feature type of the current round of matching.

[0071] Step d2: If the matching score is greater than the dynamic threshold, the adversarial generative network is activated to perform feature decoding and position mapping on the reconstructed semantic vector and the historical defect feature vector of the matching, and generate the defect localization prompt vector for this round.

[0072] In an optional embodiment, if the matching score is greater than a dynamic threshold, it indicates that the current code snippet matched highly with known defect features in that dimension, suggesting the existence of a suspected defect of the corresponding type. At this point, the Generative Adversarial Network (GAN) performs feature decoding and position mapping on the reconstructed semantic vector and the matched historical defect feature vector, generating a defect location hint vector for this round. This defect location hint vector includes defect location information and a defect type identifier.

[0073] Step d3: If the matching score is less than or equal to the dynamic threshold, it is determined that there is no suspected defect in the current code segment, and no defect location hint vector is generated for this round.

[0074] In an optional embodiment, when the matching score is less than or equal to the dynamic threshold, it indicates that the similarity between the features of the current code segment in the corresponding dimension and the historical defect features in the defect pattern reinforcement knowledge base has not reached the judgment threshold, and no abnormal features consistent with known defects are presented in this dimension; therefore, it is directly determined that the code segment has no suspected defects in this dimension, and the adversarial generative network is no longer triggered to generate defect location hint vectors.

[0075] The software testing defect localization method provided in this embodiment uses a dynamic threshold to differentiate the matching score in each round, which can adapt to the differences in different code segments and feature dimensions, avoiding the false negatives or missed positives that are easily caused by fixed thresholds. When the score exceeds the threshold, an adversarial generative network is triggered to complete feature decoding and location mapping, directly generating a prompt vector containing the defect location and defect type. When the score does not reach the threshold, it is directly determined that there is no suspected defect and the generation of prompt vector is terminated. This not only ensures the sensitivity of suspected defect identification, but also improves the reliability of the localization results through precise filtering, and makes the defect localization output directly applicable to engineering.

[0076] In some optional implementations, the software testing defect localization method provided in this embodiment further includes: Step e1: Output the defect location hint vector to the development end to obtain verification feedback.

[0077] In one optional embodiment, the suspected code region marked by the defect location hint vector and the confidence score are output to the development end, and the verification feedback of the defect location result is received from the development end.

[0078] Step e2: If the verification feedback is a false alarm of the defect location prompt vector, extract the semantic fingerprint and control flow features of the false alarm code fragment, and update the negative sample filter of the defect pattern reinforcement knowledge base.

[0079] In one optional embodiment, when the development team reports a false positive, the semantic fingerprint and control flow features of the falsely reported code fragment are extracted, and these features are used to update the defect pattern and strengthen the negative sample filter in the knowledge base. Specifically, the system analyzes the semantic fingerprint of the falsely reported code, i.e., extracts the similarity with historical defect features, and uses a graph neural network (GNN) to adjust the negative sample filter to prevent future false positives of similar types of defects. By optimizing the negative sample filter, the system can better identify and exclude irrelevant code patterns.

[0080] Step e3: If the verification feedback indicates that the defect location prompt vector is missed, return to the step of performing hierarchical abstraction of cross-file code segments to generate a set of context segments with hierarchical tags, trace back the information loss nodes in the hierarchical abstraction process, and expand the dependency capture range of dynamic code slices.

[0081] In one alternative embodiment, when a developer reports a missed defect, the process returns to the step of hierarchically abstracting code snippets across files to generate a set of context snippets carrying hierarchical tags, identifying and expanding information loss nodes, thereby broadening the dependency capture scope of the dynamic code slices. Specifically, the purpose of dynamic code slicing is to extract defect-related parts from the source code; expanding the capture scope of these slices will help the model capture more contextual information, ensuring that missed defects can be identified in subsequent analysis.

[0082] Furthermore, upon receiving developer feedback, the system fine-tunes the graph attention mechanism of the pre-trained language model based on the feedback data to optimize the accuracy of defect localization. The system adjusts the graph attention weights in the model according to the feedback, allowing the model to pay more attention to code sections deemed important in the feedback when handling long-distance dependencies. This fine-tuning process is achieved by optimizing the graph attention weight update algorithm. The algorithm's purpose is to dynamically adjust the dependency weights based on developer feedback to improve localization accuracy. The dependency weight calculation formula is as follows:

[0083] in, It is the learning rate, which controls the step size for updating weights; It is a loss function Weights The gradient indicates the direction of adjustment needed to reduce the overall positioning error; and These represent nodes triggered by developer feedback (such as confirmed false positives or false negatives). and nodes The changes in the semantic feature vectors, which act as the concrete carriers of feedback signals, are determined by multiplying the learning rate, the gradient-guided direction, and the feedback-driven feature changes. Increment This enhances the connections between nodes that are closely related to real defects, while suppressing connections that correspond to noise or irrelevant dependencies.

[0084] The software testing defect localization method provided in this embodiment forms a closed-loop optimization mechanism by introducing verification feedback from the development end. For the localization results of false positives, corresponding code features are extracted and the negative sample filter is updated. This allows the defect knowledge base to gradually eliminate normal code features that are prone to misjudgment, reducing subsequent repeated false positives from the source. For missed positives, the method traces back to the hierarchical abstraction stage and expands the scope of dependency capture. This can specifically make up for the information loss in the early code slicing and abstraction process, strengthen the capture capability of cross-file dependencies, and enable the entire defect localization process to continuously self-correct, gradually reducing the probability of false positives and missed positives, and improving the stability and accuracy of defect localization in long-term use.

[0085] This embodiment also provides a software testing defect location device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0086] This embodiment provides a software testing defect location device, such as... Figure 3 As shown, it includes: The code snippet acquisition module 301 is used to acquire the source code and test failure cases of the software under test, and extract cross-file code snippets related to defects in the source code of the software under test according to the execution path of the test failure cases. The hierarchical abstraction module 302 is used to perform hierarchical abstraction of code fragments across files, generating a set of context fragments carrying hierarchical tags; The multi-granularity semantic coding module 303 is used to embed lexical symbols into the context fragment set at the lexical level to obtain the lexical embedding vector of each statement, fuse the structural information of the program control flow graph with the lexical embedding vector at the statement level to obtain the statement-level fused semantic representation, and fuse the cross-file call chain features with the statement-level fused semantic representation at the function level to obtain the function-level fused semantic representation. The semantic reconstruction module 304 is used to reconstruct the cross-file dependencies between code segments based on statement-level fused semantic representation and function-level fused semantic representation, and to generate reconstructed semantic vectors. The defect localization module 305 is used to perform multiple rounds of matching between the reconstructed semantic vector and the historical defect feature vector in the defect pattern reinforcement knowledge base, and determine the defect localization in the reconstructed semantic vector based on the matching results.

[0087] The software testing defect localization device provided in this embodiment of the invention can execute the software testing defect localization method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method. Further functional descriptions of the various modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0088] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0089] The following is a detailed reference. Figure 4 This diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0090] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0091] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory 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 409, or installed from a memory 408, or installed from a ROM 402. When the computer program is executed by the processor 401, it performs the functions defined in the software testing defect localization method of the embodiments of the present invention.

[0092] Figure 4The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0093] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the software testing defect localization method shown in the above embodiments is implemented.

[0094] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0095] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for locating software testing defects, characterized in that, The method includes: Obtain the source code and test failure cases of the software under test, and extract cross-file code segments related to defects from the source code of the software under test according to the execution path of the test failure cases; The cross-file code snippets are abstracted hierarchically to generate a set of context snippets carrying hierarchical tags; Lexical symbol embedding is performed on the context fragment set at the lexical level to obtain the lexical embedding vector of each statement. At the statement level, the structural information of the program control flow graph is fused with the lexical embedding vector to obtain the statement-level fused semantic representation. At the function level, the cross-file call chain features are fused with the statement-level fused semantic representation to obtain the function-level fused semantic representation. Based on the statement-level fused semantic representation and the function-level fused semantic representation, the cross-file dependency relationship between each code segment is reconstructed using a graph attention mechanism, and a reconstructed semantic vector is generated; The reconstructed semantic vector is matched with the historical defect feature vector in the defect pattern reinforcement knowledge base in multiple rounds, and the defect location in the reconstructed semantic vector is determined based on the matching results.

2. The method according to claim 1, characterized in that, The cross-file code snippets are subjected to hierarchical abstraction to generate a set of context snippets carrying hierarchical tags, including: Save the signature information of all functions in the cross-file code segment and the key control flow nodes in the cross-file code segment to obtain the first-level abstract segment; Extract and retain the data flow dependencies in the cross-file code snippets to obtain the second-level abstract snippet, wherein the data flow dependencies are determined based on the data dependency graph; Compress and replace loop bodies and nested structures that exceed the threshold in the cross-file code snippet with abstract symbols, while retaining the core structural semantic features, to obtain the third-level abstract snippet; Based on the first-level abstract fragment, the second-level abstract fragment, and the third-level abstract fragment, a set of context fragments carrying hierarchical tags is generated.

3. The method according to claim 1, characterized in that, Based on the statement-level fused semantic representation and the function-level fused semantic representation, a graph attention mechanism is used to reconstruct cross-file dependencies between code segments and generate reconstructed semantic vectors, including: Construct a code dependency graph to be repaired. The code dependency graph includes several nodes, which are used to represent the statement-level fused semantic representation of code fragments, or the function-level fused semantic representation of code fragments. Based on the graph attention mechanism, the attention coefficients between nodes in the code dependency graph are calculated, and the weights of long-distance cross-file dependencies between nodes are adjusted according to the attention coefficients. Based on the code dependency graph with corrected weights, the cross-file dependencies between code segments are reconstructed, and the reconstructed cross-file dependencies are fused with the statement-level fused semantic representation and the function-level fused semantic representation to generate a reconstructed semantic vector.

4. The method according to claim 1, characterized in that, The reconstructed semantic vector is matched with historical defect feature vectors in the defect pattern reinforcement knowledge base in multiple rounds, including: The code structure features in the reconstructed semantic vector are matched with the code structure features in the historical defect feature vector to obtain the structure matching score of the first round of matching; Align and match the data flow dependency features in the reconstructed semantic vector with the abnormal data flow features in the historical defect feature vector to obtain the abnormal matching score of the second round of matching; The constraints in the reconstructed semantic vector are verified and matched with the constraints in the historical defect feature vector to obtain the constraint matching score of the third round of matching.

5. The method according to claim 1, characterized in that, Determining the location of defects in the reconstructed semantic vector based on the matching results includes: Determine whether the matching score for this round exceeds the dynamic threshold; If the matching score is greater than the dynamic threshold, the adversarial generative network is activated to perform feature decoding and location mapping on the reconstructed semantic vector and the matched historical defect feature vector to generate the defect location prompt vector for this round. The defect location prompt vector includes defect location information and defect type identifier. If the matching score is less than or equal to the dynamic threshold, it is determined that there is no suspected defect in the current code segment, and no defect location hint vector is generated for this round.

6. The method according to claim 1, characterized in that, The method further includes: Output the defect location hint vector to the development end to obtain verification feedback; If the verification feedback is a false alarm of the defect location prompt vector, extract the semantic fingerprint and control flow features of the false alarm code fragment, and update the negative sample filter of the defect pattern reinforcement knowledge base; If the verification feedback is a missed defect location hint vector, return to the step of performing hierarchical abstraction on the cross-file code fragment to generate a set of context fragments carrying hierarchical tags, trace back the information loss nodes in the hierarchical abstraction process, and expand the dependency capture range of the dynamic code slice.

7. A software testing defect location device, characterized in that, The device includes: The code snippet acquisition module is used to acquire the source code and test failure cases of the software under test, and extract cross-file code snippets related to defects in the source code of the software under test according to the execution path of the test failure cases. The hierarchical abstraction module is used to perform hierarchical abstraction on the cross-file code fragments and generate a set of context fragments carrying hierarchical tags; The multi-granularity semantic coding module is used to perform lexical symbol embedding on the context fragment set at the lexical level to obtain the lexical embedding vector of each statement, fuse the structural information of the program control flow graph with the lexical embedding vector at the statement level to obtain the statement-level fused semantic representation, and fuse the cross-file call chain features with the statement-level fused semantic representation at the function level to obtain the function-level fused semantic representation. The semantic reconstruction module is used to reconstruct cross-file dependencies between code segments based on the statement-level fused semantic representation and the function-level fused semantic representation, using a graph attention mechanism, and to generate reconstructed semantic vectors; The defect localization module is used to perform multiple rounds of matching between the reconstructed semantic vector and the historical defect feature vector in the defect pattern reinforcement knowledge base, and determine the defect localization in the reconstructed semantic vector based on the matching results.

8. An electronic device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the software testing defect location method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the software testing defect location method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to perform the software testing defect location method according to any one of claims 1 to 6.

Images