CN113742207A

CN113742207A - Interface testing method, device, equipment and computer readable storage medium

Info

Publication number: CN113742207A
Application number: CN202011010772.5A
Authority: CN
Inventors: 涂寅辉; 张伟
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2020-09-23
Filing date: 2020-09-23
Publication date: 2021-12-03

Abstract

The embodiment of the application provides an interface testing method, an interface testing device, equipment and a computer readable storage medium, wherein the method comprises the following steps: acquiring first configuration information aiming at a first target script input from a network page, wherein the first configuration information comprises to-be-tested interface information and at least one candidate parameter value of a first target variable parameter in the first target script; sequentially determining the at least one candidate parameter value as a target value of the first target variable parameter to obtain at least one corresponding script to be executed; and sequentially executing the at least one script to be executed so as to test the interface to be tested corresponding to the interface information to be tested and obtain at least one corresponding test result.

Description

Interface testing method, device, equipment and computer readable storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, and relates to but is not limited to a method, a device and equipment for testing an interface and a computer readable storage medium.

Background

The interface test is mainly used for detecting interaction points between an external system and a tested system and between internal systems, and the test is mainly used for checking data interaction, transmission, control management processes, interdependence relations between systems and the like. In the related art, the interface test can be performed through the test script and the program, but the interface test through the test script and the program has certain requirements on the technical level of testers, the testers need to have certain programming capability, and certain difficulty is provided for the testers who cannot program. The method of filling interface information on a World Wide Web (Web) page and then executing a test script at a back end to perform an interface test has no requirement on the programming capability of a tester, but the test script can only perform simple tests and has limited test capability.

Disclosure of Invention

The embodiment of the application provides an interface testing method, an interface testing device, interface testing equipment and a computer readable storage medium.

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides an interface testing method, which comprises the following steps:

acquiring first configuration information aiming at a first target script input from a network page, wherein the first configuration information comprises to-be-tested interface information and at least one candidate parameter value of a first target variable parameter in the first target script;

sequentially determining the at least one candidate parameter value as a target value of the first target variable parameter to obtain at least one corresponding script to be executed;

and sequentially executing the at least one script to be executed so as to test the interface to be tested corresponding to the interface information to be tested and obtain at least one corresponding test result.

The embodiment of the application provides an interface testing arrangement, the device includes:

the system comprises a first acquisition module, a first configuration module and a second acquisition module, wherein the first acquisition module is used for acquiring first configuration information aiming at a first target script input from a network page, and the first configuration information comprises to-be-tested interface information and at least one candidate parameter value of a first target variable parameter in the first target script;

the first determining module is used for sequentially determining the at least one candidate parameter value as a target value of the first target variable parameter to obtain at least one corresponding script to be executed;

the first testing module is used for sequentially executing the at least one script to be executed so as to test the interface to be tested corresponding to the interface to be tested information and obtain at least one corresponding testing result.

An embodiment of the present application provides an interface test apparatus, the apparatus at least includes:

a processor; and

a memory for storing a computer program operable on the processor;

wherein the computer program realizes the steps of the interface testing method when being executed by a processor.

Embodiments of the present application provide a computer-readable storage medium, in which computer-executable instructions are stored, and the computer-executable instructions are configured to execute the steps of the interface testing method.

The embodiment of the application provides an interface testing method, an interface testing device and a computer readable storage medium, when an interface is tested, a user sets to-be-tested interface information and at least one candidate parameter value of a first target variable parameter in a first target script through a network page, when the interface testing device receives the to-be-tested interface information and the at least one candidate parameter value, the value of the first target variable parameter can be changed according to the at least one candidate parameter value, and therefore a to-be-tested interface is tested based on different target values of the first target variable parameter.

Drawings

In the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed herein.

Fig. 1 is a schematic flowchart of an interface testing method according to an embodiment of the present disclosure;

fig. 2 is a schematic flowchart of another implementation of an interface testing method according to an embodiment of the present disclosure;

fig. 3 is a schematic flowchart of sequentially executing the at least one script to be executed for testing according to an embodiment of the present application;

fig. 4 is a schematic flowchart of another implementation process of an interface testing method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of another implementation process of an interface testing method according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an interface testing apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an interface test apparatus according to an embodiment of the present application.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

The following description will be added if a similar description of "first \ second \ third" appears in the application file, and in the following description, the terms "first \ second \ third" merely distinguish similar objects and do not represent a specific ordering for the objects, and it should be understood that "first \ second \ third" may be interchanged under certain circumstances in a specific order or sequence, so that the embodiments of the application described herein can be implemented in an order other than that shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Based on the problems in the related art, the embodiments of the present application provide an interface testing method, which is applied to an interface testing device. The interface testing device may be a server, a database, or the like, and the method provided by this embodiment may be implemented by a computer program, and when the computer program is executed, each step in the method provided by this embodiment is completed. In some embodiments, the computer program may be executed by a processor in the interface test apparatus. Fig. 1 is a schematic flowchart of an interface testing method provided in an embodiment of the present application, and as shown in fig. 1, the method includes:

step S101, acquiring first configuration information aiming at a first target script input from a network page.

In this embodiment of the application, the first configuration information includes information of an interface to be tested and at least one candidate parameter value of a first target variable parameter in the first target script. The interface information to be tested may be an Internet Protocol (IP) address of the interface to be tested; the network page can be a WEB page, the network page includes a configuration interface of a script, option information of a target script selected by a user can be provided in the configuration interface, so that the user can select a first target script, the first target script is pre-stored in the interface test equipment, after the first target script is selected, a variable parameter of the first target script and information of an interface to be tested can be displayed in the configuration interface, and at this time, the user can input the information of the interface to be tested and at least one candidate parameter value of the first target variable parameter in the first target script through the configuration interface. After the user finishes setting, the user can click to finish configuration operation, and the equipment where the network page is located sends the first configuration information to the interface test equipment, so that the interface test equipment can obtain the first configuration information. In the embodiment of the application, the first target variable parameter is determined by the user from the variable parameter in the first target script. For example, the first target script has a variable parameter a, a variable parameter B, and a variable parameter C, and when the user selects the variable parameter B, the variable parameter B is the first target variable parameter. The user may configure at least one candidate parameter value for the first target variable parameter. In the embodiment of the present application, the at least one candidate parameter value may be one or multiple. For example, the candidate parameter value of the variable parameter B may be 1, and the candidate parameter value of the variable parameter B may also be: 1.2, 3 and 4.

And step S102, sequentially determining the at least one candidate parameter value as a target value of the first target variable parameter to obtain at least one corresponding script to be executed.

In the embodiment of the present application, each variable parameter in the first target script has a default parameter value, exemplarily, the default parameter value is 0, and after the interface test device receives at least one candidate parameter value, the candidate parameter value may be sequentially determined as the target value of the first target parameter.

Step S103, the at least one script to be executed is executed in sequence, so as to test the interface to be tested corresponding to the interface to be tested information, and obtain at least one corresponding test result.

In the embodiment of the application, after obtaining at least one script to be executed, the at least one script to be executed can be executed to generate corresponding at least one test request message; the interface test equipment sends the at least one test request message to a to-be-tested interface corresponding to the to-be-tested interface message; after receiving the at least one piece of test request information, the interface to be tested generates first response information, the interface to be tested sends the first response information to the interface test equipment, and after receiving the at least one piece of first response information, the interface test equipment tests the interface to be tested based on the at least one piece of first response information to determine at least one corresponding test result.

The embodiment of the application provides an interface testing method, when an interface is tested, a user sets at least one candidate parameter value of interface information to be tested and a first target variable parameter in a first target script through a network page, and when interface testing equipment receives the interface information to be tested and the at least one candidate parameter value, the value of the first target variable parameter can be changed according to the at least one candidate parameter value, so that the interface to be tested is tested based on different target values of the first target variable parameter.

In some embodiments, fig. 2 is a schematic flow chart of another implementation of an interface testing method provided in this embodiment of the present application, and as shown in fig. 2, before step S101 "acquiring first configuration information for a first target script input from a web page", the method further includes:

step S101A, obtaining second configuration information for creating the first target script input from the web page.

In this embodiment of the present application, the second configuration information at least includes parameter information and an assertion, where the parameter information includes a variable parameter and a default parameter value corresponding to the variable parameter. The parameter information includes all parameters required for generating the test request information, and for a hypertext Transfer Protocol (HTTP) interface, the parameter information includes a Uniform Resource Locator (URL), header information, query parameters, and a message body (body); for a Remote Procedure Call (RPC) interface, the parameter information includes an interface name, a method parameter, a packet name, and the like.

In this embodiment of the application, for the HTTP interface, the parameter information may be represented by a field, and exemplarily, the parameter information is:

{"url":"http://api.m.jd.com/client.actionfunctionId＝hello","headers":[{"name":"Con tent-Type","value":"application/x-www-form-urlencoded"}],"params":[{"name":"cli ent","value":"android"},{"name":"clientVersion","value":"8.0.0"},{"name":"uuid","value":"867633021311568-38bc92874435"},{"name":"pin","value":"${pin}"}],"bo dies":[{"name":"body","value":"${body}"}]}。

wherein url is the IP address of the interface to be tested, heads is the request header, params is the query parameter, and books is the body of the request. There is a { "name": pin "," value ":" $ { pin } "} in params, which means that there is a query parameter pin, the value of which is not determined at the time of script creation, and the value of $ { pin } is defined by variable configuration at the time of execution, and $ { body } in books is also defined by variable configuration. In the embodiment of the present application, the body is represented by a list because when the Content-Type is application/x-www-form-url, there may be a plurality of body parameters, each having its own name and value. When the Content-Type is application/json, the books are not lists, but object types, "books" { "onlineFlag":1, "page size":10, "orderBy": created DESC "," forUn patent ": false }.

For the RCF interface, the parameter information may be expressed as:

{"interface":"com.jd.qt.service.xxx","method":"yyy","alias":"zzz",

"params" [ { name ": facial", "type": java.util.list "," value ":" [ \\ 06817888\ ji, 06817883] "}, {" name ": keys", "type": java.lang.string "," value ": sodium chloride injection" }.

The interface is an interface name, the method is a method name, the alias is a group name, the params is a parameter, the params is a list, each element represents a parameter, the name is a parameter name, the type is a parameter type, and the value is a parameter value.

In the embodiment of the application, the assertion is used for checking the response information of the interface to be tested, and the first target script may include a plurality of assertions, each assertion including a reference parameter, a value type, a verification method, a result type, a reference check value, and the like. The reference parameter refers to which field of the response information is checked, such as $. The value type refers to how to read the reference parameter, and exemplarily includes: JsonPath and XPATH. The verification method refers to what kind of comparison is made between the extracted value and the expected value, and exemplarily comprises the following steps: string contains (contacts), string does not contain (notcontacts), equal to (equials), not equal to (notsquares), list contains (listcontacts), Json object has a certain key (haskey), greater than (greaterThan), greater than or equal to (greaterEquals), less than (lessThan), less than or equal to (lessEquals), null (isnull), not null (notnull), string with length of 0 or list with size of 0 (null), string with length of 0 or list with size of 0 (notspace), null or list (nulspace), neither null nor notspace (notspace), and the like. In the embodiment of the application, the verification method is extensible. In some embodiments, the verification method may further obtain a property value (getValue) of the specified object, which is to save the read value of the reference parameter, save the value of the reference parameter to the variable represented by the reference check value, and read the value of the reference parameter in a subsequent dependent script to be used as the target value of the variable parameter. The result type refers to the data type of the read reference check value, verification is passed only if the data types are consistent, and the verification is carried out, wherein the verification is carried out by Boolean, String, Integer, Float, Long, Asstring and the like, and the Asstring refers to that the type is not verified, and the read result is directly converted into String to be compared with the reference check value. The reference check value is an expected result for the reference parameter. In the embodiment of the application, some verification methods do not need to fill in reference check values, such as isNull, notNull, empty, notEmpty, nulempty, notnulempty and the like, are unitary operations, and do not need to be compared with any reference check value.

Assertions can also be represented by fields, illustratively: [ { "item", "$," op ": JSONPATH", "valid": equals "," valType ": Boolean", "exp": true "}, {" item ": $ data. item.number", "op": JSONPATH "," valid ":" greaterEquals "," valType ": Integer", "exp": 2"} { ]

The field represents a list, each element of the list represents an assertion, item is a verification item, op is a value type, validate is a verification method, valType is a result type, and exp is an expected value.

Step S101B, creating the first target script at least based on the parameter information and the assertion, and storing the first target script.

In the embodiment of the application, after the interface test equipment receives the parameter information and the assertion, a first target script can be created based on the parameter information and the assertion, and the first target script is stored in the database.

According to the interface testing method provided by the embodiment of the application, the first target script is configured in advance and stored in the database, when a user needs to call the first target script to test an interface to be tested, the first target script can be selected through a network page and configured, so that the test on the interface to be tested is completed, and the programming capability of a tester is not required.

In some embodiments, step S103 "sequentially executes the at least one script to be executed to test the interface to be tested corresponding to the interface to be tested information to obtain the corresponding at least one test result" may be implemented by steps S1031 to S1034 shown in fig. 3, as shown in fig. 3:

and step S1031, sequentially executing the at least one script to be executed to generate corresponding at least one test request message.

In the embodiment of the application, at least one script to be executed can be executed to generate corresponding at least one piece of test request information. The test request information may be constructed according to parameter information of at least one script to be executed, and the test request information may include HTTP interface test request information and RPC interface test request information. The test request information may be represented by a field. For the HTTP interface test request information, constructing HTTP interface test request information (request) of an HTTP3 through an open source framework (HTTP 3) of a network request, where the HTTP interface test request information is expressed as:

parameter information provides headers, url, body when constructing HTTP interface test request information. Wherein the headers are from the headers field of the first target script, the url is from the url and params fields of the first target script, and the body is from the pages field of the first target script. After the request is constructed, the HTTP interface test request information is executed by the okhtttpclient.

For the RPC interface test request information, taking the standard framework (JSF, JavaServer Faces) of the application as an example, the RPC interface test request information is executed through a generalization call, and a generalization call (GenericService) is first constructed:

the interface name, alias and ip are respectively from the interface and alias of the first target script and the host configured before the script is executed. Then, constructing RPC interface test request information based on generalized calls, firstly, acquiring all types from params of a first target script to form an array paramType of a String type, then acquiring values of all parameters from values of the params, constructing an object of the type according to the types and the values, storing the parameter array paramVal, acquiring method names of interfaces from methods of the first target script, and finally executing the RPC interface test request information through genericService $ invoke (method, paramType, paramVal).

Step S1032, sending the at least one test request message to the interface to be tested.

In the embodiment of the application, after the corresponding at least one piece of test request information is generated, the interface test equipment sends the test request information to the interface to be tested.

Step S1033, receiving at least one first response message for the at least one test request message sent by the interface to be tested.

In this embodiment of the present application, after receiving at least one test request message, the interface to be tested may generate at least one first response message for the at least one test request message, and the interface to be tested sends the at least one first response message to the interface test device.

Step S1034, testing the interface to be tested based on the at least one first response message, and determining at least one corresponding test result.

In the embodiment of the application, after the interface testing equipment receives the at least one response message, the reference parameter can be extracted from the at least one response message, so as to extract the at least one value to be checked corresponding to the reference parameter, and then the testing result is determined according to the value to be checked and the reference check value, so that the testing of the interface to be tested is realized.

In some embodiments, the assertion includes a reference parameter and a reference check value corresponding to the reference parameter, and the step S1034 "testing the interface to be tested based on the at least one first response message, and determining the corresponding at least one test result" may be implemented by:

step S1, extracting at least one value to be checked corresponding to the reference parameter from the at least one first response message.

In the embodiment of the present application, at least one to-be-checked value corresponding to the reference parameter may be read through JsonPath or XPATH according to the type of the reference parameter.

Step S2, determining at least one corresponding test result based on each value to be verified and the reference verification value.

In the embodiment of the application, after at least one to-be-verified value is obtained, each to-be-verified value may be compared with the reference verification value to determine a test result according to a verification method. Illustratively, when the verification methods are equal, when the comparison is performed, when each value to be verified is equal to the reference verification value, a test result that the verification passes is obtained, and when each value to be verified is not equal to the reference verification value, a test result that the verification fails is obtained.

As another example, the assertion is: the method comprises the following steps of { ' item ' $, data.item.number ', ' op ': JSONPATH ', ' valid ': greaterEquals ', ' valType ': Integer ', ' exp ': 2 ', reading $ data.item.number through JsonPath, and obtaining a test result which is verified to be passed when the value of the data.item.number is an Integer and is greater than or equal to 2, or obtaining a test result which is not verified to be passed.

In some embodiments, the assertion further includes a type of a reference verification value, and the step S2 "determining at least one corresponding test result based on each value to be verified and the reference verification value" may be implemented by:

step S21, determining whether the type of each value to be checked is the same as the type of the reference check value.

In the embodiment of the present application, when the to-be-verified value is obtained, it may be determined whether the type of the to-be-verified value is the same as the type of the reference verification value, if so, step S22 is executed, and if not, a test result that the test does not pass is obtained.

Step S22, determining at least one corresponding test result based on the respective values to be verified and the reference verification value.

In the embodiment of the application, when the value to be checked is the same as the reference check value, a test result passing the test is obtained.

According to the interface testing method provided by the embodiment of the application, when the value to be checked is obtained, whether the type of the value to be checked is the same as that of the reference check value is judged at first, so that quick judgment is realized, and the checking processing speed is improved.

In some embodiments, fig. 4 is a schematic flow chart of another implementation of the interface testing method provided in the embodiment of the present application, and as shown in fig. 4, the second configuration information further includes: dependencies between scripts, after step S101, the method further comprising:

step S31, it is determined whether there is a second target script that satisfies the dependency relationship in the first target script.

In the embodiment of the application, after the first target script is determined, whether a second target script meeting the dependency relationship exists or not can be determined through the second configuration information of the first target script. Each script has an ID, and the dependency relationship between scripts can be represented by the ID of each script. Illustratively, the first target script is represented by script A, the second target script is represented by script B, the dependency relationship may be represented as [ A, B ], when there is a second target script satisfying the dependency relationship, step S32 is executed, when there is no second target script satisfying the dependency relationship, step S102 is executed.

Step S32, obtaining second response information, where the second response information is obtained from the test interface corresponding to the second target script.

Taking the above example, script A depends on script B, and then script B is automatically executed before executing script A. And when the script B is executed, generating test request information of a test interface corresponding to the script B, and generating second response information by the test interface corresponding to the script B based on the test request information, so that the interface test equipment acquires the second response information.

Step S33, extracting a parameter value corresponding to the second target variable parameter from the second response information.

In the embodiment of the application, after the interface test device acquires the second response information, a parameter value corresponding to the second target variable parameter may be extracted.

Step S34, determining the parameter value corresponding to the second target variable parameter as the target value of the second target variable parameter.

According to the interface testing method provided by the embodiment of the application, when the first target script is configured, the second target script having the dependency relationship with the first target script is configured at the same time, so that when the first target script is executed to test the interfaces to be tested, the second target script is executed to test the corresponding interfaces to be tested according to the dependency relationship, and thus, the automatic testing of a plurality of interfaces to be tested is realized.

In some embodiments, the method further comprises:

and step S41, acquiring the information to be verified input from the network page.

In this embodiment of the application, the information to be verified may be information directly input from a web page.

Step S42, extracting the to-be-verified value corresponding to the reference parameter from the to-be-verified information.

In the embodiment of the application, the reference parameter can be determined according to the assertion, so that the value to be checked corresponding to the reference parameter is extracted from the information to be checked.

Step S43, determining a test result corresponding to the information to be verified based on the value to be verified and the reference verification value.

In the embodiment of the application, the test result corresponding to the information to be verified can be determined based on the verification method in the assertion, the value to be verified and the reference verification value.

The embodiment of the application provides an interface testing method, which comprises the following steps: after a script is configured on a page (like the network page in the above embodiments), the server stores the information of the script, and stores the information into the database, and the script can be executed subsequently. Before executing the script, a variable (like at least one candidate parameter value of the first target variable parameter in the above embodiments) and a host (host) are configured on the page (like the interface information to be tested in the above embodiments), and it is determined on which host the value of the parameterized variable and the interface in the script are executed. And after receiving the call of the execution script, the server program inquires the information of the script in the database according to the script ID, then executes the script according to the configured variable value and host, checks the assertion after the execution is finished, and returns the execution result to the client page. Fig. 5 is a schematic flow chart of another implementation of an interface testing method provided in the embodiment of the present application, and as shown in fig. 5, the interface testing method includes:

step S501, perform script configuration on a WEB page (the same as the WEB pages in the above embodiments).

The script configuration information includes: the configuration of request parameters (same as the parameter information in the above embodiments), assertions, pre-processors, post-processors, script dependencies (same as the dependencies between scripts in the above embodiments), etc., the request parameters and assertions are the most basic, and all scripts are required.

The request parameter comprises all information required by the interface request, and the HTTP interface comprises URL, header information, query parameter and body; the RPC interface comprises an interface name, a method parameter and a packet name.

The assertion is a check on the interface access response, one assertion may include a verification item (same as the reference parameter in each of the above embodiments), a value type (same as the type of the reference check value in each of the above embodiments), a verification method, a result type, and an expected value, and one script may include a plurality of assertions. The validation term refers to which field of the response is checked, such as $. The value type refers to how to read the verification item, and exemplarily includes: JsonPath, XPATH. The verification method refers to comparing the extracted value with an expected value, and comprises the following steps: continains, notcontinans, equils, notsquares, listcontinans, hasKey, greaterThan, greaterEquals, lessThan, lessEquals, isNull, notNull, empty, notEmpty, nulempty, notnulempty, etc., the verification method is extensible and any desired verification method can be extended as desired. In some embodiments, the verification method may also be getValue, and the variable represented by the expected value is saved by saving the value of the read verification item, and can be read out in a subsequent dependent script to be used as a parameter. The result type refers to the data type of the read verification item, verification is passed only if the types are consistent, and the verification item comprises Boolean, String, Integer, Float, Long, Asstring and the like, wherein the Asstring refers to that the type is not checked, the read result is directly converted into a character String (String), and then the character String is compared with an expected value. The expected value is the expected result for the validation item, and the expected value does not need to be filled in for some validation methods, such as isNull, notNull, empty, notEmpty, nulEmpty, notNullEmpty, etc., which are unitary operations and do not need to be compared with what expected value.

The pre-processor and the post-processor are used for processing access to a database, a Remote Dictionary service (Remote Dictionary Server), and a message middleware (such as JMQ), generally performing data preparation before performing interface access, and performing data check and cleaning after performing interface access, and have the same structure, except that the access defined by the pre-processor is performed before performing interface access, and the access defined by the post-processor is performed after performing interface access. The pre-processor and post-processor may contain multiple entries, each entry corresponding to access to a database, Redis, JMQ. For a database, a user needs to fill in database connection information (address, username, password) and fill in one or more pieces. Structured Query Language (SQL) statements, because the pre-processor and the post-processor can also perform data verification, the user can also fill in the content related to the verification here, and for each SQL statement, the verification item, the value type, the verification method, the result type, the expected value, and the assertion can be completely the same, except that the verification content here is from the execution result of the SQL statement, not the response of the interface. For Redis, Redis addresses and one or more access Key values (Key) need to be filled, and each access Key also has a verification item, a value type, a verification method, a result type and an expected value. For JMQ, JMQ addresses, Application programs (apps), titles (topics), accounts, passwords, one or more message operations including behaviors and message contents, and each message operation also includes a verification item, a value type, a verification method, a result type, and an expected value.

The script dependency is used for multi-interface scene test, one script can depend on a plurality of scripts, the script dependent on the script needs to be executed before the script is executed, and the definition of the script dependency only needs to fill the script ID of the dependent script in the script dependent item of the script.

In step S502, a script is generated in the server.

After the content needed by the script is configured on the Web page, the server interface is called, and the script is generated by the server and is stored in the database.

The request parameters are represented in the database by a field, and for the HTTP interface, the following is represented:

{"url":"http://api.m.jd.com/client.actionfunctionId＝hello","headers":[{"name":"Content-Type","value":"application/x-www-form-urlencoded"}],"params":[{"name":"client","value":"android"},{"name":"clientVersion","value":"8.0.0"},{"name":"uuid","value":"867633021311568-38bc92874435"},{"name":"pin","value":"${pin}"}],"bodies":[{"name":"body","value":"${body}"}]}。

url is the address of the interface, headers are the request header, params are the query parameters, and books are the BODY of the request. There is a { "name": pin "," value ":" $ { pin } "} in params, which means that there is a query parameter pin, the value of which is not determined at the time of script creation, and the value of $ { pin } is defined by variable configuration at the time of execution, and likewise $ { body } in books. BODY is tabulated because when the Content-Type is application/x-www-form-url, there can be multiple BODY parameters, each with its own name and value. When the Content-Type is application/json, the books are not lists, but object types, such as "books" { "onlineFlag":1, "page":1, "pageSize":10, "orderBy": created DESC "," forUnputlike ": false }.

For the RPC interface, the request parameters are as follows:

{ "interface": com.jd.qt.service.xxx "," method ": y", "alias": zzz "," params ": name": factors "," type ": java.util", "value": "[ \\ 06817888\",06817883] "}, {" name ": keys", "type": java.land.string ] }, { "value": sodium chloride injection "} type

The interface is an interface name, the method is a method name, the alias is a group name, the params is a parameter, the parameter is a list, each element represents a parameter, the name is a parameter name, the type is a parameter type, and the value is a parameter value.

The assertion is expressed as follows:

[{"item":"$.success","op":"JSONPATH","validate":"equals","valType":"Boolean","exp":"true"},{"item":"$.data.item.number","op":"JSONPATH","validate":"greaterEquals","valType":"Integer","exp":"2"}]

the code indicates that the assertion is a list, each element of the list represents an assertion, item is a verification item, op is a value type, validate is a verification method, valType is a result type, and exp is an expected value.

The preprocessor is represented by a list, each element being accessed by a database, Redis or JMQ. These three types are included below.

[ { "type": db "," config ": {" url ": jdbc: mysql:// xxx. xxx: 3306/db? "true": result ", "action": send "," item ": $", "$", "op": JSONPATH "," valid ":", "contacts", "valid type": String "," exp ": success" }

The Type has values of db, redis and jmq, which respectively represent three types, each Type has respective connection information config, also verify represents access operation, db is sql access, redis is reading of a certain key, jmq is sending or reading message, and the access operation also has check information.

The post processor structure and the pre processor are identical when the script is generated

Script dependencies are represented by a list of values, e.g., [12,23], representing the current script dependent scripts 12 and 23.

In step S503, variables and host are configured on the page.

In the generated script, there may be a variable, such as $ { pin }, which indicates a variable pin, the value of which needs to be provided by the user before the script is executed, and a host is also provided before the script is executed, and is provided as a parameter together with the script id to the interface of the server-side execution script, such as "properties": { "name": "pin", "value": jack "}," hosts "[ {" host ": www.jd.com", "ip": 1.2.3.4"}, {" host ": com.jd.qt.service.xxx and" ip ": 1.2.3.4" }. Later execution will replace $ { pin } in the script with jack, HTTP access will bind www.jd.com to 1.2.3.4, RPC access will hit the request of interface com.jd.qt.service.xxx to 1.2.3.4.

Step S504, the script is executed at the server to perform the test.

The script is executed at the server, a record exists in a database after the script is generated, the record only defines information, assertion and the like executed by an interface, the record is not an executable script like a Java program, and when the script is executed at the server, an HTTP (hyper text transport protocol) or RPC (remote procedure call) request is pieced up, the requests of a front processor and a back processor are pieced up, and assertion verification is executed.

First, HTTP and RPC requests are constructed. For the HTTP interface, the request is executed through an open source framework of the network request (such as HTTP3), so a request (request) of HTTP3 needs to be constructed:

Request request＝new Request.Builder()

.cacheControl(CacheControl.FORCE_NETWORK)

.headers(headers)

.url(url)

.post(body)

.build()；

headers, url, body need to be provided for the construction of okhttp 3. The headers is from the headers field of the script, the url is from the url and params fields of the script, and the body is from the bodies field. After the request is constructed, the HTTP request is executed by okhtttpclient.

For the RPC interface, taking a JSF (JavaServer Faces) request of an application as an example, the JSF request is executed by generalization call, and a GenericService is first constructed:

ConsumerConfig<GenericService>consumerConfig＝newConsumerConfig<>()；

consumerConfig.setRegistry(new RegistryConfig())；

consumerConfig.setInterfaceId(interfaceName)；

consumerConfig.setGeneric(true)；

consumerConfig.setAlias(alias)；

consumerConfig.setUrl(ip)；

GenericService genericService＝consumerConfig.refer()；

the ifacenName, alias and ip are respectively from the iface and alias of the script and the host configured before the script is executed.

And then constructing parameters of the request, firstly, acquiring all types from params of the script to form an array paramType of a String type, then acquiring values of all the parameters from values of the params, constructing an object of the type according to the types and the values, storing the parameter array paramVal, acquiring a method name of an interface from a method of the script, and finally executing the JSF request through genericService $ invoke (method, paramType, paramVal).

Any one component (interface name, packet name, information header, query parameter, body, assertion, front and back processors, etc.) in the script can have a variable, the value of the variable is specified by a user before executing the script, and all the variables appearing in each position in the script are replaced by the values specified by the user when the server executes the script, and the replacement can be directly performed by character strings.

If circulation is needed, the object needing circulation is set as a variable, the value of the variable is specified before the script is executed, a plurality of values are provided at the moment, but not one value, the variable in the script is replaced by one value each time when the script is executed, the multi-value is circulated, and the circulation execution of the script is realized.

As previously described, the multi-interface scenario is implemented through script dependency, and if script A depends on script B, script B is automatically executed before executing script A. If the assertion of the script B is verified by getValue, such as { "item": "$. pin", "op": JSONPATH "," valid ": getValue", "valType": String "," exp ":" $ { pin } ", then the response $. pin field of B is saved to the variable pin after the B is executed, and the saved result is replaced where the script A uses the variable pin.

For the HTTP interface, host binding is implemented via the leopard library. The method of Javahost. update VirtualDns (String host, String ip) of the library realizes host binding, and the values of host and ip come from user configuration.

And after the interface executes, making an assertion on the response, firstly, reading the value of the field to be verified according to JsonPath or XPATH of the verification item, then checking whether the type of the value is the same as the result type, if so, failing the verification, and if so, judging whether the verification is passed according to the verification method and the expected value.

Illustratively, this assertion, { "item": "$. success", "op": JSONPATH "," valid ": equals", "valtate", "valType": "Boolean", "exp": "true" }, reads the value of $. success according to JSONPATH, type is Boolean and result is true, verification passes, otherwise fails. Illustratively, the assertion of { "item" $. data. item.number "," op ": JSONPATH", "valid": greaterEquals "," valType ": integrar", "exp": 2"} is read according to JSONPATH, data. item.number passes when its value is an Integer and greater than or equal to 2, and fails otherwise.

The pre-processor is executed before the interface access, and the post-processor is executed after the interface access, so that the access to the database, Redis and JMQ is completed, and the access result is asserted.

A database:

{ "type": db "," config ": {" url ": jdbc mysql:// xxx. xxx: 3306/dbuseSSL:. false & useUnicode ═ true & character encoding [ -UTF-8 & servicetime zone ═ UTC ]," user ": xxx", "password": xxx "}," verify "[ {" sql ":" select _ { "free table1 ]," item ": book": jsjsonPATH "," valid ": contents", "valid": exp "," hello "} the result is verified after each element in the list of connections is retrieved according to url, user, password.

Redis:

{ "type": redis "," config ": {" url ": xx" }, "verify" [ { "key": N _ CURRENT _ STORE _ INFO "," item ":" $. name "," op ": JSONPATH", "valid": contacts "," valType ": String", "exp": hello "} according to url and key, obtain the key value of this redis and make assertion.

JMQ：

{ "type": jmq "," config ": {" app ": xx", "address": xx "," user ": xx", "password": xx "," topic ": xx" }, [ { "message": good "," action ": sense", "item": "$", "op": JSONPATH "," valid ":" contents "," valid ": String", "exp": success ] }, when the action is send, a producer is established according to the configuration of the configuration, then the message is sent, when the action is receive, a consumer is established according to the configuration of the configuration, and then the message is received. The assertion is made after the transmission or reception is completed.

And when the assertion of the script is completely passed and the assertion of the post processor is also completely passed, the script result is passed, otherwise, the script result is failed.

In the method provided by the embodiment of the application, any one component (interface name, packet name, header, query parameter, body, assertion, pre-post processor, and the like) in the script may have a variable, the value of the variable is specified by a user before the script is executed, and all the variables appearing in various places in the script are replaced by the value specified by the user when the server executes the script. The loop is implemented by multiple values of variables. If circulation is needed, the object needing circulation is set as a variable, the value of the variable is specified before the script is executed, a plurality of values are provided at the moment, but not one value, the variable in the script is replaced by one value each time when the script is executed, the multi-value is circulated, and the circulation execution of the script is realized.

The multi-interface scene is realized through script dependence, if the script A depends on the script B, the script B is automatically executed first when the script A is executed, and the response of the script B can be used as the parameter value of the variable of the script A. If the assertion of the script B is verified by getValue, such as { "item": "$. pin", "op": JSONPATH "," valid ": getValue", "valType": String "," exp ":" $ { pin } ", then the response $. pin field of B is saved to the variable pin after the B is executed, and the saved result is replaced where the script A uses the variable pin.

The access to the interface is added with pre-processing and post-processing, the pre-processor is executed before the access to the interface, the post-processor is executed after the access to the interface, the access to the database, Redis and JMQ is completed, and the access result is asserted. The pre-processing can carry out data preparation, and the post-processing can carry out data verification and data cleaning, so that the test of the interface not only can verify the response of the interface, but also can verify the data storage influenced by the interface. The configuration information of the database, the Redis and the JMQ is filled in the page, the SQL sentence, the cache key and the JMQ message are filled in, the server acquires connection according to the configuration information during execution, access is performed according to the SQL sentence, the cache key, the message content and the like, and assertion and verification are performed on an access result.

By accessing HTTP and RPC interfaces, rich verification methods for interface response, parameterized variables, circulation, multi-interface scenes, pre-and post-processors, and external data (databases, Redis, JMQ), the scheme forms a comprehensive test scheme, and is low in technical threshold in a page mode.

Based on the foregoing embodiments, the present application provides an interface testing apparatus, where each module included in the apparatus and each unit included in each module may be implemented by a processor in a computer device; of course, the implementation can also be realized through a specific logic circuit; in the implementation process, the processor may be a Central Processing Unit (CPU), a Microprocessor Unit (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.

An embodiment of the present application further provides an interface testing apparatus, fig. 6 is a schematic structural diagram of the interface testing apparatus provided in the embodiment of the present application, and as shown in fig. 6, the interface testing apparatus 600 includes:

a first obtaining module 601, configured to obtain first configuration information for a first target script input from a web page, where the first configuration information includes interface information to be tested and at least one candidate parameter value of a first target variable parameter in the first target script;

a first determining module 602, configured to sequentially determine the at least one candidate parameter value as a target value of the first target variable parameter, so as to obtain at least one corresponding script to be executed;

the first testing module 603 is configured to sequentially execute the at least one script to be executed, so as to test the interface to be tested corresponding to the interface to be tested information, and obtain at least one corresponding testing result.

In some embodiments, the interface test apparatus 600 further comprises:

a second obtaining module, configured to obtain second configuration information input from the web page and used to create the first target script, where the second configuration information at least includes parameter information and assertion, and the parameter information includes a variable parameter and a default parameter value corresponding to the variable parameter;

and the creating module is used for creating the first target script at least based on the parameter information and the assertion and storing the first target script.

In some embodiments, the first test module 603, comprises:

the generating unit is used for sequentially executing the at least one script to be executed so as to generate at least one piece of corresponding test request information;

a sending unit, configured to send the at least one test request message to the interface to be tested;

the receiving unit is used for receiving at least one piece of first response information aiming at the at least one piece of test request information sent by the interface to be tested;

and the first determining unit is used for testing the interface to be tested based on the at least one piece of first response information and determining at least one corresponding test result.

The assertion includes a reference parameter and a reference check value corresponding to the reference parameter, and the first determining unit includes:

an extracting subunit, configured to extract at least one value to be checked corresponding to the reference parameter from the at least one first response message;

and the determining subunit is used for determining at least one corresponding test result based on each value to be verified and the reference verification value.

In some embodiments, the type of reference check value is also included in the assertion, the determining subunit being configured to:

determining whether the type of each value to be checked is the same as the type of the reference check value;

and under the condition that the type of each value to be checked is the same as that of the reference check value, determining at least one corresponding test result based on each value to be checked and the reference check value, wherein when the value to be checked is the same as the reference check value, the test result which passes the test is obtained.

In some embodiments, the second configuration information further comprises: the interface testing apparatus 600 further includes:

a third obtaining module, configured to obtain second response information when it is determined that a second target script that satisfies a dependency relationship with the first target script exists, where the second response information is obtained from a test interface corresponding to the second target script;

a second determining module, configured to determine a second target variable parameter in the first target script based on the second response information;

the first extraction module is used for extracting a parameter value corresponding to the second target variable parameter from the second response information;

and the fourth determining module is used for determining the parameter value corresponding to the second target variable parameter as the target value of the second target variable parameter.

In some embodiments, the interface test apparatus 600 further comprises:

a fifth obtaining module, configured to obtain information to be verified input from the web page;

the second extraction module is used for extracting the value to be checked corresponding to the reference parameter from the information to be checked;

and the second testing module is used for determining a testing result corresponding to the information to be verified based on the value to be verified and the reference verification value.

The above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

An embodiment of the present application provides an interface test device, fig. 7 is a schematic diagram of a structure of the interface test device provided in the embodiment of the present application, and as shown in fig. 7, the interface test device 700 includes: a processor 701, at least one communication bus 702, a user interface 703, at least one external communication interface 704 and a memory 705. Wherein the communication bus 702 is configured to enable connective communication between these components. The user interface 703 may include a display screen, and the external communication interface 704 may include standard wired and wireless interfaces, among others. The processor 701 is configured to execute the program of the interface testing method stored in the memory to implement the steps in the interface testing method provided in the above embodiments.

The above description of the interface test apparatus and storage medium embodiments is similar to the description of the method embodiments described above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the interface test device and the storage medium of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be noted that, in this embodiment of the present application, if the symmetric storage cluster catalog quota management method is implemented in the form of a software function module and is sold or used as an independent product, the method may also be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Accordingly, embodiments of the present application provide a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps in the interface testing method provided in the above embodiments.

The above description of the storage medium embodiment is similar to the description of the method embodiment described above, with similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the interface test device and the storage medium of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units; can be located in one place or distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for realizing the method embodiments can be completed by hardware related to program instructions, the program can be stored in a computer readable storage medium, and the program executes the steps comprising the method embodiments when executed; and the aforementioned storage medium includes: various media that can store program codes, such as a removable Memory device, a Read Only Memory (ROM), a magnetic disk, or an optical disk.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing an AC to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a magnetic or optical disk, or other various media that can store program code.

The above description is only for the embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An interface testing method, the method comprising:

2. The method of claim 1, further comprising:

acquiring second configuration information which is input from the network page and used for creating the first target script, wherein the second configuration information at least comprises parameter information and assertion, and the parameter information comprises variable parameters and default parameter values corresponding to the variable parameters;

and creating the first target script at least based on the parameter information and the assertion, and storing the first target script.

3. The method of claim 2, wherein the sequentially executing the at least one script to be executed to test the interface to be tested corresponding to the interface to be tested information to obtain at least one corresponding test result comprises:

sequentially executing the at least one script to be executed to generate corresponding at least one test request message;

sending the at least one test request message to the interface to be tested;

receiving at least one first response message aiming at the at least one test request message sent by the interface to be tested;

and testing the interface to be tested based on the at least one piece of first response information, and determining at least one corresponding test result.

4. The method of claim 3, wherein the assertion comprises a reference parameter and a reference check value corresponding to the reference parameter, and wherein the testing the interface to be tested based on the at least one first response message to determine the corresponding at least one test result comprises:

extracting at least one value to be checked corresponding to the reference parameter from the at least one first response message;

and determining at least one corresponding test result based on each value to be checked and the reference check value.

5. The method according to claim 4, wherein the assertion further includes a type of a reference verification value, and the determining the corresponding at least one test result based on each value to be verified and the reference verification value includes:

6. The method of claim 2, wherein the second configuration information further comprises: dependencies between scripts, the method further comprising:

under the condition that a second target script meeting the dependency relationship with the first target script is determined to exist, second response information is obtained, and the second response information is obtained from a test interface corresponding to the second target script;

determining a second target variable parameter in the first target script based on the second response information;

extracting a parameter value corresponding to the second target variable parameter from the second response information;

and determining the parameter value corresponding to the second target variable parameter as the target value of the second target variable parameter.

7. The method of claim 4, further comprising:

acquiring information to be verified input from the network page;

extracting a value to be checked corresponding to the reference parameter from the information to be checked;

and determining a test result corresponding to the information to be verified based on the value to be verified and the reference verification value.

8. An interface test apparatus, the interface test apparatus comprising:

9. Interface test device, characterized in that it comprises at least:

a processor; and

a memory for storing a computer program operable on the processor;

wherein the computer program when executed by a processor implements the steps of the interface testing method of any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon computer-executable instructions configured to perform the steps of the interface testing method of any one of claims 1 to 7.