Before starting API interface testing, we need to clarify the meaning of interface testing:
Interface testing is the process of simulating the client to send request data to the server according to the interface list, and after obtaining the response data, check whether the response data meets expectations.
The whole process can be divided into three steps:
the first step: simulate the client sending a request to the server;
the second step: accept the data returned by the server;
the third step: check whether the returned data meets expectations.
It must be clear that the interface test is based on the interface list, the interface list is based on the API document, and the API document is based on the project requirements document and prototype diagram. After having the list of interfaces, the process of performing the above three steps in turn for each interface is the interface test.
So how is it implemented? Because the interface test is carried out in the process of program development, there is no complete program, so the test needs to use tools. Not only does it require tools to simulate the client sending a request to the server, it also requires tools to receive data from the server, and sometimes it also requires tools to verify whether the returned data meets expectations.
This has to mention the packet capture tools such as fiddler, postman, Jmeter and other tools commonly used in interface testing. But here I will recommend another open source API tool that is more in line with the needs of Chinese people - Postcat.
Next, I will use Postcat to demonstrate how to test the API interface:
In the test, we may pay attention to the status code, response body, and response time. Postcat will display all these data to you to judge whether the API is normal.
Before starting the test, we need to fill in the test data~, you can click the plus sign on the tab page to create a new test tab page.
You can also quickly launch a test on an API by clicking the lightning icon of the grouped API.
It is often faster to learn new knowledge by analogy with existing knowledge. Usually, we usually look at the API request information in the browser. What is the corresponding position of this information in Postcat? I believe you can quickly know how to test in Postcat through the comparison chart below:
the same color of the underline represents the same module
Request URL/Request Method/Request Header/Query Parameter
API Path may be filled with Query parameter, and Postcat will automatically synchronize it to the table of Query parameter.
First confirm your HTTP request body format , select the corresponding request body format and click the Test button.
You can see the corresponding API response information!
By clicking on the test history, you can also go back to all the API request information tested at that time, and quickly return to the test.
Tips: Since the software has been under maintenance, the screenshots of the current version may be slightly different from those in this article.
At present, this software has been updated to v0.3.0. In addition to the interface testing, interface documentation, interface management and Mock functions we often talk about, team collaboration and API sharing functions have been added. In addition they also support:
- Rich plug-in market, expandable
- Pre and post scripts
- Support viewing all test history
- Supports the Websocket protocol, and will support more mainstream protocols in the future
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!