CN112799959A - Interface test method, device, storage medium and electronic device - Google Patents

Abstract

The invention discloses an interface testing method, an interface testing device, a storage medium and an electronic device. The method comprises the following steps: loading a behavior tree corresponding to a target interface to be tested; generating a test case based on the behavior tree; testing the target interface by using the test case to obtain a test result; and generating a test report of the target interface based on the test result. By the method and the device, the technical effect of improving the interface testing efficiency is achieved.

Description

Interface test method, device, storage medium and electronic device

Technical Field

The invention relates to the field of interface testing, in particular to an interface testing method, an interface testing device, a storage medium and an electronic device.

Background

Currently, API automation unit testing tools include a web debugging tool client (postman) and a stress testing tool (meter), which can perform a single interface test. However, in a more complex system, a huge amount of policy combinations and scenario dependencies will be generated, which are difficult to implement a series of tests of complex actions in a complex scenario, for example, a test scenario needs to be prepared in advance in a relatively low manual manner, a test execution process needs to be performed, a test may be interrupted due to complex link factors, a manual retry is needed, a test flow is unstable, and it is also difficult to implement a series connection of tests of each single interface.

In addition, the script writing freedom of the pytest testing framework is high, the constraint and unified standard is not adopted, different testers can write scripts with different styles and levels, so that the handover and collaborative development are difficult, meanwhile, the complex logic codes bring huge maintenance cost, once the system is iterated frequently, the codes need to be maintained frequently, the use stability is not facilitated, and the technical problem of low efficiency of testing the interface exists.

Aiming at the problem of low efficiency of testing the interface in the prior art, no effective solution is provided at present.

Disclosure of Invention

The invention mainly aims to provide an interface testing method, an interface testing device, a storage medium and an electronic device, and at least solves the technical problem of low efficiency of testing an interface.

To achieve the above object, according to one aspect of the present invention, there is provided a method of interface testing. The method is applied to a pytest testing framework and can comprise the following steps: loading a behavior tree corresponding to a target interface to be tested; generating a test case based on the behavior tree; testing the target interface by using the test case to obtain a test result; and generating a test report of the target interface based on the test result.

Optionally, the behavior tree is tree-structure data composed of a plurality of test behavior nodes, each test behavior node is a result of encapsulating one test behavior of the target interface, and the generating of the test case based on the behavior tree includes: and configuring the plurality of test behavior nodes to obtain the test case.

Optionally, configuring a plurality of test behavior nodes to obtain a test case, including: configuring a plurality of testing behavior nodes to obtain a subtree of a behavior tree, wherein the subtree is a testing template which is allowed to be reused when a target interface is tested; and generating the subtree into a test case.

Optionally, the test behavior node comprises at least one of: a polling node for executing cyclically a sub-tree associated with the polling node; the interface request node is used for requesting data of a target interface; the judging node is used for judging the data of the target interface; and the global definition node is used for defining global variables of the target interface.

Alternatively, if a child node of the polling node returns a logically true result, execution of a sub-tree associated with the polling node is prohibited and a logically true result is returned to a parent node of the polling node.

Optionally, if the child node of the polling node does not return a logically true result within the target time period, a logically false result is returned to the parent node of the polling node.

Optionally, the parameters of the interface requesting node include at least one of: the system comprises a target interface, a request mode, a request parameter, a state code and a variable name, wherein the state code is a state expected value returned by a request of an interface request node, and data requested by the interface request node is stored by the variable name.

Optionally, the parameter of the determination node includes at least one of: left data, conditional comparator, and right data.

Optionally, the parameters of the globally defined node include at least one of: variable name and value.

Optionally, the testing the target interface by using the test case to obtain a test result, including: and loading and executing the target interface in the test case to obtain a logic true result or a logic false result of the target interface.

Optionally, the testing the target interface by using the test case to obtain a test result, including: sending a test request to a server based on the test case; and obtaining a test result obtained by the server responding to the test request and testing the target interface.

Optionally, generating a test report of the target interface based on the test result includes: generating a test report for the target interface based on at least one of the following test results: test time, name of test case, and test conclusion.

Optionally, in a case where the test case is edited by a target terminal device of the plurality of terminal devices, the test case prohibits editing by a terminal device other than the target terminal device of the plurality of terminal devices.

Optionally, in a case that the target terminal device sends an unlocking request to the server, or after the target duration that the target terminal device is in the closed state, or after the target duration that the target terminal device does not continuously edit the test case, the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal, where the unlocking request is used to request the server that the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal.

Optionally, the terminal device is further configured to perform at least one of the following operations on the test case: the method comprises the following operations of sharing operation, storing operation, executing operation and displaying test report.

In order to achieve the above object, according to another aspect of the present invention, there is also provided an interface test apparatus applied to a pytest test framework, including: the loading unit is used for loading a behavior tree corresponding to a target interface to be tested; the processing unit is used for generating a test case based on the behavior tree; the test unit is used for testing the target interface by using the test case to obtain a test result; and the generating unit is used for generating a test report of the target interface based on the test result.

In order to achieve the above object, according to another aspect of the present invention, there is also provided a computer-readable storage medium. The computer readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the apparatus where the computer readable storage medium is located is controlled to execute the interface testing method according to the embodiment of the present invention.

In order to achieve the above object, according to another aspect of the present invention, an electronic device is provided. The electronic device comprises a memory and a processor, and is characterized in that the memory stores a computer program, and the processor is configured to run the computer program to execute the data processing method of the embodiment of the invention.

In the invention, loading a behavior tree corresponding to a target interface to be tested; generating a test case based on the behavior tree; testing the target interface by using the test case to obtain a test result; and generating a test report of the target interface based on the test result. That is to say, this application generates the test case through the action tree to can unify the manufacture standard of test case, reduce the test handing-over cost, and collect and output the test result in the test frame of pytest, keep the original report function of test frame of pytest, thereby solved the technical problem that the efficiency that tests to the interface is low, reached the technological effect that improves the efficiency that tests to the interface.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this application, illustrate embodiments of the invention and, together with the description, serve to explain the invention and not to limit the invention. In the drawings:

fig. 1 is a block diagram of a hardware structure of a mobile terminal according to an interface testing method of an embodiment of the present invention;

FIG. 2 is a flow chart of a method of interface testing according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of use case collaborative development according to an embodiment of the present invention;

FIG. 4 is a schematic illustration of a test management according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a behavior tree execution flow logic scheme according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of a seed tree structure according to an embodiment of the present invention;

fig. 7 is a schematic diagram of an interface testing apparatus according to an embodiment of the invention.

Detailed Description

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present invention will be described in detail below with reference to the embodiments with reference to the attached drawings.

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It should be understood that the data so used may be interchanged under appropriate circumstances such that embodiments of the application described herein may be used. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The method provided by the embodiment of the application can be executed in a mobile terminal, a computer terminal or a similar operation device. Taking an example of the application to a mobile terminal, fig. 1 is a block diagram of a hardware structure of the mobile terminal according to an interface testing method of the embodiment of the present invention. As shown in fig. 1, the mobile terminal may include one or more (only one shown in fig. 1) processors 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, and optionally may also include a transmission device 106 for communication functions and an input-output device 108. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration, and does not limit the structure of the mobile terminal. For example, the mobile terminal may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The memory 104 can be used for storing computer programs, for example, software programs and modules of application software, such as a computer program corresponding to a data processing method in the embodiment of the present invention, and the processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, so as to implement the above-mentioned method. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the mobile terminal over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.

In the embodiment, an interface test method running in the mobile terminal is provided, and the method can be applied to a pytest test framework.

Fig. 2 is a flowchart of an interface testing method according to an embodiment of the present invention. As shown in fig. 2, the method may include the steps of:

step S202, loading a behavior tree corresponding to the target interface to be tested.

In the technical solution provided in step S202 of the present invention, the target Interface is an Interface to be tested, and may be an Application Program Interface (API) to be tested, and a behavior tree corresponding to the target Interface may be loaded in a test framework, for example, a test module formed by the test framework loads the behavior tree, where the behavior tree is tree-structured data, and is used to implement testing of the target Interface, and may be used to implement complex testing behaviors performed on the target Interface, and in the whole test flow performed on the target Interface, a next testing action to be executed may be determined and selected according to a current testing scenario.

In this embodiment, the behavior tree is a tree structure data composed of a plurality of test behavior nodes, and may extend from left to right, each node has zero or more child nodes attached thereto, and has a traversal execution rule, which is a default order from left to right and from top to bottom, after each node is executed, there is a boolean return value, logical true (true) or logical false (false), and the logical true or logical false may be returned to the parent node of the current node, and after the return, control is transferred to the parent node of the current node to determine the next node to be tested. Further explaining the traversal rule, the traversal rule may be executed from the top left root node, the uppermost child node is executed to the right root level until there is no child node, and then the parent node of the current node is returned to find whether there are child nodes that have not been executed. If the unexecuted child nodes are found, the child nodes which are not executed at the top can be continuously executed rightward layer by layer according to the rule until no child node exists, and the parent node of the current node is returned, so that all the nodes are continuously traversed, for example, the root node has two child nodes a and d, wherein the node a has two child nodes b and c, the node d has two child nodes e and f, and the execution sequence of the tree-structured behavior tree is the child nodes a, b, c, d, e and f.

And step S204, generating a test case based on the behavior tree.

In the technical solution provided in step S204 of the present invention, after the behavior tree corresponding to the target interface to be tested is loaded, a test case (test case) may be generated based on the behavior tree, and a test case with high reusability and portability may be generated through the behavior tree, where the number of the test cases may be multiple, and a case library may be formed through multiple test cases, so as to achieve the purpose of making the test case.

The embodiment generates the test case through the behavior tree, so that the manufacturing standard of the test case can be unified, the test handover cost is reduced, the manufacturing efficiency of the test case can be improved by the test case with high reusability and portability, and the code maintenance cost is further reduced.

And step S206, testing the target interface by using the test case to obtain a test result.

In the technical solution provided by step S206 of the present invention, after the test case is generated based on the behavior tree, the target interface may be tested by using the test case to obtain the test result.

In this embodiment, when the target interface is tested, the target interface may be tested through the generated test cases, for example, one or more test cases are selected from the multiple test cases, a virtual isolation environment is created, and the target interface is tested through the selected one or more test cases in the virtual isolation environment, so as to obtain a test result.

And step S208, generating a test report of the target interface based on the test result.

In the technical solution provided by step S208 of the present invention, after the target interface is tested by using the test case to obtain the test result, a test report of the target interface may be generated based on the test result.

In this embodiment, the pytest module may collect the test result of the target interface, generate a test report based on the test result, and output the test report. Optionally, the embodiment may store the test report in a report library for the terminal device to perform the request query.

In the embodiment, in the pytest testing framework, not only can an intuitive testing report be generated, but also various complex logic behavior scripts can be written, and single interface tests can be connected in series, so that more complex testing logics are realized.

Loading a behavior tree corresponding to a target interface to be tested through the steps S202 to S208; generating a test case based on the behavior tree; testing the target interface by using the test case to obtain a test result; and generating a test report of the target interface based on the test result. That is to say, the embodiment generates the test case through the behavior tree, so that the manufacturing standard of the test case can be unified, the test handover cost is reduced, the test result is collected and output in the test framework, the original report function of the test framework is maintained, the technical problem of low efficiency of testing the interface is solved, and the technical effect of improving the efficiency of testing the interface is achieved.

The above-described method of this embodiment is further described below.

As an optional implementation manner, the behavior tree is tree-structured data composed of a plurality of test behavior nodes, each test behavior node is a result of encapsulating one test behavior of the target interface, and step S204 is to generate a test case based on the behavior tree, including: and configuring the plurality of test behavior nodes to obtain the test case.

In this embodiment, the behavior tree for testing the target interface may be composed of a plurality of test behavior nodes, each test behavior node is a packaging result of one test behavior, and the embodiment may configure the plurality of test behavior nodes to implement the production of the test case.

As an optional implementation manner, configuring a plurality of test behavior nodes to obtain a test case includes: configuring a plurality of testing behavior nodes to obtain a subtree of a behavior tree, wherein the subtree is a testing template which is allowed to be reused when a target interface is tested; and generating the subtree into a test case.

In this embodiment, when configuring multiple testing behavior nodes, a tester may perform a combined configuration on multiple testing behavior nodes in advance on a reusable testing row for testing a target interface to make a subtree of a behavior tree, where the subtree may serve as a testing template that can be reused and may be hung below a certain testing behavior node of the behavior tree to serve as a testing branch point. Optionally, in the embodiment, subtrees can be hooked under a plurality of behavior trees, or subtrees can be hooked under a plurality of behavior trees, and the test case is generated through the subtrees, so that the reusability and the portability are high, the production efficiency of the test case can be improved, and the code maintenance cost is reduced.

As an optional implementation, the test behavior node includes at least one of: a polling node for executing cyclically a sub-tree associated with the polling node; the interface request node is used for requesting data of a target interface; the judging node is used for judging the data of the target interface; and the global definition node is used for defining global variables of the target interface.

This embodiment provides various designs of test behavior nodes for a behavior tree, where a test behavior node may be a control flow node that controls the flow of execution of a child node and changes the flow of execution of the child node as appropriate. Optionally, the control flow node of this embodiment may include: polling node, sequence node and selection node. Wherein a polling node may be configured to cyclically execute a sub-tree associated with the polling node, i.e., the polling node may cyclically execute its sub-tree; the function of the sequential node may be to execute its child nodes from top to bottom in sequence, when any child node executes a logic false result (false), the subsequent child node is not executed any more, and a logic false result is returned to the parent node, if all child nodes do not return a logic false result, a logic true result (true) may be returned to the parent node, and it can be understood that its child node is in a logical and (and) relationship; the selected node is also a child node which executes the selected node from top to bottom in sequence, but contrary to the logic of the sequential nodes, when the execution result of one child node is a logic true result, the subsequent child node can not be executed any more, and the logic true result is returned to the parent node, if all the child nodes do not return the logic true result, a logic false can be returned to the parent node, and the relationship that the child node is logic or (or) can be understood.

Optionally, the test behavior node of this embodiment may also be a test execution node, which may include an interface request node, a judgment node, a global definition node, and other test behavior nodes. The interface request node can be an API request node and can be used for requesting data of a target interface, the requested data can be stored in the global storage, and the data depended on by the interface request node is provided for subsequent nodes; the judgment node can be used for judging the data of the target interface, when the judgment is executed, the data can be obtained from the global memory for comparison, the left data and the right data meet the condition, the execution result returns a logic true result, otherwise, a logic false result is returned; the global definition node may be used to define a global variable of the target interface, for example, there may be multiple interface request nodes under one behavior tree, if the API address needs to be changed and there is a global definition of the API address, only the address in the global definition node needs to be changed without modifying each interface request node, if multiple API addresses are tested through the same set of test behaviors, multiple behavior trees may be copied, and the global definition node is hung at the beginning of each behavior tree and may be used to define the addresses of multiple APIs respectively.

It should be noted that, in an actual application scenario, there is not only one API address, but also many request parameters that need to be changed frequently, and global control is also needed.

It should be noted that, in the related art, the behavior tree is mostly applied to Artificial Intelligence (AI) in the game, and the polling node, the interface request node, the judgment node, and the global definition node in this embodiment are specific to the interface test in the present solution. The embodiment can expand more test behavior nodes with test functions according to test requirements, and each test behavior node can be composed of a basic data structure, which is respectively as follows: the node type, the node brief description, the parameter list and the child node list, wherein the settable parameter in the parameter list is determined by the type of the test behavior node.

The function of the above-described polling node of this embodiment is further described below.

As an alternative embodiment, if a child node of a polling node returns a logically true result, execution of a sub-tree associated with the polling node is prohibited and a logically true result is returned to a parent node of the polling node; and if the child node of the polling node does not return a logical true result in the target time period, returning a logical false result to the parent node of the polling node.

In this embodiment, if a child node of a polling node returns a logically true result, its subtree may not continue to be executed and a logically true result may be returned to the parent node. Optionally, the polling node in this embodiment further has a timeout parameter set, and if the child node of the polling node does not return a logically true result within the target time period, the logical true result may be returned to the parent node until the target time period is exceeded, and the polling node may be configured to poll the test status of the target interface, and may exit the polling when the test status is an expected status.

The parameters of the above-mentioned interface requesting node of this embodiment are further described below.

As an optional implementation, the parameters of the interface request node include at least one of: the system comprises a target interface, a request mode, a request parameter, a state code and a variable name, wherein the state code is a state expected value returned by a request of an interface request node, and data requested by the interface request node is stored by the variable name.

In this embodiment, the parameters of the interface request node may be composed of a target interface, a request mode, a request parameter, a status code, and a variable name. The request return data can be stored in the global storage by the variable name, so that the data depended on by the request return data is provided for the subsequent node, and if the request parameter of the request interface node needs to depend on the return data requested before, the corresponding variable name can be used for obtaining the data, so that the problem of dependency between interfaces is solved; the state code is a state expected value requested to be returned by the interface request node, when the test state accords with the state expected value, the execution result of the interface request node can return a logic true result, otherwise, a logic false result is returned.

The above-described determination node of this embodiment is further described below.

As an optional implementation manner, the parameter of the determination node includes at least one of the following: left data, conditional comparator, and right data.

In this embodiment, the parameter of the determination node may be composed of left data, a condition comparator and right data, where the condition comparator may include less than, greater than or equal to, less than or equal to, contained, partially contained, and the like, and the left data and the right data may be global variable names. When the judgment is executed, the data corresponding to the global variable name can be obtained from the global memory for comparison, if the left data and the right data both meet the condition, the execution result of the judgment node can return a logic true result, otherwise, a logic false result is returned.

The global definition node of this embodiment is further described below.

As an optional implementation, the parameters of the globally defined node include at least one of: variable name and value.

In this embodiment, the global definition node accepts two parameters, namely, a global definition node defines an address of the API, the variable name may be @ req, and the value is the address of the API, after the node executes, the global variable of @ req is generated, and the variable may be transmitted to other nodes, so that the API requesting node may use the variable @ req as an API parameter, and thus, the global definition node may be hung at the beginning of the behavior tree for initializing some global variables, thereby achieving the purpose of global control.

As an optional implementation manner, in step S206, testing the target interface by using the test case to obtain a test result, including: and loading and executing the target interface in the test case to obtain a logic true result or a logic false result of the target interface.

In this embodiment, the behavior tree may be used to derive JSON data. This embodiment may load and execute the target interface in the test case of the pytest test framework. After the execution of the target interface is completed, a logically true result or a logically false result is output. Optionally, one test case may correspond to one behavior tree, multiple test cases may form an integrated test, and when the behavior tree is used to solve a complex test behavior, a pytest test framework is also used to collect a test result and generate a test report.

As an optional implementation manner, in step S206, testing the target interface by using the test case to obtain a test result, including: sending a test request to a server based on the test case; and obtaining a test result obtained by the server responding to the test request and testing the target interface.

The embodiment provides a test management scheme, which includes a test execution and report generation policy, and a user can select one or more test cases in a terminal device to send a test request to a server (server), where the test request is used to request the server to execute a test on a target interface. After the server receives the test request, the corresponding test case can be taken out from the case library based on the test request, a virtual isolation environment (virtual execution environment) can be created through an open-source application container engine (dorker), the test is independently executed on the target interface in the isolation environment, and the obtained test result is transmitted to the pytest module.

As an optional implementation manner, in step S208, generating a test report of the target interface based on the test result includes: generating a test report for the target interface based on at least one of the following test results: test time, name of test case, and test conclusion.

In this embodiment, the pytest module may generate a test report based on the received test result, store the test report in the report library, where the test result may be composed of a test time, a name of a test case, and a test conclusion, and may request a query through the terminal device.

In this embodiment, an architecture consisting of a plurality of terminal devices (user terminals), a server, and a case library is provided, so as to implement test case development, test execution, and report management, which will be further described below.

As an optional implementation manner, in a case where the test case is edited by a target terminal device of the plurality of terminal devices, the test case prohibits editing by a terminal device other than the target terminal device of the plurality of terminal devices.

In this embodiment, the test case may be edited on the terminal device, and when the test case is edited by a target terminal device of the plurality of terminal devices, the test case is prohibited from being edited by a terminal device other than the target terminal device of the plurality of terminal devices, that is, the test case is in a locked state (locked state), so that a problem that a plurality of terminal devices are likely to collide when editing the same test case is avoided.

Optionally, the server in this embodiment may provide a use case lock manager, where the use case lock manager is configured to allow one terminal device to open only one test for editing, and not allow two terminal devices to open one test case at the same time. When the terminal equipment initiates a request for editing a test case to the server, the server locks the test case, so that the terminal equipment occupies the test case and prohibits other terminal equipment from editing the test case.

As an optional implementation manner, in a case where the target terminal device sends an unlocking request to the server, or after the target duration that the target terminal device is in the off state, or after the target terminal device does not continuously edit the target duration of the test case, the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal, where the unlocking request is used to request the server that the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal.

In this embodiment, the target terminal device may not always edit the test case, and may allow any terminal device of the plurality of terminal devices except the target terminal device to edit the test case when a certain condition is satisfied.

Optionally, in a case where the target terminal device sends the unlocking request to the server, the server may release the right of editing the test case only by the target terminal device at this time, that is, release the occupied state of editing the test case by the target terminal device, and the test case may be edited by any terminal device of the plurality of terminal devices except the target terminal device.

Optionally, after the target duration that the target terminal device is in the closed state, for example, the target terminal device is abnormally closed and fails to send the unlocking request to the server, so that after the target duration, for example, after 10 minutes, any terminal device of the plurality of terminal devices except the target terminal device performs editing.

Optionally, after the target terminal device does not continuously edit the target duration of the test case, for example, after 10 minutes, the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal device.

Optionally, the terminal device may reset the target duration each time the test case is edited, and keep holding the test.

As an optional implementation manner, the terminal device is further configured to perform at least one of the following operations on the test case: the method comprises the following operations of sharing operation, storing operation, executing operation and displaying test report.

In this embodiment, the terminal device may implement test case manufacturing, may perform a sharing operation on the test cases to implement case sharing, may perform a storage operation on the test cases to implement case storage, may perform an operation on the test cases to implement case execution, and may perform an operation of displaying a test report on the test cases, thereby implementing an object of outputting the test report.

In this embodiment, the terminal device may include: report window, use case list window, use case edit window, operation button group. The report window can be used for displaying a historical execution result of testing a target interface, the case list window can be divided into a subtree list and a test case list, the subtree list and the test case list are all data of a behavior tree structure, the subtree list or the test case list is operated, for example, double-click on the test case list or the subtree list can be rendered in a case editing window by analyzing a graph formed by the tree structure, the case editing window is a tree-shaped graph editor and can be used for performing operations such as adding, deleting, copying, dragging and connecting nodes, and double-click on the nodes can expand parameter editing of the nodes.

The embodiment provides an interface automatic testing scheme combining a pytest testing framework and a behavior tree, wherein a testing case is written through the behavior tree, the behavior tree can be loaded and executed by a pytest module, and a testing result of the testing of a target interface by the testing case is finally collected by the pytest module and a report is output. Because the case production standard can be unified through the behavior tree compiling case, the handover cost is reduced, the pytest module collects the case execution result corresponding to each behavior tree and outputs the report, the original report function is kept, the technical problem of low data testing efficiency is solved, and the technical effect of improving the data testing efficiency is achieved.

The above technical solution of this embodiment is further described below by way of example, specifically, a target interface is taken as an API for example.

In the related art, the API automation unit tester has postman, meter, which can perform a single interface test of API request response, return status, return data, etc. However, in a more complex system, a huge amount of policy combinations and scenario dependencies are generated, which are difficult to realize that a series of tests of complex action behaviors are completed in a complex scenario, and that the tests of each single interface are connected in series. For example, for a test deletion transaction, the transaction needs to be in an idle state depending on the existence of the transaction, the transaction state may be in a creation state, an idle state, a busy state, an adjustment state, and the like, the inside of the program may be switched according to the current situation, if the test deletion transaction needs to be performed, a request for creating the transaction needs to be initiated first and returned successfully, the transaction will enter the creation state, and a certain creation time is required. After the transaction is completed, the transaction is switched to an idle state, the test of deleting the transaction can be carried out, or the state switching can be carried out at the moment of initiating the request for deleting the transaction, so that the request fails, the test is interrupted, automatic retry is needed at the moment, when the request for deleting is returned successfully, the transaction enters deletion, certain deletion processing time is needed, after the transaction is completed and deleted, the request for inquiring the transaction is sent again, whether the transaction is successfully deleted or not is judged by utilizing the condition that the transaction cannot be inquired, and finally the test is completed.

The above series of complex action behaviors also depend on a specific test scenario, that is, a scenario in which a transaction can be deleted exists, so that the test scenario has to be prepared in advance in a relatively low manual manner, the test execution process is tested, and also the test is interrupted by a complex link factor, which requires manual retry, and the test flow is very unstable.

Therefore, the pytest framework can be considered. However, the script writing freedom of the pytest testing framework is high, no constraint and unified standard exists, different testers can write scripts with different styles and levels, handover and collaborative development are difficult, meanwhile, complex logic codes bring huge maintenance cost, once the system is iterated frequently, the codes need to be maintained frequently, and the use stability is not facilitated.

In response to the above problems, this embodiment provides an interface automated testing scheme that is combined with a behavior tree by the pytest testing framework, which is further described below.

The following introduces a method for editing the same use case library by multiple users to avoid the problem of collision.

FIG. 3 is a schematic diagram of collaborative development of a use case according to an embodiment of the present invention. As shown in fig. 3, the following steps may be included:

step S301, a user uses a terminal device to initiate requests of adding, modifying, deleting and acquiring test cases, the transmitted request data can include user ID and test case data, if the requests are the requests of modifying, deleting and acquiring the test cases, the transmitted request data can also include the ID of the test cases, and after receiving the request data, a server can judge whether the test cases are in a locked state, and whether the test case ID has a case lock list is the basis.

Step S302, if the test case ID exists in the case lock list, it indicates that the test case is in a locked state.

Step S303, if the test case is in a locked state, a prompt message is returned to the terminal device to indicate that the test case is in the locked state, the editing is prohibited, and the occupied user ID, wherein the messages are from the case lock, other terminal devices are prohibited from opening the test case editing window, and if the test case editing window is in an opened state on the terminal device at present, the test case editing window is also forcibly exited.

Step S304, if the test case is in an unlocked state, the test case is divided into two situations, one is that the user holds the case lock, and the other is that the user does not hold the case lock.

Step S305, if the user does not hold the case lock, the user ID and the test case ID of the editing request are delivered to the case lock manager to create a case lock and added into the case lock list, and if the user holds the case lock, the effective time of the case lock can be reset, which indicates that the case lock is always held by the user.

Step S306, updating the case lock data, synchronizing the case lock data to the case lock list, and providing judgment before the terminal requests to edit the test case.

Step S307, if the test case is in an unlocked state, if the test case data is modified, the case data corresponding to the test case ID in the case library is covered, if the test case is newly added, the data is newly inserted into the case library, and if the test case is deleted, the case data corresponding to the case ID is deleted.

Step S308, if the terminal equipment requests to acquire the test case, the case library firstly returns the case data of the corresponding test case ID to the server.

Step S309, returning the case data of the test case ID to the terminal device corresponding to the request, so as to provide the user with editing on the terminal device.

Step S310, the use case lock manager can check the effective time of all use case locks every second, can destroy expired use case locks, and clear a use case lock list, so that the overtime automatic unlocking function is realized.

The test management scheme of this embodiment is further described below.

FIG. 4 is a schematic diagram of a test management according to an embodiment of the present invention. As shown in fig. 4, the test management of this embodiment includes a test execution and report generation policy, and may include the following steps:

step S401, through the terminal device, one or more test cases may be selected, and a test execution request is actively sent to the server.

Step S402, after the use case execution controller receives the execution request through the server, a virtual execution environment can be created, the test framework for generating the pytest module is led into the virtual execution environment to execute the test, if a plurality of execution requests exist at the same time, a plurality of virtual execution environments can be created, and the virtual execution environments are isolated independently and can execute the test at the same time.

Step S403-step S404, after the use case execution controller receives the execution request, the use case execution controller may find the test case data corresponding to the test case ID from the use case library, import the test case data into the virtual execution environment, and perform merge loading with the test framework.

Step S405, after the virtual execution environment is prepared, executing the test, and if the test case is a plurality of test cases, executing the test case according to the sequence selected by the user and generating a test result.

Step S406 — step S406, the test result may be received by the pytest module and a test report is generated, where each test report may be composed of user information, execution time, execution type (timing/active), and test conclusion, and the test report is sent to the report library for storage, so as to provide the terminal device with a request to view.

Step S407-step S410, the terminal device may request the server to view the report according to the specified screening condition, and the server may take the test report from the report library according to the screening condition and return the test report to the terminal device.

Step S411-step S412, the terminal device checks the timing execution configuration information of the test case according to the ID request of the test case, and after receiving the ID request, the server can search the timing configuration information corresponding to the ID of the test case through the timing task manager and return the timing configuration information to the terminal device.

Step S413, the terminal device requests to set or delete the timing configuration of the test case, if the request is set, the ID of the test case and the timing configuration data may be sent to the server, the timing task manager searches the configuration of the ID of the corresponding case, performs the overlay data, if the configuration of the ID of the corresponding case is not found, the overlay data is added, if the request is deleted, only the ID of the test case is sent to the server, and the timing task manager searches the configuration of the ID of the corresponding test case and deletes the configuration.

Step S414, the timing task manager scans all timing configurations every second, and if there is a timing configuration meeting the execution condition, the timing task manager may notify the test case execution controller to execute the test flow.

The behavior tree execution flow logic scheme of this embodiment is further described below.

FIG. 5 is a schematic diagram of a behavior tree execution flow logic scheme according to an embodiment of the present invention. As shown in fig. 5, taking a behavior tree of a test deletion instance as an example, wherein the behavior tree includes an example of a subtree hook, and also includes functional examples of a sequence node, a selection node, a global definition node, and a global storage, and the method may include the following steps:

step S501, the root node of the behavior tree is generally a sequential node, the sequential node executes its child nodes sequentially from top to bottom, the child nodes of the sequential node can be a global definition node, a selection node, a deletion instance subtree, and an inquiry instance subtree, when the execution result of any child node is false, the false result can be returned from step S513 to the parent node, the subsequent child nodes are not executed, the test execution is completed, and the result is false; if all child nodes do not return false, true is returned to the parent node, the test is completed, and the result is true.

In step S502, the global variable definition node may be configured to define a global variable required by the current test, and store the defined variable in a global storage, where the global storage is used to transfer the number of nodes generated by the node, and the currently defined variable may include an instance query API, an instance creation API, an instance deletion API, and an instance name, and provides parameters for use of subsequent nodes, and an execution result of the node is true.

In step S503, after the global definition node returns true to the parent node, the sequence node may sequentially execute the next child node.

Step S504, the selected node is also a child node executing it from top to bottom in sequence, the child node of the selected node has an instance query sub-tree and an instance creation sub-tree respectively, when the execution result of any child node is true, the execution result is returned from step S512 to the parent node, the subsequent child node is not executed any more, the execution of the selected node is completed, and the result is true; if all child nodes do not return true, false is returned to the parent node, the execution of the selected node is completed, and the result is false.

Step S505, the query instance API and the instance name are obtained from the global storage, and a query request is made.

In step S506, if the execution result of the query instance subtree is true, the instance ID is saved in the global storage for use by subsequent deletion instances.

Step S507, if the found instance can be found, the execution result is true, the true is returned from step S512, the subsequent child nodes are not executed any more, the execution of the selected node is completed, and the execution result is true; if the instance cannot be found, the result is false, the next child node is continuously executed, and the instance subtree is executed and created.

Step S508, the creation of instance subtree is hooked, the subtree is composed of multiple behavior nodes, including sequence node, API request node, judge node, polling node, etc., the behavior logic is to send the API request of creation instance with the appointed instance name, poll the state of instance, and wait for the state of instance to be the creation completed state.

Step S509, the created instance API and the instance name are obtained from the global storage.

Step S510, if the result of creating the instance subtree is true, the instance ID is saved in the global storage for use by subsequent instances to be deleted.

In step S511, if the instance is created, the execution result may be true, and true is returned from step S512, and if the instance is not created, the execution result is false, and false is returned from step S512.

Step S512, if the returned result received by the selection node is true, the subsequent child nodes are not executed any more, the execution of the selection node is completed, and the execution result is true; if the received returned is false, the next child node of the node continues to execute, and if all child nodes do not return true, the execution of the selected node is completed, and the execution result is false.

Step S513, after the execution of the selected node is completed, returning an execution result from step S513 to the parent node, where the parent node may be a sequential node, and if the received return result is true, executing its next child node; if the received return result is false, the execution is terminated, the behavior tree test is completed, and the final result is false.

Step S514, if the result returned from S513 is true, continue to execute the next child node to delete the instance subtree, where the subtree may be composed of multiple behavior nodes, including sequence node, API request node, judgment node, polling node, etc., and its behavior logic is similar to that of creating an instance, and it sends a request to delete an instance with a specified instance ID, polls the state of an instance, and waits until the deletion of the instance state is completed.

Step S515, obtain the delete instance API and the instance ID from the global storage.

In step S516, if the deletion fails, the execution result is false, and returns false to the parent node in step S513, and if the deletion succeeds, the execution result is true.

Step S517, if the result returned in step S513 is true, continue to execute the next child node to query the instance subtree, the query instance subtree may be reused, and is the same subtree as the subtree in step S504, but the parameters of the judgment node inside the subtree are different, and the judgment is opposite, if the instance is not found, the execution result is true, and after the instance is verified and deleted, the instance should not be queried.

Step S518, a query instance API and an instance name are obtained from the global storage, and a query request is made.

Step S519, returning the execution result of the query instance subtree from step S512, and completing the execution of the behavior tree; if false is returned, the execution result of the behavior tree may be false, and if true is returned, the execution result of the behavior tree may be true.

The subtree structure of this embodiment is further described below.

FIG. 6 is a diagram of a seed tree structure according to an embodiment of the present invention. As shown in fig. 6, taking an example of creating an instance subtree, which also includes a function example of a polling node, the method may include the following steps:

step S601, the subtree is a subtree for creating an instance, and is a logical behavior node combination for creating an instance, and a root node of the subtree can be hung under a certain node of the behavior tree for multiplexing and can be used as a partial branch logic of the behavior tree.

Step S602, the sequence node executes its child nodes from top to bottom in sequence, the child nodes of the sequence node respectively have instance creation request and polling node, when the execution result of any child node is false, the result is returned from step S617 to the parent node, the subsequent child nodes are not executed any more, the test execution is completed, and the result is false; if all child nodes do not return false, true is returned to the parent node, the test is completed, and the result is true.

Step S603, the instance creation request is an API request node, and may be composed of an API address, a request method, a request parameter, a state code, and a result variable, where the API address may be defined in the global definition node by a tester, the API address parameter may be a variable name, when it is executed, a value of the corresponding variable may be obtained from the global storage, the parameter of the request method may be selected to fill in post, get, delete, and put, the state code may return an expected value for the request, the state code of the get method may be generally 200, the state code of the post method may be generally 201, if the returned state code is inconsistent with the expectation, the execution result of the node is false, the result variable parameter is filled in the variable name, and the result of the request is stored in the global storage with the variable name, thereby implementing data transfer between nodes.

Step S604, if the instance creation request is successful, the request result is stored in the global storage, where the task ID included in the request result provides the use of the subsequent node query creation state. It should be noted that there are some web site backend, which is composed of multiple components, and the creation instance depends on different components for creation, so that there is an asynchronous call situation across components, and after receiving the creation request, the backend will create an asynchronous task, which may include task ID and status, and it will apply for creating an instance to another component, and continuously monitor the component creation status information and synchronize.

Step S605, if the instance creation request fails, the execution result is false, and false is returned from step S617 to the parent node; the execution of the subtree is completed with a false end.

In step S606, if the instance creation request is successful, the execution result is true, and true is returned from step S617 to the parent node, and the next child node is executed continuously.

In step S607, if the child node of the polling node returns false from step S613, it will re-execute its child node until its child node returns true from step S613 or the set timeout time is exceeded, and then the execution is completed, and the execution result is true, and the result is returned to the parent node, and the node also has a timeout parameter set.

In step S608, the query creation state is an API request node, and requests to query the current creation task state.

Step S609, the query task API and the task ID of the current created instance are obtained from the global storage.

Step S610, if the query task API request is successful, storing the query result in the global storage to provide the following check node for use.

Step S611, if the query task API request is incorrect, the execution result is false, and false is returned from step S612 to the parent node; if the query task request is successful, the execution result is true, and true may be returned to the parent node from step S612.

Step S612, if the sequence node receives a true result, continuing to execute the next child node, if the sequence node receives a false result, terminating executing the child node, where the execution result of the sequence node is false, and returning the false result from step S613 to the polling node; when the polling node receives no more than a future and does not time out, it will re-execute its child node, thereby achieving the effect of a polling state.

In step S614, the checking creation status is a check node, which may be used to check the result of the last API query node to determine whether the result is expected in advance, and includes three settable parameters, including a left value, a comparator, and a right value, where the left value and the right value may be a variable name, and the parameter may be set to "creation completed" and equal to the variable name of the task status.

Step S615, the result of the last node inquiring the task state is obtained from the global storage.

Step 616, if the task state is creation completed, the execution result is true, and the steps are returned from step 612 to step 613 in sequence, and the polling node exits polling and returns a result to its parent node if the execution result of the polling node is true; if the task state is not created completely, the execution result is false, the steps from step S612 to step S613 are returned in sequence, and if the timeout time is not reached, the polling node re-executes the child node to perform the query state, thereby achieving the effect of polling the creation state within the specified time, waiting for the creation to be completed, or polling until the timeout.

Step S617, if the sequence node receives the true result, continuing to execute the next child node, and if all child nodes are executed, finally completing the execution of the subtree and obtaining a true result; if a false result is received, the execution child node is terminated, and finally the execution of the sub-tree is completed, and the execution result is false.

If the execution result returned from step S617 is a true result, the next child node continues to be executed; if all the child nodes do not return false, true is returned to the parent node, the test execution is completed, the result is true, the execution of the subtree is completed, and if any child node returns false, the execution result of the subtree is false, and the execution of the subtree is completed.

According to the embodiment, the method provides an interface automatic test scheme combining a pytest test framework and a behavior tree, and the test case is compiled through the behavior tree, wherein the behavior tree can be loaded and executed by a pytest module, and the test result of the test case for testing the target interface is finally collected and output by the pytest module. Because the case production standard can be unified through the behavior tree compiling case, the handover cost is reduced, the pytest module collects the case execution result corresponding to each behavior tree and outputs the report, the original report function is kept, the technical problem of low data testing efficiency is solved, and the technical effect of improving the data testing efficiency is achieved.

The embodiment of the invention also provides an interface testing device. It should be noted that the interface testing apparatus of this embodiment can be used to execute the interface testing method shown in fig. 2 according to the embodiment of the present invention.

Fig. 7 is a schematic diagram of an interface testing apparatus according to an embodiment of the invention. As shown in fig. 7, the interface test apparatus 70 may include: a loading unit 71, a processing unit 72, a testing unit 73 and a generating unit 74.

And the loading unit 71 is used for loading the behavior tree corresponding to the target interface to be tested.

And the processing unit 72 is used for generating a test case based on the behavior tree.

And the test unit 73 is configured to test the target interface by using the test case to obtain a test result.

And a generating unit 74, configured to generate a test report of the target interface based on the test result.

In the interface testing device of the embodiment, the test cases are generated through the behavior tree, so that the manufacturing standards of the test cases can be unified, the test handover cost is reduced, the test results are collected and output in the test framework, the original report function of the test framework is kept, the technical problem of low efficiency of testing the interface is solved, and the technical effect of improving the efficiency of testing the interface is achieved.

The embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, where the computer program, when executed by a processor, controls an apparatus where the computer-readable storage medium is located to execute the interface testing method according to the embodiment of the present invention.

Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing computer programs, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

The embodiment of the invention also provides an electronic device. The electronic device comprises a memory in which a computer program is stored and a processor arranged to run the computer program to perform the interface testing method of an embodiment of the invention.

Optionally, the electronic apparatus may further include a transmission device and an input/output device, wherein the transmission device is connected to the processor, and the input/output device is connected to the processor.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of 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.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the principle of the present invention should be included in the protection scope of the present invention.

Claims (18)

1. An interface test method, applied to a pytest test framework, includes:

loading a behavior tree corresponding to a target interface to be tested;

generating a test case based on the behavior tree;

testing the target interface by using the test case to obtain a test result;

and generating a test report of the target interface based on the test result.

2. The method of claim 1, wherein the behavior tree is tree-structured data composed of a plurality of test behavior nodes, each test behavior node is a result of encapsulating one test behavior of the target interface, and generating a test case based on the behavior tree comprises:

and configuring the plurality of test behavior nodes to obtain the test case.

3. The method of claim 2, wherein configuring the plurality of test behavior nodes to obtain the test case comprises:

configuring the plurality of testing behavior nodes to obtain a subtree of the behavior tree, wherein the subtree is a testing template which is allowed to be reused when the target interface is tested;

and generating the subtree into the test case.

4. The method of claim 3, wherein the test behavior node comprises at least one of:

a polling node for executing cyclically the sub-trees associated with the polling node;

the interface request node is used for requesting the data of the target interface;

the judging node is used for judging the data of the target interface;

and the global definition node is used for defining the global variable of the target interface.

5. The method of claim 4, wherein if a child node of the polling node returns a logically true result, then prohibiting execution of a sub-tree associated with the polling node and returning the logically true result to a parent node of the polling node.

6. The method of claim 4, wherein if the child node of the polling node does not return a logically true result within a target time period, then returning a logically false result to the parent node of the polling node.

7. The method of claim 4, wherein the parameters of the interface requesting node include at least one of: the target interface, the request mode, the request parameter, the state code and the variable name, wherein the state code is a state expected value returned by the interface request node, and the data requested by the interface request node is stored by the variable name.

8. The method of claim 4, wherein the parameters of the decision node comprise at least one of: left data, conditional comparator, and right data.

9. The method of claim 4, wherein the parameters of the globally defined nodes comprise at least one of: variable name and value.

10. The method of claim 1, wherein testing the target interface with the test case to obtain a test result comprises:

and loading and executing the target interface in the test case to obtain a logical true result or a logical false result of the target interface.

11. The method of claim 1, wherein testing the target interface with the test case to obtain a test result comprises:

sending a test request to a server based on the test case;

and obtaining the test result obtained by the server responding to the test request and testing the target interface.

12. The method of claim 1, wherein generating a test report for the target interface based on the test results comprises:

generating a test report for the target interface based on at least one of the following test results: testing time, the name of the test case and a testing conclusion.

13. The method according to any one of claims 1 to 12, wherein in a case where the test case is edited by a target terminal device among a plurality of terminal devices, the test case prohibits editing by a terminal device other than the target terminal device among the plurality of terminal devices.

14. The method according to claim 13, wherein the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal in a case where the target terminal device sends an unlocking request to a server, or after a target duration that the target terminal device is in a closed state, or after a target duration that the target terminal device does not continuously edit the test case, wherein the unlocking request is used for requesting the server that the test case allows editing by any terminal device of the plurality of terminal devices except the target terminal.

15. The method of claim 13, wherein the terminal device is further configured to perform at least one of the following operations on the test case: sharing operation, storing operation, executing operation and displaying the test report.

16. An interface test apparatus, applied to a pytest test framework, comprising:

the loading unit is used for loading a behavior tree corresponding to a target interface to be tested;

the processing unit is used for generating a test case based on the behavior tree;

the test unit is used for testing the target interface by using the test case to obtain a test result;

and the generating unit is used for generating a test report of the target interface based on the test result.

17. A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, controls an apparatus in which the computer-readable storage medium is located to carry out the method of any one of claims 1 to 15.

18. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and wherein the processor is configured to be executed by the processor to execute the computer program to perform the method of any of claims 1 to 15.

Images