A workflow-based automated testing method and device

Abstract

The present invention discloses a workflow-based automated testing method and device. Preconditions, use case execution, and postconditions are used as individual use cases. Each use case is written as a workflow according to a use case writing specification. The use case writing specification includes a workflow dependency configuration specification. Each workflow is scanned to construct a binary tree. Each node on the binary tree corresponds to a workflow. The binary tree is scanned and, based on the workflow dependencies, corresponding workflows are selected and executed in sequence to implement test case execution. The present invention redefines the scenario of automated testing and redesigns the original test case design and execution method based on graph theory. Good design patterns can reduce code duplication, making all use cases reusable without the need for rewriting due to dependencies such as preconditions. This makes maintainability stronger and the strategic control based on this easier.

Description

Technical Field

[0001] The present invention relates to the field of automated testing, and in particular to a workflow-based automated testing method and device. Background Art

[0002] In the development of management software for private clouds, functional testing execution is highly dependent on other tests. Current implementations are relatively basic, with a single test method executing the entire test case, including precondition handling, test case execution, and postcondition handling. This dependency leads to a significant amount of repetitive work. For example, precondition handling may largely rely on basic operations like adding a license, which may also belong to a separate test case. Current, simplistic implementations simply extract common code and create public methods for invocation. This restricts or even interferes with test case development efficiency, debugging efficiency, and concurrent development capabilities, resulting in wasted human resources and difficult code maintenance. Summary of the Invention

[0003] To solve the above problems, the present invention provides a workflow-based automated testing method and device, which makes all use cases reusable without the need to rewrite them due to dependencies such as preconditions, making them more maintainable and making the strategies based on them easier to control.

[0004] In a first aspect, the technical solution of the present invention provides a workflow-based automated testing method, comprising the following steps:

[0005] Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes workflow dependency configuration specifications;

[0006] Scan each workflow to build a binary tree; each node in the binary tree corresponds to a workflow;

[0007] Scan the binary tree and select the corresponding workflow based on the workflow dependency to execute the test case in sequence.

[0008] Furthermore, when writing use cases into workflows according to workflow dependency configuration specifications, it specifically includes:

[0009] Configure workflow dependencies through annotations or configuration files.

[0010] Furthermore, each workflow is scanned to construct a binary tree, including:

[0011] Perform a global scan of the workflow and build a binary tree with the current workflow as the root node;

[0012] Based on the workflow dependency, the precondition workflow of the workflow corresponding to the root node is taken as the left node of the root node, and the postcondition workflow of the workflow corresponding to the root node is taken as the right node of the root node.

[0013] Furthermore, the method further comprises the following steps:

[0014] When scanning each workflow to build a binary tree, if the workflow corresponding to the precondition or postcondition has already scanned and built a binary tree, the built binary tree will be directly used.

[0015] Furthermore, based on the workflow dependency, the corresponding workflows are selected and executed in sequence to implement the execution of the test cases, specifically including:

[0016] For a certain test case, locate the root node of the test case, start from the leftmost node of the root node and execute each node on the outermost path on the left in sequence until the root node is executed, then start from the first right node of the root node and execute each node on the outermost path on the right in sequence until the rightmost node is executed.

[0017] Furthermore, the method further comprises the following steps:

[0018] Based on the workflow dependency, the corresponding workflow is selected and executed in sequence. If an error occurs when executing a node, the right node of the right subtree of the error node is executed to clean up the environment and roll back. If the cleanup fails, a global cleanup operation is performed.

[0019] Furthermore, the use case writing specification also includes internal context parameter configuration specifications and global context parameter configuration specifications;

[0020] Create multiple steps within the workflow written according to the use case writing specification, corresponding to the execution steps of the use case, and number or name each step;

[0021] When executing a workflow, each step within the workflow uses the internal context to pass data;

[0022] After the workflow execution is completed, the execution data is saved to the corresponding location based on the global context parameters, and the subsequent workflow extracts the saved execution data based on the corresponding global context parameters.

[0023] Furthermore, the method further comprises the following steps:

[0024] A waiting mechanism is implemented for steps that take longer than a threshold to execute in the workflow.

[0025] Furthermore, the use case writing specifications also include use case disassembly specifications and other test case workflow specifications for reuse.

[0026] In a second aspect, the technical solution of the present invention provides a workflow-based automated testing device, comprising:

[0027] Workflow writing module: Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes the workflow dependency configuration specification;

[0028] Binary tree construction module: scans each workflow to build a binary tree; each node in the binary tree corresponds to a workflow;

[0029] Execution module: Scans the binary tree and selects the corresponding workflow based on the workflow dependency to execute the test case in sequence.

[0030] In a third aspect, the technical solution of the present invention further provides a terminal, comprising:

[0031] A memory for storing workflow-based automated testing programs;

[0032] A processor is configured to implement the steps of any of the above-mentioned workflow-based automated testing methods when executing the workflow-based automated testing program.

[0033] In a fourth aspect, the technical solution of the present invention also provides a readable storage medium, on which a workflow-based automated testing program is stored. When the workflow-based automated testing program is executed by a processor, the steps of the workflow-based automated testing method as described in any one of the above items are implemented.

[0034] The present invention provides a workflow-based automated testing method and device, which has the following beneficial effects compared to the prior art: extracting three parts: preconditions, use case execution, and postconditions, and summarizing them into separate use cases. The execution of each use case is written and processed using the workflow specification. A binary tree of all test cases is generated through configuration and scanning, and the execution path is executed by traversing the tree from left to right, thereby covering all use cases. The present invention redefines the scenario of automated testing, and re-deconstructs and designs the original test case design and execution method based on graph theory. The code duplication can be reduced through good design patterns, so that related tests only focus on the execution body steps of the use case without paying attention to other conditions. The writing of the test method is more focused and easier to debug, which improves the maintainability of the overall code. Each individual use case body is relatively independent, and the writing time of the use case can be shortened by increasing manpower. The workflow-based writing method is also more flexible. The test logic can be executed in steps and stages, and some rollback operations can be performed well. Time-consuming operations can release thread resources based on the workflow framework, and rely on the framework's polling operations to increase concurrency, so that more test cases can be executed concurrently with fewer threads. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present application or the technical solutions of the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0036] Figure 1 A flowchart of a workflow-based automated testing method provided in Example 1 of the present invention.

[0037] Figure 2 Schematic diagram of a binary tree constructed in Example 1 of the present invention.

[0038] Figure 3 A schematic diagram of the structure of a workflow-based automated testing device provided in Example 2 of the present invention.

[0039] Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0040] The following are explanations of the terms used in the present invention.

[0041] Workflow: A task execution process that meets certain process specifications and has the concept of context within it, tentatively defined as local context, as distinct from the global context.

[0042] Binary tree: used to represent a complete use case, with the left node being the precondition and the right node being the postcondition.

[0043] Global context: used for sharing data across workflows.

[0044] Annotation: specifically refers to the annotation in the Java language, which is used for special marking, similar to a configuration file.

[0045] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific embodiments. Obviously, the embodiments described are only a part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making any creative efforts are within the scope of protection of the present application.

[0046] In the development of management software for private clouds, functional testing execution is highly dependent on other tests. Current implementations are relatively basic, with a single test method executing the entire test case, including precondition handling, test case execution, and postcondition handling. This dependency leads to a significant amount of repetitive work. For example, precondition handling may largely rely on basic operations like adding a license, which may also belong to a separate test case. Current, simplistic implementations simply extract common code and create public methods for invocation. This restricts or even interferes with test case development efficiency, debugging efficiency, and concurrent development capabilities, resulting in wasted human resources and difficult code maintenance.

[0047] Therefore, the present invention provides a workflow-based automated testing solution that extracts preconditions, use case execution, and postconditions into three components, grouping them into separate use cases. Each use case's execution is written and processed using workflow specifications. A binary tree of all test cases is generated through configuration and scanning, and execution paths are traversed from left to right through the tree, thus covering all use cases. This solution makes all use cases reusable, eliminating the need for rewriting to account for dependencies such as preconditions. This improves maintainability and makes strategic control easier.

[0048] Example 1

[0049] like Figure 1 The figure shows a flow chart of a workflow-based automated testing method provided in the first embodiment, which includes the following steps.

[0050] S101, taking preconditions, use case execution, and postconditions as separate use cases, and writing each separate use case into a workflow according to a use case writing specification; the use case writing specification includes a workflow dependency configuration specification.

[0051] When writing a workflow, configure the dependencies between the workflow and other workflows according to the workflow dependency configuration specification. For example, if the execution of a use case depends on preconditions and postconditions, when executing the workflow for the use case, you need to configure its dependencies on the precondition workflow and the postcondition workflow.

[0052] In subsequent execution, the workflow is retrieved and executed in sequence according to the dependency relationship. In this embodiment, the workflow is constructed as a binary tree, and the binary tree is constructed according to the workflow dependency relationship. Subsequently, the corresponding nodes are selected and executed in sequence based on the construction standard of the binary tree.

[0053] S102, scanning each workflow to construct a binary tree; each node on the binary tree corresponds to a workflow.

[0054] In specific implementation, a binary tree is constructed based on the dependency relationship of the workflow, with a workflow as the root node, the precondition of the workflow as the left node of the root node, and the postcondition of the workflow as the right node of the root node.

[0055] S103, scanning the binary tree, selecting corresponding workflows based on workflow dependencies and executing them in sequence to implement the execution of the test cases.

[0056] As mentioned above, when constructing a binary tree, it is constructed based on the rule that the left node is the precondition and the right node is the postcondition. When executing the test case in step S103, the corresponding workflow is selected based on the workflow dependency relationship and executed in sequence. The workflow can be called from left to right in accordance with the tree structure for execution.

[0057] To further explain the present invention, a specific embodiment is provided below in combination with the above steps based on the principles of the present invention. The specific embodiment includes three parts: workflow writing, binary tree construction, and test case execution.

[0058] (1) Workflow Writing

[0059] A standard test case consists of three parts: preconditions, test steps, and postconditions. The test steps are the main body of the test. To improve testing efficiency and facilitate maintenance, testers can re-identify and disassemble these three parts of a test case after receiving it, so that each part can implement independent functional tests and then compile these three parts into workflows. The use case writing specification provides a disassembly use case specification and reuses other test case workflow specifications to allow testers to split the test case. Specifically, if a precondition already has an independent use case and requires separate testing, the precondition only needs to be written in a workflow according to its corresponding test case and does not need to be included in the main workflow of this test case (i.e., the test step workflow). Postconditions are treated the same way. If the precondition and postcondition do not have independent use cases, they should either be added as separate use cases or included in the main workflow of this test case for execution.

[0060] It's important to note that preconditions and postconditions can also be used to independently test functional tests. A precondition in one test case can be the test subject in another. For example, suppose you have functions A, B, and C, and function B depends on A and C. You only need to define three workflows to test A, B, and C separately, but the second workflow depends on the other two.

[0061] Some workflows rely on other workflows, so the corresponding dependencies must be configured when writing workflows. The use case writing specification also includes a workflow dependency configuration specification. Use cases are written as workflows according to the workflow dependency configuration specification, and workflow dependencies are configured specifically through annotations or configuration files. It should be noted that a unique ID address is defined for each workflow to facilitate annotation or configuration file creation. For example, if the precondition for configuration B is A and the postcondition is C, configuring the preconditions to A1 and A2 will result in an error and termination of the writing process.

[0062] When writing a workflow, you can create multiple steps within the workflow that correspond to the execution steps of the use case. Each step can be numbered or named to facilitate log printing and problem location.

[0063] Data needs to be transferred between steps within a workflow. During workflow execution, each step uses the internal context to pass data, facilitating data calls between steps. Accordingly, set the internal context parameter configuration specification in the use case writing specification. When writing a workflow, the workflow's internal context parameters are written based on this internal context parameter configuration specification.

[0064] Dependent workflows also need to transfer data. For example, a precondition workflow needs to pass its execution data to a use case execution workflow. Therefore, a global context parameter configuration specification is set in the use case writing specification. When writing workflows, global context parameters for the workflow are written based on the global context parameter configuration specification, if necessary. It should be noted that global context parameters define the storage location for data after the workflow execution. Furthermore, it is best to avoid defining data that can be queried through the backend software interface to avoid complexity. Therefore, after the workflow execution completes, the execution data is saved to the corresponding location based on the global context parameters. Subsequent workflows retrieve the saved execution data based on the corresponding global context parameters.

[0065] For steps whose execution time exceeds the threshold (i.e., steps that are executed for a long time), the waiting mechanism of the workflow is executed. By declaring the next step, the workflow framework is used to execute the next step in a loop, and the current thread is released within the loop interval.

[0066] (2) Binary tree construction

[0067] Scan each workflow to build a binary tree. Each node in the binary tree corresponds to a workflow. Some workflows have dependencies, so a binary tree is built based on the dependencies of the workflows.

[0068] Specifically, the workflow is globally scanned and a binary tree is constructed with the current workflow as the root node. Based on the workflow dependency, the precondition workflow of the workflow corresponding to the root node is taken as the left node of the root node, and the postcondition workflow of the workflow corresponding to the root node is taken as the right node of the root node. Figure 2 Shown is a schematic diagram of the constructed binary tree.

[0069] It should be noted that the constructed binary tree is saved in time. When scanning each workflow to construct a binary tree, if the workflow corresponding to the precondition or postcondition has already scanned and constructed a binary tree, the already constructed binary tree is directly used without the need for a second traversal scan, thus reducing the overall scanning time.

[0070] The root node represents the test subject of the corresponding test case and corresponds to the ID of the related test case. A tree may contain a left subtree and a right subtree, and the left or right subtree also has a left and a right node, but only the left node of the left subtree is a precondition, and the right node of the right subtree is a postcondition. The complete path used by this test case is only the leftmost node -> root node -> rightmost node.

[0071] (3) Test case execution

[0072] The test cases are executed according to the binary tree constructed above, and the corresponding workflows are selected based on the workflow dependency relationship to execute the test cases in sequence.

[0073] Specifically, for a certain test case, locate the root node of the test case, start from the leftmost node of the root node and execute each node on the outermost path on the left in sequence until the root node is executed, and then start from the first right node of the root node and execute each node on the outermost path on the right in sequence until the rightmost node is executed.

[0074] by Figure 2 For example, if a test case with D as the root node is executed, the execution path is A->B->D->E->G. In this scenario, D is the main execution subject of the test case, and any subtree is also a complete test case. For example, ABC, B is the main execution subject of the corresponding test case.

[0075] Based on the workflow dependency, the corresponding workflow is selected and executed in sequence. If a node (workflow) reports an error during the execution, it is marked as a use case execution failure. The right node of the right subtree of the error node is executed to clean up the environment and roll back. If the cleanup fails, a global cleanup operation is performed to ensure the normal execution of the next use case.

[0076] by Figure 2 For example, if a test case with D as the root node is executed, the execution path is A->B->D->E->G. If B fails, C will be executed, and B also contains a simple rollback operation.

[0077] This embodiment provides a workflow-based automated testing method that extracts three parts: preconditions, use case execution, and postconditions, and summarizes them into separate use cases. The execution of each use case is written and processed using workflow specifications. A binary tree of all test cases is generated through configuration and scanning, and the execution path is traversed from left to right in the tree, thus covering all use cases. This invention redefines the scenario of automated testing and reconstructs the design and execution method of existing test cases based on graph theory. It can reduce code duplication through good design patterns, so that related tests only focus on the main execution steps of the use case without paying attention to other conditions. The writing of test methods is more focused and easier to debug, improving the maintainability of the overall code. Each individual use case body is relatively independent, and the writing time of the use case can be shortened by increasing manpower. The workflow-based writing method is also more flexible. The test logic can be executed step by step and in stages, and partial rollback operations can be performed well. Time-consuming operations can release thread resources based on the workflow framework. Relying on the framework's polling operation to increase concurrency, more test cases can be executed concurrently with fewer threads.

[0078] Example 2

[0079] The second embodiment provides a workflow-based automated testing device for implementing the workflow-based automated testing method of the first embodiment.

[0080] like Figure 3 The figure shows a schematic structural diagram of a workflow-based automated testing device provided in the second embodiment, which includes the following functional modules.

[0081] Workflow writing module: Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes the workflow dependency configuration specification.

[0082] Binary tree construction module: Scan each workflow to build a binary tree; each node on the binary tree corresponds to a workflow.

[0083] Execution module: Scans the binary tree and selects the corresponding workflow based on the workflow dependency to execute the test case in sequence.

[0084] The workflow-based automated testing device of this embodiment is used to implement the aforementioned workflow-based automated testing method. Therefore, the specific implementation method of the device can be seen in the embodiment part of the workflow-based automated testing method in the previous text. Therefore, its specific implementation method can refer to the description of the corresponding embodiments of each part, and will not be elaborated here.

[0085] In addition, since the workflow-based automated testing device of this embodiment is used to implement the aforementioned workflow-based automated testing method, its function corresponds to that of the aforementioned method and will not be described in detail here.

[0086] Example 3

[0087] Figure 4 A schematic diagram of the structure of a terminal device 400 provided in an embodiment of the present invention includes: a processor 410, a memory 420, and a communication unit 430. The processor 410 is configured to implement the following steps when implementing a workflow-based automated testing program stored in the memory 420:

[0088] Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes workflow dependency configuration specifications;

[0089] Scan each workflow to build a binary tree; each node in the binary tree corresponds to a workflow;

[0090] Scan the binary tree and select the corresponding workflow based on the workflow dependency to execute the test case in sequence.

[0091] The present invention redefines the scenario of automated testing, and re-deconstructs and designs the original test case design and execution method based on graph theory. It can reduce the duplication of code through good design patterns, so that related tests only focus on the execution main steps of the use case without paying attention to other conditions. The writing of the test method is more focused and easier to debug, which improves the maintainability of the overall code. Each individual use case body is relatively independent, and the writing time of the use case can be shortened by increasing manpower. The workflow-based writing method is also more flexible. The test logic can be executed in steps and stages, and partial rollback operations can be performed well. Time-consuming operations can release thread resources based on the workflow framework, and the polling operation relying on the framework increases concurrency, and more test cases can be executed concurrently with fewer threads.

[0092] The terminal device 400 includes a processor 410, a memory 420, and a communication unit 430. These components communicate via one or more buses. Those skilled in the art will appreciate that the server structure shown in the figure does not limit the present invention; it may be a bus structure or a star structure, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0093] Memory 420 can be used to store execution instructions of processor 410. Memory 420 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 memory, flash memory, magnetic disk, or optical disk. When the execution instructions in memory 420 are executed by processor 410, terminal 400 can perform some or all of the steps in the above-described method embodiments.

[0094] The processor 410 is the control center of the storage terminal. It uses various interfaces and lines to connect various parts of the entire electronic terminal. It executes various functions of the electronic terminal and / or processes data by running or executing software programs and / or modules stored in the memory 420, and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor 410 can only include a central processing unit (CPU). In an embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0095] The communication unit 430 is configured to establish a communication channel so that the storage terminal can communicate with other terminals, receive user data sent by other terminals, or send user data to other terminals.

[0096] Example 4

[0097] The present invention also provides a computer storage medium, wherein the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0098] The computer storage medium stores a workflow-based automated testing program, which, when executed by a processor, implements the following steps:

[0099] Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes workflow dependency configuration specifications;

[0100] Scan each workflow to build a binary tree; each node in the binary tree corresponds to a workflow;

[0101] Scan the binary tree and select the corresponding workflow based on the workflow dependency to execute the test case in sequence.

[0102] The present invention redefines the scenario of automated testing, and re-deconstructs and designs the original test case design and execution method based on graph theory. It can reduce the duplication of code through good design patterns, so that related tests only focus on the execution main steps of the use case without paying attention to other conditions. The writing of the test method is more focused and easier to debug, which improves the maintainability of the overall code. Each individual use case body is relatively independent, and the writing time of the use case can be shortened by increasing manpower. The workflow-based writing method is also more flexible. The test logic can be executed in steps and stages, and partial rollback operations can be performed well. Time-consuming operations can release thread resources based on the workflow framework, and the polling operation relying on the framework increases concurrency, and more test cases can be executed concurrently with fewer threads.

[0103] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus a necessary general-purpose hardware platform. Based on this understanding, the technical solutions in the embodiments of the present invention, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, among other media capable of storing program code, and includes instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention.

[0104] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0105] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0106] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0107] The above disclosure is only a preferred embodiment of the present invention, but the present invention is not limited thereto. Any non-creative changes that can be thought of by those skilled in the art, as well as several improvements and modifications made without departing from the principles of the present invention, should fall within the scope of protection of the present invention.

Claims

1. A workflow-based automated testing method, characterized in that: The following steps are involved: Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes workflow dependency configuration specifications; Scan each workflow to build a binary tree; Each node in the binary tree corresponds to a workflow; Scan the binary tree and select the corresponding workflows based on workflow dependencies to execute the test cases in sequence, including: performing a global scan of the workflows and building a binary tree with the current workflow as the root node; Based on the workflow dependency, the precondition workflow of the workflow corresponding to the root node is taken as the left node of the root node, and the postcondition workflow of the workflow corresponding to the root node is taken as the right node of the root node; locate the root node of the test case, start from the leftmost node of the root node and execute each node on the outermost path on the left in sequence until the root node is executed, and then start from the first right node of the root node and execute each node on the outermost path on the right in sequence until the rightmost node is executed.

2. The workflow-based automated testing method according to claim 1, wherein: When a use case is written as a workflow according to a workflow dependency configuration specification, the use case writing specification also includes a workflow dependency configuration specification. Accordingly, the use case is written as a workflow according to the workflow dependency configuration specification, and the workflow dependency is configured through annotations or configuration files.

3. The workflow-based automated testing method according to claim 1, wherein: The method further comprises the following steps: When scanning each workflow to build a binary tree, if the workflow corresponding to the precondition or postcondition has already scanned and built a binary tree, the built binary tree will be directly used.

4. The workflow-based automated testing method according to claim 1, wherein: The method further comprises the following steps: Based on the workflow dependency, the corresponding workflow is selected and executed in sequence. If an error occurs when executing a node, the right node of the right subtree of the error node is executed to clean up the environment and roll back. If the cleanup fails, a global cleanup operation is performed.

5. The workflow-based automated testing method according to any one of claims 1 to 4, characterized in that: The use case writing specification also includes internal context parameter configuration specifications and global context parameter configuration specifications; Create multiple steps within the workflow written according to the use case writing specification, corresponding to the execution steps of the use case, and number or name each step; When executing a workflow, each step within the workflow uses the internal context to pass data; After the workflow execution is completed, the execution data is saved to the corresponding location based on the global context parameters, and the subsequent workflow extracts the saved execution data based on the corresponding global context parameters.

6. The workflow-based automated testing method according to claim 5, characterized in that: The method further comprises the following steps: A waiting mechanism is implemented for steps that take longer than a threshold to execute in the workflow.

7. The workflow-based automated testing method according to claim 6, characterized in that: The use case writing specifications also include use case disassembly specifications and workflow specifications for reusing other test cases.

8. A workflow-based automated testing device, characterized in that: include, Workflow writing module: Treat preconditions, use case execution, and postconditions as separate use cases, and write each separate use case into a workflow according to the use case writing specification; the use case writing specification includes the workflow dependency configuration specification; Binary tree construction module: scans each workflow to build a binary tree; each node in the binary tree corresponds to a workflow; Execution module: Scans the binary tree and selects the corresponding workflows based on workflow dependencies to execute the test cases in sequence, including: performing a global scan of the workflows and building a binary tree with the current workflow as the root node; Based on the workflow dependency, the precondition workflow of the workflow corresponding to the root node is taken as the left node of the root node, and the postcondition workflow of the workflow corresponding to the root node is taken as the right node of the root node; locate the root node of the test case, start from the leftmost node of the root node and execute each node on the outermost path on the left in sequence until the root node is executed, and then start from the first right node of the root node and execute each node on the outermost path on the right in sequence until the rightmost node is executed.

Images