Test case execution method and device, storage medium and electronic device

Abstract

This disclosure relates to a method, apparatus, storage medium, and electronic device for executing test cases, and pertains to the field of computer technology. The method includes: obtaining an initial causal graph corresponding to a target component and historical operational information of the target component; updating the initial causal graph based on the historical operational information to obtain a target causal graph; obtaining multiple second test cases corresponding to the target component from multiple first test cases based on the target causal graph; and executing the multiple second test cases to test the target component. In this way, updating the initial causal graph with the historical operational information of the target component can effectively eliminate meaningless and low-value causal relationships in historical execution, strengthen the core causal relationships related to actual operational failures and execution anomalies of the target component, and make the target causal graph more closely reflect the actual operational characteristics of the target component.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, storage medium, and electronic device for executing test cases. Background Technology

[0002] Software testing, as a core component in ensuring software product quality, is an indispensable part of the entire software development lifecycle. With the rapid development of information technology, software system architectures in fields such as servers and cloud computing are becoming increasingly complex, and the interrelationships between functional modules are constantly strengthening, posing numerous serious challenges to the design, management, and optimization of test cases.

[0003] Traditional test case design methods are mostly applicable to test scenarios with single or simple conditions. They are difficult to effectively handle complex dependencies and combinational logic between multiple input conditions, which can easily lead to redundancy and one-sidedness in test case design. This not only results in a large number of test cases and excessively long execution cycles, but also significantly increases the maintenance costs and resource consumption of the testing process. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, storage medium, and electronic device for executing test cases.

[0005] Firstly, this disclosure provides a method for executing test cases, the method comprising: Obtain the initial cause-effect graph corresponding to the target component and the historical running information of the target component. The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationship between the execution steps of the multiple first test cases. The historical running information is the running record of the target component when executing historical test cases within a historical time period. Based on the historical operation information, the initial causal graph is updated to obtain the target causal graph; Based on the target cause-effect graph, obtain multiple second test cases to be tested corresponding to the target component from multiple first test cases; Execute multiple second test cases to test the target component.

[0006] Thus, updating the initial causal graph by combining the historical operational information of the target component can effectively eliminate meaningless and low-value causal relationships in historical execution, strengthen the core causal relationships related to actual operational failures and execution anomalies of the target component, and make the target causal graph more closely reflect the actual operational characteristics of the target component. Based on the updated target causal graph, selecting second test cases can accurately extract test cases covering core causal paths, key functions of related components, or high-risk points. While ensuring complete test coverage, this significantly reduces redundant test cases and lowers the execution time and hardware resource consumption of test cases. Simultaneously, the dynamic integration of historical operational information allows the causal model to adapt to different operating environments and version variations of the target component, giving the testing process stronger generalization capabilities. It eliminates the need to redesign a complete set of test cases for every change to the component, significantly improving the generalization capability of the testing method provided in this disclosure.

[0007] Optionally, updating the initial causal graph based on the historical operation information to obtain the target causal graph includes: Based on the historical operation information, identify the abnormal test cases that contain anomalies in the historical test cases; Based on the abnormal test cases, the initial cause-effect graph is updated to obtain the target cause-effect graph.

[0008] Therefore, by locating abnormal test cases based on historical operational information and updating the initial cause-effect graph accordingly, the update of the initial cause-effect graph can better reflect the actual failure scenarios of the target component during operation, closely aligning with the characteristics of real-world anomalies and avoiding unfounded model adjustments. Simultaneously, it can strengthen causal relationships related to anomalies, correct logical relationships in the initial cause-effect graph that do not match reality, and make the causal representation of the target cause-effect graph more accurate. This provides a model basis that closely reflects actual failures for subsequent test case selection, enabling subsequent tests to focus on anomaly-related paths.

[0009] Optionally, the initial cause-effect graph includes multiple first nodes and multiple directed edges, each first node representing an execution step of the first test case, and multiple first nodes connected by directed edges constitute a test case; updating the initial cause-effect graph according to the abnormal test case to obtain the target cause-effect graph includes: Based on the abnormal test cases, update at least one of the node state, node attributes, node constraints, and directed edge weights of the first node of the initial causal graph to obtain the target causal graph.

[0010] In this way, the core elements of the initial cause-effect graph, such as node states, attributes, constraints, and directed edge weights, can be updated in a targeted manner. This makes the modification of the initial cause-effect graph more specific and in line with actual abnormal scenarios, accurately reflecting the abnormal characteristics of test case execution steps and relationships, and enabling subsequent tests to accurately correspond to the abnormal execution steps and logical relationships.

[0011] Optionally, obtaining multiple second test cases to be tested corresponding to the target component from multiple first test cases based on the target cause-effect graph includes: Based on the target cause-effect graph, with the goal of covering more key nodes, more cause-effect paths, and more other nodes related to key nodes, multiple third test cases are obtained from multiple first test cases; Based on multiple third test cases, determine multiple second test cases.

[0012] Therefore, selecting third-party test cases based on the goals of covering key nodes, causal paths, and key points ensures that the tests fully cover the core execution steps and core causal logic of the target component, avoiding omissions in critical aspects. Simultaneously, it eliminates irrelevant and redundant test cases, improving the relevance and accuracy of test cases, making test case selection more logical, and ensuring the effectiveness of subsequent test execution.

[0013] Optionally, determining multiple second test cases based on multiple third test cases includes: Obtain the test scenarios, version change information, and known defect information of the target component; Based on the historical operation information, the test scenario, the version change information, and the known defect information, multiple second test cases are selected from multiple third test cases.

[0014] In this way, by combining test scenarios, version change information, known defect information, and historical operation information to filter second test cases, the selection of test cases can be made to better match the actual testing needs and current state of the target component, thereby improving the accuracy of the second test cases.

[0015] Optionally, the method further includes: Obtain the target dependencies corresponding to multiple second test cases; Based on the target dependency relationship, the multiple second test cases are divided into multiple test case groups, and the second test cases contained in each test case group have a dependency relationship; Based on multiple test case groups, determine the target execution order of multiple second test cases; The execution of multiple second test cases to test the target component includes: Multiple second test cases are executed in the order of the target execution to test the target component.

[0016] Therefore, by analyzing the target dependencies between various test cases, we can more accurately grasp the interrelationships in the execution of each test case. Dividing multiple second test cases according to target dependencies allows us to group dependent second test cases into a test case group. The test cases are then executed according to the target execution order, based on the grouping. This ensures the rationality of the execution order, guarantees the logical connection of test steps, reduces test blocking or result deviations caused by improper execution order, and improves the overall smoothness and efficiency of test execution.

[0017] Optionally, the target dependency is determined in the following way: The second test case is parsed to determine its static dependencies, which include function call relationships and data dependencies. Based on historical runtime information, determine the dynamic dependencies of the second test case; The target dependency is determined based on the static dependency and the dynamic dependency.

[0018] Therefore, by combining static dependencies (function calls, data dependencies) and dynamic dependencies (derived from historical runtime information) to determine target dependencies, we can cover both the inherent logical connections of test cases and incorporate the dynamic dependency characteristics of actual operation, avoiding the one-sidedness of judging dependencies solely based on static logic. This allows target dependencies to more comprehensively reflect the true connection state of test cases. Using this to divide test case groups and determine the execution order can better align with actual execution scenarios and reduce test execution problems caused by incomplete dependency determination.

[0019] Secondly, this disclosure provides a test case execution apparatus, the apparatus comprising: The first acquisition module is used to acquire the initial cause-effect graph corresponding to the target component and the historical running information of the target component. The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationship between the execution steps of the multiple first test cases. The historical running information is the running record of the target component when executing historical test cases within a historical time period. The update module is used to update the initial causal graph based on the historical operation information to obtain the target causal graph; The second acquisition module is used to acquire multiple second test cases to be tested corresponding to the target component from multiple first test cases based on the target cause-effect graph. The execution module is used to execute multiple second test cases to test the target component.

[0020] Thirdly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the test case execution method provided in the first aspect of this disclosure.

[0021] Fourthly, this disclosure provides an electronic device, comprising: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the test case execution method provided in the first aspect of this disclosure.

[0022] The above technical solution involves obtaining an initial causal graph corresponding to the target component and its historical operational information. The initial causal graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationships between the execution steps of the multiple first test cases. The historical operational information is the execution record of the target component when executing historical test cases within a historical time period. Based on the historical operational information, the initial causal graph is updated to obtain a target causal graph. Based on the target causal graph, multiple second test cases corresponding to the target component are obtained from the multiple first test cases. The multiple second test cases are executed to test the target component. By updating the initial causal graph with the historical operational information of the target component, meaningless and low-value causal relationships in historical execution can be effectively eliminated, and core causal relationships related to actual operational failures and execution anomalies of the target component can be strengthened, making the target causal graph more closely reflect the actual operational characteristics of the target component. By selecting second test cases based on the updated target causal graph, test cases covering core causal paths, key functions of related components, or high-risk points can be accurately extracted. While ensuring the integrity of test coverage, redundant test cases are significantly reduced, and the execution time and hardware resource consumption of test cases are reduced. Meanwhile, by dynamically integrating historical operational information, the causal model can adapt to the characteristics of different operating environments and versions of the target component, making the testing process more generalizable. It eliminates the need to redesign the entire set of test cases for every change to the component, significantly improving the generalization ability of the testing method provided in this disclosure.

[0023] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the execution phase of a test case according to an exemplary embodiment.

[0025] Figure 2This is a flowchart illustrating a method for executing a test case according to an exemplary embodiment.

[0026] Figure 3 This is a schematic diagram illustrating the execution of a tabu particle swarm optimization algorithm according to an exemplary embodiment.

[0027] Figure 4 This is a schematic diagram illustrating a test case execution system according to an exemplary embodiment.

[0028] Figure 5 This is a block diagram illustrating an execution device for a test case according to an exemplary embodiment.

[0029] Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0030] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0031] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily construed as referring to a specific order or sequence. Furthermore, in the description with reference to the accompanying drawings, the same reference numerals in different drawings denote the same elements.

[0032] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0033] In the description of this disclosure, unless otherwise stated, "multiple" means two or more, and other quantifiers are similar; "at least one," "one or more," or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one 'a' can represent any number of 'a's; as another example, one or more of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple; "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " indicates that the preceding and following related objects are in an "or" relationship.

[0034] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this disclosure, it should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this disclosure, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.

[0035] Before introducing the execution methods, apparatus, storage media, and electronic devices for test cases provided in this disclosure, the application scenarios involved in the various embodiments of this disclosure are first described. This disclosure can be applied to software testing scenarios. As the complexity of software systems continues to increase, the design, management, and optimization of test cases face unprecedented challenges. In traditional software testing practices, testers typically use classic black-box testing methods such as equivalence class partitioning and boundary value analysis to design test cases. However, these methods are difficult to effectively handle complex dependencies and combinatorial logic between input conditions, often resulting in a large number of test cases with significant redundancy, leading to problems such as long test execution cycles and high maintenance costs.

[0036] The Baseboard Management Controller (BMC), as a core management component of a server system, undertakes critical functions such as hardware status monitoring, remote out-of-band management, and fault alarms. Its stability directly affects the reliability and availability of the entire system. With the increasing complexity of server systems, the functional complexity and version iteration frequency of BMC firmware have significantly increased, posing serious challenges to its testing. On the one hand, BMC testing involves numerous test scenarios deeply coupled with hardware, and test cases are highly sensitive to hardware status; even minor changes in firmware versions can cause a large number of test cases to fail. On the other hand, the exclusive nature of BMC hardware resources (e.g., a single I2C bus can only be accessed by one test case at a time) makes resource dependencies between test cases extremely prominent. Traditional execution strategies based on fixed order or random scheduling are unable to avoid resource conflicts, leading to low testing efficiency.

[0037] Therefore, while traditional methods are feasible for dealing with stable, low-frequency changing systems, they show significant shortcomings in the following scenarios: 1. In actual test execution, test cases commonly exhibit various dependencies, including data dependencies (the result of one test case serves as the input for another), execution order dependencies (test cases must be executed in a specific order to be effective), and hardware resource dependencies (multiple test cases compete for the same exclusive hardware resource). If these dependencies are not fully identified or handled properly, they can lead to insufficient testing and missed defects, or even test blocking or hardware damage, resulting in significant resource waste.

[0038] 2. Traditional test case generation primarily relies on cause-effect graphs. This involves identifying input conditions (causes) and outputs (effects), determining the logical relationships between inputs, drawing a cause-effect graph, converting it into a decision table, and ultimately generating test cases. However, real-world causal relationships are extremely complex, involving numerous interacting factors. Traditional cause-effect graph testing methods must consider various causal paths and interaction effects when constructing the graph, significantly increasing model complexity and construction difficulty. For example, in autonomous driving systems, traditional static cause-effect graphs struggle to handle dynamic traffic scenarios. In cases like sudden collapses of construction barriers at intersections, traditional methods suffer inference delays far exceeding safety thresholds. Furthermore, causal relationships are inherently uncertain. Inferring causal relationships based on observational data is susceptible to noise and randomness, leading to biased results. For instance, traditional causal analysis algorithms in industrial process fault diagnosis not only fail to achieve the desired results but also require lengthy analysis times. Moreover, existing technologies for constructing causal relationship models often rely on specific datasets and samples, resulting in insufficient model reliability and generalization ability, making it difficult to adapt to other datasets or real-world application scenarios.

[0039] 3. During actual operation, the hardware status (such as temperature, voltage, and power consumption), firmware version, and load characteristics of the target component are constantly and dynamically changing. The value and risk of executing the same set of test cases under different operating states are drastically different. Most existing test execution methods adopt static, offline test case selection and sorting strategies, meaning that once the test case set is determined, its execution priority and selection rules remain unchanged for a long period. This one-time modeling and long-term use mode cannot perceive the real-time health status of the component before test execution, nor can it utilize the failure modes and degradation trends contained in historical operation records. As a result, high-risk test scenarios are not prioritized for coverage, while a large number of low-value, already stable, redundant test cases are repeatedly executed, causing a serious misallocation of test resources.

[0040] To address the aforementioned technical problems, this invention provides a method, apparatus, storage medium, and electronic device for executing test cases. By updating the initial causal graph with historical operational information of the target component, meaningless and low-value causal relationships in historical execution can be effectively eliminated, while core causal relationships related to actual operational failures and execution anomalies of the target component are strengthened, making the target causal graph more closely reflect the actual operational characteristics of the target component. Based on the updated target causal graph, second test cases are selected, accurately extracting test cases covering core causal paths, key functions of related components, or high-risk points. While ensuring complete test coverage, redundant test cases are significantly reduced, lowering the execution time and hardware resource consumption of test cases. Simultaneously, through the dynamic integration of historical operational information, the causal model can adapt to different operating environments and version variations of the target component, giving the testing process stronger generalization capabilities. It eliminates the need to redesign a complete set of test cases for every change to the component, significantly improving the generalization capability of the testing method provided in this disclosure.

[0041] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0042] Figure 1 This is a flowchart illustrating the execution phase of a test case according to an embodiment of this disclosure, such as... Figure 1 As shown, the test case execution method provided in this disclosure can be divided into five stages: initial preparation stage, pre-test execution optimization stage, test execution stage, post-test execution analysis stage, and continuous optimization stage.

[0043] The initial preparation phase primarily involves building the foundational model and data support for test case optimization. First, based on the functional requirements document and historical test cases of the target component, input conditions and output results are identified and used as nodes in a cause-effect graph. For example, in the BMC hardware monitoring function, temperature sensor readings are the input condition (cause node), and the alarm signal generated when the temperature exceeds a threshold is the output result (result node). The logical and constraint relationships between inputs and outputs are analyzed (e.g., mutual exclusion constraints exist between temperature sensor data and other sensor data (only one sensor can collect primary data at a time)), constructing an initial cause-effect graph describing the causal path of the test scenario. Second, historical operation records of the target component are collected (including historical test results, test result analysis (e.g., risk coverage, resource conflict rate, defect detection efficiency, version adaptation time, etc.), historical test cases, execution rate, pass rate, first-time pass rate, and other quality indicators), version change information, and known defect information. A historical test case library and an execution result database are established to provide data support for subsequent analysis and optimization.

[0044] In the pre-test optimization phase, the core task is to generate the optimal test execution plan based on dynamic information. First, the initial cause-effect graph is dynamically updated based on historical runtime information to obtain the target cause-effect graph. Second, through static code analysis, dynamic execution monitoring, and causal reasoning methods, the static and dynamic dependencies between test cases are deeply mined to obtain the target causal relationships. Relevant test cases are then obtained based on historical runtime information, test scenarios, version change information, and known defect information. Finally, based on the updated target cause-effect graph and target dependencies, a test case minimization algorithm is used to eliminate redundancy, and the selected test cases are prioritized to generate a set of test cases to be executed and their execution order that balances high-risk coverage with resource constraints.

[0045] During the test execution phase, test cases are automatically invoked through standard interfaces (such as IPMI and Redfish API) provided by the target component, following the execution order generated in the previous phases. During execution, hardware status data, interface response information, and test logs of the component under test are collected in real time, and abnormal events are captured and recorded immediately, providing a real-time data stream for subsequent analysis.

[0046] In the post-test analysis phase, the results of this execution are thoroughly analyzed and feedback is provided. For example, the pass / fail status of test cases can be analyzed in detail, quality indicators such as execution rate, pass rate, and first-run pass rate can be statistically analyzed, and effectiveness metrics such as average defect detection efficiency (APFD) can be calculated. Simultaneously, the execution results and failure reasons are fed back to the cause-effect graph modeling module and dependency analysis module, triggering updates to the cause-effect graph node states, directed edge weights, and dependencies. Furthermore, a test report containing key indicators such as test coverage, defect detection rate, and execution time can be generated, along with test case optimization suggestions to facilitate optimization in the next round of testing.

[0047] During the continuous optimization phase, based on the optimization suggestions output in the post-execution analysis phase, the test case library (such as adding, modifying, or discarding test cases) and optimization strategies can be automatically adjusted to enter a new round of test case optimization. Simultaneously, by continuously learning from historical execution data and introducing machine learning methods to predict test case execution results, the accuracy and intelligence of system decision-making are further improved, forming a closed-loop iterative mechanism of execution-feedback-learning-optimization.

[0048] Figure 2 This is a flowchart illustrating a method for executing a test case according to an exemplary embodiment, such as... Figure 2 As shown, the method may include the following steps: In step S101, the initial causal graph corresponding to the target component and the historical operation information of the target component are obtained.

[0049] The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component, and is used to characterize the causal relationship between the execution steps of multiple first test cases. The historical running information is the running record of the target component when executing historical test cases within a historical time period.

[0050] In this step, the target component can be the BMC chip to be tested, or other components to be tested; this disclosure does not specifically limit this. The initial cause-effect graph includes multiple first nodes and multiple directed edges. Each first node represents an execution step of the first test case, and multiple first nodes connected by directed edges constitute a test case.

[0051] In some embodiments, the initial cause-effect graph can be used to identify the input and output conditions involved in each test case based on functional requirements. Input conditions (such as sensor input, user commands, and fault states) are defined as cause nodes, and output results (such as device status changes, response messages, and speed adjustment values) are defined as result nodes. The logical relationships between inputs and outputs (e.g., AND, OR, NOT) are analyzed, and directed edges are used to connect nodes to construct the initial cause-effect graph. For example, in the BMC fan speed control function, the temperature sensor input is the cause node, and the fan speed adjustment is the result node. When the temperature rises, the fan speed is increased through an AND logical relationship. In the cause-effect graph, directed edges with AND logical labels connect the two nodes to form a complete test case logic path.

[0052] In other embodiments, the initial cause-effect graph may also include constraints to define the relationships between different input conditions. Examples include mutual exclusion (two sensors cannot be active simultaneously), inclusion (activating a function includes the activation of specific sub-functions), and uniqueness (a resource can only be used by one process at a time). These constraints can be pre-analyzed using prior knowledge and associated with relevant nodes, facilitating the subsequent selection and sorting of test cases. Additionally, a visual editing interface can be provided to the operator to display the initial cause-effect graph, allowing users to modify and view the constraints according to actual conditions.

[0053] At the same time, it can obtain the historical running information of the target component. By analyzing the historical running information, it can identify the test cases that cause anomalies in the target component during the actual testing process, which is convenient for updating the initial cause-effect graph later.

[0054] In step S102, the initial causal graph is updated based on the historical running information to obtain the target causal graph.

[0055] In this step, based on the historical execution information, abnormal test cases containing anomalies can be identified from the historical test cases. Then, based on these abnormal test cases, the initial cause-effect graph is updated to obtain the target cause-effect graph. Specifically, based on the abnormal test cases, at least one of the following can be updated in the initial cause-effect graph: node state, node attributes, node constraints, and directed edge weights, to obtain the target cause-effect graph.

[0056] For example, the Maximum Information Coefficient (MIC) algorithm can be used to analyze historical runtime information to determine the time delay relationships between nodes in the initial cause-effect graph. If a time delay relationship exists between two nodes, the node attributes in the initial cause-effect graph are updated to reflect this time delay. Anomaly detection functions can also be used to analyze whether the state of each node is abnormal. If anomalies are found, the node state information and the weights of the corresponding directed edges in the initial cause-effect graph are updated, allowing for focused testing of abnormal situations during subsequent testing. Similarly, if analysis reveals constraints between the execution of a test case and other test cases, the relevant node constraints in the initial cause-effect graph can be updated.

[0057] For example, when the temperature sensor reading exceeds the upper limit of the normal range, the state of the temperature node in the causal graph is updated to "abnormal", and the delay time between the temperature abnormality and the failure of the fan speed to be adjusted in time is calculated according to the MIC algorithm, and the delay time attribute of the corresponding edge is updated.

[0058] For example, if it is found that in three consecutive test cycles, when the temperature of component A exceeds 75°C and the temperature of component B simultaneously exceeds 65°C, there is approximately a 5% probability that the BMC fails to increase the fan speed in time, causing the system to trigger overheat protection and restart. Based on this finding, the initial causal graph can be updated as follows: increase the weight of the directed edge between high component A temperature and fan speed increase, representing the failure probability of this causal path under specific conditions. Then, add a new causal path from the combined node of high component A temperature and high component B temperature to the system restart, to reflect the abnormal behavior patterns observed in historical operation.

[0059] In this way, the updated target cause-effect graph is no longer a static mapping of the requirement specifications, but a dynamic knowledge graph that incorporates the actual operating results of the target components.

[0060] In step S103, based on the target cause-effect graph, multiple second test cases corresponding to the target component are obtained from multiple first test cases.

[0061] In some embodiments, a test case screening algorithm can be executed based on the updated target cause-effect graph. The screening objective is to ensure that all critical cause-effect paths (especially newly added or weighted paths) in the updated cause-effect graph are covered by at least one test case.

[0062] Specifically, based on the target cause-effect graph, with the goal of covering more key nodes, more cause-effect paths, and more other nodes related to the key nodes, multiple third test cases can be obtained from multiple first test cases; and based on the multiple third test cases, multiple second test cases can be determined.

[0063] For example, based on the target cause-effect graph, starting from the initial cause node, the weight values ​​of intermediate nodes and result nodes are calculated sequentially according to the causal logic relationship to generate all possible cause-effect combinations as first test cases. For instance, in the cause-effect graph of the BMC power management function, test cases for corresponding power output states (result nodes) are generated through combinations of different power input states (cause nodes). A test case minimization algorithm is then employed, aiming to cover more critical nodes, more causal paths, and more other nodes related to the critical nodes. Multiple superior third test cases are selected from among the multiple first test cases to reduce the number of test cases and improve testing efficiency.

[0064] In one possible implementation, multiple third test cases can be directly used as multiple second test cases.

[0065] In another possible implementation, multiple third test cases can be further filtered. First, the test scenario, version change information, and known defect information of the target component can be obtained. Second, based on the historical runtime information, the test scenario, the version change information, and the known defect information, multiple second test cases can be filtered from the multiple third test cases. The test scenario can be the target scenario currently being tested on the target component. Different test scenarios correspond to different test requirements, so the selected test cases will also differ. For example, in a smoke test scenario, test cases with short execution times that can quickly verify the basic functions of the BMC can be selected. In a regression test scenario, test cases affected by code changes can be prioritized. Version change information refers to the changes made to the target component in this version compared to the previous version. By analyzing version change information and using it to filter test cases, the changed parts can be tested more accurately. Known defect information is a list of known but unfixed defects in the current version. By analyzing the known defect information of the target component, the testing of faulty parts can be accurately achieved. For example, through the BMC defect list, it can be discovered that a certain version is prone to packet loss in the network communication module under high load. Therefore, corresponding test cases can be obtained for the network communication module, such as network communication test cases.

[0066] In step S104, multiple second test cases are executed to test the target component.

[0067] In this step, the selected second test cases are executed sequentially by calling the standard test interface of the target component. During execution, hardware status data and test logs of the target component can be collected in real time, and the execution results of each test case are recorded. After execution, a test report is generated, including metrics such as test coverage, defect detection, and execution time, for testers to evaluate the firmware quality of the target component.

[0068] The above methods achieve a complete closed loop from historical operation information perception to dynamic update of cause-effect graphs and intelligent screening of test cases, enabling the testing strategy to be continuously optimized as the actual operation status of the target component evolves.

[0069] The following further explains the step S102 above, which involves updating the initial cause-effect graph based on the historical operational information to obtain the target cause-effect graph. First, by performing anomaly detection and analysis on the historical operational information, abnormal test cases with anomalies can be identified. For example, the types of abnormal test cases include, but are not limited to, the following: abnormal execution results, i.e., the number of test case execution failures or execution blocking exceeds a preset threshold (e.g., three consecutive execution failures); abnormal execution time, i.e., the execution time of the test case deviates significantly from the historical average (e.g., exceeding twice the standard deviation of the average); abnormal resource contention, i.e., the number of hardware resource conflicts (such as I2C bus access conflicts) during test case execution increases abnormally; and abnormal failure propagation, i.e., after a test case fails, the proportion of downstream dependent test cases experiencing cascading failures increases abnormally. Subsequently, the initial cause-effect graph can be updated specifically based on the characteristics of these abnormal test cases to obtain the target cause-effect graph. For example, the core logic of the update could be to encode the abnormal patterns observed in the historical operational information into the cause-effect graph, enabling the cause-effect graph to reflect the failure patterns in the real operational environment.

[0070] Specifically, the initial causal graph can be updated to obtain the target causal graph from the following dimensions: Updating node states, which characterize the health of a step or state in the current test environment. The state identifier of the corresponding node can be adjusted based on the failure rate of abnormal test cases. Updating node attributes, which include quantitative indicators such as execution time, resource consumption, and stability coefficient. Node attributes can be dynamically calibrated based on statistical data from historical operation information. Updating node constraints, which refer to the preconditions or resource exclusivity requirements that a node must meet to execute. The constraint relationships between nodes can be supplemented or strengthened based on dependency conflicts exposed during the execution of abnormal test cases. Updating directed edge weights, which quantify the strength of the causal relationship or the probability of failure propagation between two nodes. The weight value of the edge can be dynamically adjusted based on the failure propagation pattern of abnormal test cases. For example, the weight of the directed edge from fan failure detection failure to overheat protection test failure is increased from 0.3 to 0.8 due to multiple observations of strong correlation. Through the above multi-dimensional update operations, the target cause-effect graph can more accurately depict the behavioral characteristics and failure patterns of the target component in the real operating environment, providing a more reliable decision-making basis for subsequent test case selection.

[0071] The following further explains the step S103 above, which involves obtaining multiple second test cases corresponding to the target component from multiple first test cases based on the target causal graph. In this embodiment, firstly, based on the updated target causal graph, multiple third test cases are selected from the first test case library with the goal of covering more key nodes, more causal paths, and more other nodes related to key nodes. Specifically, the identification criteria for key nodes include risk level (nodes with high-risk or sensitive status), out-degree / in-degree (nodes connected by more edges in the causal graph), and functional importance (nodes corresponding to the core functions of the target component, such as system restart nodes, whose failure will cause the entire machine to become unusable). Further, a test case minimization algorithm (e.g., a greedy algorithm) is used to iteratively select test cases that can cover the most unmet requirements from multiple first test cases until all requirements are covered. The selected test cases are the third test cases. After obtaining the third test case set, a second screening is performed by combining the test scenario, version change information, and known defect information of the target component to obtain the final set of second test cases to be executed. Through context-aware secondary filtering, the execution scope of test cases can be dynamically adjusted according to different test objectives and constraints, thereby achieving optimal allocation of test resources.

[0072] The following further explains the steps in step S104 above, which involve executing multiple second test cases to test the target component. After obtaining multiple test cases, it is necessary to further determine the execution order among the multiple second test cases and execute them based on the execution order. Specifically, the target dependencies corresponding to the multiple second test cases can be obtained first. Secondly, based on the target dependencies, the multiple second test cases can be divided into multiple test case groups, with each test case group containing second test cases that have dependencies. Then, based on the multiple test case groups, the target execution order of the multiple second test cases can be determined. Finally, the multiple second test cases can be executed according to the target execution order to test the target component. During execution, if a test case fails or is blocked, the execution strategy of subsequent test cases can be automatically adjusted according to the dependencies (such as skipping downstream dependent test cases, lowering priority, etc.).

[0073] In some embodiments, the target dependency is determined by: parsing the second test case to determine its static dependencies, which include function call relationships and data dependencies; determining the dynamic dependencies of the second test case based on historical runtime information; and determining the target dependency based on the static dependencies and the dynamic dependencies.

[0074] For example, static dependencies can be established by statically parsing the code or script of a second test case, constructing an abstract syntax tree, identifying function call relationships and data dependencies, and generating a static dependency graph. For instance, if test case A calls a function in test case B, a static dependency is established from A to B. Similarly, if test case C uses a global variable defined in test case D, a data dependency is established from C to D. Dynamic dependencies can be established by analyzing historical execution information and mining the dynamic dependencies exhibited by test cases during actual runtime from the execution logs. For example, if a network communication test case depends on the successful execution of a network initialization test case, then a dynamic dependency exists between the network communication test case and the network initialization test case. Another example is finding that test case E consumes a large amount of memory during execution, causing subsequent test case F to fail due to insufficient memory, establishing a dynamic dependency from E to F. Yet another example is that if test case G fails, cause-effect graph analysis reveals that it affects the execution of test case H, which has a causal relationship with it, establishing a dynamic dependency from G to H. After obtaining the static and dynamic dependencies, the results are merged to generate the final target dependency graph. Each target dependency can include multiple second nodes, each representing a different test case. Dependencies between different nodes can be represented by directed edges, node attributes, and node weights. When merging the static and dynamic dependencies, the static dependency serves as the basic framework to ensure the correctness of the basic execution logic. The dynamic dependency is used as a supplement and correction, adjusting dependency strength, supplementing dynamic dependencies, and marking resource conflicts. When static and dynamic dependencies conflict, the dynamic dependency takes precedence because it reflects behavior in the real-world runtime environment. By clearly defining dependencies, test failures and resource waste caused by incomplete dependency identification are effectively avoided.

[0075] In some embodiments, the target execution order of multiple second test cases, based on multiple test case groups, can be determined as follows: Multiple test case groups are prioritized using a tabu particle swarm optimization algorithm to generate an optimized test case set and execution order. First, test cases can be grouped using a dynamic sorting optimization algorithm (Test-Case Prioritization based on Graph and Time-Dynamic Search Optimization, TPG-TDSO). Closely dependent test cases are grouped together, optimizing the execution order within and between groups to reduce resource contention and execution time. For example, network-related test cases can be grouped together, with network initialization test cases executed first, followed by network communication test cases. Second, considering factors such as test case risk level (determined based on historical failure rate and impact on key BMC functions), coverage, and execution time, the tabu particle swarm optimization algorithm is used to prioritize multiple second test cases. For example, high-risk test cases that affect the stability of the BMC system are given higher priority and executed first.

[0076] The following details the use of the taboo particle swarm optimization algorithm to prioritize multiple second test cases. In the scenario of prioritizing test cases for the target component, each particle can be mapped to a set of test case execution order schemes. Through iterative optimization, the optimal order that maximizes defect detection efficiency and minimizes resource conflicts is found. The core requirements of the taboo particle swarm optimization algorithm are shown in the table below:

[0077] like Figure 3 As shown, the particle swarm and tabu list are first initialized. A certain number of particles (i.e., the initial sorting scheme) are generated. The initial sorting adopts a random + basic rule strategy, that is, the order of test cases is randomly shuffled, but high-risk test cases (such as power switching and sensor anomaly related test cases) are forcibly assigned to the first 30% of the sorting queue to ensure that high-risk scenarios are covered first. A tabu list of length N is created (e.g., N=5, recording the globally optimal solution of the last 5 iterations), initially empty.

[0078] Next, the fitness value of each particle is calculated. For example, the fitness value of each particle can be calculated using a fitness function. The fitness function evaluates the performance of each particle (sorting scheme) and integrates multiple dimensions of metrics in the target component testing scenario: risk coverage, i.e., the degree of coverage of high-risk use cases in the sorting, calculated through cause-effect graph path coverage; resource conflict rate, i.e., the probability of hardware resource contention that may occur during the sorting; and defect detection efficiency, i.e., the estimated number of defects that can be found per unit time based on historical running information. A higher fitness value indicates that the sorting scheme can find more defects and fewer resource conflicts in a shorter time.

[0079] Then, the individual optimal solutions and the global optimal solutions are updated. Specifically, by comparing the current fitness of each particle with its historical best fitness, if the current fitness is better, the individual optimal position is updated (e.g., particle 1's historical best fitness was 0.62, and its current fitness of 0.66 is better, so the individual optimal is updated to the current ranking). From all the individual optimal solutions of all particles, the solution with the highest fitness is selected as the global optimal (e.g., particle 18's fitness is 0.82, making it the initial global optimal).

[0080] Next, update the particle positions and velocities. Substitute the particles representing the individual optimal solutions into the velocity update formula to calculate the absolute velocity value at each position within each particle. Based on the pairwise swapping mechanism of the velocity ranking, perform a random crossover mutation operation, selecting the two positions with the largest absolute velocity values ​​and swapping their positions in the sequence to generate a new ranking. If the swapped solution remains in the taboo list, continue swapping the positions with the second largest velocity until a new solution is generated. Furthermore, during the position update process, if adjusting a particle causes a high-risk use case to shift its position further back by more than a preset threshold (e.g., 5 positions), a forced retention operation is triggered to ensure that high-risk use cases always remain at the front of the queue.

[0081] Furthermore, update the tabu list. Add the globally optimal solution of this iteration to the tabu list. If the list length exceeds 5, delete the earliest added solution.

[0082] Finally, the iteration terminates and the structure is output. The iteration terminates when any of the following conditions are met: the number of iterations reaches a preset maximum value (e.g., 50 times) or the change in the globally optimal fitness value over multiple consecutive iterations (e.g., 10 times) is less than a set threshold (e.g., 0.01), indicating algorithm convergence. The final output is the test case sorting scheme corresponding to the globally optimal particle, obtaining the target execution order. It also includes metrics such as risk coverage, resource conflict rate, and defect detection efficiency, serving as the basis for the execution order of this test.

[0083] Through the above steps, this solution can automatically generate a dynamic execution order from a massive number of test cases, prioritizing high-risk cases, minimizing resource conflicts, and maximizing defect detection efficiency, significantly improving the intelligence level of target component testing.

[0084] Furthermore, during the execution of multiple second test cases, test data can be collected in real time, recording information such as the start time, end time, and execution results of each test case. After executing multiple second test cases, the test results can be further analyzed to determine whether the test cases passed or failed, and to statistically analyze metrics such as test case execution rate and pass rate. Detailed analysis of abnormal events and error information during the testing process is performed, such as locating the location and cause of errors based on error logs. If a test case fails, the states and weights of relevant nodes in the target cause-effect graph can be further updated, and relevant dependencies in the target dependency relationship can be strengthened. Through reinforcement learning methods, system decision parameters are continuously adjusted to improve the system's prediction and optimization capabilities. Detailed test execution reports can be generated based on the analysis results, including charts of key indicators such as test coverage, defect detection rate, and execution time. Test case optimization suggestion reports are generated, providing specific test case optimization suggestions for problems discovered during testing, such as adding new test cases or adjusting the execution order of test cases, and are provided to operators in document form. Furthermore, historical data can be analyzed using dynamic Bayesian networks to predict test case execution results, further optimizing the system's decision-making capabilities and providing quantitative basis for test case optimization.

[0085] By employing the above method and updating the initial causal graph with historical operational information of the target component, meaningless and low-value causal relationships in historical execution can be effectively eliminated, while core causal relationships related to actual operational failures and execution anomalies of the target component are strengthened, making the target causal graph more closely reflect the actual operational characteristics of the target component. Based on the updated target causal graph, second test cases can be selected, accurately extracting test cases covering core causal paths, key functions of related components, or high-risk points. While ensuring complete test coverage, redundant test cases are significantly reduced, lowering test case execution time and hardware resource consumption. Simultaneously, the dynamic integration of historical operational information allows the causal model to adapt to different operating environments and version variations of the target component, giving the testing process stronger generalization capabilities. This eliminates the need to redesign a complete set of test cases for every component change, significantly improving the generalization ability of the testing method provided in this disclosure.

[0086] Figure 4 This is a schematic diagram illustrating a test case execution system according to an exemplary embodiment, such as... Figure 4As shown, the system can include a data acquisition and analysis module, a cause-effect graph modeling module, a dependency analysis module, a test case optimization module, and an execution feedback module. The data acquisition and analysis module can include sub-modules for problem analysis, historical data acquisition, data acquisition, and data preprocessing. The cause-effect graph modeling module can include sub-modules for initial cause-effect graph construction, constraint processing, dynamic updating, and model visualization. The dependency analysis module can include sub-modules for static dependency analysis, dynamic dependency analysis, and dependency analysis. The test case optimization module can include sub-modules for test case generation, test case selection, test case optimization strategies, and test case priority ranking. The execution feedback module can include sub-modules for test execution, result analysis, feedback learning, and report generation. The functions of each model are further explained below: (1) Data acquisition and analysis module Problem Analysis Submodule: Receives user input describing the problems existing in the current version of the target component (which can be used as known defect information), extracts key information through natural language processing (such as BMC frequently restarting in high-temperature environments), combines historical operation information, analyzes potentially related test cases, establishes the correlation between problems and test cases, and provides a problem-oriented screening basis for subsequent optimization.

[0087] The historical data acquisition submodule can extract historical execution information of the target component's tests from storage media such as databases and test report files. This information may include test case execution results (pass / fail), failure information (error logs), execution time, and other data. It also collects documentation such as version change information and known defect information for the target component, providing a data foundation for subsequent analysis.

[0088] Data Acquisition Submodule: Utilizes the hardware interfaces (such as the IPMI interface to acquire hardware sensor data) and software interfaces (such as the Redfish API to acquire system status information) provided by the target component to acquire data in real time during test execution. For example, it acquires temperature sensor readings, network interface traffic data, and log information generated during test execution once per second.

[0089] The data preprocessing submodule cleans the collected data, removing duplicates and correcting erroneous data formats. It also standardizes the data, unifying sensor data of different dimensions to a specific range. Furthermore, it extracts data feature vectors, combining multiple sensor data such as temperature and voltage into a single feature vector, and establishes a data index for easy and quick querying and retrieval.

[0090] (2) Cause-effect graph modeling module The initial cause-effect graph construction submodule: Based on the target component's functional requirements document, input conditions are defined as cause nodes, and output results are defined as result nodes. The logical relationships between inputs and outputs (such as AND, OR, NOT) are analyzed, and directed edges are used to connect nodes to construct an initial cause-effect graph describing the causal path of the test scenario.

[0091] The constraint handling submodule defines the constraint relationships between input conditions, such as mutual exclusion, inclusion, and uniqueness.

[0092] Dynamic update submodule: Based on historical running information, dynamically update the initial cause-effect graph to obtain the target cause-effect graph.

[0093] The model visualization submodule uses a visualization library to graphically display the target cause-effect graph. Nodes can be distinguished by different shapes (e.g., circles for cause nodes and squares for result nodes) and colors (e.g., green for normal states and red for abnormal states). Directed edges use arrowed lines to indicate the cause-effect direction and are labeled with logical relationships and weights. Interactive user operations are also supported, such as hovering the mouse to display detailed node information and clicking on edges to view logical relationships and weight values.

[0094] (3) Dependency Analysis Module The static dependency analysis submodule parses the test case code, constructs an abstract syntax tree, analyzes function call relationships, and determines static call dependencies between test cases. It also analyzes variable usage to determine data dependencies and ultimately constructs the static dependency relationships.

[0095] The dynamic dependency analysis submodule monitors the execution order and resource usage (such as CPU time slice usage, memory allocation, and I2C bus usage) of test cases during test execution using instrumentation techniques. It also analyzes historical runtime information to uncover implicit dependencies such as shared database tables and resource contention, thus obtaining dynamic dependencies.

[0096] The dependency analysis submodule integrates the analysis results of static and dynamic dependencies to construct target dependencies. Based on these dependencies, test cases are grouped, with closely dependent test cases grouped together to optimize the execution order within and between groups, reducing resource contention and execution time.

[0097] (4) Test Case Optimization Module The test case generation submodule is used to generate initial test cases based on the target cause-effect graph. Specifically, this submodule traverses the target cause-effect graph starting from the initial cause node, calculates the weight values ​​of intermediate and result nodes according to the causal logic, and maps different combinations of cause node states and their corresponding result node states to test cases. By traversing all possible causal paths in the cause-effect graph, it generates an initial test case set covering various combinations of input conditions, ensuring the logical completeness of the test case set.

[0098] The test case selection submodule is used to filter out a set of test cases from the initial test case set that meet preset coverage objectives. This submodule aims to cover more critical nodes and more causal paths, employing a test case minimization algorithm to select multiple third-party test cases from the initial test case set. During the selection process, priority is given to test cases that cover the most uncovered objectives (such as high-risk nodes and critical causal paths). This process iterates until all preset coverage objectives are met, thereby eliminating redundant test cases while ensuring complete test coverage, resulting in a streamlined set of test cases.

[0099] The Test Case Optimization Strategy submodule defines test case selection and sorting strategies for different testing scenarios. This submodule stores and manages various optimization strategy templates. For example, in smoke testing scenarios, it prioritizes test cases with short execution times that can quickly verify core functions; in regression testing scenarios, it focuses on test cases affected by code changes; and in performance testing scenarios, it emphasizes test cases related to system resource consumption. Furthermore, this submodule supports automatically selecting or switching optimization strategies based on the version characteristics of the current target component (such as new features or optimizations) and testing objectives (functional verification, stability testing). It also supports user-defined strategies that can be added to the strategy library.

[0100] The test case priority ranking submodule determines the target execution order of multiple second test cases to be tested. This submodule comprehensively considers factors such as the risk level of the test cases (determined based on historical failure rates and the degree of impact on key functions), coverage contribution, execution time, and resource requirements. It employs a tabu particle swarm optimization algorithm to prioritize the second test cases, resulting in the target execution order. During the ranking process, each particle represents a test case execution order scheme. Iterative optimization finds the ranking scheme with the highest defect detection efficiency and the fewest resource conflicts, and forcibly places high-risk test cases at the top of the ranking queue to ensure that critical test scenarios are executed first.

[0101] (5) Execution feedback module The Test Execution Submodule executes multiple second test cases in the target execution order to test the target component. This submodule integrates with the test execution environment of the target component under test, automatically invoking test cases through standard interfaces provided by the component (such as IPMI interface and Redfish API). During execution, it collects real-time hardware status data (such as sensor readings and register status), interface response information, and test logs of the component under test, and immediately captures and records abnormal events (such as connection timeouts, hardware failures, and assertion failures) to provide real-time data support for subsequent analysis. Simultaneously, this submodule records the start time, end time, and execution result (pass / fail / blocked) of each test case, forming a complete execution trajectory.

[0102] The results analysis submodule performs in-depth analysis of test execution results. This submodule receives execution data collected by the test execution submodule, determines whether each second test case passes, and calculates quality metrics such as test case execution rate, pass rate, and first-run pass rate. Simultaneously, it calculates effectiveness metrics such as Average Defect Detection Rate (APFD) to evaluate the defect detection capability of the current test case set. For test cases that fail, this submodule combines execution logs and hardware status data to analyze the reasons for failure (such as unexpected results, environmental anomalies, or resource conflicts), and associates the failure information with the corresponding test cases for storage, providing a basis for subsequent feedback and learning.

[0103] The feedback learning submodule is used to feed test execution results back to the cause-effect graph modeling module and the dependency analysis module, achieving closed-loop updates of the test model. This submodule receives failed test case information and failure reasons from the result analysis submodule and transmits them as the basis for updates to the dynamic update submodule of the cause-effect graph modeling module, triggering updates to the states, attributes, and directed edge weights of relevant nodes in the target cause-effect graph. Simultaneously, it transmits information such as dependency conflicts and failure propagation observed during execution to the dependency analysis module to strengthen or adjust the target dependencies between test cases. Through continuous learning and feedback, this submodule continuously improves the system's accuracy in characterizing the behavioral patterns of target components, enabling the test strategy to evolve after each execution.

[0104] The report generation submodule generates test execution reports and test case optimization suggestions. This submodule summarizes the statistical indicators output by the results analysis submodule, as well as data recorded during test execution, such as hardware status changes and resource usage, to generate a structured test report. The report includes key information such as test coverage (e.g., critical node coverage, causal path coverage), defect detection rate, execution time distribution, and resource conflict statistics, presented intuitively in charts and graphs. Furthermore, based on the knowledge accumulated by the feedback learning submodule, this submodule generates a test case optimization suggestion report, proposing specific improvement directions for problems exposed during testing, such as adding test cases to cover missing causal paths, adjusting the execution order of existing test cases, and splitting complex test cases to reduce resource conflict risks, providing a basis for decision-making in subsequent test cycle optimizations.

[0105] Figure 5 This is a block diagram illustrating an execution device for a test case according to an exemplary embodiment, such as... Figure 5 As shown, the device 200 includes: The first acquisition module 201 is used to acquire the initial cause-effect graph corresponding to the target component and the historical running information of the target component. The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationship between the execution steps of multiple first test cases. The historical running information is the running record of the target component when executing historical test cases in a historical time period. Update module 202 is used to update the initial causal graph based on the historical running information to obtain the target causal graph; The second acquisition module 203 is used to acquire multiple second test cases to be tested corresponding to the target component from multiple first test cases based on the target cause-effect graph. Execution module 204 is used to execute multiple second test cases to perform tests on the target component.

[0106] Optionally, the update module 202 is used to determine, based on the historical running information, the abnormal test cases that exist in the historical test cases; and to update the initial cause-effect graph based on the abnormal test cases to obtain the target cause-effect graph.

[0107] Optionally, the initial cause-effect graph includes multiple first nodes and multiple directed edges. Each first node represents an execution step of the first test case. Multiple first nodes connected by directed edges constitute a test case. The update module 202 is used to update at least one of the node state, node attributes, node constraints, and weights of the directed edges of the first nodes of the initial cause-effect graph according to the abnormal test case, so as to obtain the target cause-effect graph.

[0108] Optionally, the second acquisition module 203 is used to acquire multiple third test cases from multiple first test cases based on the target cause-effect graph, with the goal of covering more key nodes, more cause-effect paths, and more other nodes related to the key nodes; and to determine multiple second test cases based on the multiple third test cases.

[0109] Optionally, the second acquisition module 203 is used to acquire the test scenario, version change information and known defect information of the target component; and to select multiple second test cases from multiple third test cases based on the historical operation information, the test scenario, the version change information and the known defect information.

[0110] Optionally, the execution module 204 is used to obtain the target dependencies corresponding to multiple second test cases; divide the multiple second test cases into multiple test case groups according to the target dependencies, and the second test cases contained in each test case group have dependencies; determine the target execution order of the multiple second test cases according to the multiple test case groups; and execute the multiple second test cases according to the target execution order to achieve the testing of the target component.

[0111] Optionally, this target dependency is determined in the following way: The second test case is parsed to determine its static dependencies, which include function call relationships and data dependencies. Based on historical runtime information, determine the dynamic dependencies of this second test case; Based on the static dependency and the dynamic dependency, determine the target dependency.

[0112] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0113] By employing the aforementioned device and updating the initial causal graph in conjunction with the historical operational information of the target component, meaningless and low-value causal relationships in historical execution can be effectively eliminated, while core causal relationships related to actual operational failures and execution anomalies of the target component are strengthened, making the target causal graph more closely reflect the actual operational characteristics of the target component. Based on the updated target causal graph, second test cases can be selected, accurately extracting test cases covering core causal paths, key functions of related components, or high-risk points. While ensuring complete test coverage, redundant test cases are significantly reduced, lowering test case execution time and hardware resource consumption. Simultaneously, the dynamic integration of historical operational information allows the causal model to adapt to different operating environments and version variations of the target component, giving the testing process stronger generalization capabilities. This eliminates the need to redesign a complete set of test cases for every component change, significantly improving the generalization ability of the testing method provided in this disclosure.

[0114] Figure 6 This is a block diagram illustrating an electronic device 300 according to an exemplary embodiment. Figure 6 As shown, the electronic device 300 may include a processor 301 and a memory 302. The electronic device 300 may also include one or more of a multimedia component 303, an input / output (I / O) interface 304, and a communication component 305.

[0115] The processor 301 controls the overall operation of the electronic device 300 to complete all or part of the steps in the execution method of the aforementioned test cases. The memory 302 stores various types of data to support the operation of the electronic device 300. This data may include, for example, instructions for any application or method operating on the electronic device 300, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 302 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, disk, or optical disk. The multimedia component 303 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 302 or transmitted via communication component 305. The audio component also includes at least one speaker for outputting audio signals. I / O interface 304 provides an interface between processor 301 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 305 is used for wired or wireless communication between the electronic device 300 and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof; therefore, the corresponding communication component 305 may include a Wi-Fi module, a Bluetooth module, or an NFC module.

[0116] In an exemplary embodiment, the electronic device 300 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the above-described test case execution method.

[0117] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the test case execution method described above. For example, the computer-readable storage medium may be the memory 302 including the program instructions described above, which may be executed by the processor 301 of the electronic device 300 to complete the test case execution method described above.

[0118] In another exemplary embodiment, a computer program product is also provided, which includes a computer program executable by a processor, wherein the computer program, when executed by the processor, implements the steps of the above-described test case execution method.

[0119] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0120] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0121] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A method for executing test cases, characterized in that, The method includes: Obtain the initial cause-effect graph corresponding to the target component and the historical running information of the target component. The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationship between the execution steps of the multiple first test cases. The historical running information is the running record of the target component when executing historical test cases within a historical time period. Based on the historical operation information, the initial causal graph is updated to obtain the target causal graph; Based on the target cause-effect graph, obtain multiple second test cases to be tested corresponding to the target component from multiple first test cases; Execute multiple second test cases to test the target component.

2. The method according to claim 1, characterized in that, The step of updating the initial causal graph based on the historical operation information to obtain the target causal graph includes: Based on the historical operation information, identify the abnormal test cases that contain anomalies in the historical test cases; Based on the abnormal test cases, the initial cause-effect graph is updated to obtain the target cause-effect graph.

3. The method according to claim 2, characterized in that, The initial cause-effect graph includes multiple first nodes and multiple directed edges. Each first node represents an execution step of the first test case. Multiple first nodes connected by directed edges constitute a test case. The step of updating the initial cause-effect graph based on the abnormal test cases to obtain the target cause-effect graph includes: Based on the abnormal test cases, update at least one of the node state, node attributes, node constraints, and directed edge weights of the first node of the initial causal graph to obtain the target causal graph.

4. The method according to claim 3, characterized in that, The step of obtaining multiple second test cases to be tested corresponding to the target component from multiple first test cases based on the target cause-effect graph includes: Based on the target cause-effect graph, with the goal of covering more key nodes, more cause-effect paths, and more other nodes related to key nodes, multiple third test cases are obtained from multiple first test cases; Based on multiple third test cases, determine multiple second test cases.

5. The method according to claim 4, characterized in that, The determination of multiple second test cases based on multiple third test cases includes: Obtain the test scenarios, version change information, and known defect information of the target component; Based on the historical operation information, the test scenario, the version change information, and the known defect information, multiple second test cases are selected from multiple third test cases.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the target dependencies corresponding to multiple second test cases; Based on the target dependency relationship, the multiple second test cases are divided into multiple test case groups, and the second test cases contained in each test case group have a dependency relationship; Based on multiple test case groups, determine the target execution order of multiple second test cases; The execution of multiple second test cases to test the target component includes: Multiple second test cases are executed in the order of the target execution to test the target component.

7. The method according to claim 6, characterized in that, The target dependency is determined in the following way: The second test case is parsed to determine its static dependencies, which include function call relationships and data dependencies. Based on historical runtime information, determine the dynamic dependencies of the second test case; The target dependency is determined based on the static dependency and the dynamic dependency.

8. A test case execution device, characterized in that, The device includes: The first acquisition module is used to acquire the initial cause-effect graph corresponding to the target component and the historical running information of the target component. The initial cause-effect graph is generated based on multiple first test cases corresponding to the target component and is used to characterize the causal relationship between the execution steps of the multiple first test cases. The historical running information is the running record of the target component when executing historical test cases within a historical time period. The update module is used to update the initial causal graph based on the historical operation information to obtain the target causal graph; The second acquisition module is used to acquire multiple second test cases to be tested corresponding to the target component from multiple first test cases based on the target cause-effect graph. The execution module is used to execute multiple second test cases to test the target component.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1 to 7.

Images