First, why do interface tests
Due to the increasing complexity of today’s system, the cost of the traditional test method increases sharply and the test efficiency drops sharply, so it is necessary to do interface test. At the same time, interface testing is relatively easy to realize automatic continuous integration, and relatively stable compared with UI automation, which can reduce the labor cost and time of manual regression testing, shorten the test cycle, and support the demand of back-end rapid release. Continuous interface integration is the source of low cost and high benefit. At present, many systems are separated from the front and back end architectures. From the perspective of security, only relying on the front end to limit has completely failed to meet the security requirements of the system (it is too easy to bypass the front), and the back end also needs to control, in this case, it needs to be verified from the interface level. It is also necessary to verify whether the information transmitted at the front and back ends and log printing is encrypted and transmitted, especially the privacy information of users, such as ID cards and bank cards.
The purpose of interface testing is to test interfaces, especially those external interfaces associated with the system. The test focuses on checking the process of data exchange, transmission and control management, including the number of processing. External interface testing is generally viewed as system testing.
How to do the interface test
Interfaces can be tested using the interface testing tool
Interface testing tools: APIPost, Jmeter, etc
Before you start doing interface testing, it is important to understand the classification of interfaces. The classification here is mainly HTTP request method classification. There are many kinds of classification below, the most common are GET/POST/PUT/DELETE four methods, the work interface is most GET and POST methods.
The meaning of interface test
1. Identify problems earlier
With the popularity of agile testing, we all know that testing should be carried out early in the project development cycle, because the earlier bugs are found, the lower the cost of fixing them.
However, functional testing can not be carried out until the system provides testable UI interface, and unit testing requires higher professional and labor costs, so interface testing is selected to intervene in the test earlier.
Interface testing can test the interface of a system before the functional interface is developed, thus finding problems earlier and fixing them at a lower cost.
2. Shorten the product cycle
The earlier intervention of interface testing can find and solve bugs earlier, thus reducing the number of bugs left for the later functional testing stage, and ultimately shortening the overall project lead time, which is conducive to the realization of agile testing.
3. Identify underlying problems
Some bugs in the system will be difficult to pass the UI layer function test, or the construction of test data and test conditions is very complex, but through the interface test can be more simple, more comprehensive coverage of the underlying code logic, so as to find some hidden bugs.
In particular, some abnormal, extreme cases can be easily verified by interface testing.
Design of interface test cases
First, define your starting point. Like all testing, interface testing starts with proving that the program you’re testing is wrong. With this starting point as the guide, your design behavior will try to develop in this direction, easier to find problems, there will be no deviation from the general direction.
Secondly, choose a good test object. For a system to do interface testing to choose a good test object is the key to interface testing. A system has countless interfaces. If each interface is tested separately, it will be a very painful thing. It is not only tedious and wasteful, but also any change of internal interface will lead to the unuse of our use cases. It is recommended to take the whole system as a whole and choose the outermost interface of the whole system for external use and interaction as your test object. The use case of this test object will be very robust and more efficient. In addition, according to the flow of data, these outermost interfaces can be divided into two categories: one is the interface of data into the system; One is the interface through which data flows out of the system. The interface that comes into the system is actually the interface for our use case to perform the call. These interfaces can be called by changing parameters to simulate external use; The outgoing interface is the real point of validation for our use case. Where the data flows out, what state it is in when it flows out, and what state the system is in are all things we should verify.
Then, validate the functionality of the complete test object: validate what the external interfaces provide to the external users using those interfaces, and what the external users really need. These two functions must be accurate and detailed, and the design of use cases should be strictly in accordance with the functional design of the test object.
Finally, when the starting points, objects, and functions are identified, you can actually design the use cases. The following details how to design a well-structured, readable, and permeable interface test case.
Interface test case design, like any other test case design, should be designed with the goal of finding bugs as much as possible. Use case design should include: main test function points, test environment, test data, actions performed, and expected results.
1) Interface test environment is divided into two types: one is the internal environment of the program; One is the context of the external interface that the program calls. There is a principle in use case design environment: design real and dangerous environment, do not ignore contingency environment. Reality means that when your use case is testing a function, it should think about what the internal and external environment is when this happens, and simulate the environment as accurately as possible by various means. Danger, that is, the probability of system failure in this environment is very high. When designing a use case environment, if both environments meet the requirements of your use case, it is recommended to choose the more dangerous environment. The so-called contingency, that is, the probability of such circumstances occurring is very small. Don’t dismiss this environment just because it’s rare, development is probably thinking the same way, and there’s a good chance there’s a problem lurking.
2) Interface test Test data is divided into interface parameter data and system data required for use case execution. Don’t be lazy in designing and preparing data for test cases. Good test data use case error checking function is fully developed. Interface parameter data should be analyzed for each parameter according to the actual function of the test interface, and logical combination and arrangement should be carried out in accordance with the business logic, without missing some boundary values and error point data. The system data and interface parameter data required for each use case execution should be as different as possible so that the use case can find problems more easily.
3) Test function points. If an interface has complex functions, it is recommended to divide the interface use cases structurally, so that the use cases will have better readability and maintainability. The interface partition principle divides the function points provided by the interface into appropriate granularity. Use cases of the same function point can be filled according to different test environments and different data.
4) Interface test case execution operation is very simple, is the call of the tested interface.
5) Verification of expected results, which is also a key step in interface use case design, should be thin and not redundant. By fine, the use case should detail the points that should be validated. Every use case should be validated. Just because the first few use cases have been validated doesn’t mean they are all correct. Avoid repeating the same validation in one use case and improve the efficiency of test cases.