WO2020088087A1

WO2020088087A1 - Method and device for testing application program interface (api)

Info

Publication number: WO2020088087A1
Application number: PCT/CN2019/103993
Authority: WO
Inventors: 杨波
Original assignee: 易保网络技术(上海)有限公司
Priority date: 2018-11-02
Filing date: 2019-09-02
Publication date: 2020-05-07
Also published as: CN111143189A

Abstract

Provided by the present invention are a method and device for testing an application program interface (API). The method comprises: determining, according to Cucumber specifications, a domain-specific language (DSL) statement that focuses on service rules in a RESTful API test field; and determining, according to Blockly specifications, graphical blocks corresponding to the DSL statement and being configured to be capable of being dragged and combined with each other in a predetermined editor. The described method can express service rules of the RESTful API test with graphical blocks according to the DSL statement and the Blockly specifications, which is convenient, intuitive and makes API testing simple.

Description

Method and equipment for application program interface API testing

Technical field

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

Background technique

Restful application program interface (API) is a lightweight WEB service. Due to its simplicity and light weight, it is widely used in software design and implementation.

The extensive use of Restful API brings some potential problems, Restful API testing is one of the problems. Restful API needs to test the software as a black box after the software is ready. For the testing of a single Restful API, there is a lack of a unified and intuitive test solution, not to mention the test of multiple Restful APIs in series.

Summary of the invention

The present invention provides a method and equipment for API test of an application program interface. A DSL statement that focuses on business rules in the field of Restful API testing can be defined according to the cucumber specification, and a graphical block corresponding to the DSL statement can be determined according to the Blockly specification. Therefore, it is convenient to test the restful API by dragging and dropping the graphical block, and it is convenient to conduct a unified and intuitive test of the Restful API.

In the first aspect, an embodiment of the present invention provides a data processing method for API testing of an application program interface, including: determining a domain-specific language DSL statement that focuses on business rules in the field of restful API testing according to the cucumber specification; A graphical block corresponding to a DSL sentence, wherein the block is configured to be draggable in a predetermined editor and combined with each other.

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

In a third aspect, an embodiment of the present invention further provides a computer-readable medium that stores computer-readable instructions that are suitable for being loaded by a processor to perform the method described in the first aspect above.

According to a fourth aspect, an embodiment of the present invention further provides an API test method, including: receiving a user's drag and drop request for a graphical block Blcok for API test, where the block corresponds to a domain-specific language DSL sentence fragments;

The graphical block corresponding to the drag request is converted into a DSL script according to the 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, the computer instructions are adapted to be loaded by the processor to perform the method described in the fourth aspect above .

According to a sixth aspect, an embodiment of the present invention further provides a computer-readable medium that stores computer-readable instructions that are suitable to be loaded by a processor to perform the method described in the fourth aspect above.

In a seventh aspect, an embodiment of the present invention further provides an API test method, including: providing a graphical block block for API testing; receiving a user's drag request for the graphical block Blcok , Where the Block corresponds to the sentence fragment of the domain-specific language DSL; the graphical block corresponding to the drag request is converted into a DSL script according to the Blockly specification; API testing.

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

In a ninth aspect, an embodiment of the present invention also provides a computer-readable medium that stores computer-readable instructions that are suitable for being loaded by a processor to perform the method described in the seventh aspect above.

BRIEF DESCRIPTION

FIG. 1 is a schematic flowchart of a processing method for an API test according to an embodiment of the present invention.

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

FIG. 3 shows a schematic flowchart of an application program interface API testing method according to an embodiment of the present invention.

4 is a schematic flowchart of an application program interface API testing method according to an embodiment of the present invention.

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, some of which are illustrated in the drawings. The following description is made with reference to the drawings, and unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The solutions described in the following exemplary embodiments do not represent all the solutions of the present invention. Rather, these solutions are merely examples of systems and methods of the various aspects of the invention referred to in the appended claims.

The following will briefly explain and explain the terms that will be used in this application. It should be noted that these explanations or explanations are only for the convenience of understanding the solution of the present invention, and should not be understood as limiting these terms. The meaning is still within the usual meaning in the art.

Restful API can refer to application or software design with Rest style. Among them, Rest, which is called Representational State Transfer, describes an architectural style network system, such as a web application. REST can refer to a set of architectural constraints and principles, and applications or designs that meet these constraints and principles can be considered Restful.

Cucumber is an automated testing tool that supports behavior-driven development (BDD) that can understand test cases described in common languages. It is written in Ruby and supports multiple development languages such as Java and .Net.

DSL, which is called Domain Specific Language, is a domain-specific language. Its basic idea is "request for speciality but not completeness". Unlike general-purpose languages, the target scope can cover all software problems, but it is a computer language specifically for a specific field.

Referring to FIG. 1, FIG. 1 is a schematic flowchart of a processing method for application program interface API testing according to an embodiment of the present invention. The processing method can be used to design test software for an application program interface API.

The processing method 100 may include

steps

110 and 120. Next, these steps will be described in conjunction with specific examples.

Step 110: Determine the domain-specific language DSL sentence segment that focuses on business rules in the field of restful API testing according to the cucumber specification.

As mentioned above, DSL is a computer language for a specific field. To implement the restful API through DSL, you first need to determine the business rules in this particular field. For Restful API, it is based on Hyper Text Transfer Protocol (Hyper Text Transfer Protocol, HTTP).

In some embodiments, business rules in the field of restful API testing may include business rules for testing a single restful API. The business rules for a single restful API test can specifically include multiple aspects, and one aspect can be focused on by a corresponding DSL sentence segment. In some embodiments, the DSL sentence segment may be an action line of the DSL script, a line beginning with action guide words such as given, when, and, then.

The business rules for a single restful API test may include a combination of the following two or more aspects: Specify the method of the HTTP request of the restful API to be tested; specify the URL of the uniform resource locator of the HTTP request; specify the parameters of the request; Specify the request load; specify the request header information; verify the response code of the HTTP request after the restful API is called; verify the response header of the HTTP request after the restful API is called; verify the response load of the HTTP request after the restful API is called . It should be noted that business rules in the field of restful API testing are not limited to the above-mentioned aspects, and other business rules can be determined according to the needs of specific tests. For a single restful API test, you need to ensure that the test data meets the predetermined requirements, otherwise the corresponding data may not be found during the test query.

The restful API is built on the basis of the HTTP protocol. According to the HTTP specification, it contains two parts, the request part and the response part.

For HTTP requests, you must specify:

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

The requested URL is a globally uniform resource identifier applied to resource requests and used to identify the location of restful APIs, such as HTTP://www.ebaocloud.com/api/mock;

The header of the request is essentially a key-value key-value pair. In the HTTP specification, some headers are predefined, but some headers can be defined during the implementation of the restful API. For example, token, a request can support multiple headers;

The parameters of the request are essentially key-value key-value pairs, which can appear on the path, such as HTTP://www.ebaocloud.com/api/mock? name = foo & version = 1, two parameters are defined in the above path, where 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 request body of the HTTP protocol. For restful APIs, it is generally text in the form of json, which represents business data.

For the response part, it generally includes:

The response code, usually a number, represents the response status of the request. For example, 200 represents the successful response, 404 represents the resource (url) was not found, and 500 represents the internal error of the server.

The response header, like the request header, is essentially a key-value pair, and the server-side implementation can place multiple response headers;

Response load, in the response body of the HTTP protocol, for restful APIs, it is generally text in the form of json, which represents business data.

After the Restful API is called, you need to verify the HTTP response code, response header and response payload. In other words, the server provides a restful API, and the client calls the restful API. It is necessary to check whether the result of the current call meets the tester's expectations, for example, whether the response code is consistent, whether a specific response header exists or whether its value is Consistent with the expected value, whether the content in the response load contains the business data of interest or consistent with the expected value.

In other embodiments, the business rules in the field of restful API testing may include business rules for testing multiple associated restful APIs. The business rules for multiple associated restful API tests may specifically include the following aspects: Specify the method of the hypertext transfer protocol HTTP request of the restful API to be tested; specify the uniform resource locator URL of the HTTP request; Specify the request parameters; specify the request payload; specify the request header information; verify the response code of the HTTP request after the restful API is called; verify the response header of the HTTP request after the restful API is called; verify the restful API after the call The response load of the HTTP request; obtaining partial data of the response body after the restful API is called; setting partial data of the response body after the restful API is called for testing of the next restful API associated with the restful API. It should be noted that business rules in the field of restful API testing are not limited to the above-mentioned aspects, and other business rules can be determined according to the needs of specific tests. Among them, specify the method of the HTTP request of the restful API to be tested, the URL of the requested uniform resource locator, the parameters of the request, the request load and the request header information; verify the HTTP response code and response after the restful API is called The header and response load are similar to the business rules used in the field of single restful API testing above, and will not be repeated here.

Obtain the predetermined part of the data of the response body after the restful API is called and set it for the test of the next restful API associated with the restful API. Specifically, it may include: after the restful API is called, get the response body The predetermined part of the data (for example, text data) to determine whether the part of the data meets the predetermined expected value; extract the part of the data in the response body and store it for the next restful API associated with this restful API test test. For example, define a test process to test user creation, query and deletion, corresponding to three restful APIs. According to the test scenario combination API for testing, you can use the delete-create-query-delete-query test process to ensure that it can be run repeatedly, so that it is less dependent on data preparation or other prerequisites of the test environment. Continuing the above example, in this test process, a user is created, and the id of the newly created user is included in the response load, and the query API uses the id as a parameter to query, therefore, we need to create a response from the API The user id is extracted from the body and placed in the context of the test scenario (which can be called a variable pool). When the next api test (user query), the variable is referenced to obtain the user id to be queried. Continuing the above example, if the query after creation is successful, it proves that the creation is effective, and if the delete operation is successful, the subsequent query should not find the user, thus proving that the delete operation is effective.

According to the cucumber specification, determine the DSL sentence fragments corresponding to the business rules of the restful API test, where the business rules may include multiple aspects, corresponding to multiple DSL sentence fragments, and one DSL sentence fragment focuses on one aspect of the business rules. In some embodiments, the DSL sentence fragment may be an Action line of the DSL script.

In some embodiments, the DSL sentence fragment focuses on the combination of the following multiple (eg, greater than or equal to 2) aspects of the business rules: specifying the method of the hypertext transfer protocol HTTP request; specifying the uniform resource locator of the hypertext transfer protocol HTTP request URL; specify the name and value of the HTTP request header of the hypertext transfer protocol; specify the name and value of the parameters of the restful API request; specify the request load of the HTTP request of the hypertext transfer protocol; verify the response code of the HTTP request of the hypertext transfer protocol; Verify that the response header of the HTTP request of the Hypertext Transfer Protocol exists or matches the expected value.

In other embodiments, the DSL sentence fragment focuses on the following aspects of the business rules: specifying the method of the hypertext transfer protocol HTTP request; specifying the uniform resource locator URL of the hypertext transfer protocol HTTP request; specifying the hypertext transfer protocol HTTP Request header name and value; specify the name and value of restful API request parameters; specify the request load of the hypertext transfer protocol HTTP request; verify the response code of the hypertext transfer protocol HTTP request; verify the hypertext transfer protocol HTTP request Whether the response header exists or matches the expected value; verify whether part of the data in the response body of the hypertext transfer protocol HTTP request meets the predetermined expected value; extract and store part of the data in the response body.

The following uses DSL-based test examples to illustrate aspects of DSL sentence fragments and corresponding business rules.

Feature: BoseApitest

Define the test process, starting with the Feature: keyword, and the process name is Bose Api test. This test process tests the deletion, creation, and query of the profile of the configuration center service.

Scenario: remove the profile shawn-test-001

A scene is defined, the name of the scene is remove the profile shawn-test-001

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

Given variable withwith default shawn-test-001

The DSL statement fragment is used to assign default values to two variables. The default value of the variable apiBase is http://172.25.12.166:7101, and the default value of the variable profile is shawn-test-001. When the DSL script is When the Cucumber engine executes, it can pass global variables to the execution engine. If no specific variables are defined, the default values defined in the DSL are used.

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

The DSL statement fragment defines the url and http method name to be tested, where url is $ {apiBase} / configs / clear, and $ {} means to resolve in the variable pool. The http method is post here.

And paramprofile is $ {profile}

And paramapplication is public

And param label is snapshot

The DSL statement fragment adds the requested parameters, where the parameter name is profile and the value is $ {profile}, that is, the profile variable is obtained from the variable pool.

Then check response

The DSL sentence fragment initiates a request to the server.

And response status is 200

The DSL sentence fragment verifies that the response code is 200, which means success. If the response code is not 200, the test process reports an error.

Scenario: add config to profile shawn-test-001

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

Given variable withwith default shawn-test-001

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

And paramprofile is $ {profile}

And paramapplication 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

Define test scenarios and add configurations to the configuration center.

Scenario: get config of profileshawn-test-001

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

Given variable withwith default shawn-test-001

Define test scenarios and obtain the configuration added in the previous procedure.

When tested for $ {apiBase} / configs

And paramprofile is $ {profile}

And paramapplication is public

And param label is snapshot

Then check response

And response status is 200

And response json data.test is 1111

In the payload of the verification response, the value of path.data.test in json is 1111. If it is not 1111, then the test will report an error at this step.

Scenario: clean the profile shawn-test-001

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

Given variable withwith default shawn-test-001

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

And paramprofile is $ {profile}

And paramapplication is public

And param label is snapshot

And param key is test

Then check response

And response status is 200

Remove the data created in the previous scenario and restore the data in the test environment.

In some embodiments, determining the domain-specific language DSL sentence fragments focusing on the business rules of the restful API testing field according to the cucumber specification includes: determining multiple DSL sentence fragments corresponding to various aspects of the business rules of the restful API testing field according to the cucumber specification One aspect corresponds to a DSL sentence fragment, and the one DSL sentence fragment may be an action line.

Step 120: Determine the block corresponding to the DSL sentence segment according to the Blockly specification.

In some embodiments of the present invention, determining the block corresponding to the DSL sentence according to the Blockly specification may include converting a DSL sentence fragment (for example, an Action line) in the DSL sentence into a block according to the Blockly specification, and a DSL sentence fragment corresponding to A block. By dragging and dropping different blocks, the DSL sentence fragments corresponding to the different blocks can be obtained, which can be handed over to the cucumber tool for execution after combination, and the restful API test can be performed simply and intuitively by dragging and dropping the blocks.

Moreover, by focusing on the business rules of multiple associated restful API testing areas, multiple serially connected restful API tests can be performed simply and intuitively.

The block corresponding to the DSL sentence fragment is a graphical block, which can be dragged and dropped on the canvas interface of the predetermined editor. Each block has a visible text portion and an inputable portion that describe the drag-and-drop element of the block, and settings in which the block is connected up, down, left, and right.

As shown in Figure 2, in a predetermined editor, different blocks can be combined through the connection of the upper, lower, left, and right of the block on the canvas interface, so as to complete the graphical combination of different blocks. No code writing is required. Complete restful API testing intuitively, reducing the difficulty of applying restful API testing based on DSL. Moreover, when the graphical block is dragged onto the canvas interface, its inputtable part can be presented on the interactive interface of the canvas to receive user input, which improves the flexibility of applying graphical blocks for restful API testing.

On the drag and drop interface, a block Blcok can correspond to an instance of Block, for example,

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

Except for the guide word Given, the changed part is an input part. These are filled out by the user. The user can fill in apiBase and http://172.25.12.166:7101; the other parts are actually visible text parts. This part is fixed. The change is something that the user cannot change. The main function is to let the user understand the semantics of the block. The visible text part does not need to correspond to the DSL line text. The visible text part is only used to assist the user to understand the meaning of the block.

Referring to FIG. 3, FIG. 3 shows a schematic flowchart of an application program interface API testing method according to an embodiment of the present invention. The method 300 may include

steps

310, 320, and 330. The above steps are described below in conjunction with specific examples.

Step S310: Receive a user's drag-and-drop request for the graphical block Blcok tested by the application program interface API, where the Block corresponds to a sentence fragment of the domain-specific language DSL.

DSL is a language for a specific field. In the embodiment of the present invention, DSL is aimed at the field of restful API testing.

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

In some embodiments of the present invention, business rules in the field of restful API testing may include business rules for testing a single restful API. The business rules for a single restful API test, specifically, can include the following aspects: Specify the method of the HTTP request of the restful API to be tested, the requested universal resource locator (Universal resource Locator, URL ), Request parameters, request payload and request header information; verify the HTTP response code, response header and response payload after the restful API is called. It should be noted that business rules in the field of restful API testing are not limited to the above-mentioned aspects, and other business rules can be determined according to the needs of specific tests. For a single restful API test, you need to ensure that the test data meets the predetermined requirements, otherwise the corresponding data may not be found during the test query.

For HTTP requests, you must specify: 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.

For the response part, generally include: response code, response header, response load.

After the Restful API is called, you need to verify the HTTP response code, response header and response payload. In other words, the server provides a restful API, and the client calls the restful API. It is necessary to check whether the result of the current call meets the tester's expectations, for example, whether the response code is consistent, whether a specific response header exists or whether its value is The expected value corresponds to whether the content in the response load contains the service data concerned or conforms to the expected value.

In other embodiments, the business rules in the field of restful API testing may include business rules for testing multiple associated restful APIs. The business rules for multiple associated restful API tests may specifically include the following aspects: the method of specifying the HTTP request of the restful API to be tested, the requested uniform resource locator URL, and the requested Parameters, request load and request header information; verify the HTTP response code, response header and response load after the restful API is called; get the predetermined message of the response body after the restful API is called and set it for association with the restful API The next restful API test. It should be noted that business rules in the field of restful API testing are not limited to the above-mentioned aspects, and other business rules can be determined according to the needs of specific tests. Among them, specify the method of the HTTP request of the restful API to be tested, the URL of the requested uniform resource locator, the parameters of the request, the request load and the request header information; verify the HTTP response code and response after the restful API is called The header and response load are similar to the business rules used in the field of single restful API testing above, and will not be repeated here.

Obtain the predetermined message of the response body after the restful API is called and set it for the test of the next restful API associated with the restful API. Specifically, it may include: after the restful API is called, obtain the information in the response body A predetermined partial text to determine whether the partial text meets a predetermined expected value; extract and store the partial text data in the response body for the next restful API test associated with this restful API test. For example, define a test process to test user creation, query and deletion, corresponding to three restful APIs. According to the test scenario combination API for testing, you can use the delete-create-query-delete-query test process to ensure that it can be run repeatedly, so that it is less dependent on data preparation or other prerequisites of the test environment. Continuing the above example, in this test process, a user is created, and the id of the newly created user is included in the response load, and the query API uses the id as a parameter to query, therefore, we need to create a response from the API The user id is extracted from the body and placed in the context of the test scenario (which can be called a variable pool). When the next api test (user query), the variable is referenced to obtain the user id to be queried. Continuing the above example, if the query after creation is successful, it proves that the creation is effective, and if the delete operation is successful, the subsequent query should not find the user, thus proving that the delete operation is effective.

In some embodiments, the business rules in the restful API testing field may include multiple aspects, and one DSL sentence segment focuses on one aspect of the business rules in the restful testing field. In a specific example, the multiple aspects are:

The multiple aspects include:

Specify the method of restful API hypertext transfer protocol HTTP request to be tested;

Specify the uniform resource locator URL for HTTP requests;

Specify the requested parameters;

Specify the request load;

Specify the request header information;

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

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

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

Get part of the response body data after the restful API is called;

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

In some embodiments, step S310 may include: receiving a drag request for one or more graphical blocks for API testing, where a graphical block corresponds to a DSL sentence segment, and different blocks correspond to different DSL sentences Fragment. In a specific embodiment, the DSL sentence fragment is an Action line.

A graphical block editing interface can be shown in Figure 2. The left side of Figure 2 is the toolbar, which includes blocks of various graphics, and the right side is the canvas interface. Receiving a user's drag-and-drop request for a graphical block of an API test may include an interactive interface in a predetermined editor, receiving a drag-and-drop request of a graphical block of a user's API test. When the graphical block is dragged into the canvas of the interactive interface, two pieces of data of the layout description data of the block in the canvas of the interactive interface and the corresponding DSL sentence fragments of the block will be generated, where the layout description data is available To reproduce the layout of the canvas and the graphical block, the DSL sentence fragment is the DSL script corresponding to the graphical block. The DSL sentence segment of the block can be converted by the translation function according to the Blockly specification, that is to say, converting the graphical block corresponding to the drag request into a DSL script according to the bockly specification includes: dragging and dropping the translation function according to the Blockly specification Request that the corresponding graphical block be converted into a DSL sentence fragment. The translation function is a tool that converts a graphical block into a DSL. The result of the translation function is a DSL line that meets the grammatical requirements. When dragging the graphical block on the canvas interface, an inputable part is presented in a predetermined area of the graphical block to receive user input.

Step 320: Convert the graphical block corresponding to the drag request into a DSL script according to the Blockly specification.

In an embodiment of the present invention, the graphical block includes an inputtable part and a visible text part, as well as settings for connecting up, down, left, and right.

Converting a graphical block into a DSL statement according to the blockly specification may include: according to the blockly specification, calling the block ’s API to convert the graphical block into a DSL fragment (for example, a line), a graphical block through the translation function of the block Translate into corresponding DSL fragments, multiple graphical blocks, and combine them through the connection settings of up, down, left, and right between these blocks to form a combination of multiple DSL sentence fragments to obtain a complete DSL script.

Each block can correspond to each line of the DSL script, for example

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

Given variable withwith default shawn-test-001

The above DSL statement corresponds to the definition of the same Block, but on the drag and drop interface, there are two Block instances. Except for the guide word Given, the changed part is an input part. These are filled out by the user. The user may fill in apiBase and http://172.25.12.166:7101 or the user fills in the profile and shawn-test-001; the other parts are actually It is the visible text part. This part is fixed and cannot be changed by the user. The main function is to let the user understand the semantics of the block. The visible text part does not need to correspond to the text on the DSL line. The visible text is only used to help users understand the meaning of the block.

When processing arbitrary graphics, the translation function of the block will be called to translate into specific DSL sentence fragments. Among them, the result of the translation function is a correct DSL line that meets the requirements. All the Block blocks have correctly translated the DSL line, then you will end up with a complete DSL script.

In some embodiments, the drag request of the graphical block includes a drag request for a plurality of graphical blocks, and the method further includes: multiple graphical blocks corresponding to the drag request, according to each The setting of the connection of up, down, left and right of the graphical block is combined to obtain multiple DSL sentence fragments as a DSL script.

Step 330, the converted DSL statement is executed according to the cucumber specification to complete the testing of the restful API.

The complete DSL script converted through step 320 can be executed according to the cucumber specification to complete the graphical testing of the restful API.

The block corresponding to the DSL sentence fragment is a graphical block, which can be dragged and dropped on the canvas interface of the editor. Each block has a visible text portion and an inputable portion that describe the fast drag-and-drop element, and settings for connecting the up, down, left, and right of the block. Through the setting of the connection of the upper, lower, left and right of the block, the graphical combination of each different block can be completed, and the restful API test can be completed without code writing, which assists the DSL-based code writing and reduces the technology of using DSL to implement related functions. Difficulty.

Referring to FIG. 4, FIG. 4 shows a schematic flowchart of an application program interface API testing method according to an embodiment of the present invention. The method 400 may include: step 410, step 420, step 430, and step 440, followed by a specific example The above steps will be explained.

Step S410: Provide a graphical block for application program interface API testing.

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

In some embodiments of the present invention, step 410 may include: determining a domain-specific language DSL sentence fragment that focuses on business rules in the restful API testing field according to the cucumber specification; and converting the DSL sentence fragment into a graphical block according to the Blockly specification . For specific descriptions of these steps, reference may be made to the related description of FIG. 1, and details are not repeated here.

In some embodiments of the present invention, step 410 may include: deploying a graphical block of restful API testing in a predetermined editor, for example, a generic version of the graphical block of restful API testing may also be deployed, and may also be deployed Restful API-tested graphical blocks that contain customized versions of specific graphical blocks.

In some embodiments of the present invention, business rules in the field of restful API testing are focused on through DSL sentence fragments, and the business rules may include multiple aspects, for example, greater than or equal to 2 aspects. A piece of DSL statement about an aspect of business rules.

In some embodiments of the present invention, determining the domain-specific language DSL sentence fragment focusing on the business rules of the restful API testing field according to the cucumber specification includes: DSL sentence fragments, each aspect corresponds to a DSL sentence fragment.

In some embodiments of the present invention, the DSL sentence segment may be a DSL Action line. In the case where the DSL sentence segment is a DSL action line, converting the DSL sentence segment into a graphical block according to the Blockly specification Block may include: converting a DSL action line into a graphical block according to the Blockly specification Block.

In some embodiments of the present invention, in a scenario where a single restful API is tested, multiple aspects of business rules in the field of restful API testing may include a combination of two or more of the following: Restful API Hypertext Transfer Protocol HTTP request method; specify the uniform resource locator URL of the HTTP request; specify the request parameters; specify the request load; specify the request header information; verify the response code of the HTTP request after the restful API is called; Check the response header of the HTTP request after the restful API is called; check the response load of the HTTP request after the restful API is called. In some embodiments, multiple aspects of business rules in the restful API testing field are all aspects listed above.

In some embodiments of the present invention, in a scenario where multiple consecutive restful APIs are tested, various aspects of business rules in the restful API testing field include a combination of the following two or more aspects: Specify to be tested The method of restful API hypertext transfer protocol HTTP request; specify the uniform resource locator URL of the HTTP request; specify the request parameters; specify the request load; specify the request header information; verify the response code of the HTTP request after the restful API is called ; Check the response header of the HTTP request after the restful API is called; check the response load of the HTTP request after the restful API is called; get the partial data of the response body after the restful API is called; set the response after the restful API is called Part of the data is used for the next restful API test associated with the restful API. In some embodiments of the invention, the business rules for multiple consecutive restful API tests include all aspects listed above.

In some embodiments of the present invention, the graphical block may include an inputtable part and a visible text part, as well as settings for connecting up, down, left, and right.

Step 420: Receive a user's drag-and-drop request to the graphical block Blcok, where the block block corresponds to a sentence fragment of a domain-specific language DSL.

In some embodiments of the present invention, the step 420 of receiving the user's drag request for the graphical block may include an interactive interface of a predetermined editor to receive the user's drag request for the API tested graphical block. The interactive interface of the predetermined editor may be the interactive interface shown in FIG. 2. The predetermined editor may include a plurality of graphical blocks, and each block may be dragged and dropped. 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 blocks can also be dragged as a whole.

In some embodiments of the present invention, while performing step 420, it may further include: when the graphical block is dragged to the canvas of the interactive interface of the predetermined editor, generating the graphical block in the interactive interface The layout description data in the canvas and the DSL sentence fragments corresponding to the graphical blocks. That is to say, when the graphical block is dragged on the canvas of the interactive interface, two pieces of data are generated at the same time, one piece of data is layout description data, which is used to describe the position of the graphical block in the canvas and other information, and the other The data is a DSL sentence fragment, which is used to generate the corresponding DSL script.

As mentioned above, the graphical block includes the inputtable part and the visible text part, as well as the settings for connecting up, down, left, and right. In some embodiments of the present invention, the method of the present invention may further include: when dragging the graphical block on the canvas interface, presenting the inputtable portion in a predetermined area of the graphical block to receive user input. In some embodiments of the present invention, the drag request of the graphical block may include a drag request for multiple graphical blocks. In the case of dragging multiple graphical blocks, the method of the present invention It may include: combining a plurality of graphical blocks corresponding to the drag request according to the setting of connecting up, down, left, and right of each graphical block.

Step 430: Convert the graphical block corresponding to the drag request into a DSL script according to the Blockly specification.

In some embodiments of the present invention, step 430 converting the graphical block corresponding to the drag request into a DSL script according to the Blockly specification may include: converting the graphical block corresponding to the drag request through a translation function according to the Blockly specification Blocks are converted into DSL sentence fragments. In some embodiments, the graphical blocks may include two or more graphical blocks. These graphical blocks are respectively translated by corresponding translation functions to obtain multiple DSL sentence fragments to form a DSL test script.

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

In some embodiments of the present invention, the converted DSL script, for example, may include multiple DSL sentence fragments. In some embodiments, the converted DSL script may be a DSL script for testing a restful API. In other embodiments, the converted DSL script is a DSL script for testing multiple associated restful APIs. Execute the converted DSL script according to the cucumber specification to complete the test of a restful API or multiple associated restful APIs.

The restful API testing method provided by the embodiment of the present invention converts the DSL sentence fragments concerned by the business rules of restful API testing into graphical blocks according to the Blockly specification, which is convenient for users to drag and drop the graphical blocks with a predetermined editor for combination and translation. The function forms a DSL script to test the restful API. The testing of restful APIs can be completed through graphical drag and drop, which is simple and intuitive, and forms a graphical auxiliary test solution for DSL, which reduces the technical difficulty of using DSL to implement test processing.

Embodiments of the present invention also provide a computer device. 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, which may load computer instructions stored in the memory 523 for implementing the above method to cause the computer device to perform the above method.

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. The computer device 500 may also include one or more databases 524, or be communicatively connected to the one or more databases 524 through a network. For example, the database 524 may be any suitable database suitable for the associated data processing of the method described above.

The display 525 may include a display screen, which may be used to display the output results of the input / output device 522 and intermediate results during data processing.

The present invention also provides a computer-readable storage medium on which computer instructions are stored. When the computer instructions are executed by a processor, the above-described method for application program interface API testing is implemented.

Through the description of the above embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software in combination with a hardware platform. Based on this understanding, all or part of the technical solutions of the present invention contributing to the background technology can be embodied in the form of software products, and the computer software products can be stored in storage media, such as ROM / RAM, magnetic disks, optical disks, etc. , Including several instructions to enable a computer device (which may be a personal computer, server, smart phone, or network device, etc.) to perform the methods described in various embodiments of the present invention or some parts of the embodiments.

The terms and expressions used in the description of the present invention are for illustration only and are not meant to be limiting. Those skilled in the art should understand that various details can be changed in the above embodiments without departing from the basic principles of the disclosed embodiments. Therefore, the scope of the present invention is determined only by the claims. In the claims, unless otherwise stated, all terms should be understood in the broadest reasonable sense.

Claims

A data processing method for application program interface API testing, which includes:

According to the cucumber specification, determine the domain specific language DSL sentence fragments that focus on the business rules of the restful API testing field;

The DSL sentence fragment is converted into a graphical block Block according to the Blockly specification, wherein the Block is configured to be draggable and combined with each other in a predetermined editor.
The method according to claim 1, wherein the block includes a visible text portion and an inputable portion for dragging elements, and a connection setting of up, down, left, and right.
The method according to claim 1, wherein the business rules in the restful API testing field include multiple aspects, one of which is concerned by the corresponding DSL sentence segment.
The method of claim 3, wherein the multiple aspects include a combination of the following two or more aspects:

Specify the method of restful API hypertext transfer protocol HTTP request to be tested;

Specify the uniform resource locator URL for HTTP requests;

Specify the requested parameters;

Specify the request load;

Specify the request header information;

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

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

Verify the response load of the HTTP request after the restful API is called.
The method according to claim 1, wherein the business rules in the field of Restful API testing include business rules of multiple associated Restful API tests, and the business rules of the plurality of associated restful API tests include:

Specify the method of restful API hypertext transfer protocol HTTP request to be tested;

Specify the uniform resource locator URL for HTTP requests;

Specify the requested parameters;

Specify the request load;

Specify the request header information;

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

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

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

Get part of the response body data after the restful API is called;

Set part of the data of the response body after the restful API is called for testing of the next restful API associated with the restful API.
The method according to claim 3, wherein the DSL sentence segment is a DSL Action line.
The method according to claim 3, characterized in that the domain-specific language DSL sentence segment determined according to the cucumber specification to focus on business rules in the field of restful API testing includes:

According to the cucumber specification, determine multiple DSL sentence fragments corresponding to multiple aspects of business rules in the field of restful API testing.
The method according to claim 6, wherein the determining of the graphical block corresponding to the DSL sentence segment according to the Blockly specification includes:

According to the Blockly specification, a DSL Action line is converted into a graphical block.
The method according to claim 2, wherein the graphical block is configured to be combined on the canvas interface of the predetermined editor according to the connection settings of the up, down, left, and right of the block.
The method according to claim 9, wherein the graphical block is configured to present the inputtable portion on the interactive interface when being dragged to the canvas interface and receive user input.
A computer device, including:

Processor; and

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