Test execution order control method, device, apparatus and storage medium

Abstract

The application relates to the field of software test automation, and in particular to a test execution sequence control method and device, equipment and a storage medium. In view of the problems of dependency configuration expansion, maintenance reuse difficulty, low execution efficiency and insufficient stability of the prior art in a complex test dependency scenario, a sequence control scheme based on a grouping dependency network is provided. The scheme first performs multi-level nested grouping on test cases according to function logic to form a hierarchical structure from a root layer to a leaf layer, then constructs a dependency relationship network according to the directed dependency between each group, calculates the execution order of each group, and combines the dependency constraints to implement mixed scheduling of series and parallel, drive the test case execution in the leaf group and output the result. The scheme can improve the organization and management efficiency of complex dependency relationships, reduce the configuration maintenance cost, improve the test resource utilization rate and overall execution efficiency, and enhance the stability and repeatability of the test result.

Description

Technical Field

[0001] This application relates to the field of software test automation, and in particular to a test execution sequence control method, apparatus, device, and storage medium. Background Technology

[0002] In the field of software test automation, existing technologies typically manage the dependencies between test cases based on tags, annotations, or framework plugins, and control the execution order accordingly.

[0003] However, when faced with multi-level and multi-relationship dependency topologies in large-scale testing scenarios, such solutions are prone to problems such as complex dependency configuration and difficulty in reuse and expansion. At the same time, due to the lack of grouping and abstraction of test cases and hierarchical dependency topology management, their ability to adapt to the execution order optimization in complex dependency scenarios is limited, resulting in low test execution efficiency.

[0004] Therefore, how to balance dependency management efficiency and execution order optimization in complex testing scenarios has become a technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a test execution order control method, apparatus, device, and storage medium to solve the aforementioned technical problems. This solution addresses complex test dependency scenarios by hierarchically organizing test objects and uniformly modeling their dependencies. Based on this, it performs order control and scheduling management of the test execution process, thereby ensuring that dependency constraints are met while also considering management efficiency, execution efficiency, and execution stability in large-scale test tasks.

[0006] In a first aspect, embodiments of this application provide a test execution order control method, including:

[0007] Get the test case set;

[0008] The test case set is organized into multi-level nested test groups according to functional logic. The multi-level nested test groups include a root group, a parent group, a child group, and a leaf group containing the actual test cases.

[0009] Construct a group dependency network based on the directed dependencies between test groups;

[0010] Based on the group dependency network, calculate the target execution order of each test group;

[0011] Based on the target execution order and group dependencies, a serial-parallel hybrid scheduling is performed on each test group to execute the actual test cases in the leaf groups and output the test results.

[0012] In one possible embodiment, the test case set is organized into multi-level nested test groups according to functional logic, including:

[0013] Divide the test case set into different leaf groups according to functional logic;

[0014] Based on the business affiliation of each leaf group, each leaf group is aggregated into subgroups, parent groups, and root groups, forming multi-level nested test groups.

[0015] In one possible embodiment, a group dependency network is constructed based on the directed dependencies between test groups, including:

[0016] Based on the business logic relationship of the test groups, determine the preceding groups that the target group in the test group depends on, so as to obtain the directed dependency relationship between the test groups;

[0017] Based on directed dependencies, a grouped dependency network is constructed.

[0018] In one possible embodiment, the target execution order of each test group is calculated based on the group dependency network, including:

[0019] Based on the directed dependencies between test groups in the group dependency network, the test groups are sorted to obtain the target execution order that satisfies all directed dependencies.

[0020] In one possible embodiment, a hybrid serial-parallel scheduling is performed on each test group according to the target execution order and group dependencies, including:

[0021] Based on the target execution order and group dependencies, determine the execution mode for each test group;

[0022] Based on a preset state aggregation strategy, the execution conditions for each test group are determined;

[0023] Based on the historical test data of each test group, determine the optimized scheduling strategy;

[0024] Based on the target execution order, the execution mode of each test group, the execution conditions, and the optimization scheduling strategy, a test execution plan is generated. The test execution plan includes a set of serial test groups that have prerequisite dependencies and are depended on by subsequent test groups, and a set of parallel test groups that have no dependency relationship with test groups at the same level.

[0025] According to the test execution plan, serial scheduling is performed on the test groups in the serial test group set, and parallel scheduling is performed on the test groups in the parallel test group set.

[0026] In one possible embodiment, the execution conditions for each test group are determined based on a preset state aggregation strategy, including:

[0027] Get the execution status of the prerequisite groups of the test group;

[0028] Based on the state aggregation strategy, the execution state of the preceding dependency group is used to calculate the execution conditions of each test group.

[0029] In one possible embodiment, the execution conditions for each test group are calculated based on the execution state of the preceding dependency groups using a state aggregation strategy, including:

[0030] When the state aggregation strategy is in strict mode, the execution condition is determined to be met when all the preceding dependency groups of the test group execute successfully.

[0031] When the state aggregation strategy is in lenient mode, the execution condition is determined to be met when any of the preceding dependent groups of the test group executes successfully.

[0032] When the state aggregation strategy is the majority voting mode, the execution condition is determined to be met when the preset number of pre-dependent groups of the test group execute successfully.

[0033] When the state aggregation strategy is a user-defined mode, it is determined whether the execution status of the preceding dependency group meets the execution conditions based on the user-preset rules.

[0034] If the execution conditions are not met, skip the execution of the test group.

[0035] In one possible embodiment, after constructing the grouped dependency network based on dependencies, the method further includes:

[0036] Perform full-process circular dependency detection on the group dependency network; the full-process circular dependency detection includes at least configuration phase detection, resolution phase detection, collection phase detection and execution phase detection.

[0037] Secondly, embodiments of this application provide a test execution order control device, the device comprising:

[0038] The acquisition module is used to acquire a set of test cases;

[0039] The grouping module is used to organize the test case set into multi-level nested test groups according to functional logic. The multi-level nested test groups include the root group, parent group, child group, and leaf group containing the actual test cases.

[0040] The building module is used to construct a group dependency network based on the directed dependencies between test groups;

[0041] The sorting module is used to calculate the target execution order of each test group based on the group dependency network;

[0042] The scheduling module is used to perform a hybrid serial-parallel scheduling of each test group according to the target execution order and group dependencies, so as to execute the actual test cases in the leaf group and output the test results.

[0043] In one possible implementation, the grouping module is specifically used for:

[0044] Divide the test case set into different leaf groups according to functional logic;

[0045] Based on the business affiliation of each leaf group, each leaf group is aggregated into subgroups, parent groups, and root groups, forming multi-level nested test groups.

[0046] In one possible implementation, the building module is specifically used for:

[0047] Based on the business logic relationship of the test groups, determine the preceding groups that the target group in the test group depends on, so as to obtain the directed dependency relationship between the test groups;

[0048] Based on directed dependencies, a grouped dependency network is constructed.

[0049] In one possible implementation, the sorting module is specifically used for:

[0050] Based on the directed dependencies between test groups in the group dependency network, the test groups are sorted to obtain the target execution order that satisfies all directed dependencies.

[0051] In one possible implementation, the scheduling module is specifically used for:

[0052] Based on the target execution order and group dependencies, determine the execution mode for each test group;

[0053] Based on a preset state aggregation strategy, the execution conditions for each test group are determined;

[0054] Based on the historical test data of each test group, determine the optimized scheduling strategy;

[0055] Based on the target execution order, the execution mode of each test group, the execution conditions, and the optimization scheduling strategy, a test execution plan is generated. This test execution plan includes a set of serial test groups that have prerequisite dependencies and are depended on by subsequent test groups, as well as a set of parallel test groups that have no dependency relationship with peer test groups.

[0056] According to the test execution plan, serial scheduling is performed on the test groups in the serial test group set, and parallel scheduling is performed on the test groups in the parallel test group set.

[0057] In one possible implementation, the scheduling module is specifically used for:

[0058] Get the execution status of the prerequisite groups of the test group;

[0059] Based on the state aggregation strategy, the execution state of the preceding dependency group is used to calculate the execution conditions of each test group.

[0060] In one possible implementation, the scheduling module is specifically used for:

[0061] When the state aggregation strategy is in strict mode, the execution condition is determined to be met when all the preceding dependency groups of the test group execute successfully.

[0062] When the state aggregation strategy is in lenient mode, the execution condition is determined to be met when any of the preceding dependent groups of the test group executes successfully.

[0063] When the state aggregation strategy is the majority voting mode, the execution condition is determined to be met when the preset number of pre-dependent groups of the test group execute successfully.

[0064] When the state aggregation strategy is a user-defined mode, it is determined whether the execution status of the preceding dependency group meets the execution conditions based on the user-preset rules.

[0065] If the execution conditions are not met, skip the execution of the test group.

[0066] In one possible implementation, the device further includes:

[0067] The detection module is used to perform full-process circular dependency detection on the group dependency network after the build module constructs it; the full-process circular dependency detection includes at least configuration phase detection, parsing phase detection, collection phase detection and execution phase detection.

[0068] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0069] The memory stores the instructions that the computer executes;

[0070] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect.

[0071] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement methods such as those described in the first aspect and / or various possible implementations of the first aspect.

[0072] The test execution order control method, apparatus, device, and storage medium provided in this application obtain a set of test cases and organize the set of test cases into multi-level nested test groups according to functional logic. By combining the directed dependency relationships between test groups to construct a group dependency relationship network, complex test dependencies can be uniformly expressed and managed at the group level, reducing the complexity of dependency configuration. By calculating the target execution order of each test group based on the group dependency relationship network, and performing serial and parallel hybrid scheduling on each test group according to the target execution order and group dependency relationships, the orderliness and resource utilization efficiency of test execution can be improved while satisfying dependency constraints, thereby improving the execution efficiency, result stability, and scalability and reusability in large-scale test scenarios. Attached Figure Description

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

[0074] Figure 1 A schematic diagram of the overall system architecture of a test execution order control method provided in this application;

[0075] Figure 2 Flowchart of the test execution order control method provided in this application Figure 1 ;

[0076] Figure 3 Flowchart of the test execution order control method provided in this application Figure 2 ;

[0077] Figure 4 Flowchart of the test execution order control method provided in this application Figure 3 ;

[0078] Figure 5 Flowchart of the test execution order control method provided in this application Figure 4 ;

[0079] Figure 6 Flowchart of the test execution order control method provided in this application Figure 5 ;

[0080] Figure 7 Flowchart of the test execution order control method provided in this application Figure 6 ;

[0081] Figure 8 A schematic diagram of the test execution sequence control device provided in this application;

[0082] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0083] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0084] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0085] First, let me explain the terms used in this application:

[0086] Test case set: refers to the summary of all test cases to be executed. It is the input data source for the test execution order control method and usually contains test cases corresponding to multiple functional modules or business scenarios.

[0087] Test groups are hierarchical structural units formed by organizing and managing a collection of test cases according to functional logic. Test groups include root groups, parent groups, child groups, and leaf groups. The root group is the top-level group, the parent and child groups are intermediate-level groups, and the leaf groups are the bottom-level groups containing the actual test cases. Through multi-level nested structures, a large number of test cases are abstracted and aggregated according to their business affiliation.

[0088] Directed dependency: refers to the preceding and following constraint relationship formed between test groups based on business logic. It is represented by a directed edge from one group to another, indicating that the target group must wait for its preceding group to complete before it can be executed.

[0089] Group dependency network: This refers to a data structure built based on the directed dependencies between test groups, used to describe the constraints between test groups in terms of execution order. This network typically uses both adjacency lists and adjacency matrices for storage, supporting efficient dependency query and update operations.

[0090] Target execution order: refers to the test group execution sequence that satisfies all directed dependencies, calculated by a hierarchical-aware topology sorting algorithm based on the group dependency network, ensuring that each group only starts execution after all its preceding dependent groups have been executed.

[0091] Hybrid serial-parallel scheduling refers to a scheduling method that dynamically selects between serial and parallel execution strategies for each test group based on the target execution order and group dependencies. Serial scheduling is used for groups with prerequisite dependencies that are also depended upon by subsequent groups, while parallel scheduling is used for groups at the same level that have no dependencies on each other, thus balancing execution correctness and efficiency.

[0092] Functional logic refers to the logical division of software functional modules or business scenarios verified by test cases, serving as a classification standard for dividing the test case set into different leaf groups.

[0093] Business attribution relationship: refers to the hierarchical relationship between leaf groups based on the business areas or functional modules they cover, used to aggregate leaf groups upwards into subgroups, parent groups, and root groups.

[0094] Business logic relationships refer to the mutual dependencies between test groups based on the business processes or function call relationships of the software system, which serve as the basis for determining the preceding groups that the target group depends on.

[0095] Pre-determined group: In a group dependency network, the target group must wait for its execution to complete before it can be executed. It is the starting group for forming a directed dependency.

[0096] Hierarchical-aware topology sorting algorithm: This is an optimized algorithm that introduces hierarchical information of groupings into traditional topology sorting, used to calculate the target execution order of test groups. This algorithm is based on Kahn's algorithm, with a time complexity optimized to O(m+e), where m is the number of groups and e is the number of dependent edges.

[0097] Execution mode: refers to the execution method assigned to test groups in the test execution plan, including serial execution mode and parallel execution mode, which is determined by the group dependencies and the target execution order.

[0098] State aggregation strategy: This refers to the set of rules used to determine the execution conditions of a test group. It calculates whether the current group meets the execution conditions based on the execution state of the preceding dependent groups. State aggregation strategies include strict mode, lenient mode, majority voting mode, and user-defined mode.

[0099] Strict mode: This refers to a state aggregation strategy that requires all preceding dependent groups of a test group to execute successfully before determining that the execution condition of the test group is met.

[0100] Relaxed mode: refers to a state aggregation strategy that requires that the execution condition of a test group is satisfied when any of its preceding dependent groups executes successfully.

[0101] Majority voting mode: This refers to a state aggregation strategy that requires a pre-set number of pre-dependent groups of a test group to execute successfully before determining that the execution condition of the test group is met.

[0102] User-defined mode: This refers to a state aggregation strategy that allows users to flexibly define whether the execution status of pre-dependent groups meets the execution conditions based on preset rules, in order to adapt to the needs of special business scenarios.

[0103] Test execution plan: refers to a complete execution scheme generated based on the target execution order, the execution mode of each test group, the execution conditions, and the optimization scheduling strategy, including the set of serial test groups and the set of parallel test groups.

[0104] Optimized scheduling strategy: This refers to a strategy that dynamically adjusts scheduling parameters based on historical test data of each test group. It is used to optimize resource allocation and parallelism configuration for subsequent test execution based on historical execution data.

[0105] Full-process circular dependency detection refers to a mechanism that performs circular dependency detection on the grouped dependency network during the test execution order control process, specifically at the configuration, parsing, collection, and execution phases. The configuration phase checks basic syntax compliance and group structure; the parsing phase performs dependency semantic parsing and preliminary circular dependency detection; the collection phase performs final circular dependency verification based on the complete dependency network; and the execution phase dynamically monitors the dependency status during test runtime.

[0106] Adjacency list: refers to a storage structure for group dependency networks. It records the direct predecessor groups by maintaining a dependency list for each test group, supporting efficient dependency queries.

[0107] Adjacency matrix: This refers to another storage structure for group dependency networks. It records the dependencies between test groups using a two-dimensional matrix, supporting fast dependency determination.

[0108] State machine model: refers to the data model used in the execution control layer to manage the test execution state, supporting real-time tracking, pause and resume operations of the test execution state, and ensuring the reliability and controllability of test execution.

[0109] Distributed environment: refers to an environment in which test cases are executed in parallel on multiple physical or virtual nodes. In this environment, a message passing mechanism is needed to ensure the consistency of the test execution status among the nodes.

[0110] In the field of software test automation technology, as software systems continue to expand in scale and the number of test cases grows dramatically, test dependency management faces severe challenges. Existing technologies typically employ test case-level dependency management solutions, such as general software dependency management systems based on model-based architecture and intelligent routing of work items, or simple dependency chain management plugins based on tagged dependencies.

[0111] However, use case-level dependency management leads to an exponential increase in the number of dependencies with the number of use cases, causing a combinatorial explosion problem. At the same time, existing solutions lack intelligent serial and parallel hybrid execution strategies, resulting in low execution efficiency. They are also often deeply coupled with specific testing frameworks, lacking sufficient architectural abstraction and making it difficult to reduce management complexity through grouping abstraction. Consequently, they cannot adapt to large-scale complex testing scenarios.

[0112] Existing test execution order control technologies have the following problems: high dependency management complexity, with a large-scale network of test case-level dependencies that is difficult to maintain; low execution efficiency, lacking the ability to dynamically select serial or parallel execution strategies based on dependencies; insufficient architectural abstraction, failing to effectively reduce management complexity through grouping abstraction; and insufficient technical versatility, with existing solutions deeply bound to specific test frameworks, resulting in high migration and extension costs.

[0113] To address the aforementioned issues, this application provides a test execution order control method and apparatus. By organizing a set of test cases into multi-level nested test groups according to functional logic, a directed dependency network is constructed at the group level. The target execution order is calculated based on a hierarchical-aware topology sorting algorithm, and a hybrid serial-parallel scheduling is performed according to the group dependencies. Simultaneously, multiple state aggregation strategies and a full-process circular dependency detection mechanism are integrated. This significantly reduces dependency management complexity from O(n²) at the test case level to O(m²) at the group level, improving test execution efficiency, enhancing test case maintainability, supporting flexible expansion in large-scale complex test scenarios, and possessing good technical versatility.

[0114] Figure 1 This is a schematic diagram of the overall system architecture for a test execution order control method provided in this application. Figure 1 As shown, in the specific application scenario of this application, the system adopts a three-level layered architecture design, including a configuration planning layer, an intelligent scheduling layer, and an execution control layer. The test case set, as the system input, first enters the configuration planning layer. The configuration planning layer outputs the constructed group dependency network to the intelligent scheduling layer. The intelligent scheduling layer outputs the generated test execution plan to the execution control layer. The execution control layer finally outputs the test results.

[0115] The configuration planning layer is responsible for defining the test group structure and modeling dependencies; the intelligent scheduling layer is responsible for calculating and scheduling the execution order; and the execution control layer is responsible for the actual execution and state management of test cases. The configuration planning layer and the intelligent scheduling layer transmit the group dependency network, and the intelligent scheduling layer and the execution control layer transmit the test execution plan.

[0116] In this embodiment, the configuration planning layer includes at least a grouping structure definition module and a dependency modeling module. The grouping structure definition module organizes the test case set into multi-level nested test groups according to functional logic. These nested test groups include a root group, parent group, child group, and leaf groups containing actual test cases. The dependency modeling module constructs a grouping dependency network based on the directed dependencies between test groups. This network uses a directed acyclic graph structure to describe the execution order constraints between test groups. The configuration planning layer transmits the constructed grouping dependency network to the intelligent scheduling layer.

[0117] The intelligent scheduling layer includes at least a topology sorting module, a serial-parallel hybrid scheduling module, and a state aggregation strategy module. The topology sorting module calculates the target execution order for each test group based on the group dependency network. The serial-parallel hybrid scheduling module determines the set of serial test groups and the set of parallel test groups based on the target execution order and group dependencies, and generates a test execution plan. The state aggregation strategy module determines the execution conditions for the current test group based on the execution status of the preceding dependent groups, supporting strict mode, lenient mode, majority voting mode, and user-defined mode. The intelligent scheduling layer then distributes the test execution plan, which includes the execution order, parallel set, and execution conditions, to the execution control layer.

[0118] The execution control layer includes at least a test case execution module, a state tracking module, and a circular dependency detection module. The test case execution module executes the actual test cases in the leaf groups according to the test execution plan. The state tracking module tracks the execution status of the test groups and records historical test data. The circular dependency detection module dynamically monitors the dependency network of the groups at runtime, detecting circular dependencies and execution anomalies. The execution control layer ultimately outputs the test results.

[0119] The test execution order control method provided in this application organizes the test case set into multi-level nested test groups according to functional logic and constructs a directed acyclic graph dependency network at the group level. It calculates the target execution order based on a hierarchical perceptual topology sorting algorithm, performs serial and parallel hybrid scheduling according to the group dependency relationship, and integrates state aggregation strategy and full-process circular dependency detection mechanism. This solves the technical problems of high dependency management complexity, low execution efficiency, insufficient architectural abstraction, and inability to reduce management complexity through group abstraction in the prior art.

[0120] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0121] Figure 2 Flowchart of the test execution order control method provided in this application Figure 1 ,like Figure 2 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0122] S201. Obtain the test case set.

[0123] The test case set is a compilation of all test cases to be executed, typically sourced from a test case library or test management platform. It covers test cases corresponding to various functional modules or business scenarios of the software under test. In this step, the system first reads all test cases corresponding to the current test task, forming a unified test case set to provide a data foundation for subsequent grouping and organization. For example, in an e-commerce system testing scenario, the test case set could cover test cases corresponding to functional modules such as user registration, user login, product browsing, shopping cart management, order creation, payment processing, and logistics tracking.

[0124] S202. Organize the test case set into multi-level nested test groups according to functional logic. The multi-level nested test groups include a root group, a parent group, a child group, and a leaf group containing the actual test cases.

[0125] This step is executed by the configuration planning layer, which uses a tree-like data structure to organize and manage the test case set. Each test group includes attributes such as group identifier, group name, parent group identifier, and a list of test cases. The system divides the test case set into different leaf groups according to functional logic. The leaf groups, as leaf nodes in the tree structure, directly contain the actual test cases. Furthermore, based on the business affiliation of each leaf group, each leaf group is aggregated upwards into sub-groups and parent groups, ultimately forming the root group, thus constructing a multi-level nested structure of root group → parent group → sub-group → leaf group. Through this grouping abstraction mechanism, a large number of test cases are organized into structured test groups according to business logic, reducing the dependency management complexity from O(n²) at the test case level to O(m²) at the group level, where m is the number of groups and is much smaller than n.

[0126] For example, test cases for user registration, user login, and password reset are grouped into the user authentication leaf group, while test cases for product search and product details viewing are grouped into the product browsing leaf group. Further, the user authentication leaf group and the user information management leaf group are aggregated into a user module subgroup, and the product browsing leaf group and the shopping cart management leaf group are aggregated into a product module subgroup. Then, the user module subgroup and the product module subgroup are aggregated into a front-end business parent group, and finally, all parent groups converge to form the root group.

[0127] S203. Construct a group dependency network based on the directed dependencies between test groups.

[0128] This step is also executed by the configuration planning layer, which is responsible for modeling the dependencies between test groups. Based on the business logic relationships of the test groups, the system determines the preceding groups that each target group depends on, thus obtaining the directed dependencies between the test groups. A directed dependency is represented by a directed edge from one group to another, indicating that a target group must wait for its preceding group to complete before execution. Based on these directed dependencies, the system constructs a group dependency network, which uses a directed acyclic graph structure to describe the execution order constraints between test groups. For data storage, dependencies are stored using both adjacency lists and adjacency matrices. Adjacency lists support efficient dependency queries, while adjacency matrices support fast dependency determination; the combination of the two balances query efficiency and storage compactness. Simultaneously, the system implements a group registration mechanism, supporting the dynamic addition and deletion of test groups, ensuring the dependency network has good scalability.

[0129] For example, the order processing group depends on the user authentication group because placing an order requires user login; the payment processing group depends on the order processing group because payment requires order creation. Thus, a directed dependency relationship is established between the user authentication group, the order processing group, and the payment processing group. An adjacency list is used to record the direct prerequisite dependencies of each group, and an adjacency matrix is ​​used to mark whether a dependency path exists between any two groups.

[0130] S204. Based on the group dependency network, calculate the target execution order of each test group.

[0131] This step is executed by the intelligent scheduling layer. Based on the directed dependencies between test groups in the group dependency network, the system uses a hierarchical-aware topology sorting algorithm to sort the test groups and calculate the target execution order that satisfies all directed dependencies. This algorithm introduces hierarchical information about the groups on top of the traditional Kahn algorithm, processing group nodes with zero in-degree layer by layer, thus optimizing the time complexity to O(m+e), where m is the number of groups and e is the number of dependent edges. The calculated target execution order ensures that each group only begins execution after all its preceding dependent groups have been executed, thereby guaranteeing the correctness of the test execution.

[0132] For example, consider a group dependency network comprising user authentication, product browsing, order processing, payment processing, and logistics tracking groups. Assume the product browsing group has no prior dependencies, the user authentication group has no prior dependencies, the order processing group depends on the user authentication group, the payment processing group depends on the order processing group, and the logistics tracking group depends on the payment processing group. The hierarchical-aware topology sorting algorithm first uses the user authentication group and the product browsing group (both with an in-degree of zero) as the first-level execution sequence. After the user authentication group completes, the order processing group's in-degree is reduced to zero, entering the second-level execution sequence. After the order processing group completes, the payment processing group enters the third-level execution sequence. Finally, the logistics tracking group enters the fourth-level execution sequence. The resulting target execution order satisfies all dependency constraints while maximizing the parallel execution opportunities for sibling groups.

[0133] S205. Based on the target execution order and group dependency, perform serial-parallel hybrid scheduling on each test group to execute the actual test cases in the leaf group and output the test results.

[0134] This step is executed collaboratively by the intelligent scheduling layer and the execution control layer. The intelligent scheduling layer determines the execution mode for each test group based on the target execution order and group dependencies. Groups with prerequisite dependencies that are also depended upon by subsequent test groups are determined to be executed in a serial execution mode; groups without dependencies among themselves are determined to be executed in a parallel execution mode. Further, the execution conditions for each test group are determined based on preset state aggregation strategies, including strict mode, lenient mode, majority voting mode, and user-defined mode. Strict mode requires all prerequisite dependent groups to execute successfully to satisfy the execution condition; lenient mode requires any prerequisite dependent group to execute successfully to satisfy the execution condition; majority voting mode requires a preset number of prerequisite dependent groups to execute successfully to satisfy the execution condition; user-defined mode allows for flexible determination of execution conditions based on preset rules. If the execution condition is not met, the execution of that test group is skipped.

[0135] Simultaneously, the system determines optimized scheduling strategies based on historical test data for each test group. For example, it dynamically adjusts parallelism allocation based on historical execution duration and optimizes resource allocation based on historical failure rates. Based on the target execution order, the execution mode and conditions of each test group, and the optimized scheduling strategy, a test execution plan is generated. This plan includes a set of serial test groups and a set of parallel test groups. The execution control layer executes serial scheduling for the test groups in the serial test group set and parallel scheduling for the test groups in the parallel test group set according to the test execution plan. Finally, it executes the actual test cases in the leaf groups and outputs the test results. During execution, the execution control layer uses a state machine model to manage the test execution state, supports pause and resume operations, and ensures state consistency in a distributed environment through a message passing mechanism.

[0136] For example, in the e-commerce system test scenario described above, the first layer of the target execution order includes a user authentication group and a product browsing group. Since there is no dependency between them, they are included in the parallel test group set and allocated to different execution nodes for parallel execution. The second layer includes an order processing group, which depends on the user authentication group and is subsequently depended upon by the payment processing group. Therefore, it is included in the serial test group set and executed serially after the user authentication group completes. The third layer includes the payment processing group, which is also included in the serial test group set. If a strict mode state aggregation strategy is adopted, the order processing group must wait for all test cases in the user authentication group to execute successfully before starting. If the user authentication group fails, the execution conditions for the order processing group are not met, and the system automatically skips the execution of this group and its subsequent dependent groups, avoiding unnecessary test resource consumption.

[0137] The test execution order control method provided in this application organizes the test case set into multi-level nested test groups according to functional logic, constructs a directed acyclic graph dependency network at the group level, calculates the target execution order based on the hierarchical perceptual topology sorting algorithm, performs serial and parallel hybrid scheduling according to the group dependency relationship, and integrates state aggregation strategy and full-process circular dependency detection mechanism. This solves the technical problems of high dependency management complexity, low execution efficiency, insufficient architectural abstraction, and inability to reduce management complexity through group abstraction in the prior art.

[0138] Figure 3 Flowchart of the test execution order control method provided in this application Figure 2 ,like Figure 3 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0139] S301. Divide the test case set into different leaf groups according to the functional logic.

[0140] Leaf groups are the lowest-level groups containing actual test cases; they are the leaf nodes in the test group tree structure. Functional logic refers to the logical division of software functional modules or business scenarios verified by the test cases, serving as the classification standard for dividing the test case set into different leaf groups. Actual test cases refer to executable test scripts or test programs written for specific software functional points.

[0141] In this step, the system divides the test case set into different leaf groups according to functional logic. Each leaf group contains attributes such as a group identifier, group name, and a list of test cases, directly carrying the actual test cases. Through functional logic division, test cases verifying the same functional module or business scenario are grouped into the same leaf group, achieving initial classification and management of test cases.

[0142] For example, in an e-commerce system testing scenario, test cases for user authentication functions such as user registration, user login, and password reset are grouped into the user authentication leaf group; test cases for product browsing functions such as product search, product details viewing, and inventory query are grouped into the product browsing leaf group; test cases for order processing functions such as order creation, order query, and order cancellation are grouped into the order processing leaf group; and test cases for payment transaction functions such as online payment, refund processing, and bill query are grouped into the payment transaction leaf group. Each leaf group contains actual test cases, serving as the basic unit for subsequent hierarchical aggregation.

[0143] S302. Based on the business affiliation of each leaf group, each leaf group is aggregated into subgroups, parent groups and root groups, forming multi-level nested test groups.

[0144] In this context, business affiliation refers to the hierarchical relationship between leaf groups based on the business domains or functional modules they cover. Subgroups are intermediate-level groups formed by aggregating one or more leaf groups, used to manage test case sets within the same business subdomain. Parent groups are high-level groups formed by aggregating one or more subgroups, used to manage test case sets within the same major business domain. The root group is the top-level group in the tree structure, containing all lower-level groups and serving as the root node of the entire test case set. Multi-level nested test groups refer to a hierarchical tree structure formed by root groups, parent groups, subgroups, and leaf groups, enabling layered abstract management of test cases.

[0145] In this step, the system aggregates each leaf group into sub-groups, parent groups, and root groups based on their business affiliation, forming multi-level nested test groups. Specifically, leaf groups with close business relationships are first aggregated into sub-groups, then sub-groups under the same business domain are aggregated into parent groups, and finally, all parent groups are aggregated into root groups, constructing a tree-like hierarchical structure of root group → parent group → sub-group → leaf group. This structure is organized using a tree-like data structure, with each group containing attributes such as group identifier, group name, parent group identifier, and a list of test cases. It supports a group registration mechanism, allowing dynamic addition and deletion of test groups. Through a hierarchical abstraction mechanism, a large number of test cases are organized into structured test groups according to functional logic, reducing dependency management complexity from O(n²) at the test case level to O(m²) at the group level, where m is the number of groups and is much smaller than n.

[0146] For example, aggregation is performed hierarchically based on business affiliation: the user authentication leaf group and the user information management leaf group are aggregated into a user module subgroup; the product browsing leaf group and the shopping cart management leaf group are aggregated into a product module subgroup; and the order processing leaf group and the payment transaction leaf group are aggregated into a transaction module subgroup. Further, the user module subgroup and the product module subgroup are aggregated into a front-end business parent group, and the transaction module subgroup and the logistics module subgroup are aggregated into a back-end business parent group. Finally, all parent groups are aggregated into a root group, forming a complete multi-level nested structure: root group → front-end business parent group, back-end business parent group → user module subgroup, product module subgroup, transaction module subgroup, logistics module subgroup → each leaf group.

[0147] The test execution order control method provided in this application divides the test case set into different leaf groups according to functional logic, and aggregates them into sub-groups, parent groups and root groups based on the business affiliation of each leaf group, forming multi-level nested test groups. This achieves hierarchical abstract management of test cases, reduces the complexity of dependency management from the test case level to the group level, and solves the technical problems of high dependency management complexity and combinatorial explosion caused by test case level dependencies in the prior art.

[0148] Figure 4 Flowchart of the test execution order control method provided in this application Figure 3 ,like Figure 4 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0149] S401. Based on the business logic relationship of the test groups, determine the predecessor groups that the target group in the test group depends on, so as to obtain the directed dependency relationship between the test groups.

[0150] In this context, business logic relationships refer to the mutual dependencies between test groups based on the business processes or function calls of the software system. A target group is the test group whose execution conditions need to be determined. A preceding group is a test group in the group dependency network that the target group must wait for to complete before it can execute. A directed dependency relationship refers to the preceding and subsequent constraints between test groups based on business logic relationships; it is represented by a directed edge from one group to another, indicating that the target group must wait for its preceding group to complete before it can execute.

[0151] In this step, the system determines the preceding groups that the target group in the test group depends on, based on the business logic relationships of the test groups, thus obtaining the directed dependencies between the test groups. Specifically, the system analyzes the business functions covered by each test group and the calling relationships between these functions, identifying other groups that the current group must depend on before execution, thereby establishing a directed dependency relationship from the preceding group to the target group. This directed dependency relationship is represented by a directed edge, with the edge pointing from the preceding group to the target group, indicating that the target group can only start after the preceding group has completed execution.

[0152] For example, in an e-commerce system test scenario, the order processing group requires user login authentication as a prerequisite. Therefore, the order processing group is determined as the target group, and the user authentication group is its predecessor group, establishing a directed dependency relationship between the user authentication group and the order processing group. Similarly, the payment processing group requires successful order creation as a prerequisite. Therefore, the payment processing group is determined as the target group, and the order processing group is its predecessor group, establishing a directed dependency relationship between the order processing group and the payment processing group. The product browsing group can be completed without depending on other groups; therefore, this group has no forward dependency and no predecessor dependency needs to be established.

[0153] S402. Construct a grouped dependency network based on directed dependency relationships.

[0154] The group dependency network is a data structure built based on the directed dependencies between test groups, used to describe the constraints between test groups in terms of execution order. This network uses a directed acyclic graph structure to ensure that there are no circular cycles in the dependencies between test groups, thus guaranteeing the computability of the execution order. For data storage, dependencies are stored using a dual approach: adjacency lists and adjacency matrices. Adjacency lists support efficient dependency queries and updates, while adjacency matrices support fast dependency determination. The combination of these two methods balances query efficiency with storage compactness.

[0155] In this step, the system constructs a group dependency network based on the established directed dependencies. Specifically, the system treats each test group as a network node and each directed dependency as a network edge, constructing a complete directed acyclic graph structure. Simultaneously, the system uses an adjacency list to record the direct preceding dependencies of each group and an adjacency matrix to mark whether a dependency path exists between any two groups, achieving dual storage to support efficient querying. It should be noted that the above example uses matrix elements with values ​​of 1 and 0; in actual applications, the specific marking method for each position in the adjacency matrix can be set according to actual data storage requirements, and this embodiment does not impose specific limitations on this. Furthermore, the system implements a group registration mechanism, supporting the dynamic addition and deletion of test groups, and automatically updating the dependency network when groups change, ensuring the system has good scalability and flexibility.

[0156] For example, based on the directed dependencies in the aforementioned e-commerce system test scenario, the system constructs a group dependency network. Network nodes include user authentication groups, product browsing groups, order processing groups, payment processing groups, and logistics tracking groups. Network edges include directed edges from user authentication groups to order processing groups, from order processing groups to payment processing groups, and from payment processing groups to logistics tracking groups. Product browsing groups have no outgoing or incoming edges and exist as independent nodes. When the network is stored using an adjacency list, the adjacency list of the order processing group records that its preceding group is the user authentication group, and the adjacency list of the payment processing group records that its preceding group is the order processing group. When stored using an adjacency matrix, the corresponding position in the matrix is ​​marked as 1 to indicate the existence of a dependency relationship, and marked as 0 to indicate the absence of a dependency relationship. Through this group dependency network, the system provides the basic data structure for subsequent calculations of the target execution order and the hybrid serial-parallel scheduling.

[0157] S403. Based on the directed dependencies between test groups in the group dependency network, sort the test groups to obtain the target execution order that satisfies all directed dependencies.

[0158] The target execution order refers to the sequence of test group executions that satisfies all directed dependencies, calculated using a hierarchical-aware topology sorting algorithm based on the group dependency network. This ensures that each group only begins execution after all its preceding dependent groups have been executed. The hierarchical-aware topology sorting algorithm is an optimized algorithm that introduces hierarchical information about groups into the traditional Kahn algorithm. By processing group nodes with zero in-degree layer by layer, the time complexity is optimized to O(m+e), where m is the number of groups and e is the number of dependent edges.

[0159] In this step, the system performs hierarchical topological sorting on each test group based on the directed dependencies between them in the group dependency network, calculating the target execution order that satisfies all directed dependencies. Specifically, the system traverses the group dependency network, identifies all group nodes with an in-degree of zero as the first-level execution sequence, removes these groups from the network, updates the in-degree of the remaining groups, and again identifies group nodes with an in-degree of zero as the next-level execution sequence, repeating this process until all groups are included in the execution sequence. The resulting target execution order ensures that each group only begins execution after all its preceding dependent groups have been executed, while maximizing the parallel execution opportunities for peer groups.

[0160] For example, in a group dependency network comprising user authentication, product browsing, order processing, payment processing, and logistics tracking groups, assume that the product browsing and user authentication groups have no prior dependencies and both have an in-degree of zero; the order processing group depends on the user authentication group and has an in-degree of 1; the payment processing group depends on the order processing group and has an in-degree of 1; and the logistics tracking group depends on the payment processing group and has an in-degree of 1. The hierarchical-aware topology sorting algorithm first uses the user authentication and product browsing groups (both with an in-degree of zero) as the first-level execution sequence; after the user authentication group is completed, the order processing group's in-degree is reduced to zero, entering the second-level execution sequence; after the order processing group is completed, the payment processing group enters the third-level execution sequence; and finally, the logistics tracking group enters the fourth-level execution sequence. The resulting target execution order is: first level (user authentication group, product browsing group) → second level (order processing group) → third level (payment processing group) → fourth level (logistics tracking group), which satisfies all directed dependencies.

[0161] The test execution order control method provided in this application determines the preceding groups that the target group depends on based on the business logic relationship of the test groups to obtain directed dependencies. Based on the directed dependencies, a group dependency network is constructed, and the test groups are sorted according to the directed dependencies between each test group in the group dependency network to obtain the target execution order that satisfies all directed dependencies. This realizes the structured modeling of the dependencies between test groups and the calculation of the optimal execution order. It adopts a dual storage method of adjacency list and adjacency matrix to support efficient querying. The hierarchical-aware topology sorting algorithm balances execution correctness and execution efficiency, solving the technical problems of chaotic dependency management, lack of unified modeling mechanism and low execution order calculation efficiency in the prior art.

[0162] Figure 5 Flowchart of the test execution order control method provided in this application Figure 4 ,like Figure 5 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0163] S501. Based on the target execution order and group dependencies, determine the execution mode for each test group.

[0164] The execution mode refers to the execution method assigned to test groups in the test execution plan, including serial execution mode and parallel execution mode. Serial execution mode is suitable for test groups with prerequisite dependencies that are also depended upon by subsequent test groups. These test groups must be executed sequentially after all prerequisite test groups have completed, and their execution results directly affect the startup conditions of subsequent test groups. Parallel execution mode is suitable for test groups at the same level that do not have dependencies on each other. These test groups can be started simultaneously within the same execution level to improve overall execution efficiency.

[0165] In this step, the system determines the execution mode of each test group based on the target execution order and group dependencies. Specifically, the system traverses each test group in the target execution order, analyzing whether the group has any preceding dependent groups and whether any subsequent groups depend on it. If a test group has preceding dependencies and is depended on by subsequent groups, its execution mode is determined to be serial execution mode; if a test group has no dependencies on other groups at the same level, its execution mode is determined to be parallel execution mode. This determination of the execution mode is completed by the intelligent scheduling layer, providing a basis for the subsequent generation of test execution plans.

[0166] For example, in an e-commerce system test scenario, the user authentication group and the product browsing group are at the first level of the target execution order, and there is no dependency between them. Therefore, the execution mode of these two groups is determined to be parallel execution mode. The order processing group depends on the user authentication group and is also depended on by the payment processing group. Therefore, its execution mode is determined to be serial execution mode. The payment processing group depends on the order processing group and is also depended on by the logistics tracking group. Therefore, its execution mode is determined to be serial execution mode. The logistics tracking group only depends on the payment processing group and has no subsequent group dependencies, but it has a preceding dependency. Therefore, its execution mode is determined to be serial execution mode.

[0167] S502. Based on the preset state aggregation strategy, determine the execution conditions for each test group.

[0168] The state aggregation strategy refers to the set of rules used to determine the execution conditions of a test group. It calculates whether the current group meets the execution conditions based on the execution states of its dependent groups. Execution conditions refer to the prerequisite state judgment results that a test group must meet before it can start execution, including both satisfied and unsatisfied states. When the execution conditions are met, the test group starts execution normally; when the execution conditions are not met, the test group is skipped.

[0169] In this step, the system determines the execution conditions for each test group based on a preset state aggregation strategy. Specifically, the system first obtains the execution states of the test group's dependent groups, and then aggregates and calculates these dependent groups' execution states according to the configured state aggregation strategy to obtain the execution conditions for the current test group. The state aggregation strategy is configured during system initialization and can dynamically switch between strict mode, lenient mode, majority voting mode, and user-defined mode. This step is executed by the state aggregation strategy module of the intelligent scheduling layer.

[0170] For example, in an e-commerce system testing scenario, the order processing group's prerequisite group is the user authentication group. If the state aggregation strategy is configured in strict mode, the execution condition of the order processing group is determined to be met if all test cases in the user authentication group execute successfully; if any test case in the user authentication group fails, the execution condition of the order processing group is determined to be unmet. If the state aggregation strategy is configured in lenient mode, the execution condition of the order processing group is determined to be met if any test case in the user authentication group executes successfully.

[0171] S503. Determine the optimal scheduling strategy based on the historical test data of each test group.

[0172] The optimized scheduling strategy refers to a strategy that dynamically adjusts scheduling parameters based on historical test data for each test group. This strategy optimizes resource allocation and parallelism configuration for subsequent test executions based on historical execution data. Historical test data includes statistics such as historical execution duration, historical failure rate, and historical resource consumption for each test group.

[0173] In this step, the system determines an optimized scheduling strategy based on historical test data for each test group. Specifically, the system reads the historical execution records of each test group and analyzes its average execution time, failure frequency, and resource consumption characteristics. For groups with longer historical execution times, the system appropriately increases execution resources or adjusts their parallelism limit during resource allocation; for groups with higher historical failure rates, the system prioritizes the execution of their dependent groups during scheduling and reserves sufficient rollback and retry resources. This optimized scheduling strategy is automatically generated by the intelligent decision engine of the intelligent scheduling layer based on historical data and supports manual intervention and adjustment.

[0174] For example, in an e-commerce system test scenario, historical test data shows that the payment processing group has the longest average execution time in history and involves external payment interface calls, resulting in a relatively high failure rate. Based on this historical test data, the system determines the following optimized scheduling strategy: reserving additional network timeout buffer time before the payment processing group executes, allocating an independent execution thread pool to avoid resource contention, and limiting the number of other groups at the same level as the payment processing group during parallel scheduling to ensure that the payment processing group receives sufficient computing resources.

[0175] S504. Based on the target execution order, the execution mode of each test group, the execution conditions, and the optimization scheduling strategy, generate a test execution plan. The test execution plan includes a set of serial test groups that have prerequisite dependencies and are depended upon by subsequent test groups, and a set of parallel test groups that have no dependencies on peer test groups.

[0176] The test execution plan is a complete execution scheme generated based on the target execution order, the execution mode of each test group, the execution conditions, and the optimized scheduling strategy. It guides the execution control layer to execute each test group sequentially. The serial test group set refers to the set of all groups in the test execution plan that are determined to execute in a serial mode; these groups are executed sequentially according to the target execution order. The parallel test group set refers to the set of all groups in the test execution plan that are determined to execute in a parallel mode; these groups are started and executed simultaneously, provided resources allow.

[0177] In this step, the system generates a test execution plan based on the target execution order, the execution mode of each test group, the execution conditions, and the optimized scheduling strategy. Specifically, the system processes each test group layer by layer according to the target execution order, including groups with a serial execution mode that meet the execution conditions into the serial test group set, and groups with a parallel execution mode that meet the execution conditions into the parallel test group set. Simultaneously, the system writes the resource allocation scheme and parallelism configuration from the optimized scheduling strategy into the test execution plan, forming a complete plan document containing the execution order, serial set, parallel set, execution conditions, and resource allocation scheme. This test execution plan is generated by the intelligent scheduling layer and distributed to the execution control layer.

[0178] For example, in an e-commerce system testing scenario, the system generates the following test execution plan: The first-layer parallel test group set includes user authentication and product browsing groups, which are executed simultaneously by two parallel execution nodes; the second-layer serial test group set includes order processing groups, which are assigned independent execution nodes and configured with additional database connection pool resources; the third-layer serial test group set includes payment processing groups, which are assigned independent execution nodes and configured with network timeout buffers and independent thread pools; the fourth-layer serial test group set includes logistics tracking groups, which are assigned standard execution nodes. Each layer is triggered sequentially according to the target execution order, and the next layer can only proceed after all previous layer groups have been completed.

[0179] S505. According to the test execution plan, perform serial scheduling for the test groups in the serial test group set and parallel scheduling for the test groups in the parallel test group set.

[0180] In this step, the system performs serial scheduling for test groups in the serial test group set and parallel scheduling for test groups in the parallel test group set according to the test execution plan. Specifically, the execution control layer receives the test execution plan from the intelligent scheduling layer and parses the serial and parallel test group sets. For the serial test group set, the execution control layer starts each group sequentially according to the target execution order. Each group must wait for all its preceding groups to complete before starting, and the execution results are fed back to the status tracking module in real time. For the parallel test group set, the execution control layer starts all groups within the set simultaneously within the resource-allowed range. Each group executes independently without blocking others and reports its execution status separately. Finally, after all groups have completed execution, the execution control layer summarizes the actual test case execution results in each leaf group and outputs the test results.

[0181] For example, in an e-commerce system testing scenario, the execution control layer executes the schedule according to the test execution plan: First, the user authentication group and the product browsing group are executed in parallel simultaneously, with each group running on different execution nodes; after the user authentication group executes successfully, the order processing group is executed serially; after the order processing group executes successfully, the payment processing group is executed serially. This group, due to its optimized scheduling strategy, is configured with an independent thread pool and network timeout buffer, and is not affected by resource contention from other groups during execution; after the payment processing group executes successfully, the logistics tracking group is executed serially. After all groups have completed execution, the system summarizes the execution results of the actual test cases in each leaf group and generates a test result report containing the execution status, execution duration, and details of failed test cases for each group.

[0182] The test execution order control method provided in this application determines the execution mode of each test group based on the target execution order and group dependency relationship, determines the execution conditions of each test group based on a preset state aggregation strategy, determines an optimized scheduling strategy based on the historical test data of each test group, and generates a test execution plan containing a set of serial test groups and a set of parallel test groups based on the target execution order, the execution mode of each test group, the execution conditions, and the optimized scheduling strategy. It then performs serial scheduling on the set of serial test groups and parallel scheduling on the set of parallel test groups according to the test execution plan, achieving intelligent dynamic scheduling of test execution. This method balances execution correctness and execution efficiency, solving the technical problems of lacking intelligent serial-parallel hybrid execution strategies and low execution efficiency in the prior art.

[0183] Figure 6 Flowchart of the test execution order control method provided in this application Figure 5 ,like Figure 6 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0184] S601. Obtain the execution status of the prerequisite dependency groups of the test group.

[0185] In this context, a preceding dependency group refers to a test group in the dependency network that the current test group must wait for to complete before it can execute. Execution status refers to the state result of a preceding dependency group after completing test execution, including two states: successful execution and failed execution. Successful execution indicates that all or part of the actual test cases within the preceding dependency group have been completed normally without triggering any blocking errors; failed execution indicates that test cases in the preceding dependency group failed or encountered execution anomalies during execution.

[0186] In this step, the system obtains the execution status of the test group's pre-dependent groups through the state tracking module at the execution control layer. Specifically, when a test group enters the pending execution state, the system first queries all pre-dependent groups associated with that group in the group dependency network and reads the state information recorded by these pre-dependent groups during previous execution. The state tracking module stores the execution results of each pre-dependent group in structured data format, including group identifier, execution completion time, number of successful test cases, number of failed test cases, and exception summary. The system retrieves and extracts this data from the state tracking module to form a set of execution states of the current test group's pre-dependent groups, providing input for subsequent state aggregation strategy calculations.

[0187] For example, in an e-commerce system testing scenario, the order processing group's prerequisite group includes the user authentication group. Before executing the order processing group, the system obtains the execution status of the user authentication group through the status tracking module. If all actual test cases within the user authentication group, such as user registration, user login, and password reset, are executed successfully, the execution status of the user authentication group is recorded as successful; if the user login test case fails due to interface timeout, the execution status of the user authentication group is recorded as failed.

[0188] S602. Based on the state aggregation strategy, calculate the execution conditions of each test group by considering the execution state of the preceding dependency group.

[0189] The state aggregation strategy refers to the set of rules used to determine the execution conditions of a test group. It calculates whether the current test group meets the execution conditions based on the execution states of its dependent groups. Execution conditions refer to the prerequisite state judgment results that a test group must meet before starting execution, including both satisfied and unsatisfied states. When the execution conditions are satisfied, the test group normally enters the execution process; when the execution conditions are not satisfied, the test group is skipped and no longer occupies execution resources.

[0190] In this step, the system aggregates and calculates the execution states of the preceding dependency groups based on a preset state aggregation strategy to obtain the execution conditions for each test group. Specifically, the system reads the execution states of all preceding dependency groups associated with the current test group, performs logical operations or counts on these execution states according to the configured state aggregation strategy type, and obtains a unified execution condition determination result. The state aggregation strategy is set by the configuration planning layer during system initialization, and the state aggregation strategy module of the intelligent scheduling layer is responsible for performing the specific calculations and writing the results into the test execution plan. This calculation process supports dynamic switching between different modes to adapt to the stringency requirements of different business scenarios for execution conditions.

[0191] For example, in an e-commerce system test scenario, the order processing group's prerequisite group is the user authentication group, and the system obtains that the user authentication group's execution status is successful. If the current status aggregation strategy is configured in strict mode, the system determines that the user authentication group has executed successfully, and the calculated execution conditions for the order processing group are met. If the user authentication group's execution status is failure, then regardless of the mode used, the execution conditions are determined to be unmet.

[0192] S603. Based on the type of state aggregation strategy, differentiate the execution status of the preceding dependency group to determine whether the execution conditions of the test group are met.

[0193] The state aggregation strategy includes strict mode, lenient mode, majority voting mode, and user-defined mode. In strict mode, the execution condition is satisfied if all preceding dependent groups of the test group execute successfully. In lenient mode, the execution condition is satisfied if any preceding dependent group of the test group executes successfully. In majority voting mode, the execution condition is satisfied if a preset number of preceding dependent groups of the test group execute successfully. In user-defined mode, the execution status of the preceding dependent groups is determined to satisfy the execution condition based on user-preset rules.

[0194] In this step, the system performs differentiated calculations on the execution status of the pre-dependency groups based on the configured status aggregation strategy type. Specifically, the status aggregation strategy module reads the strategy configuration identifier, identifies the currently effective mode type, and calls the corresponding judgment logic to process the set of execution statuses of the pre-dependency groups. In strict mode, a full success check is performed, iterating through the execution statuses of all pre-dependency groups, and outputting a satisfactory result only when all statuses are successful. In lenient mode, an existence success check is performed, iterating through the execution statuses of the pre-dependency groups, and outputting a satisfactory result when at least one successful execution is detected. In majority voting mode, a counting threshold check is performed, counting the number of successfully executed pre-dependency groups, and outputting a satisfactory result when the number of successes is greater than or equal to a preset threshold. In user-defined mode, a user-preset rule script or configuration table is loaded, custom logic checks are performed, and a satisfactory or unsatisfactory result is output. All modes output a unified execution condition judgment result for use in subsequent steps.

[0195] For example, in an e-commerce system test scenario, the payment processing group's prerequisite dependency groups include the order processing group and the coupon group. If the state aggregation strategy is in strict mode, both the order processing group and the coupon group must execute successfully for the payment processing group's execution condition to be met. If the state aggregation strategy is in lenient mode, the execution condition of the payment processing group is met if either the order processing group or the coupon group executes successfully. If the state aggregation strategy is in majority voting mode, with a preset number of 1, the condition is met if at least one of the two prerequisite dependency groups executes successfully. If the state aggregation strategy is in user-defined mode, with the user-preset rule that the order processing group must succeed and the coupon group is optional, the execution condition of the payment processing group is only met if the order processing group executes successfully.

[0196] S604. Determine whether the execution conditions are met. If the execution conditions are met, execute the test group. If the execution conditions are not met, skip the execution of the test group.

[0197] "Execution conditions met" means that the test group has met all the prerequisites for starting execution and can enter the actual test case execution phase. "Skipping a test group" means that the system cancels the execution plan of the test group, no longer schedules the actual test cases it contains, and records the reason for skipping and the dependency status for subsequent test reports and manual analysis.

[0198] In this step, the system triggers different execution paths based on the execution condition determination result calculated by S603. Specifically, if the execution condition is met, the test case execution module of the execution control layer starts the actual test case execution of the test group according to the test execution plan, and the status tracking module records that the group has entered the execution state. If the execution condition is not met, the intelligent scheduling layer sends a skip instruction to the execution control layer, the test case execution module cancels the execution plan of the group and its downstream dependent groups, the status tracking module marks the group's status as skipped, and records the identifier of the preceding dependent group that caused the skip and the failure details. The skip operation avoids the waste of ineffective test resources and prevents the chain reaction of errors caused by the failed preceding group from spreading.

[0199] For example, in an e-commerce system test scenario, the order processing group's prerequisite dependency group is the user authentication group. If the user authentication group fails to execute and the state aggregation strategy is in strict mode, then in S603, the execution condition for the order processing group is calculated to be unmet. In S604, the system determines that the execution condition is not met, skips the execution of the order processing group, and no longer executes actual test cases such as order creation, order query, and order cancellation. At the same time, the system skips the payment processing group and logistics tracking group, which are dependent on the order processing group, and records in the test report that the reason for skipping is the failure of the prerequisite dependency group's user authentication execution.

[0200] The test execution order control method provided in this application obtains the execution status of the pre-dependent groups of the test group, calculates the execution conditions of each test group based on the execution status of the pre-dependent groups using a state aggregation strategy, supports four state aggregation strategies: strict mode, lenient mode, majority voting mode, and user-defined mode, and skips the execution of the test group when the execution conditions are not met. This achieves flexible determination and intelligent filtering of the execution conditions of the test group, avoids invalid test resource consumption, and solves the technical problems in the prior art of lacking a flexible execution condition determination mechanism and causing invalid execution of subsequent tests due to the failure of the pre-dependent groups.

[0201] Figure 7 Flowchart of the test execution order control method provided in this application Figure 6 ,like Figure 7 As shown, the test execution order control method in this embodiment can be specifically defined by... Figure 1 The overall system architecture execution of the test execution order control method shown is as follows: Specifically, the method includes:

[0202] S701. Perform full-process circular dependency detection on the group dependency network.

[0203] The full-process circular dependency detection includes at least configuration phase detection, resolution phase detection, collection phase detection, and execution phase detection.

[0204] The full-process circular dependency detection refers to a mechanism that performs circular dependency checks on the group dependency network during the configuration, parsing, collection, and execution phases of the test execution order control process to ensure the rationality and stability of dependencies. Configuration phase detection mainly performs basic syntax compliance checks and verifies the integrity of the group structure. Parsing phase detection is responsible for semantic parsing of dependencies and preliminary circular dependency identification. Collection phase detection performs final circular dependency verification based on the complete dependency network. Execution phase detection dynamically monitors the dependency status during test runtime, promptly detecting and handling anomalies. A circular dependency refers to a path in the group dependency network that starts from a group, traverses several directed edges, and then returns to the same group. This type of dependency prevents the test execution order from being calculated using topological sorting and must be detected and blocked.

[0205] In this step, after constructing the group dependency network, the system performs full-process circular dependency detection on the network. Specifically, the detection process is collaboratively completed by the configuration planning layer, intelligent scheduling layer, and execution control layer, and is executed progressively in four stages. The configuration stage detection is initiated by the configuration planning layer during the group structure definition and dependency modeling phase. It parses the group configuration files, checks the format compliance of fields such as group identifier, group name, and parent group identifier, and verifies whether the group structure forms a complete tree hierarchy without isolated groups or broken hierarchies. The parsing stage detection is initiated by the intelligent scheduling layer when reading the group dependency network. It performs semantic parsing on the dependency edges in the adjacency list and adjacency matrix, checks whether the target group pointed to by the dependency exists in the current group structure, and identifies preliminary circular characteristics such as obvious self-loop dependencies and bidirectional dependencies. The collection stage detection is initiated by the execution control layer before formal execution. Based on the complete group dependency network, a depth-first search path is constructed, and a backtracking algorithm is used to verify whether there are circular paths with a length greater than or equal to 2 in the network, performing final circular dependency verification. The execution phase detection is dynamically performed by the execution control layer during the test run, which monitors the consistency between the actual execution status of each group and the dependency network in real time. When a runtime dynamically injected dependency change or an implicit loop caused by an abnormal state is detected, the exception handling process is immediately triggered.

[0206] For example, in an e-commerce system testing scenario, the configuration phase verifies that the group identifiers of the user authentication group, product browsing group, order processing group, payment processing group, and logistics tracking group are all unique and non-empty, the parent group identifier correctly points to the parent group, and the group structure forms a complete root group → parent group → child group → leaf group hierarchy. The parsing phase detects that the adjacency list of the order processing group records a dependency edge pointing to the payment processing group, and simultaneously, the adjacency list of the payment processing group records a dependency edge pointing to the order processing group. The system identifies this bidirectional dependency as a preliminary circular dependency feature and triggers an alarm. The collection phase performs a depth-first search based on the complete network, confirming that there is a circular path of length 2 between the order processing group and the payment processing group. This determines that the group dependency network has a circular dependency, blocks subsequent execution processes, and outputs the detection results. During the execution phase, the system detected that the dynamically loaded coupon group was incorrectly configured to depend on the logistics tracking group, which in turn depended on the payment processing group, which in turn depended on the order processing group, which in turn depended on the coupon group, forming a runtime loop path of length 4. The system immediately triggered exception handling, skipped the execution of the relevant groups, and logged the exception event.

[0207] The test execution order control method provided in this application performs full-process circular dependency detection on the group dependency network after it is constructed. This detection covers four stages: configuration stage detection, parsing stage detection, collection stage detection, and execution stage detection. It achieves full-process, multi-level detection of circular dependencies, ensuring the rationality and stability of the dependency relationship. This solves the technical problems of existing circular detection mechanisms being simple, unable to cover the entire test lifecycle, and difficult to detect dynamic loops during runtime.

[0208] Figure 8 A schematic diagram of the test execution sequence control device provided in this application is shown below. Figure 8 As shown, the test execution sequence control device 80 provided in this embodiment includes:

[0209] Module 801 is used to obtain the test case set;

[0210] Grouping module 802 is used to organize the test case set into multi-level nested test groups according to functional logic. The multi-level nested test groups include a root group, a parent group, a child group, and a leaf group containing the actual test cases.

[0211] Module 803 is used to build a group dependency network based on the directed dependencies between test groups;

[0212] The sorting module 804 is used to calculate the target execution order of each test group based on the group dependency network;

[0213] The scheduling module 805 is used to perform serial-parallel hybrid scheduling on each test group according to the target execution order and group dependency relationship, so as to execute the actual test cases in the leaf group and output the test results.

[0214] In one possible implementation, the grouping module 802 is specifically used to divide the test case set into different leaf groups according to functional logic; based on the business affiliation of each leaf group, each leaf group is aggregated into sub-groups, parent groups and root groups step by step to form multi-level nested test groups.

[0215] In one possible implementation, the construction module 803 is specifically used to determine the preceding groups that the target group in the test group depends on based on the business logic relationship of the test group, so as to obtain the directed dependency relationship between the test groups; and to construct a group dependency relationship network based on the directed dependency relationship.

[0216] In one possible implementation, the sorting module 804 is specifically used to sort each test group based on the directed dependencies between each test group in the group dependency network, so as to obtain the target execution order that satisfies all directed dependencies.

[0217] In one possible implementation, the scheduling module 805 is specifically used to determine the execution mode of each test group based on the target execution order and group dependencies; determine the execution conditions of each test group based on a preset state aggregation strategy; determine an optimized scheduling strategy based on the historical test data of each test group; generate a test execution plan based on the target execution order, the execution mode of each test group, the execution conditions, and the optimized scheduling strategy; the test execution plan includes a set of serial test groups that have prerequisite dependencies and are depended on by subsequent test groups, and a set of parallel test groups that have no dependencies on peer test groups; according to the test execution plan, serial scheduling is performed on the test groups in the serial test group set, and parallel scheduling is performed on the test groups in the parallel test group set.

[0218] In one possible implementation, the scheduling module 805 is specifically used to obtain the execution status of the preceding dependent groups of the test group; and to calculate the execution conditions of each test group based on the execution status of the preceding dependent groups using the state aggregation strategy.

[0219] In one possible implementation, the scheduling module 805 is specifically used to determine that the execution condition is met when all the preceding dependent groups of the test group execute successfully in the strict mode of the state aggregation strategy; when the state aggregation strategy is relaxed mode, the execution condition is met when any preceding dependent group of the test group executes successfully; when the state aggregation strategy is majority voting mode, the execution condition is met when a preset number of preceding dependent groups of the test group execute successfully; when the state aggregation strategy is user-defined mode, the module determines whether the execution status of the preceding dependent groups meets the execution condition based on user-defined rules; and if the execution condition is not met, the execution of the test group is skipped.

[0220] In one possible implementation, the device further includes:

[0221] The detection module 806 is used to perform full-process circular dependency detection on the group dependency network after the construction module 803 has built the group dependency network; wherein, the full-process circular dependency detection includes at least configuration phase detection, parsing phase detection, collection phase detection and execution phase detection.

[0222] The test execution sequence control device provided in this embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0223] Figure 9 A schematic diagram of the structure of the electronic device provided in this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 901 and a memory 902. Optionally, the device 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0224] In a specific implementation, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above-described method.

[0225] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0226] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0227] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0228] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0229] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0230] The aforementioned readable storage medium 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, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0231] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0232] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0233] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0234] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0235] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0236] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0237] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A test execution order control method, characterized in that, include: Get the test case set; The test case set is organized into multi-level nested test groups according to functional logic. The multi-level nested test groups include a root group, a parent group, a child group, and a leaf group containing the actual test cases. Construct a group dependency network based on the directed dependencies between the test groups; Based on the group dependency network, calculate the target execution order for each test group; Based on the target execution order and the grouping dependency, a serial-parallel hybrid scheduling is performed on each of the test groups to execute the actual test cases in the leaf groups and output the test results.

2. The method according to claim 1, characterized in that, The step of organizing the test case set into multi-level nested test groups according to functional logic includes: The test case set is divided into different leaf groups according to the functional logic described above; Based on the business affiliation of each leaf group, each leaf group is aggregated level by level into the subgroup, the parent group, and the root group to form the multi-level nested test group.

3. The method according to claim 1, characterized in that, The step of constructing a group dependency network based on the directed dependencies between the test groups includes: Based on the business logic relationship of the test groups, determine the preceding groups that the target groups in the test groups depend on, so as to obtain the directed dependency relationship between the test groups; Based on the directed dependency relationship, the group dependency relationship network is constructed.

4. The method according to claim 1, characterized in that, The step of calculating the target execution order of each test group based on the group dependency network includes: Based on the directed dependencies between the test groups in the group dependency network, the test groups are sorted to obtain the target execution order that satisfies all the directed dependencies.

5. The method according to claim 1, characterized in that, The step of performing a serial-parallel hybrid scheduling on each test group according to the target execution order and the group dependency relationship includes: Based on the target execution order and the grouping dependency, determine the execution mode of each test group; Based on a preset state aggregation strategy, the execution conditions for each test group are determined; Based on the historical test data of each test group, determine the optimized scheduling strategy; Based on the target execution order, the execution mode of each test group, the execution conditions, and the optimization scheduling strategy, a test execution plan is generated; the test execution plan includes a set of serial test groups that have prerequisite dependencies and are depended on by subsequent test groups, and a set of parallel test groups that have no dependency relationship with peer test groups; According to the test execution plan, serial scheduling is performed on the test groups in the serial test group set, and parallel scheduling is performed on the test groups in the parallel test group set.

6. The method according to claim 5, characterized in that, The method for determining the execution conditions for each test group based on a preset state aggregation strategy includes: Obtain the execution status of the preceding dependent groups of the test group; Based on the state aggregation strategy, the execution conditions of each test group are calculated for the execution state of the preceding dependency group.

7. The method according to claim 6, characterized in that, The calculation of the execution conditions for each test group based on the execution state of the preceding dependency group using the state aggregation strategy includes: When the state aggregation strategy is in strict mode, if all the preceding dependency groups of the test group execute successfully, the execution condition is determined to be satisfied. When the state aggregation strategy is in lenient mode, if any of the preceding dependent groups of the test group executes successfully, the execution condition is determined to be satisfied. When the state aggregation strategy is the majority voting mode, the execution condition is determined to be satisfied when a preset number of the preceding dependency groups of the test group are executed successfully. When the state aggregation strategy is a user-defined mode, it is determined whether the execution state of the preceding dependency group meets the execution conditions based on the user-preset rules. If the execution conditions are not met, the execution of the test group is skipped.

8. The method according to claim 1, characterized in that, After constructing the grouped dependency network based on the dependencies, the method further includes: Perform full-process circular dependency detection on the grouped dependency network; wherein, the full-process circular dependency detection includes at least configuration phase detection, parsing phase detection, collection phase detection and execution phase detection.

9. A test execution sequence control device, characterized in that, The device includes: The acquisition module is used to acquire a set of test cases; The grouping module is used to organize the test case set into multi-level nested test groups according to functional logic. The multi-level nested test groups include a root group, a parent group, a child group, and a leaf group containing actual test cases. The building module is used to construct a group dependency network based on the directed dependencies between the test groups; The sorting module is used to calculate the target execution order of each test group based on the grouping dependency network; The scheduling module is used to perform serial-parallel hybrid scheduling on each of the test groups according to the target execution order and the grouping dependency relationship, so as to execute the actual test cases in the leaf group and output the test results.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

Images