CN116126723A

CN116126723A - Interface automatic test construction method based on workflow platform

Info

Publication number: CN116126723A
Application number: CN202310161447.6A
Authority: CN
Inventors: 黄博涛; 花京武; 兰倩倩; 秦钢; 宋杨
Original assignee: Hangzhou Diji Intelligent Technology Co ltd
Current assignee: Hangzhou Diji Intelligent Technology Co ltd
Priority date: 2023-02-24
Filing date: 2023-02-24
Publication date: 2023-05-16

Abstract

The application relates to an interface automation test construction method based on a workflow platform, which comprises the steps of generating test cases of various service scenes in a service layer, packaging the test cases, and sending the packaged test cases to a logic layer; the logic layer receives and reads the packaged test cases, and analyzes the test case information list of each service scene; reading the test case information list, and judging whether a case exists or not: if the use case exists, a request is issued, and a corresponding use case test is responded; and judging the execution condition of the use case according to the response of the use case test, and outputting the corresponding use case execution result and carrying out statistics. The component object layer can be abstracted, and the whole interface automation can be completed efficiently with low maintenance cost; specific input parameters of the design interface are automatically generated through the combination relation of the parameters, and the problem that the input parameters of the design interface are complex and difficult to generate is solved; the complexity of the low code design state is fully considered, the attribute of the component and the component is abstracted, and the method has the advantages of being configurable and high in maintainability.

Description

Interface automatic test construction method based on workflow platform

Technical Field

The disclosure relates to the technical field of automated testing, in particular to an interface automated testing construction method based on a workflow platform.

Background

The workflow platform shown in the figure 1 of the specification mainly designs an automatic task for automatically transmitting information according to rules through configuration components, drag visualization operation and the like. In task design, however, if the coverage is removed by UI automation, some problems are encountered:

the operation of clicking and dragging the arrow line segment to another component is performed, and the UI realizes that the script stability is not high;

the design operation of the whole workflow is difficult to abstract in a service layer and a logic layer;

the test check point of the workflow is mainly placed on whether the processing and information transmission of each flow node are correct or not.

Thus, workflow automated test recommendations are mainly automated with interfaces. The same automatic decovering through the interface also encounters problems, the design interface structure of the workflow platform is complex, the input/output parameters of the interface are required to be analyzed, and the method packaging is carried out through the developed thought.

The existing industry automation test framework is roughly divided into an object layer, a logic layer, a service layer and a data layer, so that when the change occurs, new addition or maintenance operation can be conveniently performed in different places, the subsequent maintenance cost is reduced, and the maintainability, the stability, the readability and the reusability of the script are improved. The framework is layered clearly, the readability of the test case is improved, the repetition of codes is reduced, and the maintainability of the case is improved.

However, although the existing industry automation test framework can automate the workflow design interface, it is difficult for the common tester to implement the workflow design interface well, if the workflow design interface is made into a fixed interface, there is a great risk point for maintaining the code readability, and the prior art does not solve how the workflow type platform automation test is implemented.

Disclosure of Invention

In order to solve the problems, the application provides an interface automation test construction method, device and control system based on a workflow platform.

In one aspect of the present application, a method for automatically testing and constructing an interface based on a workflow platform is provided, including the following steps:

generating test cases of each service scene in the service layer, packaging, and sending to the logic layer after packaging;

the logic layer receives and reads the packaged test cases, and analyzes the test case information list of each service scene;

reading the test case information list, and judging whether a case exists or not: if the use case exists, a request is issued, and a corresponding use case test is responded;

and judging the execution condition of the use case according to the response of the use case test, and outputting the corresponding use case execution result and carrying out statistics.

As an optional embodiment of the present application, optionally, generating and packaging test cases of each service scenario in the service layer includes:

according to a preset workflow, each flow node is built in a service layer, and a corresponding service scene is built;

writing and generating test cases of each service scene through an excel table case compatible module or a metersphere case compatible module configured by the service layer;

and then, the test cases of each service scene are packaged through a service function method packaging module configured by the service layer.

As an optional embodiment of the present application, optionally, a service scenario established in the service layer may employ at least one of the following scenarios:

the business layer directly uses the model scene pre-packaged in the logic layer;

a model scene is pre-built in a business layer;

the business layer uses the model scene generated by the specific logic method of the newly built model scene provided by the logic layer.

As an optional implementation manner of the present application, optionally, the logic layer receives and reads the packaged test cases, analyzes and obtains a test case information list of each service scenario, and includes:

reading an excel file through an excel table case compatible module, and obtaining case interface information of a corresponding test case; or alternatively, the process may be performed,

reading a corresponding test case file through a metersphere case compatible module, and acquiring case interface information of a corresponding test case;

analyzing the case interface information, analyzing global parameters of the current test case and information of each row of cases, and placing the case information in a test case list;

and preprocessing the test case list according to preset processing pre-conditions to obtain the test case information list node-list.

As an optional implementation manner of the present application, optionally, the test case information list is read to determine whether a case exists: if the use case exists, a request is issued, and the corresponding use case test is responded, wherein the method comprises the following steps:

starting a test and requesting assembly;

reading and analyzing a test case information list node-list, and acquiring interface basic information of the test case through a request Id;

judging whether nodes of the test case exist in the test case information list node-list according to the interface basic information:

if so, responding to an assembly request according to the interface basic information and front-end and back-end parameter information of the to-be-tested test case of the current node, and issuing a test request of the to-be-tested test case;

if the current node does not have the test case to be tested, writing the current node into the statistical result.

As an optional implementation manner of the present application, optionally after issuing a test request for a current test case to be tested, the method further includes:

receiving and responding to a test request for executing the current test case to be tested;

calling an Http request to obtain a test request response for executing the current test case to be tested;

and returning a request response.

As an optional implementation manner of the present application, optionally, according to a response of a use case test, determining a use case execution condition, and outputting interface test information executed by a corresponding use case, including:

receiving the returned response information, judging the use case execution condition of the current node according to the response information, and writing the use case execution condition into the result statistics;

reading the test case information list node-list again, and continuously judging whether the next node has a case or not until all nodes are read completely;

and collecting the interface test result counted after the reading is finished, and outputting a report.

In another aspect of the present application, an apparatus is provided for implementing the method for automatically testing and constructing an interface based on a workflow platform, including:

the test case packaging module is used for generating test cases of each service scene in the service layer, packaging the test cases and sending the packaged test cases to the logic layer;

the analysis module is used for receiving and reading the packaged test cases by the logic layer and analyzing to obtain a test case information list of each service scene;

the test response module is used for reading the test case information list and judging whether the case exists or not: if the use case exists, a request is issued, and a corresponding use case test is responded;

and the test statistics module is used for judging the execution condition of the use case according to the response of the use case test, outputting the corresponding use case execution result and carrying out statistics.

In another aspect of the present application, a control system is also provided, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the workflow platform-based interface automation test construction method upon execution of the executable instructions.

The invention has the technical effects that:

the method comprises the steps of generating test cases of each service scene in a service layer, packaging, and sending the packaged test cases to a logic layer; the logic layer receives and reads the packaged test cases, and analyzes the test case information list of each service scene; reading the test case information list, and judging whether a case exists or not: if the use case exists, a request is issued, and a corresponding use case test is responded; and judging the execution condition of the use case according to the response of the use case test, and outputting the corresponding use case execution result and carrying out statistics. The component object layer can be abstracted, and the whole interface automation can be completed efficiently with low maintenance cost; specific input parameters of the design interface are automatically generated through the combination relation of the parameters, and the problem that the input parameters of the design interface are complex and difficult to generate is solved; the complexity of the low code design state is fully considered, the attribute of the component and the component is abstracted, and the method has the following advantages:

the method comprises the following steps: the components and the properties of the components are made into configurable items, no matter how the subsequent components are changed, the point to be modified is only in one place, and the condition that the maintenance is difficult due to the change of the order of magnitude of automation does not exist;

high maintainability: the change of the service of the component can ensure that only one point needs to be maintained no matter the change of the interface access logic or the change of the service demand of the component.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments, features and aspects of the present disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 illustrates a platform work schematic for a workflow platform;

FIG. 2 is a schematic diagram of an underlying application architecture of the present invention;

FIG. 3 is a schematic diagram of an abstract architecture of the present invention;

FIG. 4 shows an illustration of a metersphere platform of the present invention;

FIG. 5 is a schematic flow chart of the implementation of the invention;

FIG. 6 illustrates a workflow diagram for business layer abstraction of the present invention;

FIG. 7 is a schematic diagram of the logic implemented by the business layer of the present invention;

FIG. 8 is a flow chart of a test case for packaging a logic layer according to the present invention.

Detailed Description

Various exemplary embodiments, features and aspects of the disclosure will be described in detail below with reference to the drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Although various aspects of the embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

In addition, numerous specific details are set forth in the following detailed description in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order not to obscure the present disclosure.

Term interpretation:

workflow refers to "automation of a part or the whole of a business process in a computer application environment". Is an abstract and generalized description of workflow and business rules between its operational steps. In a computer, the workflow is part of a computer-supported collaborative work (CSCW). The latter is a popular study of how a community works cooperatively with the aid of a computer.

The main problems that workflow mainly solves are: to achieve a certain business objective, a computer is used to automatically transfer documents, information, or tasks between multiple participants according to certain predetermined rules.

The invention discloses an automatic testing method which is used for solving the problems that a working platform is multiple in testing flow, complex in operation and difficult to realize UI automatic testing, and adds some automatic framework capability suitable for the characteristics of the Internet of things.

As shown in fig. 2, to implement the underlying technical architecture of the method, the main supported functions are:

1. use case management (data driving, front-end post processing, parameterization, use case marking, assertion, use case design, business function method encapsulation);

2. existing finished legacy frame compatibility (excel, metersphere);

3. test report (alure report presentation);

4. the underlying capabilities (interface message issue package, UI control check package, concurrency control, result collection, notification alert, script version control, multi-environment test, overlay interface statistics).

The framework may be abstracted into an architecture layer as shown in fig. 3, where the architecture mainly includes: object layer, logical layer, business layer and data layer (mainly data support layer in the framework of fig. 2).

The service layer is added with a compatible use case development platform, is configured with an excel form use case compatible module and a metersphere use case compatible module, and can write and generate test use cases of various service scenes (stream nodes) in the workflow according to different workflows.

The old framework of the execl format is compatible, and each row in the execl case file is a test case; the flow is simple, and a request is issued to check its return value. The execl table use case can directly read execl file to obtain use case interface information.

The metersphere platform use case is a visualized api information platform, and can write test use cases on the visualized api information platform. As shown in FIG. 4, the Metersphere platform can acquire json information of the whole test case through an interface, then analyze the json information, simulate the issuing of an http request and judge the response.

The construction method of the present interface test will be described below based on the above architecture.

Example 1

Fig. 5 is a schematic flow chart of the implementation of the method. In one aspect of the present application, a method for automatically testing and constructing an interface based on a workflow platform is provided, including the following steps:

1. generating test cases of each service scene in the service layer, packaging, and sending to the logic layer after packaging;

it can be seen from the workflow design page presented above that the addition and deletion of each component, the change in each configuration of the components, is quite difficult for the entry of the interface, not to make a large json string to modify it, but to analyze according to the entry of the interface, how the composition of the entry is, and what relationships are with each component, each attribute configuration.

The design interface of the platform workflow is analyzed to be composed of front-end design state page information, component front-end display information, component logic chain information and component configuration, and the information is respectively placed in three fields below the root entering node.

The filling of the interface entry pair should be to design a scenario, which components, how the component parameters are, how the component logic chain is, etc., and fill these parameters into the interface entry through the same business logic, respectively. Component differences here.

As shown in fig. 6, a schematic diagram of the workflow set up in the business layer is shown. In a workflow of one item, tasks of different nodes are different, and configuration information such as interface information is also different. Specific node tasks in the workflow are abstracted into corresponding application nodes, such as personnel submitting approval sheets, which are used as a starting node of the workflow, and corresponding functional components are configured in a business layer correspondingly. The service layer performs use case design according to different scenes. Specific:

when the service layer designs the case (by using the compatible excel table case or metersphere case function, write the test case), the workflow can design some scenes covering all the function points, and 10+ scenes in number can be used for testing the function combinations in all the workflows. So there may be multiple components in the workflow business layer script that are combined into a code implementation of a workflow, but if it is a very general scenario, it may also be packaged into a logic flow method for business layer use. The method has the advantages that when the testing scene of the subsequent service layer is changed and the component attribute is changed, the adaptation can be realized by maintaining in a limited place as few as possible.

As shown in fig. 7, each node (to-be-tested node) corresponds to a service scenario, and logic execution is set between the nodes according to a workflow flow mode. Firstly, configuring a scene for a node, wherein the scene can be built in a service layer by a user, and an existing model scene can be called from a logic layer through an interface.

a model scene is pre-built in a business layer;

There are three ways: the business layer directly uses a model scene encapsulated by the logic layer; constructing an arbitrary model scene in a service layer, and modifying component attributes; the service layer uses the scene of the new model provided by the logic layer and modifies the data corresponding to a certain node.

As shown in fig. 7, in the service scenarios 1-3, all the nodes in different scenarios are extracted, the nodes in each scenario are divided into one type of Node, a Node list is built, and finally a unified model (such as a model scenario generated by a specific logic method of a newly built model scenario provided by a logic layer) is called, and the Node list is packaged, so that a new test case information list Node-list model (see description below).

When the test cases are written for the node list, the excel table case or the metersphere case module is utilized to edit the cases, the corresponding test cases are written for each service scene, and the node list is uniformly packaged, so that the rapid packaging effect of the test cases for each service scene is realized.

2. The logic layer receives and reads the packaged test cases, and analyzes the test case information list of each service scene;

the logic layer encapsulates specific interface calls, and the main difficulty is that the workflow model designs interfaces, and other interfaces do according to normal automation. The design interface of the workflow generally contains front-end information of the design page, and attribute configuration of each component, back-end information of the logic chain. According to the multiple components transferred in by the service layer, front and back end information of each component needs to be split and written into respective fields in parameters.

The code logic is easy to realize, and the method for acquiring the front-end information and the back-end information of each component is difficult to achieve, so that the respective components are required to be abstracted, and the problem is solved at an object layer. And the object layer is used for abstracting each component, and the attribute of the component, the design state position information, the component data authorization information and the attribute unique to each component. The method has the advantages that a plurality of components are initialized in the service layer, the components are provided for the logic layer, the logic layer can automatically generate specific input parameters of the design interface through the combination relation of parameters, the problem that the input parameters of the design interface are complex and difficult to generate is solved, how to build a designed scene specifically, which functions are used and which functions are default values can be easily seen through the service layer.

The data layer may be a script configuration stored via a file, may be a list within code, may be invoked via an interface, etc., specifically to see how the test tool is used. The specific scene of the workflow is realized without special optimization.

As shown in fig. 5, the logic layer mainly reads each test case in the list to obtain case interface information of the corresponding test case, and after analysis, parameter configuration information of the test case is obtained, for example, json information of the whole test case can be obtained through an interface by a Metersphere platform, then analysis is performed, then an http request is simulated to issue, and response is judged.

When analyzing the case interface information, analyzing the global parameters of the current test case and the information of each row of cases, and placing the case information in a test case list (including the parameter entering information of all nodes). Before reading, a user needs to log in a system, clear data and the like, and obtains a test case information list node-list waiting for testing through a pre-processing program.

3. Reading the test case information list, and judging whether a case exists or not: if the use case exists, a request is issued, and a corresponding use case test is responded;

during testing, the logic layer firstly needs to obtain the testing parameters of each use case by reading the node parameter information in the list, and assembles each parameter to request for entering into the parameters. And then issuing a test request and responding to the test request.

starting a test and requesting assembly;

reading and analyzing a test case information list node-list, acquiring interface basic information of the test case through a request Id, and judging whether nodes of the test case exist in the test case information list node-list according to the interface basic information:

if so, responding to an assembly request according to the interface basic information of the to-be-tested test case of the current node, and issuing a test request of the to-be-tested test case;

Therefore, each node of the workflow is packaged in a node list, and therefore, the list node-list needs to be read and parsed to obtain interface basic information configured by each node.

Interface basic information specifically includes: the method comprises the steps of obtaining front-end and back-end parameter information and design-state display information from each component, and extracting json strings and other information of corresponding parameters from each component. And a tester can judge the nodes to be tested according to the interface basic information. And if the node is found to have the entry, the node indicates that the corresponding test case is configured, and the test can be executed.

As shown in fig. 8, in this embodiment, front end information, design style and configuration information of all nodes need to be obtained from the list node-list during parsing, and a request for joining is set according to these information. After analysis, the parameters are assembled, and a test request is issued, so that the test is convenient to execute. And after the test, returning a response result of the request.

and returning a request response.

In this embodiment, in a manner of covering interface statistics, as shown in fig. 8, all http requests issued in a framework are http_clients that are encapsulated in a unified manner, and on this basis, data collection of a path+method dimension can be performed for each issued request, and finally, the interface statistics of the covered test can be output when the test is completed.

4. And judging the execution condition of the use case according to the response of the use case test, and outputting the corresponding use case execution result and carrying out statistics.

And when judging that all the nodes provided with the effective test cases in the discovery list are tested, counting all the execution results to be used as a test report of the test and outputting the test report.

After the test case execution test of each node is finished, writing the execution condition into the result statistics; and judging and executing other nodes in turn. And writing the node condition of the node with no use case into the result statistics.

In the embodiment, when the node is managed and the use case is read, written and managed, the adopted functional components are correspondingly selected according to the steps of the method, and the embodiment is not described. By adopting the method, the component object layer of the method can be removed, and the whole interface automation can be completed efficiently and with low maintenance cost.

Therefore, the present application has the following advantages:

In addition to the scheme, the scheme can also be controlled by script version. The specific implementation is as follows: the test cases are marked by adding modifiers, and then the case collection stage is used for judging whether the cases are suitable for the version number of the test. The specific application will not be described in detail.

It should be apparent to those skilled in the art that the implementation of all or part of the above-described embodiments of the method may be implemented by a computer program for instructing relevant hardware, and the program may be stored in a computer readable storage medium, and the program may include the steps of the embodiments of the control methods described above when executed. It will be appreciated by those skilled in the art that implementing all or part of the above-described embodiment methods may be implemented by a computer program for instructing relevant hardware, and the program may be stored in a computer readable storage medium, and the program may include the embodiment flow of each control method as described above when executed. The storage medium may be a magnetic disk, an optical disc, a Read-only memory (ROM), a random access memory (RandomAccessMemory, RAM), a flash memory (flash memory), a hard disk (HDD), or a Solid State Drive (SSD); the storage medium may also comprise a combination of memories of the kind described above.

Example 2

Based on the implementation principle of embodiment 1, in another aspect of the present application, an apparatus is provided for implementing the method for automatically testing and constructing an interface based on a workflow platform, where the method includes:

The functions and interactions An Yunli of the various modules described above, detailed description of embodiment 1.

The modules or steps of the invention described above may be implemented in a general-purpose computing device, they may be centralized in a single computing device, or distributed across a network of computing devices, or they may alternatively be implemented in program code executable by a computing device, such that they may be stored in a memory device and executed by a computing device, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps within them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

Example 3

Furthermore, another aspect of the present application further provides a workflow platform-based control system for an automated test construction method of an interface, including:

a processor;

a memory for storing processor-executable instructions;

Embodiments of the present disclosure control a system that includes a processor and a memory for storing processor-executable instructions. The processor is configured to implement any of the workflow platform-based interface automation test construction methods described above when executing the executable instructions.

Here, it should be noted that the number of processors may be one or more. Meanwhile, in the control system of the embodiment of the present disclosure, an input device and an output device may be further included. The processor, the memory, the input device, and the output device may be connected by a bus, or may be connected by other means, which is not specifically limited herein.

The memory is a computer-readable storage medium that can be used to store software programs, computer-executable programs, and various modules, such as: the workflow platform-based interface automation test construction method of the embodiment of the disclosure corresponds to a program or a module. The processor executes various functional applications and data processing of the control system by running software programs or modules stored in the memory.

The input device may be used to receive an input number or signal. Wherein the signal may be a key signal generated in connection with user settings of the device/terminal/server and function control. The output means may comprise a display device such as a display screen.

The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. The interface automation test construction method based on the workflow platform is characterized by comprising the following steps:

2. The method for automatically testing and constructing an interface based on a workflow platform according to claim 1, wherein generating and packaging test cases of each service scene in a service layer comprises:

3. The method for automatically testing and constructing an interface based on a workflow platform according to claim 1, wherein at least one of the following service scenarios established in the service layer can be adopted:

a model scene is pre-built in a business layer;

4. The method for automatically testing and constructing the interface based on the workflow platform according to claim 2, wherein the logic layer receives and reads the packaged test cases, analyzes the test case information list of each service scene, and comprises the steps of:

5. The method for automatically testing and constructing an interface based on a workflow platform according to claim 4, wherein the method comprises the steps of reading a test case information list and judging whether a case exists: if the use case exists, a request is issued, and the corresponding use case test is responded, wherein the method comprises the following steps:

starting a test and requesting assembly;

6. The method for automatically testing and constructing an interface based on a workflow platform according to claim 5, further comprising, after issuing a test request for a current test case to be tested:

and returning a request response.

7. The method for constructing an automated testing of an interface based on a workflow platform according to claim 6, wherein determining a case execution condition according to a response of a case test and outputting interface test information of a corresponding case execution comprises:

8. Apparatus for implementing the workflow platform-based interface automation test construction method of any one of claims 1 to 7, comprising:

9. A control system, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the workflow platform based interface automation test construction method of any one of claims 1 to 7 when executing the executable instructions.