01. Interface test principle
What we call interface testing is that the developer implements the interface, and he needs to verify whether the implementation of the interface is correct.
But this is a background function, and this development is also a background development. When he verifies the interface, he does not want the front-end personnel to intervene, because it will be troublesome for the front-end personnel to intervene.
Then he needs a tool to simulate the front-end interface. (The front end actually provides a window that allows users to input data and view results.)
02. Interface test implementation
In fact, when we do interface testing, it is still a mode of "input-processing-output".
The user inputs a string of data, and then let this interface or this background function process it, and then check whether the output result is consistent with the expectation.
This is actually what we call black box testing. It is also a conventional way of thinking for us to do testing.
The user enters a string of data, and then let the system process it, and then we check whether the result is consistent with the expectation.
Functional testing does this, and interface testing actually does it.
However, compared with functional testing, interface testing has an obvious difference, that is, the input is no longer an interface, but an HTTP-based request; the output is no longer an interface, but an HTTP-based request. the response to. So we need to enter our data and check our results through requests and responses respectively.
03. Interface test cases
In fact, interface testing and functional testing are very similar. How to do functional testing and how to do interface testing.
The three core parts of a functional test case are: input, operation steps, and expected results.
Interface test cases, in fact, are mainly these three parts. The test case design method usually referred to is to take various values of input items and then make combinations.
Take login as an example, the login function has a user name and a password, the user name, there are two cases of correct user name and wrong user name, and the password has two cases of correct password and wrong password. Usernames and passwords together create some combinations:
1) The username and password are correct;
2) The user name is correct and the password is wrong;
3) The user name is wrong and the password is correct;
4) The user name is wrong; the password is wrong;
When inputting, selecting different data combinations will generate different test scenarios, and each scenario needs to be executed once.
Functional testing is done in this way, but interface testing has no interface, so there is no way to input, what should I do?
There is something called a parameter in the interface test, and this parameter corresponds to the input item in the functional test.
Therefore, the interface test case is actually to divide the input parameters and then combine them to form an interface test case. After each set of test cases is executed, different results will definitely be obtained.
For example, if the user name and password are correct, the login is successful; if the user name or password is incorrect, the login fails. Then just think about how to apply parameter values and test results to the tool, and this problem will be solved.
04. Interface testing tool
There are many interface testing tools, such as soapUI, postman, jmeter, etc. Tools are really just tools.
To do interface testing, you must understand the interface testing process.
05. Interface testing process
1) Design operation steps
Requests, some requests are separate, and some requests are linked before and after multiple requests. In this case, we need to create an association. Then we need to understand the format, specification and how to make an association. SoapUI, postman, and jmeter are all related.
2) Design data use cases
Write the data case into an Excel document, and let the tool read Excel. There are several sets of data use cases in Excel, and they are executed several times. Loop execution (automation) allows each use case to be executed once, and each test scenario is also run.
3) Affirmations
That is to write the expected results into the tool in advance, so that the tool can automatically judge whether the result is correct. Different tools are called differently. It is called assertion in soapUI and Jmeter, and it is called tests in postman.
4) Execute and check the test results
Execution is simple, but understanding the protocol is required to analyze the test results. Only by knowing what was sent and what was returned can we know which link went wrong.
5) HTTP protocol
The HTTP protocol is very important. Once you understand the HTTP protocol, it is actually very easy to use the tool, just follow the above four steps. Why the HTTP protocol and not other protocols? Because 90% of the systems are based on the HTTP protocol.
The HTTP protocol includes requests and responses. The request is the user's input, and the response is the result. We find the parameters through the request, then input different parameter values, and then combine them into a request. As long as the request is legal, it can be sent and received by the server.
Therefore, first of all, we must be able to judge what is called a legal request. Then we need to understand the composition of HTTP protocol requests, request specifications, and know which request items we care about, which request items we must follow, and which items we can delete.
06. Interface test JMeter
In fact, any tool is fine, but jmeter has two advantages:
It is in Chinese, and the learning cost is low. Both postman and soapUI are in English.
jmeter can do both interface testing and performance testing.
07. Interface test packet capture
The packet capture tool recommends fiddler, which has two advantages:
1. Simple and easy to use
2. After fiddler captures the package, it can be directly exported as a jmeter script
Under normal circumstances, there are interface documents for interface testing, but if there is no interface document, how do we do interface testing? This requires packet capture. We can capture the request, but if we cannot capture the response, we can analyze what kind of results we should get based on the test data.
A common problem is that the input box on the page may have a length limit, such as a limit of ten characters, but there is no limit in the background, which can easily lead to some database exceptions, such Problems may not be found in functional tests, but interface tests can.
So in many cases, interface testing can be considered as a supplement to functional testing. It allows our testing to be deeper and more comprehensive.