Minimum test case generation method, device, equipment, medium and program product

Abstract

The application provides a minimum test case generation method, device, equipment, medium and program product, relates to the network fault diagnosis technical field, and is used for improving the accuracy and efficiency of root cause positioning. The specific technical scheme is: based on the track data of the failed test case, at least two candidate root cause variables in the failed test case are determined, and the at least two candidate root cause variables are key variables in the failed test case that affect the occurrence of the fault; based on the data types of the at least two candidate root cause variables, a plurality of intervention test cases are generated; the plurality of intervention test cases are executed to obtain intervention test results of each intervention test case, the intervention test results are analyzed, and a fault causal relationship of the failed test case is determined; and based on the fault causal relationship, a minimum test case is generated. The application is applied to the scene of fault root cause diagnosis.

Description

Technical Field

[0001] This application relates to the field of network fault diagnosis technology, and in particular to a method, apparatus, device, medium and program product for generating minimal test cases. Background Technology

[0002] The increasing complexity of software systems places higher demands on the efficiency and accuracy of software testing. During testing, when failed test cases occur, the key to improving defect localization and remediation efficiency lies in quickly and automatically extracting the minimal test case that can deterministically and simply trigger the same fault. This is also an important development direction in this field.

[0003] To meet this need, existing technologies offer various methods for automating the simplification of failed test cases. Among them, Coverage-Guided Pruning (CGP) is a commonly used method. This method typically performs an iterative pruning process based on the original failed test cases. Its main process is as follows: In each iteration, it attempts to remove some inputs or operation steps from the test case, then executes the pruned test case and monitors its code coverage (such as statement coverage, path coverage, etc.). By comparing whether the code coverage changes before and after pruning, it is determined whether the removed part is redundant. If the coverage remains unchanged, it is considered that the removed part does not affect the basic execution flow required to trigger a failure and can be safely deleted; if the coverage decreases, it may mean that a critical operation has been removed and needs to be restored. This iterative process gradually yields a smaller test case while maintaining a specific code coverage.

[0004] However, since code coverage primarily reflects the traversal of program code by test execution, and many types of software failures may occur unrelated to the execution path, simply covering the same code paths does not guarantee that the failure will be reproduced. This results in low accuracy and efficiency in root cause localization. Summary of the Invention

[0005] This application provides a method, system, and storage medium for minimizing the generation of root cause test cases based on causal inference, which can improve the accuracy and efficiency of root cause localization.

[0006] In a first aspect, embodiments of this application provide a method for determining a minimum causal link. The method includes: determining at least two candidate root variables in the failed test cases based on trajectory data of the failed test cases, wherein the at least two candidate root variables are key variables affecting the occurrence of the failure in the failed test cases; generating multiple intervention test cases based on the data types of the at least two candidate root variables; executing the multiple intervention test cases to obtain the intervention test results of each intervention test case; analyzing the intervention test results to determine the causal relationship of the failure in the failed test cases; and generating a minimum test case based on the causal relationship of the failure.

[0007] The technical solution provided in this application offers at least the following beneficial effects: In this solution, for failed test cases, key variables affecting the occurrence of the fault are automatically identified through trajectory data. Then, based on these variables, multiple intervention test cases are generated and executed to verify the causal relationship, thereby determining the fault causal relationship that can directly reveal the root cause of the defect. Finally, a minimal test case is generated based on this fault causal relationship. Therefore, it can effectively eliminate the interference of irrelevant variables, directly locate the root cause of the fault, and thus improve the accuracy and efficiency of root cause localization.

[0008] One possible implementation involves identifying at least two candidate root causes in the failed test cases based on their trajectory data. This includes: extracting input variables and key state variables from the trajectory data and constructing a time-series dependency between the input variables and key state variables; constructing a causal graph based on the time-series dependency, whereby the causal graph represents the causal relationship between the input variables and key state variables in the failed test cases and the root cause variables of the failed test cases; and traversing the causal graph to identify at least two candidate root causes.

[0009] Another possible implementation, as described above, involves traversing the causal graph to determine at least two candidate root variables. This includes: traversing the causal graph to determine N variables, where N variables are variables in the causal graph that can influence the occurrence of the fault through directed paths, and N is an integer greater than 1; calculating the priority score of each of the N variables based on the causal strength and intervention cost; and selecting at least two candidate root variables from the N variables based on the priority score of each variable.

[0010] Another possible implementation involves generating multiple intervention test cases based on the data types of at least two candidate root dependent variables, including: determining the intervention type for each candidate root dependent variable according to the data type of each candidate root dependent variable among the at least two candidate root dependent variables; generating a set of intervention values ​​for each candidate root dependent variable according to the intervention type of each candidate root dependent variable; and generating multiple intervention test cases based on the set of intervention values ​​corresponding to each candidate root dependent variable.

[0011] Another possible implementation, based on the fault causal relationship, generates the minimum test case, which includes: constructing a set of causal links based on the fault causal relationship; taking the causal link with the highest score in the causal link set as the minimum causal link of the failed test case; and generating the minimum test case based on the minimum causal link.

[0012] Another possible implementation, which uses the highest-scoring causal link in the causal link set as the minimum causal link for a failed test case, includes: pruning the highest-scoring causal link in the causal link set and using the pruned causal link as the minimum causal link for a failed test case.

[0013] Another possible implementation involves generating minimum test cases based on the minimum causal link, which includes: generating counterfactual test cases for each link in the minimum causal link, and comparing the actual results of the counterfactual test cases for each link with the expected results; if the actual results are inconsistent with the expected results, reducing the confidence in the causal relationship of each link, and re-evaluating the minimum causal link of the failed test cases; and generating minimum test cases based on the minimum causal link of the re-evaluated failed test cases.

[0014] Secondly, embodiments of this application provide a minimal test case generation apparatus, comprising: a determination module, a generation module, and an execution module. The determination module is used to determine at least two candidate root causes in the failed test cases based on trajectory data, wherein the at least two candidate root causes are key variables affecting the occurrence of the failure in the failed test cases. The generation module is used to generate multiple intervention test cases based on the data type of the at least two candidate root causes determined by the determination module. The execution module is used to execute the multiple intervention test cases generated by the generation module to obtain the intervention test result of each intervention test case. The determination module is also used to analyze the intervention test results obtained by the execution module to determine the causal relationship of the failed test cases. The generation module is also used to generate minimal test cases based on the causal relationship determined by the determination module.

[0015] One possible implementation is that the aforementioned determining module is specifically used to extract input variables and key state variables from trajectory data, and construct time series dependencies between input variables and key state variables; and based on the time series dependencies, construct a causal graph, which is used to represent the causal relationship between the input variables and key state variables in failed test cases and the root cause variables of failed test cases; and traverse the causal graph constructed by the execution module to determine at least two candidate root cause variables from the causal graph results.

[0016] Another possible implementation, the aforementioned determination module, is specifically used to traverse the causal graph, determine N variables from the causal graph, where N variables are variables in the causal graph that can influence the occurrence of the fault through a directed path, and N is an integer greater than 1; based on the causal strength and intervention cost of the N variables, calculate the priority score of each of the N variables; based on the priority score of each variable, select at least two candidate root variables from the N variables.

[0017] Another possible implementation is that the above-mentioned generation module is specifically used to determine the intervention type of each candidate root dependent variable based on the data type of each candidate root dependent variable among at least two candidate root dependent variables; generate a set of intervention values ​​for each candidate root dependent variable based on the intervention type of each candidate root dependent variable; and generate multiple intervention test cases based on the set of intervention values ​​corresponding to each candidate root dependent variable.

[0018] Another possible implementation is that the above-mentioned generation module is specifically used to construct a set of causal links based on the causal relationship of the failure; take the causal link with the highest score in the set of causal links as the minimum causal link of the failed test case; and generate the minimum test case based on the minimum causal link.

[0019] Another possible implementation is that the above-mentioned generation module is specifically used to prune the causal link with the highest score in the causal link set, and use the causal link after the pruning operation as the minimum causal link of the failed test cases.

[0020] Another possible implementation is that the above-mentioned generation module is specifically used to generate counterfactual test cases corresponding to each link in the minimum causal link, and compare the actual results of the counterfactual test cases corresponding to each link with the expected results; if the actual results are inconsistent with the expected results, the confidence in the causal relationship of each link is reduced, and the minimum causal link of the failed test cases is re-evaluated; based on the minimum causal link of the failed test cases obtained by re-evaluation, the minimum test cases are generated.

[0021] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory stores a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the first aspect described above.

[0022] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0023] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0024] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0025] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0026] Figure 1 A schematic diagram of the network architecture for an application of a minimal test case generation method provided in this application embodiment;

[0027] Figure 2 A flowchart illustrating a minimum test case generation method provided in an embodiment of this application;

[0028] Figure 3 A flowchart illustrating another minimal test case generation method provided in this application embodiment;

[0029] Figure 4 A flowchart illustrating the implementation process of a minimum test case generation method provided in this application embodiment;

[0030] Figure 5 A flowchart illustrating yet another minimal test case generation method provided in this application embodiment;

[0031] Figure 6 A flowchart illustrating yet another minimal test case generation method provided in this application embodiment;

[0032] Figure 7 A flowchart illustrating yet another minimal test case generation method provided in this application embodiment;

[0033] Figure 8 A flowchart illustrating yet another minimal test case generation method provided in this application embodiment;

[0034] Figure 9 A flowchart illustrating yet another minimal test case generation method provided in this application embodiment;

[0035] Figure 10 A flowchart illustrating the implementation process of another minimal test case generation method provided in this application embodiment;

[0036] Figure 11 A flowchart illustrating the implementation process of yet another minimal test case generation method provided in this application embodiment;

[0037] Figure 12A flowchart illustrating the implementation process of yet another minimal test case generation method provided in this application embodiment;

[0038] Figure 13 A flowchart illustrating the implementation process of yet another minimal test case generation method provided in this application embodiment;

[0039] Figure 14 A schematic diagram of a minimum test case generation device provided in an embodiment of this application;

[0040] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0042] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0043] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0044] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0045] The present application provides a method, apparatus, device, medium, and program product for generating minimal test cases, which can be applied to scenarios of root cause diagnosis of faults.

[0046] Test case failures are a common occurrence in software development and testing. Traditional testing requires extensive manual backtracking and root cause analysis after a defect is discovered. To efficiently locate defects, developers need to simplify the original, complex test cases into the minimum reproducible test cases.

[0047] Currently, the following three mainstream methods are commonly used to streamline test cases:

[0048] (1) Incremental debugging (Delta Debugging, DD): Iteratively deletes test elements through a divide-and-conquer strategy, retaining the smallest subset that can still trigger the fault. However, it only relies on the binary feedback of "whether the fault is reproduced" and cannot distinguish between causal factors and accompanying operations, and is prone to retaining redundant steps.

[0049] Causal Factor (CF): The necessary operation or input that directly leads to the occurrence of a failure.

[0050] Accompanying / Incidental Operations (AO / IO): Operations that are not directly causally related to the fault but are retained because they appear in the original use case. These accompanying operations do not participate in triggering the bug, and the bug will still exist after deletion. However, Delta Debugging may not be able to delete them.

[0051] (2) Reduction tools based on Abstract Syntax Tree (AST) (such as C and C++ Program Reducer (C-Reduce) and Perses): suitable for compiler testing, but ineffective for semantically unrelated operations.

[0052] (3) Coverage-guided pruning: It depends on changes in code coverage, but high coverage is not the same as root cause and cannot handle environment-sensitive faults.

[0053] It is ineffective for non-coverage-sensitive defects. Some bugs are unrelated to control flow coverage, such as numerical boundary errors (e.g., x = 2^31 causing integer overflow) and timing / concurrency bugs (race conditions, deadlocks). These defects may be triggered by only specific input values ​​under the same coverage path, and coverage-guided pruning ignores the importance of the "value".

[0054] However, the above methods have at least the following problems: (1) pruning efficiency is low, requiring a large number of replays; (2) generated use cases still contain unnecessary operations; and (3) there is a lack of interpretability for "why it failed". In summary, this results in low accuracy and efficiency of root cause localization.

[0055] To address the aforementioned technical problems, this application provides a method, apparatus, device, medium, and program product for generating minimal test cases. In this solution, for failed test cases, key variables affecting the occurrence of the fault are automatically identified through trajectory data. Then, based on these variables, multiple intervention test cases are generated and executed to verify causal relationships, thereby determining the fault causal relationship that can directly reveal the root cause of the defect. Finally, minimal test cases are generated based on this fault causal relationship. Therefore, it can effectively eliminate the interference of irrelevant variables, directly locate the root cause of the fault, and thus improve the accuracy and efficiency of root cause localization.

[0056] The following description, in conjunction with the accompanying drawings, details the minimum test case generation method, apparatus, device, medium, and program product provided in the embodiments of this application.

[0057] Figure 1 The network architecture of a minimal test case generation method provided in this application embodiment is illustrated. For example... Figure 1 As shown, the network architecture includes a minimum test case generation device 101 and a terminal device 102. The minimum test case generation device 101 and the terminal device 102 are interconnected.

[0058] In some embodiments, the minimum test case generation device 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster consisting of multiple servers. It should be noted that the specific device form of the minimum test case generation device 101 is not limited in the embodiments of this application. Figure 1 The example shown is a single server using the minimum test case generation device 101.

[0059] In some embodiments, the terminal device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, with terminal device 102 as an example.

[0060] In some embodiments, the terminal device 102 sends failed test cases to the minimum test case generation device 101. The minimum test case generation device 101 receives the failed test cases sent by the terminal device 102, and then, based on the trajectory data of the failed test cases, the minimum test case generation device 101 determines at least two candidate root causes in the failed test cases; based on the data types of the at least two candidate root causes, it generates multiple intervention test cases; it executes the multiple intervention test cases to obtain the intervention test results of each intervention test case, analyzes the intervention test results to determine the fault causal relationship of the failed test cases, and generates minimum test cases based on the fault causal relationship.

[0061] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0062] See Figure 2 This is a flowchart illustrating a minimal test case generation method provided in an embodiment of this application. Figure 2 As shown, the minimum test case generation method provided in this application embodiment can be implemented by the above-mentioned minimum test case generation device, specifically including the following steps 201 to 204.

[0063] Step 201: The minimum test case generation device determines at least two candidate root variables in the failed test cases based on the trajectory data of the failed test cases.

[0064] In some embodiments, the above-mentioned at least two candidate root causes are key variables that affect the occurrence of failure in failed test cases.

[0065] In some embodiments, the aforementioned failed test cases specifically refer to test cases where the execution result is inconsistent with the expected result.

[0066] In some embodiments, the trajectory data mentioned above includes at least one of the following: input variables, operation sequences, key state variables, fault results, variable assignments, method calls, and condition judgment results.

[0067] For example, the aforementioned key state variables can also be understood as state transition information, program state information, or state sequences.

[0068] For example, the above failure results include exception throwing information.

[0069] In some embodiments, the minimum test case generation apparatus can perform fine-grained instrumentation on failed test cases to obtain the aforementioned trajectory data.

[0070] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, step 201 above can be implemented through steps 301 to 303 as follows.

[0071] Step 301: The minimum test case generation device extracts input variables and key state variables from the trajectory data and constructs the time series dependency relationship between the input variables and key state variables.

[0072] In some embodiments, constructing the aforementioned Temporal Dependency Modeling (TDM) refers to identifying the causal or statistical dependency structure between variables in the time dimension from data observed in chronological order.

[0073] For example: Given a set of multidimensional time series data: X(t)={x1(t),x2(t),…,xn(t)},t=1,2,…,T.

[0074] Here, each xi(t) represents the observed value of the i-th variable at time t. The goal is to construct a directed graph G=(V,E), where nodes V={x1,…,xn} and edges (xj→xi)∈E indicate that xj has a significant influence on the current state of xi in the past (causal or predictive dependence).

[0075] Step 302: The minimum test case generation device constructs a cause-effect graph based on time series dependencies.

[0076] In some embodiments, the cause-effect graph described above is used to characterize the causal relationship between input variables and key state variables in failed test cases and root cause variables of failed test cases.

[0077] In some embodiments, the aforementioned minimum test case generation device may construct a causal graph based on time-series dependencies using a causal discovery algorithm.

[0078] In some embodiments, the above cause-effect graph is a local cause-effect graph with "failure occurrence" as the result node.

[0079] In some embodiments, the minimum test case generation device can analyze the temporal dependencies between variables based on time-series dependencies using the Granger Causality Test (GCT). For example, if the historical value of variable A can significantly predict the current value of variable B (p-value less than 0.05), then variable A is considered to have a temporal causal or predictive dependency on variable B, and its influence strength, lag order, and other statistical indicators are recorded. Then, based on this, multiple causal discovery algorithms (e.g., the Peter-Clark (PC) algorithm for handling latent variables (Fast Causal Inference, FCI), and the algorithm assuming linear non-Gaussian acyclic model (LiNGAM)) are invoked to learn the causal structure between variables. The results of different algorithms are then fused through an ensemble strategy (e.g., majority voting mechanism) to form the aforementioned causal graph.

[0080] In some embodiments, such as Figure 4 As shown, constructing the aforementioned causal graph using causal discovery algorithms can include the following steps: 1. Preparing causal discovery data; 2. Using multiple algorithms such as PC, FCI, and LiNGAM for causal discovery, each algorithm may produce different causal graph representations; 3. Ensemble learning to merge the results of multiple algorithms: comparing and integrating the causal graphs generated by different algorithms. A voting mechanism and weighted consensus algorithm are used to determine causal relationships; 4. Post-processing using domain knowledge: applying domain expert knowledge to conduct a preliminary review of the generated causal graph, checking for any obvious irrationalities or relationships that do not conform to reality. Adjusting inaccurate parts of the causal graph to ensure its logic and practicality; 5. Refining the causal graph using domain knowledge: further combining domain expertise and technical background to deeply analyze each node and its connections in the causal graph, optimizing causal paths.

[0081] Specifically, the aforementioned time-series dependency data is first organized into a standardized multidimensional variable matrix, serving as input for causal discovery. Then, multiple classic causal discovery algorithms are invoked in parallel, each outputting a causal graph. Next, an ensemble learning strategy is employed to fuse these results: for each possible causal edge, its frequency in each algorithm is counted, retaining only edges receiving more than half the votes as the consensus structure, and calculating their average causal weight. Finally, domain knowledge is introduced to post-process the consensus graph: edges violating program semantics are removed (e.g., reversed read / write order, mismatched scope, etc.); edges missing due to data sparsity but consistent with program logic are added (e.g., explicit assignment dependencies); and the confidence of edges is adjusted to better reflect the actual behavior of the software system. This process ensures that the causal graph possesses both data-driven objectivity and conforms to the inherent structural constraints of the program.

[0082] In some embodiments, the minimum test case generation device can enhance the causal graph by combining it with static program structure information. Specifically, it can add semantic context to each node and edge to improve the interpretability and program relevance of the causal graph.

[0083] For example, the static structure information of the program mentioned above may include at least one of the following: variable scope, data type, code location, etc.

[0084] Step 303: The minimum test case generation device traverses the cause-effect graph and determines at least two candidate root dependent variables from the cause-effect graph.

[0085] Thus, since the minimum test case generation device can construct a cause-effect graph based on actual trajectory data, and then identify at least two key variables affecting the occurrence of the fault from the cause-effect graph, the multiple intervention test cases generated based on these variables can reflect the real fault situation, thereby improving the accuracy of root cause localization.

[0086] In some embodiments, combined with Figure 3 ,like Figure 5 As shown, step 303 above can be implemented through steps 303a to 303c.

[0087] Step 303a: The minimum test case generation device traverses the cause-effect graph and determines N variables from the cause-effect graph.

[0088] In some embodiments, the N variables are variables in the causal graph that can influence the occurrence of a fault through a directed path, where N is an integer greater than 1.

[0089] Step 303b: The minimum test case generation device calculates the priority score of each of the N variables based on the causal strength and intervention cost of the N variables.

[0090] For example, the causal strength mentioned above may include at least one of the following: path weight, effect size.

[0091] For example, the intervention costs mentioned above may include at least one of the following: difficulty of modification, testing costs.

[0092] Step 303c: The minimum test case generation device selects at least two candidate root variables from N variables based on the priority score of each variable.

[0093] Understandably, the minimum test case generation device can take the constructed cause-effect graph as input and identify possible candidate root variables around the defect manifestation.

[0094] In some embodiments, the minimum test case generation device can sort N variables based on the priority score of each variable, and then select the top-ranked variables as at least two candidate root causes, that is, select the high-priority variables among the N variables as candidate root causes.

[0095] In some embodiments, the minimum test case generation device may select from N variables a priority score greater than or equal to a preset threshold as at least two candidate root cause variables.

[0096] Thus, since the minimum test case generation device can construct a cause-effect graph based on actual trajectory data, and then identify at least two key variables affecting the occurrence of the fault from the cause-effect graph, the multiple intervention test cases generated based on these variables can reflect the real fault situation, thereby improving the accuracy of root cause localization.

[0097] Step 202: The minimum test case generation device generates multiple intervention test cases based on the data types of at least two candidate root dependent variables.

[0098] In some embodiments, combined with Figure 2 ,like Figure 6 As shown, step 202 above can be implemented through steps 401 to 403 as follows.

[0099] Step 401: The minimum test case generation device determines the intervention type for each candidate root variable based on the data type of each candidate root variable among at least two candidate root variables.

[0100] In some embodiments, the above data types may include any of the following: Boolean, numeric, or string.

[0101] In some embodiments, the above-mentioned intervention types may include any of the following: binary switching, boundary value perturbation, and null value injection.

[0102] Step 402: The minimum test case generation device generates a set of intervention values ​​for each candidate root variable based on the intervention type of each candidate root variable.

[0103] In some embodiments, the intervention value may include at least one of the following: historical extreme value expansion, median value, or null value.

[0104] Step 403: The minimum test case generation device generates multiple intervention test cases based on a set of intervention values ​​corresponding to each candidate root variable.

[0105] In some embodiments, the minimum test case generation device can construct control group and experimental group conditions based on a set of intervention values ​​corresponding to each candidate root dependent variable, predict the impact of the intervention on the fault, and then automatically synthesize multiple executable intervention test cases.

[0106] For example, the above intervention test cases include test logic, expected results, and verification assertions.

[0107] In some embodiments, the control group uses the actual value of each candidate root variable at the time of the fault, while the experimental group uses the intervention value of each candidate root variable.

[0108] It should be noted that for a detailed description of the conditions for constructing the control group and experimental group, please refer to the relevant descriptions in the related technologies, which will not be repeated here.

[0109] Thus, since the minimum test case generation device is based on a cause-effect graph, after identifying at least two key variables that affect the occurrence of a fault, it can simulate an "intervention" operation to generate new test cases to verify the causal relationship. Therefore, it can accurately determine the causal relationship of a fault that can directly reveal the root cause of the defect, thereby improving the accuracy of root cause localization.

[0110] Step 203: The minimum test case generation device executes multiple intervention test cases, obtains the intervention test results for each intervention test case, analyzes the intervention test results, and determines the causal relationship of the failure test cases.

[0111] In some embodiments, the minimum test case generation device can first analyze the execution results of all intervention test cases, and by comparing the failure occurrence of the experimental group (intervention group) and the control group, calculate the causal effect size (such as relative rate of change) and confidence level of each intervention variable, thereby confirming which causal relationships are verified to be valid, i.e., the failure causal relationships mentioned above.

[0112] For example, a series of intervention experiments (such as do(X = x) operations) are performed, the response changes of the target variable Y are observed, and statistical tests or causal effect estimations (such as average treatment effect (ATE) and conditional average treatment effect (CATE)) are used to determine whether there is a significant causal effect and whether the causal direction is reliable, and a set of verified causal edges (such as A→B, B→C) are output.

[0113] In some embodiments, the minimum test case generation device may comprehensively consider causal strength, experimental cost, and information gain (i.e., independence between experiments), and employ a multi-objective optimization algorithm (e.g., Non-dominated Sorting Genetic Algorithm II, NSGA-II) to sort multiple intervention test cases, and then execute multiple intervention test cases in the sorted order to maximize root cause identification efficiency with limited resources.

[0114] Step 204: The minimum test case generation device generates minimum test cases based on the fault causal relationship.

[0115] In some embodiments, combined with Figure 2 ,like Figure 7 As shown, step 204 above can be implemented through steps 501 to 503 as follows.

[0116] Step 501: The minimum test case generation device constructs a set of causal links based on the fault causal relationship.

[0117] In some embodiments, the above-mentioned causal relationship of the failure includes: the identified root cause and the failure manifestation.

[0118] In some embodiments, the above set of causal links includes at least one causal link.

[0119] In some embodiments, the minimum test case generation device may use a graph traversal algorithm to find all feasible causal paths in the aforementioned causal graph based on the fault causal relationship, so as to form the aforementioned causal link set.

[0120] For example, the graph traversal algorithm described above can be either depth-first search (DFS) or breadth-first search (BFS).

[0121] It is understandable that the minimum test case generation device can start from the confirmed root cause and end with the fault manifestation, and use a graph traversal algorithm to find all feasible causal paths in the above causal graph to form a set of causal links.

[0122] For example, if the causal relationship of the fault includes: root cause R and fault F, then all paths from R to F are extracted; for example, an original chain can be: R→X1→X2→…→Xk→F.

[0123] Step 502: The minimum test case generation device takes the causal link with the highest score in the causal link set as the minimum causal link for the failed test case.

[0124] In some embodiments, the aforementioned minimum causal link can be understood as: a causal link that retains the fewest nodes / edges while still being able to explain the causal relationship of the failure.

[0125] For example, when the causal relationship of a fault includes root cause R and fault F, the minimum causal link is the causal link that retains the fewest nodes / edges and can still explain the causal transmission from R to F.

[0126] In some embodiments, the minimum test case generation device may score each causal link in the causal link set and then use the causal link with the highest score as the minimum causal link for the failed test case.

[0127] In some embodiments, the minimum test case generation apparatus may score each causal link based on at least one of the following: path length, causal strength, number of mediators, and interpretability.

[0128] It is understandable that the shorter the consideration path length of each causal link, the higher the corresponding score; the higher the causal strength, the higher the corresponding score; and the fewer the mediating variables, the higher the corresponding score.

[0129] For example, the minimum test case generation device can comprehensively consider factors such as the path length, causal strength, number of mediating variables, and interpretability of each causal link to score each causal link.

[0130] In some embodiments, after obtaining the minimum causal link, the minimum test case generation device can perform sufficiency verification and necessity verification on the minimum causal link, and then output the minimum causal link as the core basis for root cause explanation after the verification is passed.

[0131] For example, the above sufficiency verification can be understood as "If all variables in the minimum causal link are set as intervention values, will it necessarily lead to the reproduction of the fault?".

[0132] For example, the above necessity verification can be understood as "If any link in the least causal link is blocked, will the fault no longer occur?" If so, then that link is a necessary link, which can be verified through counterfactual simulation experiments.

[0133] For example, blocking any link in the least causal link can restore the root dependent variable to its normal value, i.e., do (M = normal).

[0134] In some embodiments, combined with Figure 7 ,like Figure 8 As shown, step 502 above can be implemented through step 502a as follows.

[0135] Step 502a: The minimum test case generation device performs a pruning operation on the causal link with the highest score in the causal link set, and uses the causal link after the pruning operation as the minimum causal link of the failed test case.

[0136] In some embodiments, the causal link can still maintain causal effect after pruning.

[0137] Specifically, for the causal link with the highest score, the minimum test case generation device can try to remove the mediator variable in the causal link one by one and verify whether the remaining link can still maintain the causal effect; if the effect disappears, the mediator variable is retained; if the effect does not disappear, the mediator variable is removed.

[0138] It is understandable that the minimum test case generation device can use pruning to remove intermediate nodes one by one, test whether the causal effect disappears, and only retain the nodes that contribute significantly to the causal effect.

[0139] For example, when the causal relationship of a fault includes root cause R and fault F, the shortest directed path from R to F can be found in the causal graph, and one or more simplified causal chains can be output, such as R→M→F.

[0140] Thus, after determining the causal link with the highest score, further pruning operations can be performed on this causal link, so that a very simple test case sequence with causal relationship can be output. Therefore, it can directly reveal the causal relationship of the root cause of the defect, thereby improving the accuracy of root cause location.

[0141] Step 503: The minimum test case generation device generates minimum test cases based on the minimum causal link.

[0142] In some embodiments, the minimum test case generation device can assign values ​​to the condition variables in the minimum causal link based on the minimum causal link and in conjunction with the constraint solver, and filter out the test set that satisfies the causal relationship and has the fewest minimum test cases.

[0143] In some embodiments, the minimal test case generation apparatus may first lock the set of dependent variables in the minimal causal chain and treat them as constraints that must be covered; then perform abstraction or default value filling on irrelevant variables outside the minimal causal chain, retaining only the necessary input combinations that can trigger the causal relationship; next, eliminate redundant preconditions and intermediate states, trim unnecessary steps, and ensure that the test path corresponds one-to-one with the minimal causal chain; finally, verify whether the test case uniquely activates the causal chain and that no further elements can be removed without destroying the causal validity, thereby forming a minimal test case that is both concise and sufficient.

[0144] It should be noted that for a detailed description of the minimum test case generation device based on the minimum causal link to generate minimum test cases, please refer to the relevant descriptions of generating minimum test cases based on the minimum causal link in related technologies, which will not be repeated here.

[0145] Thus, since the minimum test case generation device can identify all feasible causal links from the cause-effect graph after determining the causal relationship of the failure, score these causal links, and finally take the causal link with the highest score as the minimum causal link of the failed test case, the reliability of determining the minimum causal link is guaranteed.

[0146] In some embodiments, combined with Figure 7 ,like Figure 9 As shown, step 503 above can be implemented through steps 503a to 503c.

[0147] Step 503a: The minimum test case generation device generates counterfactual test cases corresponding to each link in the minimum causal link, and compares the actual results of the counterfactual test cases corresponding to each link with the expected results.

[0148] In some embodiments, for each link in the minimal causal chain, the minimal test case generation device may first construct counterfactual conditions, then predict counterfactual results, and finally generate counterfactual test cases corresponding to each link.

[0149] In some embodiments, the counterfactual condition described above may be to prevent abnormal assignment of candidate root variables or to reset candidate root variables to valid values.

[0150] In some embodiments, the minimal test case generation device constructs counterfactual conditions for each link in the minimal causal chain, specifically including:

[0151] Objective: Define a hypothetical scenario that is "contrary to the facts".

[0152] Input: 1) Actual observed execution traces (e.g., variable sequences, logs, state snapshots);

[0153] 2) Identified candidate root causes (e.g., a function call, abnormal input, configuration value).

[0154] Action: Set intervention: do(cause = normal_value); For example: change incorrect user input to a valid value; Another example: disable a faulty module.

[0155] Fixed background conditions: Infer noise terms or latent variables based on actual observations (in the Structural Causal Model (SCM)).

[0156] Output: A formalized counterfactual condition, such as "If variable X is not assigned the value null at t=5...".

[0157] In some embodiments, the minimal test case generation apparatus may use a structural causal model (SCM) to perform counterfactual reasoning and execute counterfactual queries to obtain counterfactual results.

[0158] Specifically, the minimum test case generation device can perform three-step counterfactual reasoning based on SCM, which includes: backward reasoning, intervention, and prediction.

[0159] The above inference includes: using actual observation data to infer exogenous variables (U) or noise terms in the model.

[0160] The above interventions include: modifying the structural equation and applying do(cause = counterfactual_value).

[0161] The above predictions include: recalculating the values ​​of downstream variables in the modified model, including defect indicators (e.g., whether an exception is thrown, whether an assertion fails).

[0162] In some embodiments, the minimum test case generation apparatus can output the system behavior in a counterfactual world, particularly whether the defect still occurs, i.e., the counterfactual results described above.

[0163] In some embodiments, the minimal test case generation apparatus can transform counterfactual results into executable counterfactual test cases.

[0164] In some embodiments, the format (or form) of the above counterfactual test cases may be: if the [root cause event] does not occur, then the [defect phenomenon] may not occur.

[0165] For example: "If variable X is not assigned a value incorrectly, then the failure will not occur."

[0166] It is understandable that, for each link in the minimum causal chain, the minimum test case generator can generate counterfactual test cases that state "if {cause} did not occur, then the defect might not occur".

[0167] It's understandable that for each link in the minimum causal chain, a counterfactual condition can be defined, and a causal model can be used to predict whether the failure will still occur under this assumption. Then, corresponding counterfactual test cases are automatically generated to simulate the assumed scenario and perform verification. Finally, after execution, the actual results are compared with the expected results.

[0168] Step 503b: If the actual result is inconsistent with the expected result, the minimum test case generation device reduces the confidence in the causal relationship of each link and re-evaluates the minimum causal link of the failed test cases.

[0169] It is understandable that when the actual results are inconsistent with the expected results, i.e. when the counterfactual is falsified, the relevant causal beliefs can be reduced, and a process of re-evaluation and correction of the causal chain can be triggered.

[0170] In some embodiments, the minimal test case generation apparatus can remove unreliable links or introduce new variables to re-evaluate the minimal causal chain of failed test cases. This ensures the robustness of the final causal explanation.

[0171] In some embodiments, if the actual results are consistent with the expected results, the minimum test case generation apparatus can enhance confidence in the causal relationship of each step.

[0172] Step 503c: The minimum test case generation device generates minimum test cases based on the minimum causal link of the failed test cases obtained from the re-evaluation.

[0173] In some embodiments, after obtaining the minimum causal link, the minimum test case generation device can generate a root cause report containing the minimum causal link, and then generate minimum test cases based on the root cause report.

[0174] In some embodiments, the above root cause report is generated, that is, it outputs a human-readable causal explanation.

[0175] For example, the minimum test case could be "crash due to invalid email format".

[0176] Thus, once the minimum causal link is initially determined, the minimum test case generation device can perform counterfactual reasoning to verify the causal relationship. If the verification fails, the minimum test case can be regenerated, thereby ensuring the reliability of the minimum causal link generation and improving the accuracy of root cause localization.

[0177] The minimum test case generation method provided in this application automatically identifies key variables affecting the occurrence of failures through trajectory data for failed test cases. Then, based on these variables, multiple intervention test cases are generated and executed to verify causal relationships, determining the causal relationship that directly reveals the root cause of the defect. Finally, minimum test cases are generated based on this causal relationship. Therefore, it can effectively eliminate the interference of irrelevant variables, directly locate the root cause of the failure, and thus improve the accuracy and efficiency of root cause localization.

[0178] The following describes the minimum test case generation method of this application through specific embodiments.

[0179] like Figure 10 As shown, the implementation process of the minimum test case generation method provided in this application embodiment includes the following S1 to S7:

[0180] S1. Execution trajectory recording: Instrumenting failed test cases and recording input variables, operation sequences, key state variables and failure results, i.e., the trajectory data mentioned above;

[0181] S2. Cause-Effect Graph Construction: Based on trajectory data, a local cause-effect graph is constructed with "fault occurrence" as the result node. The implementation flowchart of the cause-effect graph is shown in Figure 11. First, variables and state sequences are extracted from the trajectory data; then, time series dependencies are constructed; next, a cause-effect graph is constructed using a cause-effect discovery algorithm; finally, the association between the cause-effect graph and the program structure is enhanced.

[0182] Constructing time series dependencies refers to identifying the causal or statistical dependency structure between variables in the time dimension from data observed in chronological order.

[0183] Given a set of multidimensional time series data:

[0184] X(t)={x1(t),x2(t),…,xn(t)},t=1,2,…,T

[0185] Each xi(t) represents the observed value of the i-th variable at time t. The goal is to construct a directed graph G=(V,E), where nodes V={x1,…,xn} and edges (xj→xi)∈E indicate that xj has a significant influence on the current state of xi in the past (causal or predictive dependence).

[0186] Specific technical implementation:

[0187] First, fine-grained instrumentation is performed on failed test cases, recording key runtime information including variable assignments, method calls, condition judgment results, state transitions, and exception throwing. Then, the time-varying sequences of each variable and the program state sequences are extracted from this trajectory data.

[0188] Next, based on these time series, Granger causality tests are used to analyze the temporal dependencies between variables: if the historical value of variable A can significantly predict the current value of variable B (p value less than 0.05), then it is considered that A has a temporal causal or predictive dependency on B, and statistical indicators such as the strength of its influence and lag order are recorded.

[0189] Building upon this foundation, multiple causal discovery algorithms (such as PC, FCI, and LiNGAM) are invoked to learn the causal structure between variables. The results of these different algorithms are then fused using an ensemble strategy (such as majority voting) to form a preliminary causal graph. Finally, the causal graph is enhanced by incorporating static program structure information (such as variable scope, data type, and code location), adding semantic context to each node and edge to improve its interpretability and relevance to the program.

[0190] The relevant code is as follows:

[0191] Python

[0192] class CausalGraphBuilder:

[0193] def __init__(self):

[0194] self.instrumentation_agent = FineGrainedInstrumentation()

[0195] self.dependency_analyzer = DependencyAnalyzer()

[0196] self.causal_discovery = CausalDiscoveryAlgorithm()

[0197] def build_causal_graph(self, failing_test):

[0198] """Building a cause-effect graph for failed tests"""

[0199] # 1. Perform tests and collect detailed tracks

[0200] execution_trace = self.execute_with_fine_grained_instrumentation(failing_test)

[0201] # 2. Extracting Variables and State Sequences

[0202] variable_sequences = self.extract_variable_sequences(execution_trace)

[0203] state_sequences = self.extract_state_sequences(execution_trace)

[0204] # 3. Constructing Time Series Dependencies

[0205] temporal_dependencies = self.analyze_temporal_dependencies(

[0206] variable_sequences, state_sequences )

[0208] # 4. Constructing a causal graph using causal discovery algorithms

[0209] causal_graph = self.causal_discovery.learn_causal_structure(

[0210] temporal_dependencies, execution_trace )

[0212] # 5. Enhance the connection between cause-effect graphs and program structure

[0213] enhanced_graph = self.enhance_with_program_structure(

[0214] causal_graph, execution_trace )

[0216] return enhanced_graph

[0217] def execute_with_fine_grained_instrumentation(self, test_case):

[0218] "Perform testing using fine-grained instrumentation"

[0219] instrumentation_points = [

[0220] 'method_entry', 'method_exit', 'variable_assignment',

[0221] 'condition_evaluation', 'exception_throw','state_change'

[0223] trace_data = {

[0224] 'variable_assignments': [],

[0225] 'method_calls': [],

[0226] 'condition_outcomes': [],

[0227] 'state_transitions': [],

[0228] 'exception_events': [],

[0229] 'timing_data': []

[0230] }

[0231] # Bytecode instrumentation using ASM or Javassist

[0232] instrumented_code = self.instrumentation_agent.instrument(

[0233] test_case.target_method, instrumentation_points )

[0235] # Execute the instrumented code

[0236] execution_result = self.execute_instrumented_test(

[0237] instrumented_code, test_case.input )

[0239] return self.merge_trace_data(execution_result, trace_data)

[0240] ​def analyze_temporal_dependencies(self, variable_sequences, state_sequences):

[0241] "Analyzing time series dependencies"

[0242] dependencies = {}

[0243] # Using Granger causality test

[0244] for var_i in variable_sequences:

[0245] for var_j in variable_sequences:

[0246] if var_i != var_j:

[0247] granger_causality = self.granger_causality_test(

[0248] variable_sequences[var_i],

[0249] variable_sequences[var_j] )

[0251] if granger_causality.p_value < 0.05: # Significance level

[0252] dependencies[(var_i, var_j)] = {

[0253] 'strength': granger_causality.strength,

[0254] 'lag': granger_causality.lag,

[0255] 'p_value': granger_causality.p_value

[0256] }

[0257] return dependencies

[0258] def enhance_with_program_structure(self, causal_graph, execution_trace):

[0259] "Enhancing Cause-Effect Graphs with Program Structure Information"

[0260] enhanced_nodes = {}

[0261] for node in causal_graph.nodes:

[0262] # Add program context information

[0263] enhanced_node = {

[0264] 'variable_name': node,

[0265] 'program_location': self.find_program_location(node,execution_trace),

[0266] 'data_type': self.infer_data_type(node, execution_trace),

[0267] 'scope': self.determine_variable_scope(node,execution_trace),

[0268] 'mutability': self.assess_mutability(node, execution_trace),

[0269] 'causal_importance': self.estimate_causal_importance(node, causal_graph)

[0270] }

[0271] enhanced_nodes[node] = enhanced_node

[0272] # Relationship Types for Enhanced Edges

[0273] enhanced_edges = {}

[0274] for edge in causal_graph.edges:

[0275] source, target = edge

[0276] enhanced_edges[edge] = {

[0277] 'causal_strength': causal_graph.edges[edge]['weight'],

[0278] 'relationship_type': self.classify_relationship_type(

[0279] source, target, execution_trace

[0280] ),

[0281] 'mediation_paths': self.find_mediation_paths(edge,causal_graph),

[0282] 'interaction_effects': self.assess_interaction_effects(edge, causal_graph)

[0283] }

[0284] return CausalGraph(enhanced_nodes, enhanced_edges)

[0285] ```

[0286] S3. Intervention Experiment Generation and Execution: Intervention experiments are designed based on causal graphs to verify causal relationships. The generation of the intervention experiment sequence involves three steps: first, identifying candidate root dependent variables; second, designing intervention experiments; and third, optimizing the experimental sequence based on causal strength and experimental cost.

[0287] Specific technical implementation:

[0288] This method takes a pre-constructed causal graph as input and identifies potential candidate root cause variables based on the fault manifestation. Specifically, it iterates through all variables in the causal graph that can affect the fault through directed paths (i.e., the N variables mentioned above), evaluates their causal strength (such as path weight or effect size) and intervention costs (such as modification difficulty and testing overhead), calculates priority scores based on these scores, and selects high-priority variables as candidate root cause variables.

[0289] For each candidate root dependent variable, design a specific intervention experiment:

[0290] 1) Determine the intervention type (such as binary switching, boundary value perturbation, null value injection, etc.) based on the data type of the variable (Boolean, null, string, etc.);

[0291] 2) Generate a set of representative intervention values ​​(e.g., historical extreme values, median values, null values, etc.);

[0292] 3) Construct control and experimental group conditions and predict the impact of intervention on the fault;

[0293] 4) Automatically synthesize executable intervention test cases, including test logic, expected results and verification assertions.

[0294] Subsequently, taking into account causal strength, experimental cost, and information gain (i.e., independence between experiments), a multi-objective optimization algorithm (such as the NSGA-II genetic algorithm) was used to sort the intervention experiment sequences in order to maximize the efficiency of root cause identification with limited resources.

[0295] The relevant code is as follows:

[0296] Python

[0297] class InterventionExperimentGenerator:

[0298] def __init__(self, causal_graph):

[0299] self.causal_graph = causal_graph

[0300] self.design_of_experiments = DesignOfExperiments()

[0301] self.constraint_solver = ConstraintSolver()

[0302] def generate_intervention_experiments(self, defect_manifestation,max_experiments=20):

[0303] """Generate intervention experiment sequences"""

[0304] # 1. Identify candidate root dependent variables

[0305] candidate_causes = self.identify_candidate_causes(defect_manifestation)

[0306] # 2. Designing intervention experiments

[0307] experiments = []

[0308] for candidate in candidate_causes[:max_experiments]:

[0309] experiment = self.design_single_intervention(candidate,defect_manifestation)

[0310] if experiment:

[0311] experiments.append(experiment)

[0312] # 3. Optimize the experimental sequence (based on causal strength and experimental cost)

[0313] optimized_order = self.optimize_experiment_order(experiments)

[0314] return optimized_order

[0315] def identify_candidate_causes(self, defect_manifestation):

[0316] "Identify possible root causes"

[0317] candidates = []

[0318] # Find the variables that cause the defective behavior in the cause-effect graph

[0319] for node in self.causal_graph.nodes:

[0320] # Check if a causal path to the defect exists.

[0321] if self.has_causal_path_to_defect(node, defect_manifestation):

[0322] causal_strength = self.estimate_causal_strength(node,defect_manifestation)

[0323] intervention_cost = self.estimate_intervention_cost(node)

[0324] candidate = {

[0325] 'variable': node,

[0326] 'causal_strength': causal_strength,

[0327] 'intervention_cost': intervention_cost,

[0328] 'priority_score': causal_strength / intervention_cost,

[0329] 'causal_path': self.find_causal_path(node,defect_manifestation)

[0330] }

[0331] candidates.append(candidate)

[0332] return sorted(candidates, key=lambda x: x['priority_score'],reverse=True)

[0333] def design_single_intervention(self, candidate_cause, defect_manifestation):

[0334] """Design a single intervention experiment"""

[0335] # Design the intervention using the do-operator

[0336] intervention_design = {

[0337] 'target_variable': candidate_cause['variable'],

[0338] 'intervention_type': self.determine_intervention_type(candidate_cause),

[0339] 'intervention_values': self.generate_intervention_values(candidate_cause),

[0340] 'control_conditions': self.design_control_conditions(candidate_cause),

[0341] 'expected_effects': self.predict_intervention_effects(

[0342] candidate_cause, defect_manifestation

[0343] ),

[0344] 'observation_metrics': self.determine_observation_metrics(defect_manifestation)

[0345] }

[0346] # Generate specific test cases

[0347] test_case = self.generate_intervention_test_case(intervention_design)

[0348] return {

[0349] 'design': intervention_design,

[0350] 'test_case': test_case,

[0351] 'candidate_cause': candidate_cause

[0352] }

[0353] def determine_intervention_type(self, candidate_cause):

[0354] """Determine the intervention type"""

[0355] variable_info = self.causal_graph.nodes[candidate_cause['variable']]

[0356] if variable_info['data_type'] in ['boolean', 'flag']:

[0357] return 'BINARY_INTERVENTION'

[0358] elif variable_info['data_type'] in ['int', 'float']:

[0359] return 'QUANTITATIVE_INTERVENTION'

[0360] elif variable_info['data_type'] in ['string', 'enum']:

[0361] return 'CATEGORICAL_INTERVENTION'

[0362] else:

[0363] return 'COMPLEX_INTERVENTION'

[0364] def generate_intervention_values(self, candidate_cause):

[0365] """Generate intervention values"""

[0366] variable_info = self.causal_graph.nodes[candidate_cause['variable']]

[0367] data_type = variable_info['data_type']

[0368] if data_type == 'boolean':

[0369] return [True, False] # Two states

[0370] elif data_type == 'int':

[0371] # Generate meaningful intervention values ​​based on historical values

[0372] historical_values ​​= self.get_historical_values(candidate_cause['variable'])

[0373] if historical_values:

[0374] min_val, max_val = min(historical_values), max(historical_values)

[0375] return [

[0376] min_val - 1, # Lower than the historical minimum value

[0377] min_val, # Historical minimum value

[0378] (min_val + max_val) / 2, # Intermediate value

[0379] max_val, # Historical maximum value

[0380] max_val + 1 # Higher than the historical maximum value ]

[0382] else:

[0383] return [-1, 0, 1] # Default value

[0384] elif data_type == 'string':

[0385] # Generate meaningful string intervention values

[0386] return ["", "test_value", "edge_case_value"]

[0387] else:

[0388] return [None] # Null value intervention

[0389] def generate_intervention_test_case(self, intervention_design):

[0390] """Generate intervention test cases"""

[0391] # Build test template

[0392] template = self.select_intervention_template(intervention_design)

[0393] # Generate specific test code

[0394] test_code = self.render_intervention_test(

[0395] template, intervention_design )

[0397] return {

[0398] 'name': f"intervention_{intervention_design['target_variable']}",

[0399] 'description': f"Intervention experiment: {intervention_design['target_variable']}",

[0400] 'code': test_code,

[0401] 'type': 'INTERVENTION_EXPERIMENT',

[0402] 'expected_outcome': intervention_design['expected_effects'],

[0403] 'validation_checks': self.generate_validation_checks(intervention_design)

[0404] }

[0405] def optimize_experiment_order(self, experiments):

[0406] "Optimize the order of experiment execution"

[0407] # Based on multi-objective optimization: causal strength, experimental cost, and information gain

[0408] optimization_model = {

[0409] 'variables': [e['candidate_cause']['variable'] for e inexperiments],

[0410] 'objectives': [

[0411] # Maximize causal strength

[0412] lambda order: sum(experiments[i]['candidate_cause']['causal_strength']

[0413] (for i in order)

[0414] # Minimize cumulative cost

[0415] lambda order: sum(experiments[i]['candidate_cause']['intervention_cost']

[0416] (for i in order)

[0417] # Maximize information gain (based on independence between experiments)

[0418] lambda order: self.calculate_information_gain(order,experiments)

[0419] ],

[0420] 'constraints': [

[0421] # Dependency constraint: Some experiments need to be executed after others.

[0422] self.check_experiment_dependencies ]

[0424] }

[0425] # Optimize the order using a multi-objective genetic algorithm

[0426] optimized_order = self.nsga_ii_optimize(optimization_model)

[0427] return [experiments[i] for i in optimized_order]

[0428] ```

[0429] S4. Minimal Causal Chain Generation: Extracting the minimum causal chain from the intervention experiment results. The flowchart for generating the minimum causal chain is shown below. Figure 12 As shown, first, the results of the intervention experiment are analyzed to identify confirmed causal relationships; then, causal chains are constructed; next, the minimal causal chain is sought; and finally, the sufficiency and necessity of the causal chain are verified.

[0430] 1) Analyze the results of the intervention experiment to identify confirmed causal relationships.

[0431] Perform a series of intervention experiments (such as do(X = x) operation), observe the response changes of the target variable Y, use statistical tests or causal effect estimation (such as ATE, CATE) to determine whether there is a significant causal effect and whether the causal direction is reliable, and output a set of verified causal edges (such as A→B, B→C).

[0432] 2) Constructing causal links

[0433] The confirmed causal relationships are combined into directed paths; if the goal is from the root cause R to the fault F, then all paths from R to F are extracted; for example, the original link: R→X1→X2→…→Xk→F, can be used to generate all candidate causal links with the help of graph traversal algorithms (such as DFS / BFS).

[0434] 3) Find the minimal causal link

[0435] Define "minimum": retain the fewest nodes / edges while still being able to explain the causal propagation from R to F. Employ pruning: remove intermediate nodes one by one and test if the causal effect disappears; employ necessity filtering: retain only nodes that significantly contribute to the causal effect; and use shortest path constraints: find the shortest directed path from R to F in the causal graph. Finally, output one or more simplified causal links, such as R→M→F.

[0436] Verify the sufficiency and necessity of causal links.

[0437] Sufficiency verification: If all variables on the fixed link are intervention values, will F necessarily occur?

[0438] Necessity verification: If any link in the chain is blocked (e.g., do(M = normal)), will F no longer occur? If so, then that link is necessary. This can be verified through counterfactual simulation experiments.

[0439] Specific technical implementation:

[0440] First, analyze the results of all intervention experiments. By comparing the occurrence of failures in the intervention group and the control group, calculate the magnitude of the causal effect (such as the relative rate of change) and the confidence level of each intervention variable, thereby confirming which causal relationships are verified to be valid.

[0441] Next, in the causal graph, starting from the confirmed root cause and ending at the fault manifestation, all feasible causal paths are found using graph traversal algorithms (such as depth-first search), forming a set of candidate causal links.

[0442] To obtain the simplest explanation, the system scores each causal link, taking into account factors such as path length (shorter is better), causal strength (higher is better), number of mediators (fewer is better), and interpretability. After selecting the link with the highest score, a pruning operation is further performed: mediators are removed one by one, and it is verified whether the remaining path can still maintain the causal effect; if the effect disappears, the mediator is retained, otherwise it is removed.

[0443] Finally, the sufficiency and necessity of the simplified causal chain are verified:

[0444] 1) Sufficiency: If all variables on the link are set to intervention values, will it necessarily lead to the reproduction of the fault?

[0445] 2) Necessity: If any link in the chain is blocked (e.g., restored to normal value), will the fault no longer occur?

[0446] Once the verification is successful, the minimum causal link is output as the core basis for the root cause explanation.

[0447] The relevant code is as follows:

[0448] Python

[0449] class MinimalCausalChainGenerator:

[0450] def __init__(self, causal_graph):

[0451] self.causal_graph = causal_graph

[0452] self.causal_inference = CausalInferenceEngine()

[0453] def generate_minimal_causal_chain(self, intervention_results,defect_manifestation):

[0454] """Generate the minimum causal chain"""

[0455] # 1. Analyze the results of the intervention experiment

[0456] causal_evidence = self.analyze_intervention_results(intervention_results)

[0457] # 2. Identify and confirm causal relationships

[0458] confirmed_causes = self.identify_confirmed_causes(causal_evidence)

[0459] # 3. Constructing a causal chain

[0460] causal_chains = self.build_causal_chains(confirmed_causes,defect_manifestation)

[0461] # 4. Finding the smallest causal chain

[0462] minimal_chain = self.find_minimal_causal_chain(causal_chains)

[0463] # 5. Verify the sufficiency and necessity of the causal chain.

[0464] validated_chain = self.validate_causal_chain(minimal_chain,causal_evidence)

[0465] return validated_chain

[0466] def analyze_intervention_results(self, intervention_results):

[0467] "Analysis of Intervention Experiment Results"

[0468] causal_evidence = {}

[0469] for result in intervention_results:

[0470] variable = result['experiment']['design']['target_variable']

[0471] effect_observed = result['test_result']['defect_manifested']

[0472] # Calculate the magnitude of causal effect

[0473] effect_size = self.calculate_causal_effect_size(result)

[0474] # Record evidence

[0475] causal_evidence[variable] = {

[0476] 'effect_observed': effect_observed,

[0477] 'effect_size': effect_size,

[0478] 'confidence': self.calculate_causal_confidence(result),

[0479] 'counterfactual_evidence': self.analyze_counterfactual(result),

[0480] 'context_dependencies': self.identify_context_dependencies(result)

[0481] }

[0482] return causal_evidence

[0483] def calculate_causal_effect_size(self, intervention_result):

[0484] """Calculate the causal effect size"""

[0485] # Compare the defect occurrence rates between the intervention group and the control group

[0486] intervention_group = intervention_result['test_result']['defect_manifested']

[0487] control_group = intervention_result['control_result']['defect_manifested']

[0488] if control_group == 0:

[0489] return 1.0 if intervention_group else 0.0

[0490] else:

[0491] return abs(intervention_group - control_group) / control_group

[0492] def build_causal_chains(self, confirmed_causes, defect_manifestation):

[0493] "Constructing a causal chain from cause to defect"

[0494] causal_chains = []

[0495] for cause in confirmed_causes:

[0496] # Finding paths in a cause-effect graph

[0497] paths = self.find_all_causal_paths(cause, defect_manifestation)

[0498] for path in paths:

[0499] chain = {

[0500] 'root_cause': cause,

[0501] 'defect': defect_manifestation,

[0502] 'causal_path': path,

[0503] 'path_length': len(path),

[0504] 'path_strength': self.calculate_path_strength(path),

[0505] 'mediating_variables': path[1:-1] # Mediating variables

[0506] }

[0507] causal_chains.append(chain)

[0508] return causal_chains

[0509] def find_minimal_causal_chain(self, causal_chains):

[0510] "Finding the smallest causal chain"

[0511] if not causal_chains:

[0512] return None

[0513] # Multi-criteria decision making: path length, strength, simplicity

[0514] scored_chains = []

[0515] for chain in causal_chains:

[0516] score = self.score_causal_chain(chain)

[0517] scored_chains.append((chain, score))

[0518] # Select the chain with the highest score

[0519] best_chain = max(scored_chains, key=lambda x: x[1])[0]

[0520] # Further simplify the chain (remove unnecessary mediator variables)

[0521] simplified_chain = self.simplify_causal_chain(best_chain)

[0522] return simplified_chain

[0523] def score_causal_chain(self, causal_chain):

[0524] """Scoring the causal chain"""

[0525] weights = {

[0526] 'path_length': 0.3,

[0527] 'path_strength': 0.4,

[0528] 'simplicity': 0.2,

[0529] 'explainability': 0.1

[0530] }

[0531] # Path length (shorter the better)

[0532] length_score = 1.0 / causal_chain['path_length']

[0533] # Path Strength

[0534] strength_score = causal_chain['path_strength']

[0535] # Simplicity (the fewer the mediating variables, the better)

[0536] simplicity_score = 1.0 / (len(causal_chain['mediating_variables']) + 1)

[0537] # Explainability

[0538] explainability_score = self.assess_explainability(causal_chain)

[0539] total_score = (weights['path_length'] * length_score +

[0540] weights['path_strength'] * strength_score +

[0541] weights['simplicity'] * simplicity_score +

[0542] weights['explainability'] * explainability_score)

[0543] return total_score

[0544] def simplify_causal_chain(self, causal_chain):

[0545] "Simplifying causal chains"

[0546] original_path = causal_chain['causal_path']

[0547] simplified_path = [original_path[0]] # Starting reason

[0548] # Check if each mediator variable is necessary

[0549] for i in range(1, len(original_path) - 1):

[0550] mediator = original_path[i]

[0551] # If the causal effect still exists after removing the mediator variable, then remove it.

[0552] if not self.is_mediator_necessary(mediator, causal_chain):

[0553] continue

[0554] simplified_path.append(mediator)

[0555] simplified_path.append(original_path[-1]) # Final defect

[0556] # Update causal chain

[0557] causal_chain['causal_path'] = simplified_path

[0558] causal_chain['mediating_variables'] = simplified_path[1:-1]

[0559] causal_chain['path_length'] = len(simplified_path)

[0560] return causal_chain

[0561] def validate_causal_chain(self, causal_chain, causal_evidence):

[0562] "Verifying the validity of the causal chain"

[0563] validation_results = {

[0564] 'sufficiency': self.test_sufficiency(causal_chain,causal_evidence),

[0565] 'necessity': self.test_necessity(causal_chain, causal_evidence),

[0566] 'robustness': self.test_robustness(causal_chain, causal_evidence),

[0567] 'consistency': self.test_consistency(causal_chain,causal_evidence)

[0568] }

[0569] causal_chain['validation'] = validation_results

[0570] causal_chain['is_valid'] = all(validation_results.values())

[0571] return causal_chain

[0572] ```

[0573] S5. Counterfactual Verification: Perform counterfactual reasoning to verify causal relationships. First, generate a single counterfactual scenario. Then, generate counterfactuals for each link in the causal chain, generating "if...then..." counterfactual test cases. Next, evaluate the counterfactual test results. If any counterfactual is disproven, re-evaluate the causal chain.

[0574] Specific technical implementation:

[0575] This method is based on a minimal causal chain and constructs a counterfactual scenario in the form of "if...then..." for each causal link in the chain. For example: "If variable X had not been incorrectly assigned a value, then the failure would not have occurred."

[0576] Specifically, for each cause node, a counterfactual intervention is defined (such as preventing its abnormal assignment or resetting it to a valid value), and the causal model is used to predict whether the failure will still occur under this assumption. Then, corresponding counterfactual test cases are automatically generated to simulate the assumed scenario and perform verification.

[0577] After execution, compare the actual results with the expected results: if they are consistent, the confidence in the causal relationship is strengthened; if they are inconsistent (i.e. the counterfactual is falsified), the confidence in the causal relationship is reduced, and a process of re-evaluating and correcting the causal link is triggered, such as removing unreliable links or introducing new variables, to ensure the robustness of the final causal explanation.

[0578] The relevant code is as follows:

[0579] Python

[0580] class CounterfactualReasoningEngine:

[0581] def __init__(self, causal_model):

[0582] self.causal_model = causal_model

[0583] self.symbolic_executor = SymbolicExecutor()

[0584] def generate_counterfactual_tests(self, causal_chain, original_failure):

[0585] """Generate counterfactual test cases"""

[0586] counterfactual_tests = []

[0587] # Generate counterfactuals for each link in the causal chain

[0588] for i, cause in enumerate(causal_chain['causal_path'][:-1]):

[0589] # Generate counterfactual tests using the "if...then..." formula

[0590] counterfactual = self.generate_single_counterfactual(

[0591] cause, causal_chain, original_failure, i )

[0593] if counterfactual:

[0594] counterfactual_tests.append(counterfactual)

[0595] return counterfactual_tests

[0596] def generate_single_counterfactual(self, cause, causal_chain, original_failure, position):

[0597] """Generate a single counterfactual scenario"""

[0598] # Constructing counterfactual conditions

[0599] counterfactual_condition = self.build_counterfactual_condition(

[0600] cause, causal_chain, position )

[0602] # Predicting Counterfactual Outcomes

[0603] predicted_outcome = self.predict_counterfactual_outcome(

[0604] cause, causal_chain, original_failure, position )

[0606] # Generate test cases

[0607] test_case = {

[0608] 'type': 'COUNTERFACTUAL',

[0609] 'description': f"counterfactual: {counterfactual_condition}",

[0610] 'assumption': f"If {cause} does not occur, then the defect may not occur",

[0611] 'test_scenario': self.build_counterfactual_scenario(

[0612] cause, causal_chain, original_failure

[0613] ),

[0614] 'expected_outcome': predicted_outcome,

[0615] 'causal_evidence_strength': self.estimate_evidence_strength(

[0616] cause, causal_chain )

[0618] }

[0619] return test_case

[0620] def build_counterfactual_condition(self, cause, causal_chain,position):

[0621] "Constructing counterfactual conditions"

[0622] if position == 0: # Root cause

[0623] return f"{cause} was prevented from happening."

[0624] else:

[0625] The value of f"{cause} has been changed" is returned.

[0626] def predict_counterfactual_outcome(self, cause, causal_chain, original_failure, position):

[0627] "Predicting counterfactual outcomes"

[0628] # Using causal models for counterfactual reasoning

[0629] intervention = self.define_counterfactual_intervention(cause,position)

[0630] # Perform a counterfactual inquiry

[0631] counterfactual_result = self.causal_model.query_counterfactual(

[0632] intervention, original_failure )

[0634] return {

[0635] 'defect_likelihood': counterfactual_result.defect_probability,

[0636] 'expected_behavior': counterfactual_result.expected_behavior,

[0637] 'confidence': counterfactual_result.confidence

[0638] }

[0639] def evaluate_counterfactual_tests(self, test_results, causal_chain):

[0640] "Evaluating the results of the counterfactual test"

[0641] evaluation = {

[0642] 'supported_counterfactuals': 0,

[0643] 'refuted_counterfactuals': 0,

[0644] 'causal_strength_evidence': [],

[0645] 'revised_causal_chain': None

[0646] }

[0647] for result in test_results:

[0648] if result['actual_outcome'] == result['expected_outcome']:

[0649] evaluation['supported_counterfactuals'] += 1

[0650] # Increase the confidence level of causality

[0651] self.strengthen_causal_belief(result['cause'],causal_chain)

[0652] else:

[0653] evaluation['refuted_counterfactuals'] += 1

[0654] # Causal chain needs correction

[0655] self.weaken_causal_belief(result['cause'], causal_chain)

[0656] # If a counterfactual is disproven, re-evaluate the causal chain.

[0657] if evaluation['refuted_counterfactuals'] > 0:

[0658] evaluation['revised_causal_chain'] = self.revise_causal_chain(

[0659] causal_chain, test_results )

[0661] return evaluation

[0662] ```

[0663] S6. Root Cause Report Generation: Outputs human-readable causal explanations;

[0664] S7. Obtain the minimum test case: such as "crash due to invalid email format".

[0665] Key technology implementation:

[0666] I. Causal Discovery Algorithm

[0667] The flowchart of the causal discovery algorithm is as follows: Figure 4 As shown, the process involves five steps: First, preparing causal discovery data; second, using multiple algorithms such as PC, FCI, and LiNGAM for causal discovery, each potentially producing different causal graph representations; third, ensemble learning to merge the results of multiple algorithms (comparing and integrating causal graphs generated by different algorithms, using voting mechanisms and weighted consensus algorithms to determine causal relationships); fourth, post-processing using domain knowledge (applying domain expert knowledge to conduct a preliminary review of the generated causal graph, checking for obvious inconsistencies or relationships that do not conform to reality, adjusting inaccurate parts of the causal graph to ensure its logic and practicality); and fifth, refining the causal graph using domain knowledge (further combining domain expertise and technical background to deeply analyze each node and its connections in the causal graph, optimizing causal paths).

[0668] Specific technical implementation:

[0669] First, the time-series dependent data is organized into a standardized multidimensional variable matrix, which serves as the input for causal discovery.

[0670] Subsequently, multiple classic causal discovery algorithms (including the PC algorithm based on conditional independence test, the FCI algorithm for handling latent variables, and the LiNGAM algorithm assuming linear non-Gaussian noise) are called in parallel, each outputting a causal graph.

[0671] Next, an ensemble learning strategy is used to fuse these results: for each possible causal edge, the number of times it appears in each algorithm is counted, only the edges that receive more than half of the votes are retained as the consensus structure, and their average causal weight is calculated.

[0672] Finally, domain knowledge is introduced to post-process the consensus graph:

[0673] 1) Remove edges that violate program semantics (such as reversed read / write order, scope mismatch, etc.);

[0674] 2) Supplement edges that are missing due to data sparsity but conform to the program logic (such as explicit assignment dependencies).

[0675] 3) Adjust the confidence of the edges to better reflect the actual behavior of the software system.

[0676] This process ensures that the cause-effect graph possesses both data-driven objectivity and conforms to the inherent structural constraints of the program.

[0677] The relevant code is as follows:

[0678] Python

[0679] class CausalDiscoveryAlgorithm:

[0680] def __init__(self):

[0681] self.pc_algorithm = PCAlgorithm()

[0682] self.fci_algorithm = FCIAlgorithm()

[0683] self.lingam_algorithm = LiNGAMAlgorithm()

[0684] def learn_causal_structure(self, temporal_dependencies, execution_trace):

[0685] """Learning causal structures"""

[0686] # Prepare data

[0687] data_matrix = self.prepare_causal_data(temporal_dependencies,execution_trace)

[0688] # Causal discovery using multiple algorithms such as PC, FCI, and LiNGAM

[0689] pc_graph = self.pc_algorithm.learn_structure(data_matrix)

[0690] fci_graph = self.fci_algorithm.learn_structure(data_matrix)

[0691] lingam_graph = self.lingam_algorithm.learn_structure(data_matrix)

[0692] # Ensemble learning: Combining the results of multiple algorithms

[0693] ensemble_graph = self.ensemble_causal_graphs(

[0694] [pc_graph, fci_graph, lingam_graph] )

[0696] # Post-processing using domain knowledge

[0697] refined_graph = self.refine_with_domain_knowledge(

[0698] ensemble_graph, execution_trace )

[0700] return refined_graph

[0701] def prepare_causal_data(self, temporal_dependencies, execution_trace):

[0702] "Preparing data for causal discovery"

[0703] # Constructing a variable time series matrix

[0704] variables = list(temporal_dependencies.keys())

[0705] time_points = max(len(td) for td in temporal_dependencies.values())

[0706] data_matrix = np.zeros((time_points, len(variables)))

[0707] for i, var in enumerate(variables):

[0708] series = temporal_dependencies[var]

[0709] # Standardized Time Series

[0710] normalized_series = (series - np.mean(series)) / np.std(series)

[0711] data_matrix[:, i] = normalized_series

[0712] return data_matrix

[0713] def ensemble_causal_graphs(self, causal_graphs):

[0714] "Integrating multiple causal graphs"

[0715] # Use voting mechanism

[0716] edge_votes = {}

[0717] for graph in causal_graphs:

[0718] For edge in graph.edges:

[0719] if edge is not in edge_votes:

[0720] edge_votes[edge] = 0

[0721] edge_votes[edge] += 1

[0722] # Choose the side that receives more than half the votes

[0723] threshold = len(causal_graphs) / 2

[0724] consensus_edges = {

[0725] edge for edge, votes in edge_votes.items()

[0726] if votes > threshold

[0727] }

[0728] # Building a consensus graph

[0729] consensus_graph = CausalGraph()

[0730] for edge in consensus_edges:

[0731] source, target = edge

[0732] # Calculate the average weight

[0733] weights = [g.edges[edge].get('weight', 0) for g incausal_graphs if edge in g.edges]

[0734] avg_weight = sum(weights) / len(weights)

[0735] consensus_graph.add_edge(source, target, weight=avg_weight)

[0736] return consensus_graph

[0737] def refine_with_domain_knowledge(self, causal_graph, execution_trace):

[0738] "Refining Cause-and-Effect Graphs Using Domain Knowledge"

[0739] # Add program semantic constraints

[0740] refined_graph = causal_graph.copy()

[0741] # Remove edges that violate program semantics

[0742] invalid_edges = self.identify_invalid_edges(causal_graph,execution_trace)

[0743] for edge in invalid_edges:

[0744] refined_graph.remove_edge(edge)

[0745] # Add missing semantic edges

[0746] missing_edges = self.identify_missing_edges(causal_graph,execution_trace)

[0747] for edge in missing_edges:

[0748] refined_graph.add_edge(edge[0], edge[1], weight=0.5) #Medium confidence

[0749] return refined_graph

[0750] ```

[0751] II. Generating Counterfactual Test Cases

[0752] The flowchart for generating counterfactual test cases is as follows: Figure 13 As shown, the first step is to construct counterfactual conditions; the second step is to predict counterfactual outcomes, including using a causal model (SCM) for counterfactual reasoning and executing counterfactual queries; the third step is to generate test cases for "if {cause} did not occur, then the defect might not occur".

[0753] Constructing counterfactual conditions

[0754] Objective: Define a hypothetical scenario that is "contrary to the facts".

[0755] enter:

[0756] Actual observed execution traces (such as variable sequences, logs, and state snapshots);

[0757] Identified candidate root causes (such as a function call, abnormal input, configuration value).

[0758] operate:

[0759] Set an intervention: do(cause = normal_value) For example: change incorrect user input to a valid value; disable a faulty module.

[0760] Fixed background conditions: Infer noise terms or latent variables based on actual observations (in SCM).

[0761] Output: A formalized counterfactual premise, such as "If variable X is not assigned the value null at t=5..."

[0762] Predicting counterfactual outcomes

[0763] Three-step counterfactual reasoning based on SCM:

[0764] Inverse inference: Using actual observation data, inferring exogenous variables (U) or noise terms in the model.

[0765] Intervention: Modify the structural equation and apply do(cause = counterfactual_value).

[0766] Prediction: In the modified model, the values ​​of downstream variables are recalculated, including defect indicators (such as whether an exception is thrown or whether an assertion fails).

[0767] Output the system's behavior in the counterfactual world, specifically whether the defects still occur.

[0768] Generate counterfactual test cases

[0769] Transform counterfactual reasoning results into executable test cases. Format: If the [root cause event] did not occur, then the [defective phenomenon] may not occur.

[0770] It should be noted that the descriptions of each step S1 to S7 in this embodiment can be found in the descriptions in the above embodiments, and will not be repeated here.

[0771] In this embodiment, the theory of "causal inference" is introduced into the test case generation stage, enabling the generation of a minimal test case sequence that directly reveals the root cause of defects. This efficient, accurate, and interpretable test case minimization method can: (1) identify the inputs / operations (root causes) that truly cause the failure from the original failed test cases; (2) eliminate non-causal but related interfering steps; (3) significantly reduce the number of test executions during the minimization process; and (4) output minimal test cases with causal interpretability. The generated test cases themselves are a "causal proof," greatly accelerating the debugging and repair process.

[0772] In this embodiment, the following technical effects can be achieved: 1. Constructing a causal graph of system behavior: During test execution, not only are inputs and outputs recorded, but also key variables, states, and the temporal relationships of function calls within the program are recorded with high precision through instrumentation technology. Based on this data, a probabilistic graphical model representing the potential causal relationships within the system is dynamically constructed. 2. Interventional test case generation: When a test case fails, the system treats it as an "effect." Subsequently, instead of aimless exploration, it simulates "intervention" operations based on the causal graph. New test cases are generated, which aim to fix other variables and only change the variables or states suspected of being the root cause, observing whether the defect still occurs. This process is iterative, and each test is a targeted causal experiment. 3. Generating a minimal causal chain: Finally, the system outputs a minimal sequence of test cases with causal relationships. This sequence is like a logical deduction chain, clearly showing the necessary causal relationship from the initial input to the final defect. For example, test case A proves that "when the memory pool is exhausted, the system enters state S"; test case B, based on state S, proves that "receiving network packets at this time will cause a null pointer exception." 4. The mature theory of "causal inference" in statistics and artificial intelligence (AI) is creatively applied to the purpose of generating test cases, realizing the leap from "discovering problems" to "explaining problems".

[0773] The technical solution in this application can be used as an automated post-test processing module, embedded into the Development and Operations (DevOps) process. When a test fails, it automatically triggers trajectory recording → cause-effect graph construction → intervention experiment → minimum test case generation, outputting a structured root cause report. The generated minimum test cases can be directly used as the content of the "reproduction steps" and "root cause" fields in bug tickets, improving R&D response efficiency. The technical solution in this application can be applied to intelligent testing platforms and integrated as a standard component.

[0774] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0775] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0776] This application embodiment can divide the minimum test case generation device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0777] In some embodiments, this application also provides a minimum test case generation apparatus. This minimum test case generation apparatus may include one or more functional modules for implementing the minimum test case generation method of the above method embodiments.

[0778] For example, Figure 14 This is a schematic diagram of a minimal test case generation device provided in an embodiment of this application. Figure 14 As shown, the minimum test case generation device 900 includes: a determination module 901, a generation module 902, and an execution module 903.

[0779] Among them, the determination module 901 is used to determine at least two candidate root causes in the failed test cases based on the trajectory data of the failed test cases. The at least two candidate root causes are key variables in the failed test cases that affect the occurrence of the failure.

[0780] The generation module 902 is used to generate multiple intervention test cases based on the data types of at least two candidate root dependent variables determined by the determination module 901.

[0781] The execution module 903 is used to execute multiple intervention test cases generated by the generation module 902 and obtain the intervention test results for each intervention test case.

[0782] The determination module 901 is also used to analyze the intervention test results obtained by the execution module 903 and determine the causal relationship of the failure test cases.

[0783] The generation module 902 is also used to generate minimum test cases based on the fault causal relationship determined by the determination module 901.

[0784] The minimum test case generation device provided in this application automatically identifies key variables affecting the occurrence of failures through trajectory data for failed test cases. Then, based on these variables, multiple intervention test cases are generated and executed to verify causal relationships, determining the causal relationship that directly reveals the root cause of the defect. Finally, minimum test cases are generated based on this causal relationship. Therefore, it can effectively eliminate the interference of irrelevant variables, directly locate the root cause of the failure, and thus improve the accuracy and efficiency of root cause localization.

[0785] In some embodiments, the determining module 901 is specifically used to extract input variables and key state variables from trajectory data, and construct time series dependencies between input variables and key state variables; and based on the time series dependencies, construct a causal graph, which is used to characterize the causal relationship between input variables and key state variables in failed test cases and root cause variables of failed test cases; and traverse the causal graph constructed by the execution module 903 to determine at least two candidate root cause variables from the causal graph.

[0786] In other embodiments, the determination module 901 is specifically used to traverse the causal graph, determine N variables from the causal graph, where N variables are variables in the causal graph that can influence the occurrence of the fault through a directed path, and N is an integer greater than 1; calculate the priority score of each of the N variables based on the causal strength and intervention cost of the N variables; and select at least two candidate root cause variables from the N variables based on the priority score of each variable.

[0787] In some other embodiments, the generation module 902 is specifically used to determine the intervention type of each candidate root dependent variable based on the data type of each candidate root dependent variable among at least two candidate root dependent variables; generate a set of intervention values ​​for each candidate root dependent variable based on the intervention type of each candidate root dependent variable; and generate multiple intervention test cases based on the set of intervention values ​​corresponding to each candidate root dependent variable.

[0788] In some other embodiments, the generation module 902 is specifically used to construct a set of causal links based on the causal relationship of the failure; take the causal link with the highest score in the set of causal links as the minimum causal link of the failed test case; and generate a minimum test case based on the minimum causal link.

[0789] In some other embodiments, the generation module 902 is specifically used to perform pruning operations on the causal link with the highest score in the causal link set, and to use the causal link after the pruning operation as the minimum causal link of the failed test case.

[0790] In some other embodiments, the generation module 902 is specifically used to generate counterfactual test cases corresponding to each link in the minimum causal link, and compare the actual results of the counterfactual test cases corresponding to each link with the expected results; if the actual results are inconsistent with the expected results, the confidence in the causal relationship of each link is reduced, and the minimum causal link of the failed test cases is re-evaluated; based on the minimum causal link of the failed test cases obtained by re-evaluation, the minimum test cases are generated.

[0791] It should be noted that the minimum test case generation device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0792] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 15 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0793] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a digital signal processor (DSP), and a microprocessor, etc.

[0794] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0795] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0796] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the minimum test case generation method provided in this application embodiment.

[0797] In another possible implementation, memory 91 can also be integrated with processor 92.

[0798] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 15 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0799] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0800] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described minimum test case generation method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0801] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0802] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the minimum test case generation method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, flash card (FC), etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0803] This application also provides a computer program product, which is stored in a storage medium and, when executed by a computer, implements the minimum test case generation method provided in the above embodiments.

[0804] It should be noted that, in this document, 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 limitations, 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 that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0805] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0806] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for generating minimal test cases, characterized in that, The method includes: Based on the trajectory data of failed test cases, at least two candidate root causes are identified in the failed test cases, and the at least two candidate root causes are key variables in the failed test cases that affect the occurrence of the failure. Based on the data types of the at least two candidate root dependent variables, generate multiple intervention test cases; Execute the multiple intervention test cases to obtain the intervention test results for each intervention test case, analyze the intervention test results, and determine the causal relationship of the failure test cases; Based on the aforementioned causal relationship of the failure, a minimum number of test cases are generated.

2. The minimum test case generation method according to claim 1, characterized in that, Based on the trajectory data of the failed test cases, at least two candidate root causes are determined in the failed test cases, including: Input variables and key state variables are extracted from the trajectory data, and the time series dependencies between the input variables and the key state variables are constructed. Based on the time series dependencies, a causal graph is constructed, which is used to characterize the causal relationship between the input variables and key state variables in the failed test cases and the root cause variables of the failed test cases. Traverse the causal graph to determine the at least two candidate root dependent variables.

3. The minimum test case generation method according to claim 2, characterized in that, The step of traversing the causal graph and determining the at least two candidate root dependent variables from the causal graph includes: Traverse the cause-effect graph and determine N variables from the cause-effect graph. The N variables are variables in the cause-effect graph that can affect the occurrence of the fault through directed paths, and N is an integer greater than 1. Based on the causal strength and intervention cost of the N variables, calculate the priority score for each of the N variables; Based on the priority score of each variable, at least two candidate root variables are selected from the N variables.

4. The minimum test case generation method according to claim 1, characterized in that, Based on the data types of the at least two candidate root dependent variables, multiple intervention test cases are generated, including: The intervention type for each candidate root dependent variable is determined based on the data type of each of the at least two candidate root dependent variables. Based on the intervention type for each candidate root dependent variable, generate a set of intervention values ​​for each candidate root dependent variable; Based on a set of intervention values ​​corresponding to each candidate root dependent variable, the multiple intervention test cases are generated.

5. The minimum test case generation method according to claim 1, characterized in that, The generation of minimal test cases based on the fault causal relationship includes: Based on the aforementioned causal relationships of the faults, a set of causal links is constructed; The causal link with the highest score in the set of causal links is taken as the minimum causal link of the failed test case. Based on the minimum causal link, the minimum test case is generated.

6. The minimum test case generation method according to claim 5, characterized in that, The step of selecting the causal link with the highest score in the set of causal links as the minimum causal link for the failed test case includes: The causal link with the highest score in the set of causal links is pruned, and the causal link after pruning is taken as the minimum causal link of the failed test case.

7. The minimum test case generation method according to claim 5, characterized in that, The generation of the minimum test case based on the minimum causal link includes: Generate counterfactual test cases for each link in the minimum causal chain, and compare the actual results with the expected results of the counterfactual test cases for each link; If the actual results are inconsistent with the expected results, the confidence in the causal relationship of each link is reduced, and the minimum causal link of the failed test case is re-evaluated. The minimum test case is generated based on the minimum causal link of the failed test cases obtained from the re-evaluation.

8. A minimum test case generation device, characterized in that, The device includes: a determining module, a generating module, and an execution module; The determining module is used to determine at least two candidate root causes in the failed test cases based on the trajectory data of the failed test cases. The at least two candidate root causes are key variables in the failed test cases that affect the occurrence of the failure. The generation module is used to generate multiple intervention test cases based on the data types of the at least two candidate root dependent variables determined by the determining module. The execution module is used to execute the multiple intervention test cases generated by the generation module to obtain the intervention test results of each intervention test case; The determining module is further configured to analyze the intervention test results obtained by the execution module and determine the causal relationship of the failure test cases; The generation module is further configured to generate minimum test cases based on the fault causal relationship determined by the determining module.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the minimum test case generation method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the minimum test case generation method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, the computer program product implements the minimum test case generation method as described in any one of claims 1-7.

Images