CN111949508A

CN111949508A - Method, device, equipment and computer readable medium for testing interface

Info

Publication number: CN111949508A
Application number: CN201910413923.2A
Authority: CN
Inventors: 李阿东
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2019-05-17
Filing date: 2019-05-17
Publication date: 2020-11-17

Abstract

The invention discloses a method, a device, equipment and a computer readable medium for testing an interface, and relates to the technical field of computers. One embodiment of the method comprises: predefining deployment environment parameters, tested interface identifiers, request modes and expected response results of a service data interface description file; replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form a current test function of the tested interface; calling parameters of the current test function based on the request mode, and calling the tested interface according to a request address; and judging whether the response result of the test interface is correct or not according to the expected response result. In the embodiment, the same original test function can be used for testing similar interfaces in a plurality of deployment environments, test data do not need to be prepared again for the replaced deployment environments, and test efficiency is improved.

Description

Method, device, equipment and computer readable medium for testing interface

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer readable medium for testing an interface.

Background

The complex software system is a software system formed by a plurality of subsystems, and complex calling relations exist among the subsystems. With the rapid iteration of software and the expansion of operation scale, interface testing is increasingly difficult to test.

In order to ensure the quality of a complex software system, it is necessary to develop an integration test of an interface and an automated regression test of the interface. Typically, the interface test described above is performed from the perspective of the user, extrapolating the functional implementation of the subsystem to verify that the subsystem can properly process the request from the interface.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:

when testing the interface, the input test data depends on the specific deployment environment. After the deployment environment is replaced, because the dependency of the test data on the deployment environment is strong, the test data needs to be prepared again for the replaced deployment environment.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method, an apparatus, a device, and a computer readable medium for testing an interface, where for different deployment environments, a service data interface description file and an original test function form a current test function suitable for the different deployment environments, and it is not necessary to prepare test data again for a changed deployment environment, so as to improve test efficiency.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method of testing an interface, including:

predefining deployment environment parameters, tested interface identifiers, request modes and expected response results of service data interface description files, wherein the deployment environment parameters indicate uniform resource locators of the deployment environment, and the corresponding relation between the deployment environment and the uniform resource locators is defined through a deployment environment mapping table;

replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form a current test function of the tested interface;

calling in parameters of the current test function based on the request mode, and calling the tested interface according to a request address, wherein the request address is obtained by splicing a uniform resource locator and the tested interface identifier according to the deployment environment parameter;

and judging whether the response result of the test interface is correct or not according to the expected response result.

The method further comprises the following steps:

predefining a virtual user identifier of a service data interface description file, wherein the virtual user identifier indicates an actual user identifier accessed to the deployment environment, and a corresponding relation between the virtual user identifier and the actual user identifier accessed to the deployment environment is defined through a user mapping table;

the current test function forming the tested interface also comprises

Replacing user parameters in the original test function corresponding to the tested interface identification according to the virtual user identification of the service data interface description file to form a current test function of the tested interface;

before the parameter of the current test function is called based on the request mode and the tested interface is called according to the request address, the method comprises the following steps:

and mounting the login credentials of the actual user according to a credential mapping table, wherein the credential mapping table comprises a corresponding relation between a deployment environment and an actual user identifier.

The original test function comprises default parameters for testing the interface.

After the determining whether the response result of the test interface is correct according to the expected response result, the method further includes:

and if the response result of the test interface is judged to be correct, caching the data extracted from the response result and/or the data generated in the process of calling the test interface.

Further comprising:

and caching the data extracted from the response result and/or the data generated in the process of testing the interface according to the deployment environment.

According to a second aspect of the embodiments of the present invention, there is provided an apparatus for testing an interface, including:

the system comprises a definition module, a test module and a response module, wherein the definition module is used for predefining deployment environment parameters, tested interface identifiers, request modes and expected response results of service data interface description files, the deployment environment parameters indicate uniform resource locators of a deployment environment, and the corresponding relation between the deployment environment and the uniform resource locators is defined through a deployment environment mapping table;

the replacing module is used for replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form a current test function of the tested interface;

a calling module, configured to call a parameter of the current test function based on the request mode, and call the tested interface according to a request address, where the request address is obtained by splicing a uniform resource locator indicated by the deployment environment parameter and the identifier of the tested interface;

and the judging module is used for judging whether the response result of the test interface is correct or not according to the expected response result.

The definition module is further configured to predefine a virtual user identifier of a service data interface description file, where the virtual user identifier indicates an actual user identifier accessed to the deployment environment, and a user mapping table defines a correspondence between the virtual user identifier and the actual user identifier accessed to the deployment environment;

the replacing module is specifically used for replacing user parameters in the original test function corresponding to the tested interface identifier according to the virtual user identifier of the service data interface description file to form a current test function of the tested interface;

the invoking module is specifically configured to mount the login credential of the actual user according to a credential mapping table, where the credential mapping table includes a correspondence between a deployment environment and the actual user.

The device further comprises:

and the cache module is used for caching the data extracted from the response result and/or the data generated in the process of calling the test interface if the response result of the test interface is judged to be correct.

The cache module is specifically configured to cache the data extracted from the response result and/or the data generated in the process of the test interface according to a deployment environment.

According to a third aspect of the embodiments of the present invention, there is provided an electronic device for testing an interface, including:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method as described above.

According to a fourth aspect of embodiments of the present invention, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the method as described above.

One embodiment of the above invention has the following advantages or benefits: because the deployment environment parameters, the tested interface identification, the request mode and the expected response result of the service data interface description file are predefined. Then, replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form the current test function of the tested interface. And calling parameters of the current test function based on the request mode, and calling the tested interface according to the request address. And finally, judging whether the response result of the test interface is correct or not according to the expected response result. Therefore, similar interfaces in a plurality of deployment environments can be tested by using the same original test function for testing the interfaces, only corresponding parameters related to the deployment environments need to be replaced, and then test data do not need to be prepared again for the replaced deployment environments, so that the test efficiency is improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic diagram of the main flow of a test interface according to an embodiment of the invention;

FIG. 2 is a schematic diagram of a main flow of a method of testing an interface according to an embodiment of the invention;

FIG. 3 is a schematic diagram of a business data interface file according to an embodiment of the invention;

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

FIG. 5a is a schematic diagram of a deployment environment mapping table according to an embodiment of the invention;

FIG. 5b is a diagram of a user mapping table according to an embodiment of the present invention;

FIG. 5c is a diagram of a credential mapping table according to an embodiment of the present invention;

FIG. 6 is a schematic illustration of a business data interface file joining a shopping cart in accordance with an embodiment of the present invention;

FIG. 7 is a schematic illustration of a test function for joining a shopping cart according to an embodiment of the present invention;

FIG. 8 is a schematic flow chart of a main process for testing an interface using a test function according to an embodiment of the present invention;

FIG. 9 is a flow diagram illustrating test case execution according to an embodiment of the invention;

FIG. 10 is a flow diagram illustrating another test case execution flow according to an embodiment of the invention;

FIG. 11 is a flow diagram illustrating the execution of four test cases according to an embodiment of the present invention;

FIG. 12 is a schematic diagram of the main structure of the device of the test interface according to the embodiment of the present invention;

FIG. 13 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 14 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Currently, in the process of testing an interface, an automation tool can be used to record a test script, and the test script is adjusted by continuously playing back the test script. When the software is iterated rapidly, the test script is recorded again to adapt to the new business process. The script is an extension of a batch file, is a pure text saving program, and is a definite series of combinations for controlling the computer to perform operation actions, wherein certain logic branches can be realized.

And then, separating the data file from the test script, reading the data file before the test case runs, and injecting the test data into the test case in a parameterized mode. Referring to fig. 1, fig. 1 is a schematic diagram of a main flow of a test interface according to an embodiment of the present invention, which specifically includes:

s101, reading the test configuration file and executing the test in batch.

And S102, reading the forward use case data, the reverse use case data and the state codes thereof. The state code is a parameter for identifying the test result of the tested interface.

S103, injecting test data and calling a tested interface.

And S104, analyzing and asserting a response result.

Generally, a set of software system has several deployment environments, such as a test system, a pre-release environment, a production environment, and the like, although test data is separated from a test script, the test data used in the test process is strongly associated with the deployment environment, a set of proprietary test data needs to be prepared for each deployment environment, and the software iteration and the influence on the test data in the test process increase the difficulty in maintaining the test data.

Particularly, the mode of recording and playing back the test script has strong correlation among parameters, poor plasticity and strong dependence on deployment environment, so that the test script has poor reusability and cannot keep up with the steps of rapid software iteration.

Secondly, the test data of each deployment environment are independent, and when the deployment environment of the software needs to be switched, the test data needs to be adjusted to adapt to the new deployment environment, so that the workload of maintaining the automatic test system is increased.

In order to solve the technical problem that test data needs to be prepared again when the deployment environment is updated, the following technical solution in the embodiment of the present invention may be adopted.

Referring to fig. 2, fig. 2 is a schematic diagram of a main flow of a method for testing an interface according to an embodiment of the present invention, in which deployment environment parameters in an original test function corresponding to an identifier of a tested interface are replaced according to deployment environment parameters of a service data interface description file to form a current test function of the tested interface. As shown in fig. 2, the method specifically includes the following steps:

s201, predefining deployment environment parameters, tested interface identifiers, request modes and expected response results of the service data interface description files, wherein the deployment environment parameters indicate uniform resource locators of deployment environments, and the corresponding relation between the deployment environments and the uniform resource locators is defined through a deployment environment mapping table.

Generally, a test case test interface may be utilized. And one test case represents one service scene, and the test case tests the service flow contained in the service scene through calling one group of interfaces.

The service data interface description file includes data for a calling interface associated with the service. And storing the data in the service data interface description file in a preset data structure.

In the embodiment of the present invention, deployment environment parameters, an interface identifier to be tested, a request mode, and an expected response result of a service data interface description file need to be predefined.

Referring to fig. 3, fig. 3 is a schematic diagram of a service data interface file according to an embodiment of the present invention. Fig. 3 includes names of two interface calls, namely service1 and service2, and data structures in service1 and service2 are the same. The following describes a data structure of the service1, taking the service1 as an example.

"user" represents a virtual user name, i.e., a virtual user identification.

"system" represents the subsystem to which the interface belongs, i.e., the deployment environment parameters.

"interface" represents the interface name, i.e. the identity of the interface under test.

"method" indicates a request mode. In the case of an http request, it is necessary to indicate which of the following specific request modes: get/post/put/delete/head.

"parameter" indicates a parameter template used by the interface request. The parameter template includes one or more parameters. Such as: the parameter template parameter1 includes a parameter: value 1.

"expected" represents a result response template, including the response result.

The 'referrer' represents the reference address of the interface on the webpage, namely the page where the interface is called and recommended, and the position where the interface is called on the page by a tester is convenient.

"remap" indicates the functional description of the interface.

In an embodiment of the present invention, other one or more parameters of the service data interface description file may also be predefined, such as: "user" is the virtual user identification, "parameter," referrer, "and" remark.

The parameters in the service data interface are predefined and are aimed at constituting the current test function of the tested interface.

S202, replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form the current test function of the tested interface.

In the embodiment of the invention, each group of interfaces to be tested has the corresponding original test function which can be multiplexed. The original test function is a collection of test interface commands. Default parameters for testing the interface are also included in the original test function. As an example, the default parameters may include deployment environment parameters and/or virtual user identification, etc. And under the condition that the default parameters exist in the original test function, forming the current test function based on the default parameters in the original test function and the service data interface description file. And when the default parameters and the parameters in the service data interface description file exist, the default parameters are preferentially used.

And on the basis of the original test function corresponding to the tested interface identifier, replacing the deployment environment parameters in the original test function corresponding to the tested interface identifier according to the deployment environment parameters of the service data interface description file to form the current test function of the tested interface.

In order to enable the test function to be applied to the updated deployment environment, the current test function of the tested interface needs to be constructed on the basis of the original test function. The current test function comprises the deployment environment parameters of the service data interface description file, so that the method can be suitable for the updated deployment environment, and further, the test data do not need to be prepared again for the replaced deployment environment.

In one embodiment of the invention, the original test function may be an operation function (operation _ service). Referring to fig. 4, fig. 4 is a schematic diagram of an operating function according to an embodiment of the present invention. Operator _ service includes the name of the interface call: service, user identification: user, and parameter template name: parameter1 and parameter 2. Wherein the deployment environment parameter system can be encapsulated into an underlying common part to be invoked. That is, by constructing the current test function using the operation _ service, the service, user, parameter1 and parameter2 in the operation _ service can be used.

S203, calling parameters of the current test function based on the request mode, and calling the tested interface according to a request address, wherein the request address is an address obtained by splicing the uniform resource locator indicated by the deployment environment parameters and the identifier of the tested interface.

The interface is tested using the current test function. Specifically, the parameters of the current test function are called in a request mode based on the service data interface description file, and the tested interface is called according to the request address. It should be noted that, since the parameters of the current test function include the parameters of the current deployment environment, the current test function is suitable for the current deployment environment.

The deployment environment is a specific environment for software to run, such as: test systems, pre-release environments, and production environments, among others. One or more subsystems are included in the deployment environment. In the embodiment of the present invention, the deployment environment mapping table may be preset. Defining the deployment environment mapping table includes mapping relationship between deployment environment and Uniform Resource Locator (URL). In conjunction with the deployment environment, the uniform resource locator of the deployment environment may be learned based on the deployment environment mapping table.

Referring to fig. 5a, fig. 5a is a schematic diagram of a mapping table of a deployment environment, specifically, a subsystem of the deployment environment, according to an embodiment of the present invention. For example, the URL corresponding to subsystem 1 of deployment environment 1 is URL _ 1; the URL corresponding to subsystem 2 of deployment environment 1 is URL _ 2.

Before testing the interface, the deployment environment mapping table needs to be loaded into the cache. In the process of testing results, the URL of the deployment environment and interface name (interface) parameters in the service data interface description file are spliced into a complete request address, so that the tested interface can be called according to the request address.

In one embodiment of the invention, the test data is user dependent in view of the data flow and state transitions between multiple roles in the software system. The test data is associated with the user.

The user mapping table may be preset according to the deployment environment. Defining a corresponding relation between a virtual user identifier and an actual user identifier accessed to the deployment environment in a user mapping table. Referring to fig. 5b, fig. 5b is a schematic diagram of a user mapping table according to an embodiment of the present invention, where the deployment environment is specifically a subsystem of the deployment environment. For example, for a plurality of deployment environments, the virtual user 1 corresponds to the actual user 1 in the subsystem 1; the virtual user 2 corresponds to the actual user 2 in the subsystem 1; the virtual user 3 corresponds to the actual user a in the subsystem 2.

Specifically, a user mapping table is defined in a directory or namespace of each deployment environment. Each deployment environment shares a set of virtual users and loads the user mapping table into a cache before the test runs. That is, the virtual users are the same for different deployment environments. Illustratively, the virtual user 1 may be tested in either the deployment environment 1 or the deployment environment 2. The virtual user replaces an actual user to associate a test function and a deployment environment, and the effect of decoupling test data from the actual user is achieved.

In one embodiment of the present invention, in the process of actually applying the user mapping table test interface, users are involved, such as: the user identification is logged in to add the item to the shopping cart. The virtual user identification of the service data interface description file is predefined. Then, the virtual user identifier of the service data interface description file needs to replace the user parameter in the original test function corresponding to the tested interface identifier according to the user mapping table.

And replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file, and finally forming the current test function of the tested interface. The current test function is not only related to the deployment environment, but also to the actual user.

And replacing the virtual user identifier in the service data interface description file with the user parameter in the original test function corresponding to the tested interface identifier, thereby indicating that the test interface needs to be logged in by an actual user. Illustratively, a user identification is logged in to add merchandise to a shopping cart, and logging in requires the user's login credentials. The login credentials represent actual users in the subsystems of the deployment environment. As one example, the login credentials are cookies. Cookies refer to data stored on a user's local terminal by some websites for the purpose of identifying the user's identity and session control tracking.

In one embodiment of the present invention, the login credentials of the actual user identification may be mounted through a credential mapping table. Referring to fig. 5c, fig. 5c is a diagram illustrating a credential mapping table according to an embodiment of the present invention. The credential mapping table is a corresponding relationship generated according to login credentials of all actual users in the deployment environment. The credential mapping table includes a correspondence of an actual user identification and a login credential. In fig. 5c, in deployment environment 3, actual user 1 in subsystem 1 corresponds to credential 1; actual user 2 in subsystem 1 corresponds to credential 2; actual user a in subsystem 2 corresponds to credential a.

After generating the credential mapping table, the credential mapping table may be cached. Then, under the condition of mounting the login credential of the actual user, the credential mapping table does not need to be generated again, and only the cached credential mapping table needs to be directly obtained.

The specific process of constructing the current test function is described below with reference to fig. 6 and 7, taking the example of adding merchandise to the shopping cart, the virtual user identification being buyer1, and the deployment environment being buyer 1.

Referring to FIG. 6, FIG. 6 is a schematic diagram of a business data interface file for joining a shopping cart according to an embodiment of the present invention.

The name of an interface call, addcall, is included in fig. 6.

"user" is "layer".

The "system" is "layer".

"interface" is "/car/male/car/addCart".

"method" is "post".

"expected" is "code": "0", "msg": "successful addition", "date": true. When the response feedback is 0, the mark is added successfully, and true is fed back.

"Remark" is "Add selected sku to shopping cart".

"refrrer" is "http: // xxx. xxx.xxx.com/item/123456 "

The "parameter" includes four parameters: platformID equals 2; itemID is null; skuID and salenum, wherein the skuID is: 654321, skuSaleNum is: 2; the area ID is 11.

Referring to FIG. 7, FIG. 7 is a schematic diagram of a test function for joining a shopping cart in accordance with an embodiment of the present invention. FIG. 7 shows the test function for the shopping cart, with 4 parameters to be kept: a user; itemID; areaID and skuIDAndSaleNum. It should be noted that, in the program implementation process, the deployment environment parameters are packaged into the common part of the bottom layer and are called.

The deployment environment parameters in the service data interface file of the shopping cart in fig. 6 replace the deployment environment parameters in the test function of the shopping cart in fig. 7, and a test function user of the shopping cart is adopted; itemID; areAID and skuIDAndSaleNum to form the current test function for adding to the shopping cart. Namely, on the basis of the four parameters in the test function added to the shopping cart, the current test function is obtained by combining the deployment environment parameter and other parameters added to the service data interface file.

Referring to fig. 8, fig. 8 is a schematic diagram of a main flow of testing an interface by using an operation function according to an embodiment of the present invention, and a specific flow of testing the interface by using the operation function is described below with reference to fig. 8.

The test functions in fig. 8 are: operator _ service (user, parameter1, parameter2), namely: and simultaneously replacing the deployment environment parameters in the operation _ service by the deployment environment parameters in the service data interface description file by using a user, a parameter1 and a parameter 2. Wherein the deployment environment parameters can be encapsulated into the underlying common part to be invoked.

And S801, reading the service data interface description file.

Testing a set of interfaces corresponds to a test function. The test case is called to a group of interfaces, and the group of interfaces at least comprises one interface. First, a service data interface description file is read.

S802, loading the object.

service1 is defined by a service data interface description file. Through the name of the service1, the definition of the service1 is obtained in the service data interface description file, and the definition of the service1 is loaded as an object. Illustratively, referring to FIG. 4, the definition of service1 is included in the business data interface description file.

And S803, acquiring the actual user identification.

The user in the operation _ service is the virtual user identifier, the user mapping table is loaded, and the actual user identifier corresponding to the user can be obtained based on the user mapping table.

And S804, replacing the virtual user identification with the actual user identification.

The virtual user id in the operation _ service is replaced with the actual user id known in S803.

S805, obtaining the credential from the credential mapping table.

And acquiring the credential from the credential mapping table according to the current deployment environment and the actual user identifier.

And S806, replacing the parameter in the operation _ service with the parameter in the service 1.

The parameters in the service1 are used to replace the corresponding parameters in the operation _ service, and the following three parameters, user, parameter1 and parameter2, in the operation _ service are reserved. For parameters not reserved in operation _ service, the parameters in service1 are used. So far, on the basis of OperateService, the current test function is formed by combining the three parameters of OperateService, namely the parameters in the user, the parameter1, the parameter2 and the service 1.

And S807, splicing into a complete interface calling address.

And splicing according to the URL of the subsystem of the deployment environment and the interface name of the service data interface description file to obtain the request address. The URL of the subsystem of the deployment environment is obtained by inquiring the deployment environment mapping table according to the subsystem of the deployment environment.

And S808, initiating interface calling.

And initiating an interface call according to the request address.

And S809, processing the response result and returning.

In the above embodiment, the deployment environment parameters of the service data interface description file are replaced, the virtual user is replaced with the actual user identifier, a current test function of the tested interface is formed, and then the interface is tested.

And S204, judging whether the response result of the test interface is correct or not according to the expected response result.

And the expected response result in the service data interface description file can judge whether the response result of the test interface is correct or not. Exemplarily, if the expected response result in the service data interface description file is the same as the response result of the test interface, the response result of the test interface is judged to be correct; and if the expected response result in the service data interface description file is different from the response result of the test interface, judging that the response result of the test interface is wrong.

In the above embodiment, on the basis of the original test function corresponding to the interface, the current test function is formed by combining the deployment environment parameters of the service data interface description file. Even if the deployment environment changes, the current test function is only required to be reconstructed on the basis of the original test function corresponding to the interface. The same interface is tested in a plurality of deployment environments, the same original test function can be used, test data do not need to be prepared again, and test efficiency is improved.

Referring to fig. 9, fig. 9 is a schematic diagram illustrating a test case execution flow according to an embodiment of the present invention. The test case in fig. 9 requires loading the deployment environment mapping table without actual user login.

The test case execution in FIG. 9 includes three parts. The first part includes setting up a deployment environment, including S901 and S902.

The second part includes executing the test case, calling a set of operation _ service, including S903 to S908. Wherein, the group of operation _ service at least comprises one operation _ service.

The third part includes a sub-flow of operation _ service involved in the process of calling operation _ service, including S909 to S916. It should be noted that the operation _ service sub-flow may not be involved in the process of calling a group of operation _ service.

S901, caching deployment environment mapping table.

And after the deployment environment mapping table is loaded, caching the deployment environment mapping table.

S902, setting a deployment environment.

And setting the deployment environment by means of externally transmitted parameters or predefined parameters.

And S903, loading the cached parameters for operation _ service.

If the parameter used by the operation _ service function exists in the cache, the parameter of the cache can be loaded.

And S904, calling an operation _ service function.

S905, judging whether the return result of calling the operation _ service function is correct or not, and if the return result of calling the operation _ service function is wrong, ending the whole process.

And S906, calling the operation _ service function to return a correct result, and caching the parameters in the returned result for other test cases to use.

S907, judging that no operation _ service function needs to be executed.

If no operation _ service function needs to be executed, the whole flow is ended.

And S908, the operation _ service function needs to be executed, and data is extracted from the return result for calling and using a subsequent interface of the test case.

The data extracted from the returned result may be data related to the operation _ service function. As an example, the purpose of the operation _ service function is to add goods to a shopping cart, and the extracted data may be a goods identification. In this way, the operation _ service function related to the subsequent interface of the test case is called, for example: if the operation _ service function is to purchase goods, the goods identifier can be directly loaded.

And S909, reading the service data interface description file.

S910, judging whether cached data exist or not, and if the cached data exist, returning to the S903; if the cached data does not exist, S911 is executed.

S911, replacing the deployment environment parameter of the operation _ service function according to the deployment environment parameter of the service data interface description file, reserving and using the parameter in the operation _ service function, and forming the current test function.

And S912, calling an interface according to the request address.

And S913, initiating interface calling.

S914, judging whether the returned result is correct, and executing S915 if the returned result is correct; and if the returned result is wrong, the test case fails.

And S915, extracting data from the returned result for the next interface calling.

And S916, caching the extracted data, and returning to S903.

In the embodiment of fig. 9, the current test function is constructed in combination with the operation _ service function according to the deployment environment parameter of the service data interface description file. The same interface is tested in a plurality of deployment environments, the same operation _ service function can be used, and test data do not need to be prepared again aiming at the replaced deployment environments.

Referring to fig. 10, fig. 10 is a schematic diagram illustrating another test case execution flow according to an embodiment of the present invention. The test case in fig. 10 needs to load a deployment environment mapping table, a user mapping table, and a credential mapping table.

The test case execution in FIG. 10 includes three parts. The first part includes setting up a deployment environment, including S1001 to S1004.

The second part includes executing the test case, calling a set of operation _ service, including S1005 to S1010. Wherein, the group of operation _ service at least comprises one operation _ service.

The third part includes a sub-flow of operation _ service involved in the process of calling operation _ service, including S1011 to S1020. It should be noted that the operation _ service sub-flow may not be involved in the process of calling a group of operation _ service.

The embodiment of fig. 10 differs from the embodiment of fig. 9 in that: the user mapping table and the credential mapping table need to be loaded.

Among them, the steps of fig. 10 identical to those of fig. 9 will not be described repeatedly, and the following description will refer to the steps of fig. 10 different from those of fig. 9.

S1002, caching a user mapping table.

S1004, generating and caching a credential mapping table.

The credential mapping table is a corresponding relationship generated according to login credentials of all actual users in the deployment environment.

And S1013, converting the virtual user identifier into an actual user identifier according to the user mapping table.

And S1015, mounting the login credentials of the actual user according to the credential mapping table.

In the embodiment of fig. 10, the current test function is formed according to the user mapping table and the deployment environment parameters of the service data interface description file. The same group of interfaces are tested in a plurality of virtual users and a plurality of deployment environments, the same operation _ service function can be used, test data do not need to be prepared again aiming at the replaced deployment environments, and the test efficiency is improved.

Referring to fig. 11, fig. 11 is a schematic diagram illustrating an execution flow of four test cases according to an embodiment of the present invention, and four operation _ services are called in the execution process of the four test cases in fig. 11, which are operation _ service0, operation _ service1, operation _ service2, and operation _ service3, respectively. Each test case calls an operation _ service respectively.

Among them, the parameter of operation _ service2 needs to be divided into extraction data from the buffer, the return result of operation _ service0, and the return result of operation _ service 1. The input to the operation _ service3 depends on the returned result of the operation _ service 2.

S1101, initializing a configuration file by the process.

The process initialization configuration file comprises a virtual user identifier: user, parameter template: function description of parameter and interface: and (5) marking.

S1102, reading the process initialization configuration file, and converting the virtual user identifier into an actual user identifier according to the user mapping table.

S1103, inquiring the cache to obtain the value of the designated parameter.

If the value of the specified parameter exists in the cache data, the value of the specified parameter can be acquired.

S1104、Operate_service0。

For the operation _ service0, the parameters used are derived from cache or preset data, and the tested interface is called based on the parameter operation _ service 0. Data is extracted from the returned result for the next operation _ service call, i.e., for operation _ service2 call.

S1105、Operate_service1。

For the operation _ service1, the parameters used are derived from cache or preset data, and the tested interface is called based on the parameter operation _ service 1. Data is extracted from the returned result for the next operation _ service call, i.e., for operation _ service2 call.

S1106、Operate_service2。

The parameters utilized are derived from the returned results in operation _ service0 and operation _ service 1. The interface under test is called based on the parameter operation _ service2 described above. Data is extracted from the returned result for the next operation _ service call, i.e., for operation _ service3 call.

S1107、Operate_service3。

The parameters utilized are derived from the return results in operation _ service 2. The interface under test is called based on the parameter operation _ service3 described above.

S1108, whether the returned result is correct is judged.

If the return result is correct, executing S1109; and if the return result is wrong, throwing the exception.

S1109, caching data.

The return result of the operation _ service3 call to the test interface is cached.

And S1110, caching data or presetting data.

The returned result of the operation _ service3 is buffered, and the preset data is received.

In the above-described embodiment, the parameter input by the operation _ service2 depends on the return result of the operation _ service0 and the return result of the operation _ service 1. The parameter input by the operation _ service3 depends on the returned result of the operation _ service 2.

In the prior art, the test cases are depended on each other, and when the test cases are run, the test cases depended on by the test cases need to be executed again.

In one embodiment of the invention, the returned result output by the test interface is determined, and the parameter called by another test case can be cached. It should be noted that the parameter called by another test case may be a return result output from the tested interface and/or data generated in the process of calling the tested interface.

As one example, invoking the tested interface involves adding the item to a shopping cart, wherein the item is successfully added to the add identification of the shopping cart as a return result output from the tested interface; the identification of the good may be used as data generated during the invocation of the interface under test. Thus, in the next test case, for example: and (4) commodity checkout, wherein the addition identifier and/or the commodity identifier can be directly obtained from the cache without running a dependent test case again.

In one embodiment of the invention, data extracted from the response results and/or data generated during the process of invoking the test interface are cached so that test cases are not directly interdependent. To avoid overlap between cached data, such as: the deployment environment 1 reads or covers the cache of the deployment environment 2; the subsystem 1 of the overlay system reads or the cache of the subsystem 2 of the overlay system. The cached parameters may be stored separately by the deployment environment and in combination with the subsystems of the deployment environment.

As an example, a cached value is obtained through a cascaded namespace, and a cached parameter is stored in a physical space corresponding to the cached value. Such as: the cache value is the deployment environment name: subsystem name: the name of the object to be cached; or, the cache value is the name of the deployment environment: cache object names independent of subsystems; or, the cache value is the global cache object name.

As another example, a parameter called by another test case is cached using a redis database or a hashmap database. In the database, parameters called by another test case are stored in different namespaces according to the deployment environment. Since the namespace is set according to the deployment environment, overlap between cached data can be avoided.

Referring to fig. 12, fig. 12 is a schematic diagram of a main structure of a device for testing an interface according to an embodiment of the present invention, where the device for testing an interface can implement a method for testing an interface, as shown in fig. 12, the device for testing an interface specifically includes:

the defining module 1201 is configured to pre-define a deployment environment parameter, a tested interface identifier, a request manner, and an expected response result of the service data interface description file, where the deployment environment parameter indicates a uniform resource locator of a deployment environment, and a corresponding relationship between the deployment environment and the uniform resource locator is defined by a deployment environment mapping table.

The replacing module 1202 is configured to replace the deployment environment parameter in the original test function corresponding to the tested interface identifier according to the deployment environment parameter of the service data interface description file, so as to form a current test function of the tested interface.

A calling module 1203, configured to call a parameter of the current test function based on the request mode, and call the tested interface according to a request address, where the request address is obtained by splicing the uniform resource locator indicated by the deployment environment parameter and the identifier of the tested interface.

The determining module 1204 is configured to determine whether the response result of the test interface is correct according to the expected response result.

In an embodiment of the present invention, the defining module 1201 is further configured to pre-define a virtual user identifier of the service data interface description file, where the virtual user identifier indicates an actual user identifier of the access deployment environment, and a corresponding relationship between the virtual user identifier and the actual user identifier of the access deployment environment is defined through a user mapping table;

the replacing module 1202 is specifically configured to replace, according to the virtual user identifier of the service data interface description file, a user parameter in the original test function corresponding to the tested interface identifier, so as to form a current test function of the tested interface.

The invoking module 1203 is specifically configured to mount the login credential of the actual user according to a credential mapping table, where the credential mapping table includes a corresponding relationship between the deployment environment and the actual user.

In one embodiment of the invention, default parameters for testing the interface are included in the original test function.

In one embodiment of the present invention, the apparatus for testing an interface further comprises:

the caching module 1205 is configured to determine that the response result of the test interface is correct, and the cache is data extracted from the response result and/or data generated in the process of invoking the test interface.

In an embodiment of the present invention, the caching module 1205 is specifically configured to cache the data extracted from the response result and/or the data generated in the process of testing the interface according to the deployment environment.

Fig. 13 illustrates an exemplary system architecture 1300 in which the method of testing an interface or the apparatus of a testing interface of an embodiment of the invention may be applied.

As shown in fig. 13, the system architecture 1300 may include

terminal devices

1301, 1302, 1303, a network 1304, and a server 1305. The network 1304 is used to provide a medium for communication links between the

terminal devices

1301, 1302, 1303 and the server 1305. The network 1304 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may use

terminal devices

1301, 1302, 1303 to interact with a server 1305 over a network 1304 to receive or send messages or the like. Various messaging client applications, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, etc. (examples only) may be installed on the

terminal devices

1301, 1302, 1303.

Terminal devices

1301, 1302, 1303 may be various electronic devices having display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 1305 may be a server that provides various services, such as a background management server (for example only) that provides support for shopping websites browsed by users using the

terminal devices

1301, 1302, 1303. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, target push information, product information — just an example) to the terminal device.

It should be noted that the method for testing the interface provided by the embodiment of the present invention is generally executed by the server 1305, and accordingly, the apparatus for testing the interface is generally disposed in the server 1305.

It should be understood that the number of terminal devices, networks, and servers in fig. 13 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 14, shown is a block diagram of a computer system 1400 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 14 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 14, the computer system 1400 includes a Central Processing Unit (CPU)1401, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)1402 or a program loaded from a storage portion 1408 into a Random Access Memory (RAM) 1403. In the RAM 1403, various programs and data necessary for the operation of the system 1400 are also stored. The CPU 1401, ROM 1402, and RAM 1403 are connected to each other via a bus 1404. An input/output (I/O) interface 1405 is also connected to bus 1404.

The following components are connected to the I/O interface 1405: an input portion 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker and the like; a storage portion 1408 including a hard disk and the like; and a communication portion 1409 including a network interface card such as a LAN card, a modem, or the like. The communication section 1409 performs communication processing via a network such as the internet. The driver 1410 is also connected to the I/O interface 1405 as necessary. A removable medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1410 as necessary, so that a computer program read out therefrom is installed into the storage section 1408 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable medium 1411. The computer program performs the above-described functions defined in the system of the present invention when executed by a Central Processing Unit (CPU) 1401.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a transmitting unit, an obtaining unit, a determining unit, and a first processing unit. The names of these units do not in some cases constitute a limitation to the unit itself, and for example, the sending unit may also be described as a "unit sending a picture acquisition request to a connected server".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

calling in parameters of the current test function based on the request mode, and calling the tested interface according to a request address, wherein the request address is obtained by splicing a uniform resource locator indicated by the deployment environment parameters and the identifier of the tested interface;

According to the technical scheme of the embodiment of the invention, the deployment environment parameters, the tested interface identification, the request mode and the expected response result of the service data interface description file are predefined. Then, replacing the deployment environment parameters in the original test function corresponding to the tested interface identification according to the deployment environment parameters of the service data interface description file to form the current test function of the tested interface. And calling parameters of the current test function based on the request mode, and calling the tested interface according to the request address. And finally, judging whether the response result of the test interface is correct or not according to the expected response result. Therefore, similar interfaces in a plurality of deployment environments can be tested by using the same original test function for testing the interfaces, only corresponding parameters related to the deployment environments need to be replaced, and then test data do not need to be prepared again for the replaced deployment environments, so that the test efficiency is improved.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of testing an interface, comprising:

2. The method of testing an interface of claim 1, further comprising:

the current test function forming the tested interface further includes:

the calling in the parameter of the current test function based on the request mode and before the calling the tested interface according to the request address comprises the following steps:

and mounting the login credentials of the actual user identifier according to a credential mapping table, wherein the credential mapping table comprises the corresponding relation between the actual user identifier and the login credentials.

3. The method of claim 1, wherein default parameters for testing the interface are included in the original test function.

4. The method according to claim 1, wherein after determining whether the response result of the test interface is correct according to the expected response result, the method further comprises:

and if the response result of the test interface is judged to be correct, caching the data extracted from the response result and/or the data generated in the process of testing the interface.

5. The method for testing an interface of claim 4, further comprising:

6. An apparatus for testing an interface, comprising:

7. The apparatus for testing an interface of claim 6,

8. The apparatus for testing an interface of claim 6, wherein default parameters for testing the interface are included in the original test function.

9. The apparatus for testing an interface of claim 6, further comprising:

10. The apparatus of claim 9, wherein the caching module is specifically configured to cache the data extracted from the response result and/or the data generated in the process of the test interface according to a deployment environment.

11. An electronic device for testing an interface, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.