1. What is interface testing
Interface testing is a software testing method used to verify that the communication interfaces between different software components work as expected. In interface testing, the tester sends requests and checks the responses received to ensure that the interface works properly in different scenarios.
As far as tools are concerned, common testing tools include Jmeter, Postman, etc. However, such tools are often used for interface debugging, and are not ideal for automation and test integration. Therefore, there are interface test scripts, which can be supported by Java, Python, GO and other languages.
However, there is always a cost to learn a language, so various testing platforms have begun to appear one after another. Why do test platforms? That is to say, the interface testing tool is combined with the interface testing script, so that it is as simple as the interface debugging of the testing tool, and it can also better support scenario testing and continuous integration testing.
2. What are the elements of interface testing
Interface testing is nothing more than sending the request and verifying the response. The interface test we often do is mainly the HTTP protocol. For this type of interface, the request data mainly consists of: request method, request address, request header, and request parameters.
The request method is the common GET/POST/PUT/DELETE, etc., which can be maintained according to the interface document, but different request methods are defined.
As for the request address, when doing automated testing, it can be split into request domain name and request routing. Generally speaking, different environment domain names will change, but the routing is generally fixed, because we want to ensure an interface when doing test integration. The request can be executed in multiple environments, and the domain name will be proposed for management in the environment, and the domain name corresponding to each interface can usually be matched according to the value of the route. Of course, in the microservice architecture, we can also mark each interface as a microservice, and the domain name of the interface of the same microservice should be consistent in any environment. Therefore, in addition to matching through routes, we can also match through microservice identifiers, which I call domain name identifiers.
In addition, the most important point of interface testing is login verification, and there are usually four ways. The most common types of RestAPI are Session/Cookies and Token, OpenAPI is generally OAuth, and the oldest authentication is HTTP Basic Authorization. For Cookies and Tokens, we generally send them out by putting them in the request header. Sessions are generally saved as state managers. Usually, the HTTP package of the programming language will come with this method. What we need to do is nothing else. After logging in, save the Session. As for OAuth, it usually needs to be encrypted into a signature for verification. I will write a separate article later to introduce the specific use.
For request data, there are generally three ways, namely: query parameters, routing parameters, and request body. The query parameter is to convert the parameter into the form of name=value and place it after the request address, and separate multiple parameters with a ? sign and add an & character in the middle. Routing parameters often put the parameter value in the route, so the value of the route is often dynamic, and the number of routes is also uncertain. As for the request body, it is easier to understand. Generally, forms and json strings are commonly used. Of course, the old interface also has text format/XML format, etc. In addition, the interface for file upload will be a binary stream.
The most important point is that no matter what the business is, the interface test must have assertions, and the interface test cases without assertions are rogue. Therefore, another important element of the interface is to write assertions. There are many ways to assert. You can assert the response data of the interface, and the interface for adding, deleting, and modifying data can also assert the content of the database.
3. How to use an open source tool platform for interface automation testing
After understanding the basic principles of interface automation testing, we use an open source test platform to quickly implement a simple interface automation test case writing. Next, we will combine pictures and texts to introduce usage:
Step 1: Create an environment. As mentioned above, the environment is an indispensable part of the interface test case in order to be reused in multiple environments. After the environment is created, a domain name needs to be created in the environment. The domain name matching rules are introduced above, and can be matched through route matching and domain name identification.
new environment
Step 2: Create an interface. When we are doing automated testing, the interface needs to be maintained and managed separately, so that when the interface changes, only the interface at the interface management office needs to be maintained, and all use cases that refer to the interface can change accordingly , improve maintenance efficiency. Before creating an interface, we can first create the business module to which the interface belongs, which is also convenient for quickly finding the interface later.
The data that the interface needs to maintain is also very simple, that is, the four major request data mentioned above can complete the most basic interface information maintenance. Of course, for later memory, we'd better give the interface a name and a description. At the same time, if you want to use the domain name identifier, you can bind the interface with a microservice identifier.
new interface
Step 3: After completing the interface maintenance, you can start writing interface use cases. The interface use case is actually just another layer of shell on the interface. The main purpose of putting on this layer of shell is to verify the business logic. Maybe the verification of a business logic needs to execute multiple interfaces, and add multiple interfaces to the into a use case and you're done. If there is a dependency relationship between data between multiple interfaces, it can also be realized through the reference of some associated parameters, which I will introduce separately in a later article.
New use case
Step 4: After the interface is added, debug directly. Just select the previously maintained environment to execute. After successful debugging, maintain the basic information of the use case, such as giving the use case a name, writing a description, and clicking Save to complete the writing of an interface automation use case.
debug use case
4. Summary
Through the above steps, it is not difficult to see that after using the platform, the program of writing interface test scripts by code can be completely abandoned, and the level of convenience is not comparable to tools such as postman. The biggest advantage is that the use case saves the server, and we can arrange the use case to execute arbitrarily, so as to verify different requirements. As long as the use case data is properly designed, automated testing can be completed even if the product manager is changed to verify, and the use case is selected and executed directly.
Finally: In order to give back to the die-hard fans, I have compiled a complete software testing video learning tutorial for you. If you need it, you can get it for free【保证100%免费】
Software Testing Interview Documentation
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
