Interface Test Basics

1. Classification of interfaces

External interface: Access to external Web pages, apps, etc., there is a specific method to call the data

Internal interface: Data calls between modules and modules, more debugging between research and development, no need to test participation

Interface is required for front-end and back-end interaction!

2. Classification of interface tests

WebService Interface Test

Do not need to spell the message, will give a WebService address, or WSDL file, directly in the soapui import, you can see the webservice inside all the interface, there are messages, directly fill in the parameters call, see return results can be. The test process is more like a functional test. At present, WebService interface test is seldom seen, mostly in traditional large enterprises, military, telecommunications and so on.

HTTP API Interface Test

Internet companies are common, using the path to distinguish between different methods, the request message multi-key-value form, the return message is mostly JSON string form, the most common two request methods are get and POST request.

Get request: Can be entered in the browser is a GET request
Post requests can only be postman with tools such as Restclient
Get request used to get data, POST request to send data

Post request, can be by stitching parameters, can also send messages directly, in the body inside the Add parameter

Interface Request Message Stitching
1) Url?param=value&param2=value
This is the simplest one, the question mark before the request URL, followed by the requested parameter name and parameter values, a number of parameters with & to connect
such as: https://api.douban.com/v2/book/search?q= Hu Weiwei
2) There is another way is that the entry is a JSON string, then you can not splice parameters, need to use tools to complete such as postman

3. Interface documentation

Interface documentation is the basis of the interface test, the interface test must be based on the interface document on the call address, request parameters, splicing the message, and then send the request, check the return results.

So the interface documentation should include:

1) interface description;

2) Request URL;

3) Request method (Get\post);

4) Request parameter, parameter type, request parameter description;

5) Return parameter description

4. Several aspects to consider when designing an interface use case

1) Pass sex verification;

2) parameter combination;
3) interface Security:
1, bypass the validation, modify the interface parameter value has not been verified
2, bypass the identity authorization, modify the interface information of the person has no permissions
3, whether the parameters are encrypted, such as the user name and password is not encrypted, encryption rules are easy to crack.
4, password security rules, the complexity of the password check
4) Exception verification: Must pass non-mandatory, parameter type, enter the length of the parameter.

Test interface use case templates, such as

Interface Test Basics