CN111143187A

CN111143187A - Method and apparatus for application program interface API testing

Info

Publication number: CN111143187A
Application number: CN201811298053.0A
Authority: CN
Inventors: 杨波
Original assignee: Ebao Network Technology Shanghai Co Ltd
Current assignee: Ebao Network Technology Shanghai Co Ltd
Priority date: 2018-11-02
Filing date: 2018-11-02
Publication date: 2020-05-12

Abstract

The invention provides a method and equipment for testing an Application Program Interface (API). The method comprises the following steps: receiving a dragging request of a user for a graphical Block Blcok tested by an application program interface API, wherein the Block Block corresponds to a statement segment of a DSL (digital subscriber line) of a field-specific language; converting the graphical block corresponding to the dragging request into a DSL script according to a Blockly specification; the converted DSL script is executed according to the cucumber specification to complete the testing of the restful API. The method can express the service rule of the restful API test into a graphical block according to the DSL statement and the blocky specification, and the API test can be conveniently, intuitively and simply carried out.

Description

Method and apparatus for application program interface API testing

Technical Field

The present invention relates to the field of computer networks, and more particularly, to a method and apparatus for application program interface API testing.

Background

A Restful Application program interface (API for short) is a lightweight WEB service, and is widely applied to software design and implementation due to its simplicity and lightweight.

The widespread use of Restful APIs presents a number of potential problems, one of which is the testing of Restful APIs. The Restful API requires that the software be tested as a black box after the software is ready. For the test of a single Restful API, a unified and intuitive test scheme is lacked, and a scheme for testing a plurality of Restful APIs in series is provided.

Disclosure of Invention

The invention provides a method and equipment for testing an Application Program Interface (API), which can define a DSL statement concerning a service rule in the field of Restful API testing according to a cumumber specification and determine a graphical Block corresponding to the DSL statement according to a Blockly specification, thereby facilitating the testing of the Restful API by dragging the graphical Block and facilitating the uniform and intuitive testing of the Restful API.

In a first aspect, an embodiment of the present invention provides a data processing method for API testing, including: determining a field-specific language DSL statement concerning a service rule of a restful API test field according to a cucumber specification; and determining a graphical Block corresponding to the DSL statement according to Block specification, wherein the blocks are configured to be dragged in a preset editor and combined with each other.

In a second aspect, the embodiment of the present invention further provides a computer device, including a processor; and a memory for storing computer instructions adapted to be loaded by the processor to perform the method of the first aspect.

In a third aspect, the present invention also provides a computer readable medium, which stores computer readable instructions, the instructions being adapted to be loaded by a processor to execute the method according to the first aspect.

In a fourth aspect, an embodiment of the present invention further provides an application program interface API testing method, including: receiving a dragging request of a user for a graphical Block Blcok tested by an application program interface API, wherein the Block Block corresponds to a statement segment of a DSL (digital subscriber line) of a field-specific language;

converting the graphical block corresponding to the dragging request into a DSL script according to a Blockly specification; the converted DSL script is executed according to the cucumber specification to complete the testing of the restful API.

In a fifth aspect, an embodiment of the present invention further provides a computer device, including a processor; and a memory for storing computer instructions adapted to be loaded by the processor to perform the method of the fourth aspect described above.

In a sixth aspect, the present invention also provides a computer readable medium, which stores computer readable instructions, the instructions being adapted to be loaded by a processor to execute the method of the fourth aspect.

In a seventh aspect, an embodiment of the present invention further provides an application program interface API testing method, including: providing a graphical Block for application program interface API testing; receiving a dragging request of a user for the graphical Block Blcok, wherein the Block Block corresponds to a statement segment of a domain-specific language DSL; converting the graphical block corresponding to the dragging request into a DSL script according to a Blockly specification; the converted DSL script is executed according to the cucumber specification to complete the testing of the restful API.

In an eighth aspect, an embodiment of the present invention further provides a computer device, including a processor; and a memory for storing computer instructions adapted to be loaded by the processor to perform the method of the seventh aspect described above.

In a ninth aspect, the present invention also provides a computer readable medium, which stores computer readable instructions, the instructions being adapted to be loaded by a processor to execute the method of the seventh aspect.

Drawings

Fig. 1 is a flowchart illustrating a processing method for API testing according to an embodiment of the present invention.

FIG. 2 is a schematic diagram of a patterned block according to an embodiment of the invention.

Fig. 3 is a flowchart illustrating an API testing method according to an embodiment of the present invention.

FIG. 4 is a flowchart illustrating an API testing method according to an embodiment of the present invention.

Fig. 5 is a schematic structural diagram of a computer device according to an embodiment of the present invention.

Detailed Description

The invention will now be described in detail with reference to exemplary embodiments thereof, some of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings, in which like numerals refer to the same or similar elements throughout the different views unless otherwise specified. The aspects described in the following exemplary embodiments do not represent all aspects of the present invention. Rather, these aspects are merely examples of systems and methods according to various aspects of the present invention as recited in the appended claims.

In the following, terms to be used in the present application will be briefly explained and explained, and it should be noted that the explanation or explanation is only for the convenience of understanding the scheme of the present invention and should not be construed as a limitation of the terms, the meanings of which are still within the meanings commonly understood in the art.

The Restful API, may refer to an application or software design having a Rest style. Where, Rest, collectively referred to as a Representational State Transfer, describes an architectural style network system, such as a web application. REST may refer to a set of architectural constraints and principles, and an application or design that satisfies these constraints and principles may be considered Restful.

Cucumber is an automated testing tool capable of understanding Behavior Driven Development (BDD) support of test cases described in a common language, is written in Ruby, and supports various Development languages such as Java and Net.

DSL, known as Domain specific language, has the basic idea of "do not require all" and, unlike general purpose languages, the target scope can cover all software problems but is a computer language specific to a particular Domain.

Referring to fig. 1, fig. 1 is a flowchart illustrating a processing method for API testing, which may be used to design test software for API testing according to an embodiment of the present invention.

The processing method 100 may include: step 110 and step 120. These steps will be described below with reference to specific examples.

And step 110, determining a field-specific language DSL statement segment concerning the business rule of the restful API test field according to the cuumber specification.

As mentioned above, DSL is a domain-specific computer language. Programming the restful API over DSL requires first determining the business rules for that particular domain. For Restful API, it is based on hypertext Transfer Protocol (HTTP).

In some embodiments, the business rules of the restful API test domain may include business rules tested against a single restful API. The business rules tested for a single restful API, in particular, may include multiple aspects, one of which may be focused on by a corresponding one of the DSL statement segments. In some embodiments, the DSL statement segment may be an Action line of a DSL script, a line beginning with an Action leader such as given, where, and then.

The business rules tested for a single restful API may include a combination of two or more of the following: specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested; specifying a uniform resource locator, URL, of the HTTP request; specifying parameters of the request; specifying a request load; specifying request header information; verifying a response code of the HTTP request after the restful API is called; verifying a response header of the HTTP request after the restful API is called; the response load of the HTTP request after the restful API is called is checked. It should be noted that the business rules in the field of restful API test are not limited to the above aspects, and other business rules may be determined according to the needs of the specific test. For the test of a single restful api, it is necessary to ensure that the tested data meets the predetermined requirement, otherwise, the corresponding data may not be found during the test query.

The restful API is built on the basis of the HTTP protocol and comprises two parts, namely a request part and a response part according to the specification of the HTTP.

For an HTTP request, it must be specified:

a request method, such as GET/POST/PUT/or other extension methods;

the URL of the request is a globally uniform resource identifier applied to the resource request to identify the location of the restful API, such as HTTP:// www.ebaocloud.com/API/mock;

the header of the request is essentially a key-value pair, in the HTTP specification, partial headers are predefined, but some headers can be defined by itself in the implementation process of the restful API, for example, token, and one request can support multiple headers;

the requested parameters, which are also key-value pairs in nature, may appear on the path, e.g., as

Defining two parameters in the path, wherein the value of the name parameter is foo, and the value of the version parameter is 1; for some request methods, the parameters will be encoded into the request payload (body);

the load of the request is stored in the body of the HTTP request, and the restful API is a text in the json form generally and represents service data.

For the response part, it generally includes:

a response code, usually a number, represents the response status of the request, such as 200 represents a response success, 404 represents a resource (url) not found, 500 represents a server internal error, etc.;

responding the head, like the head of the request, the essence is a key value pair, and the server side can place a plurality of response heads;

the response payload, in the responder body of the HTTP protocol, for restful API, text, generally in json form, represents the traffic data.

After the Restful API is called, the HTTP response code, response header and response payload need to be checked. That is, the server provides a restful API, and the client calls this restful API, and needs to check whether the result of the current call is in accordance with the expectation of the tester, for example, whether the response code is consistent, whether a specific response header exists or the value thereof is consistent with the expected value, whether the content in the response payload contains the concerned service data or is consistent with the expected value.

In still other embodiments, the business rules of the restful API test domain may include business rules tested against a plurality of associated restful APIs. The business rules tested against multiple associated restful APIs may include, in particular, the following aspects: specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested; specifying a uniform resource locator, URL, of the HTTP request; specifying parameters of the request; specifying a request load; specifying request header information; verifying a response code of the HTTP request after the restful API is called; verifying a response header of the HTTP request after the restful API is called; verifying the response load of the HTTP request after the restful API is called; acquiring partial data of a response body after the restful API is called; the partial data of the response body after the restful API is called is set for testing of the next restful API associated with the restful API. It should be noted that the business rules in the field of restful API test are not limited to the above aspects, and other business rules may be determined according to the needs of the specific test. The method for specifying the hypertext transfer protocol (HTTP) request of the restful Application Program Interface (API) to be tested, the Uniform Resource Locator (URL) of the request, the parameter of the request, the request load and the request header information are specified; the HTTP response code, the response header and the response load after the restful API is called are verified, which are similar to the above service rules for the single restful API test field and are not described herein again.

Obtaining a predetermined portion of data of the responder after the restful API is called and setting for testing of a next restful API associated with the restful API may include, in particular: after the restful API is called, acquiring a predetermined part of data (for example, data in a text form) in the response body, and determining whether the part of data meets a predetermined expected value; the portion of data in the responder is extracted and stored for testing of the next restful API associated with the current restful API test. For example, a test flow is defined to test the creation, query and deletion of users, corresponding to three restful APIs. By combining the API according to the test scenario to perform the test, the delete-create-query-delete-query test flow can be adopted, so that the test can be repeatedly executed, and the dependence on data preparation or other prerequisites of the test environment is less. Continuing with the above example, in this test flow, a user is created, the load of the response includes the id of the new user, and the query API is queried by using the id as a parameter, so we need to extract the user id from the response body of the created API, place the user id in the context of the test scenario (which may be referred to as a variable pool), and refer to this variable when the next API test (user query) is performed, so as to obtain the user id to be queried. Continuing with the above example, if the query after creation is successful, the creation is validated, and if the delete operation is successful, the user should not be detected by the subsequent query, thereby validating the delete operation.

And determining a DSL statement segment corresponding to the service rule tested by the restful API according to the cucumber specification, wherein the service rule can comprise a plurality of aspects, the service rule corresponds to a plurality of DSL statement segments, and one DSL statement segment focuses on one aspect of the service rule. In some embodiments, the DSL statement segment may be an Action line of a DSL script.

In some embodiments, the DSL statement segment focuses on a combination of the following (e.g., greater than or equal to 2) aspects of the business rule: specifying a method of a hypertext transfer protocol, HTTP, request; specifying a uniform resource locator, URL, of a hypertext transfer protocol, HTTP, request; specifying a name and a value of a hypertext transfer protocol (HTTP) request header; specifying the name and value of the parameters of the restful API request; specifying a request load for a hypertext transfer protocol, HTTP, request; checking a response code of the hypertext transfer protocol HTTP request; it is checked whether a response header of the hypertext transfer protocol HTTP request is present or matches the expected value.

In some other embodiments, the DSL statement segment focuses on the following aspects of the business rules: specifying a method of a hypertext transfer protocol, HTTP, request; specifying a uniform resource locator, URL, of a hypertext transfer protocol, HTTP, request; specifying a name and a value of a hypertext transfer protocol (HTTP) request header; specifying the name and value of the parameters of the restful API request; specifying a request load for a hypertext transfer protocol, HTTP, request; checking a response code of the hypertext transfer protocol HTTP request; checking whether a response header of a hypertext transfer protocol (HTTP) request exists or is matched with an expected value; checking whether partial data in a response body of the HTTP request meets a preset expected value; and extracting partial data in the response body and storing the partial data.

Aspects of DSL statement fragments and corresponding business rules are described below in a DSL-based test example.

Feature: Bose Api test

Defining a test flow, starting with Feature which is a keyword, wherein the name of the flow is Bose Api test, and the test flow tests deletion, creation and query of profile of the configuration center service.

Scenario: remove the profile shawn-test-001

A scene is defined, and the name of the scene is removed the profile shot-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

The DSL statement fragment is used for endowing two variables with default values, the default value of apiBase of the variable is http://172.25.12.166:7101, the default value of profile of the variable is shawn-test-001, when the DSL script is executed by a Cucumber engine, a global variable can be transmitted to the execution engine, and if a specific variable is not defined, the default value defined in the DSL is used.

When test post for ${apiBase}/configs/clear

The DSL statement fragment defines the url and http method names to be tested, where url is $ { apiBase }/configs/clear, $ { } represents the resolution into the variable pool. The http method is here post.

And param profile is ${profile}

And param application is public

And param label is snapshot

The DSL statement segment adds the requested parameter, wherein the parameter name is profile, the value is $ { profile }, and then the profile variable is obtained from the variable pool.

Then check response

The DSL statement segment initiates a request to the server side.

And response status is 200

The DSL statement fragment verifies that the response code is 200, i.e. successful, and if the response code is not 200, the test flow reports an error.

Scenario: add config to profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

When test post for ${apiBase}/configs/update

And param profile is ${profile}

And param application is public

And param label is snapshot

And param key is test

And param value is 1111

Then check response

And response status is 200

Defining a test scene, and adding configuration to the configuration center.

Scenario: get config of profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

And defining a test scene and acquiring the configuration added in the last process.

When test get for ${apiBase}/configs

And param profile is ${profile}

And param application is public

And param label is snapshot

Then check response

And response status is 200

And response json data.test is 1111

In the load of the verification response, the value corresponding to the path data.test of json is 1111. If not 1111, then the test will be at this step in error.

Scenario: clean the profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

When test post for ${apiBase}/configs/remove

And param profile is ${profile}

And param application is public

And param label is snapshot

And param key is test

Then check response

And response status is 200

And removing the data created by the scene and recovering the data of the test environment.

In some embodiments, determining a domain-specific language DSL statement segment for a business rule concerning the restful API test domain according to the cucumber specification comprises: according to the cucumber specification, a plurality of DSL statement segments corresponding to a plurality of aspects concerning the business rules of the restful API test field are determined, one aspect corresponds to one DSL statement segment, and the one DSL statement segment can be an Action line.

And step 120, determining a Block corresponding to the DSL statement segment according to a Block specification.

In some embodiments of the invention, determining a block to which a DSL statement corresponds according to the Blockly specification may comprise converting one DSL statement segment (e.g. one Action line) in the DSL statement into one block, one DSL statement segment corresponding to one block, according to the blocky specification. By dragging different blocks, DSL statement fragments corresponding to the different blocks can be obtained, the combined blocks can be sent to a cucumber tool for execution, and restful API testing can be simply and visually performed through dragging the blocks.

Furthermore, by focusing on the business rules of the plurality of related restful API test fields, the test of the plurality of restful APIs connected in series can be simply and intuitively performed.

And the Block corresponding to the DSL statement segment is a graphical Block and can be dragged on a canvas interface of a preset editor. Each tile has a visible text portion and an inputtable portion that describe the elements of the tile for dragging, and a contiguous arrangement of the tile up, down, left, and right.

As shown in fig. 2, in a predetermined editor, different blocks can be combined through the up-down, left-right connection setting of the blocks on a canvas interface, so that the graphical combination of the different blocks is completed, the testing of the restful API can be simply and intuitively completed without code writing, and the application difficulty of the restful API testing according to the DSL is reduced. Moreover, when the graphical block is dragged to the canvas interface, the inputtable part of the graphical block can be presented on the interactive interface of the canvas, and the input of a user is received, so that the flexibility of applying the graphical block to carry out restful API test is improved.

On the dragged interface, one Block Blcok may correspond to one instance of Block, e.g.,

Given variable apiBase with default http://172.25.12.166:7101

apart from the introductory word Given, the changed parts are inputtable parts, which are filled in by the user himself, who can fill in apiBase and http://172.25.12.166: 7101; the other part, actually the visible text part, is fixed and unchangeable and cannot be changed by the user, the main function is to let the user know the semantics of the Block, the visible text part does not need to correspond to the text of the DSL line, and the visible text part is only used for assisting the user in deblocking meaning.

Referring to fig. 3, fig. 3 is a flow chart illustrating an API testing method according to an embodiment of the present invention, where the method 300 may include: step 310, step 320 and step 330, which are described below with reference to specific examples.

Step S310, receiving a dragging request of a user to a graphical Block Blcok tested by an application program interface API, wherein the Block corresponds to a statement segment of a field-specific language DSL.

DSL is a domain specific language. In an embodiment of the invention, DSL is in the field of restful API testing.

In some embodiments of the present invention, the patterned block in step 310 may be a patterned block generated according to the method shown in FIG. 1. In some embodiments of the present invention, the patterned block in step 310 may be a patterned block generated according to a method other than the method shown in fig. 1.

In some embodiments of the invention, the business rules of the restful API test domain may include business rules tested on a single restful API. The business rules tested against a single restful API may include, in particular, the following aspects: specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested, a Uniform Resource Locator (URL) of the request, a request parameter, a request load, and request header information; the HTTP response code, response header and response payload after the restful API is called are checked. It should be noted that the business rules in the field of restful API test are not limited to the above aspects, and other business rules may be determined according to the needs of the specific test. For the test of a single restful API, it is required to ensure that the tested data meet the predetermined requirements, otherwise, the corresponding data may not be found during the test query.

For an HTTP request, it must be specified: the method of the request, the URL of the request, the header of the request, the parameters of the request and the load of the request.

The response part generally comprises a response code, a response header and a response load.

In still other embodiments, the business rules of the restful API test domain may include business rules tested against a plurality of associated restful APIs. The business rules tested against multiple associated restful APIs may include, in particular, the following aspects: specifying a method of a hypertext transfer protocol (HTTP) request of a restful Application Program Interface (API) to be tested, a Uniform Resource Locator (URL) of the request, parameters of the request, a request load and request header information; checking an HTTP response code, a response header and a response load after the restful API is called; predetermined messages for the responder after the restful API is called are obtained and set for testing of the next restful API associated with the restful API. It should be noted that the business rules in the field of restful API test are not limited to the above aspects, and other business rules may be determined according to the needs of the specific test. The method for specifying the hypertext transfer protocol (HTTP) request of the restful Application Program Interface (API) to be tested, the Uniform Resource Locator (URL) of the request, the parameter of the request, the request load and the request header information are specified; the HTTP response code, the response header and the response load after the restful API is called are verified, which are similar to the above service rules for the single restful API test field and are not described herein again.

The predetermined message of the responder after the restful API is called is obtained and set for testing of the next restful API associated with the restful API, which may specifically include: after the restful API is called, acquiring a predetermined part of text in a response body, and determining whether the part of text meets a predetermined expected value; the portion of text data in the response body is extracted and stored for testing of the next restful API associated with the current restful API test. For example, a test flow is defined to test the creation, query and deletion of users, corresponding to three restful APIs. By combining the API according to the test scenario to perform the test, the delete-create-query-delete-query test flow can be adopted, so that the test can be repeatedly executed, and the dependence on data preparation or other prerequisites of the test environment is less. Continuing with the above example, in this test flow, a user is created, the load of the response includes the id of the new user, and the query API is queried by using the id as a parameter, so we need to extract the user id from the response body of the created API, place the user id in the context of the test scenario (which may be referred to as a variable pool), and refer to this variable when the next API test (user query) is performed, so as to obtain the user id to be queried. Continuing with the above example, if the query after creation is successful, the creation is validated, and if the delete operation is successful, the user should not be detected by the subsequent query, thereby validating the delete operation.

In some embodiments, the business rules of the restful API test domain may include multiple aspects, one DSL statement segment focusing on one aspect of the business rules of the restful API test domain. In one specific example, the aspects are:

the aspects include:

specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested;

specifying a uniform resource locator, URL, of the HTTP request;

specifying parameters of the request;

specifying a request load;

specifying request header information;

verifying a response code of the HTTP request after the restful API is called;

verifying a response header of the HTTP request after the restful API is called;

verifying the response load of the HTTP request after the restful API is called;

acquiring partial data of a response body after the restful API is called;

the partial data of the response body after the restful API is called is set for testing of the next restful API associated with the restful API.

In some embodiments, step S310 may include: and receiving a dragging request for one or more graphical blocks for API test, wherein one graphical block corresponds to one DSL statement segment, and different blocks correspond to different DSL statement segments. In a specific embodiment, the DSL statement fragment is an Action line.

A graphical block editing interface may be as shown in fig. 2. On the left side of FIG. 2 is a toolbar, where the blocks comprising various graphics are included, and on the right side is a canvas interface. Receiving a user drag request for the graphical block of the API test may include receiving a user drag request for the graphical block of the API test at an interactive interface in a predetermined editor. When the graphical block is dragged into the canvas of the interactive interface, two pieces of data, namely layout description data of the block in the canvas of the interactive interface and DSL statement fragments corresponding to the block, are generated, wherein the layout description data can be used for reproducing the layout of the canvas and the graphical block, and the DSL statement fragments are DSL scripts corresponding to the graphical block. The DSL statement segment of the block may be obtained by translation function conversion according to a Blockly specification, that is, converting the graphical block corresponding to the drag request into a DSL script according to the Blockly specification includes: and converting the graphical block corresponding to the drag request into a DSL statement segment through a translation function according to the Blockly specification. The translation function is the tool that converts the graphical block into a DSL, the result of which is a syntactically compliant DSL line. When the graphical block is dragged on the canvas interface, an inputtable part is presented in a predetermined area of the graphical block, and input of a user is received.

Step 320, converting the graphical block corresponding to the drag request into a DSL script according to a blockaly specification.

In an embodiment of the invention, the graphical block comprises an inputtable part and a visible text part, and an up-down, left-right, and connected setting.

Converting the graphical block into a DSL statement according to the block specification may comprise: according to the block specification, calling an API (application programming interface) of the block to convert graphical blocks into DSL segments (for example, a line), translating one graphical block into a corresponding DSL segment through a translation function of the block, combining a plurality of graphical blocks through the up-down left-right connection settings among the blocks to form a combination of a plurality of DSL statement segments, and obtaining a complete DSL script.

Each block may correspond to each line of a DSL scenario, for example

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

The DSL statements described above correspond to the same Block definition, but on a dragged interface, are two Block instances. Apart from the introductory word Given, the changed part is the inputtable part, which is filled in by the user himself, who may fill in apiBase and http://172.25.12.166:7101 or who may fill in profile and shawn-test-001; the other part is actually a visible text part, which is fixed and unchangeable and cannot be changed by the user, and the main function is to make the user know the semantics of the Block. The visible text portion need not correspond to the text of the DSL line, but the visible text is only used to assist the user in the meaning of deblocking.

When any graph is processed, the translation function of the block will be called to translate to a particular DSL statement segment. Wherein the result of the translation function is a correct, compliant DSL line. All Block blocks translate the DSL line correctly, and the complete DSL script is finally obtained.

In some embodiments, the drag request for the graphical block comprises a drag request for a plurality of graphical blocks, the method further comprising: and combining the plurality of graphical blocks corresponding to the dragging request according to the arrangement of the graphical blocks in up-down, left-right connection to obtain a plurality of DSL statement segments as DSL scripts.

Step 330, executing the converted DSL statement according to the cucumber specification to complete the test of the restful API.

The complete DSL script converted in step 320 can be executed according to the cucumber specification, thereby completing the graphical test of the restful API.

And the Block corresponding to the DSL statement segment is a graphical Block and can be dragged on a canvas interface of an editor. Each tile has a visible text portion and an inputtable portion that describe the fast elements for dragging, and a contiguous arrangement of top, bottom, left, and right of the tile. The graphical combination of different blocks can be completed through the arrangement of the up-down left-right connection of the blocks, the testing of restful API can be completed without code writing, the code writing based on DSL is assisted, and the technical difficulty of realizing related function processing by adopting DSL is reduced.

Referring to fig. 4, fig. 4 is a flow chart illustrating an API testing method according to an embodiment of the present invention, where the method 400 may include: step 410, step 420, step 430 and step 440, which are described below with reference to specific embodiments.

Step S410, providing a graphical Block for testing the application program interface API.

In some embodiments of the present invention, the graphical blocks provided for API testing in step 410 may be graphical blocks generated according to the method shown in FIG. 1. In still other embodiments, the graphical blocks provided in step 410 for API testing may be graphical blocks generated according to other methods.

In some embodiments of the present invention, step 410 may comprise: determining a field-specific language DSL statement segment concerning the service rule of the restful API test field according to the cucumber specification; and converting the DSL statement segment into a graphical Block according to Block specification. For the detailed description of these steps, reference may be made to the related description of fig. 1, which is not repeated herein.

In some embodiments of the present invention, step 410 may comprise: in a predetermined editor, the graphical blocks of the restful API test are deployed, for example, a generic version of the restful API test may be deployed, or a customized version of the restful API test containing specific graphical blocks may be deployed.

In some embodiments of the invention, the traffic rules in the field of restful API testing are focused on by DSL statement fragments, which may include multiple aspects, for example, greater than or equal to 2 aspects. One DSL statement fragment relates to one aspect of the business rules.

In some embodiments of the invention, determining the segment of the domain-specific language DSL statement concerning the business rule of the restful API test domain according to the cucumber specification comprises: and determining a plurality of DSL statement segments corresponding to a plurality of aspects concerning the service rule of the restful API test field according to the cucumber specification, wherein each aspect corresponds to one DSL statement segment.

In some embodiments of the invention, the DSL statement segment may be an Action line of a DSL. In the case that the DSL statement segment is an Action line of DSL, converting the DSL statement segment into a graphical Block according to the Blockly specification may include: the Action line of a DSL is converted into a graphical Block according to the Block ly specification.

In some embodiments of the invention, in the scenario of testing a single restful API, aspects of the business rules of the restful API testing domain may include a combination of two or more of the following: specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested; specifying a uniform resource locator, URL, of the HTTP request; specifying parameters of the request; specifying a request load; specifying request header information; verifying a response code of the HTTP request after the restful API is called; verifying a response header of the HTTP request after the restful API is called; the response load of the HTTP request after the restful API is called is checked. In some embodiments, the aspects of the restful API test domain's business rules are all the aspects listed above.

In some embodiments of the present invention, in scenarios where multiple successive restful APIs are tested, aspects of the business rules of the restful API testing domain include a combination of two or more of the following: specifying a method of a hypertext transfer protocol (HTTP) request of a restful API to be tested; specifying a uniform resource locator, URL, of the HTTP request; specifying parameters of the request; specifying a request load; specifying request header information; verifying a response code of the HTTP request after the restful API is called; verifying a response header of the HTTP request after the restful API is called; verifying the response load of the HTTP request after the restful API is called;

acquiring partial data of a response body after the restful API is called; the partial data of the response body after the restful API is called is set for testing of the next restful API associated with the restful API. In some embodiments of the present invention, the business rules for multiple successive restful API tests include all of the aspects listed above.

In some embodiments of the invention, the graphical block may include an inputtable portion and a visible text portion, as well as an up, down, left, right, and left set.

Step 420, receiving a drag request of the user to the graphical Block Blcok, where the Block corresponds to a statement fragment of the domain specific language DSL.

In some embodiments of the present invention, the step 420 of receiving a user drag request for the graphical block may include receiving a user drag request for the graphical block tested by the API at an interactive interface of a predetermined editor. Wherein the interactive interface of the predetermined editor may be the interactive interface as shown in fig. 2. The predetermined editor may include a plurality of graphical blocks, each of which may be subjected to a drag operation. In the interactive interface of the editor, there is an editing interface in which a graphical block can be dragged multiple times. In some embodiments, the combined graphical block may also be dragged in its entirety.

In some embodiments of the present invention, while performing step 420, the method may further include: when the graphical block is dragged into a canvas of an interactive interface of a predetermined editor, generating layout description data of the graphical block in the canvas of the interactive interface and a DSL statement segment corresponding to the graphical block. That is to say, when a graphical block is dragged in a canvas of an interactive interface, two pieces of data are generated simultaneously, one piece of data is layout description data for describing information such as the position of the graphical block in the canvas, and the other piece of data is a DSL statement segment for generating a corresponding DSL script.

As described above, the graphic block includes an inputtable portion and a visible text portion, and an arrangement of up, down, left, and right. In some embodiments of the invention, the method of the invention may further comprise: and when the graphical block is dragged on the canvas interface, presenting the inputtable part in a preset area of the graphical block and receiving the input of the user. In some embodiments of the present invention, the dragging request of the graphical block may include a dragging request of a plurality of graphical blocks, and in case of dragging the plurality of graphical blocks, the method of the present invention may include: and combining a plurality of graphical blocks corresponding to the dragging request according to the arrangement of the graphical blocks in a vertical and horizontal connection mode.

Step 430, converting the graphical block corresponding to the drag request into a DSL script according to a blockaly specification.

In some embodiments of the present invention, the step 430 of converting the graphical block corresponding to the drag request into the DSL script according to the blockaly specification may include: and converting the graphical block corresponding to the drag request into a DSL statement segment through a translation function according to a Blockly specification. In some embodiments, a patterned tile may include two or more patterned tiles. The graphical blocks are translated through corresponding translation functions respectively to obtain a plurality of DSL statement segments, and a DSL test script is formed.

Step 440, executing the converted DSL script according to the cucumber specification to complete the test of the restful API.

In some embodiments of the invention, the converted DSL script, for example, may comprise a plurality of DSL statement segments. In some embodiments, the converted DSL script may be a DSL script tested against one restful API, in other embodiments, the converted DSL script is a DSL script tested against a plurality of associated restful APIs. And executing the converted DSL script according to the cucumber specification to finish the test of one restful API or a plurality of related restful APIs.

According to the restful API testing method provided by the embodiment of the invention, the DSL statement segment concerned by the service rule of the restful API test is converted into the graphical block according to the Block specification, so that a user can drag the graphical block by using a preset editor for combination, and a DSL script is formed through a translation function for testing the restful API. The testing of the restful API can be completed through graphical dragging, the testing is simple and visual, a graphical auxiliary testing scheme of the DSL is formed, and the technical difficulty of realizing testing processing by adopting the DSL is reduced.

The embodiment of the invention also provides computer equipment. As shown in fig. 5, the computer device 500 may include a processor 521, an input/output (I/O) device 522, a memory 523, a database 524, and a display 525.

The processor 521 may be one or more known processing devices that can load computer instructions stored in the memory 523 for implementing the above-described methods to cause a computer apparatus to perform the above-described methods.

The I/O device 522 may be configured to allow data to be received and/or transmitted. I/O device 522 may include one or more digital and/or analog communication devices that allow computer device 500 to communicate with other machines and devices. Computer device 500 may also include one or more databases 524, or be communicatively coupled to one or more databases 524 via a network. For example, database 524 may be any suitable database suitable for performing the associated data processing of the methods described above.

The display 525 may include a display screen that may be used to display the output of the input/output device 522 as well as intermediate results in the processing of data.

The present invention also provides a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the above-described method for application program interface, API, testing.

Through the above description of the embodiments, those skilled in the art will clearly understand that the present invention can be implemented by combining software and a hardware platform. With this understanding in mind, all or part of the technical solutions of the present invention that contribute to the background art may be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, a smart phone, or a network device, etc.) to execute the methods according to the embodiments or some parts of the embodiments.

The terms and expressions used in the specification of the present invention have been set forth for illustrative purposes only and are not meant to be limiting. It will be appreciated by those skilled in the art that changes could be made to the details of the above-described embodiments without departing from the underlying principles thereof. The scope of the invention is, therefore, indicated by the appended claims, in which all terms are intended to be interpreted in their broadest reasonable sense unless otherwise indicated.

Claims

1. An API testing method is characterized by comprising the following steps:

receiving a dragging request of a user for a graphical Block Blcok tested by an application program interface API, wherein the Block Block corresponds to a statement segment of a DSL (digital subscriber line) of a field-specific language;

converting the graphical block corresponding to the dragging request into a DSL script according to a Blockly specification;

the converted DSL script is executed according to the cucumber specification to complete the testing of the restful API.

2. The method of claim 1, wherein the DSL statement segment is focused on business rules in the restful API test domain.

3. The method of claim 2, wherein the business rules include aspects, and wherein a segment of a DSL statement focuses on an aspect.

4. The method of claim 1, wherein receiving a drag request from a user for a graphical block Blcok of an application program interface API test comprises:

an interactive interface in a predetermined editor receives a user drag request for a graphical block of an API test.

5. The method of claim 4, further comprising:

when the graphical block is dragged into the canvas of the interactive interface, generating layout description data of the graphical block on the canvas of the interactive interface and a DSL statement segment corresponding to the graphical block.

6. The method of claim 1, wherein converting the graphical block corresponding to the drag request into a DSL script according to a Blockly specification comprises:

and converting the graphical block corresponding to the drag request into a DSL statement segment through a translation function according to a Blockly specification.

7. The method of claim 1, wherein the graphical block comprises an inputtable portion and a visible text portion, and an up-down, left-right, and side-by-side arrangement.

8. The method of claim 7, further comprising:

and when the graphical block is dragged on the canvas interface, presenting the inputtable part in a preset area of the graphical block and receiving the input of a user.

9. The method of claim 7, wherein the drag request for the graphical Block comprises a drag request for a plurality of graphical blocks, the method further comprising: and combining the plurality of graphical blocks corresponding to the dragging request according to the arrangement of the graphical blocks in a vertical and horizontal connection mode.

10. The method of claim 3, wherein the plurality of aspects comprise:

specifying a uniform resource locator, URL, of the HTTP request;

specifying parameters of the request;

specifying a request load;

specifying request header information;

verifying a response code of the HTTP request after the restful API is called;

acquiring partial data of a response body after the restful API is called;

11. A computer apparatus, comprising:

a processor; and

a memory for storing computer instructions adapted to be loaded by the processor to perform the method of any of claims 1 to 10.

12. A computer readable medium storing computer readable instructions adapted to be loaded by a processor to perform the method of any of claims 1 to 10.