01 Generic project structure
02 What is an interface
Interface: A unified access method provided by the server program to the outside world, usually using the HTTP protocol, and executing different business logic through different urls, different request types (GET, POST), and different parameters.
Most of the client's business operations need to call the server interface to obtain some data, or trigger some business, and then the client will do different processing and display according to the data content after getting the data returned by the interface.
03 Why do interface testing
A. In the company, the client and the server are usually developed by different teams. During the project development process, the development progress of the client and the server is inconsistent. For example, the development of the server is completed first. Perform interface testing to ensure that the server logic and return data are correct, and then test the client. Or some testing departments specialize in testing server-side development teams, so their test objects are interfaces.
B. When testing certain services, it cannot be tested only through the front end, such as user registration. The front end restricts the user name to not be empty. However, some people may bypass the front end through tools and directly call the server interface. If the server does not do related work The logical judgment will cause data errors. Including whether key information is encrypted during interface data transmission. Therefore, it must be tested separately for the server interface.
C. After developing and testing, you can first run the server-side interface test through the tool to ensure that all the interface test cases pass, and quickly judge whether the server-side interface meets the expectations. Then test it through the UI interface. Otherwise, there are bugs in the interface, and there must be bugs in the front-end page.
04 Interface testing tools and processes
Common HTTP interface testing tools include Jmeter, Postman, SoupUI, etc. Jmeter is used more in the enterprise.
Jmeter is an open source, free interface testing tool, which can test the function and performance of the interface. Interface automation is also possible.
For the specific use of Jmeter, please refer to the document "Jmeter Interface Tool Practice"
picture
Interface test process:
Like ordinary web testing, it is also necessary to analyze requirements, write test cases, execute tests, submit bugs, regression tests, and submit test reports.
05 The focus of interface testing
1. Input
Input mainly refers to the input parameters of the interface. In our usual test, we will first consider the normal input parameters and the abnormal input parameters. The abnormal conditions include: parameter abnormality and data abnormality. The use case design is mostly equivalent. Class Partitioning and Boundary Value Analysis
normal input
The normal input parameters are well understood, that is, according to the input parameters of the interface design document, input the normal parameters, and the response will return normally according to the agreed conditions of the interface design document.
parameter exception
Parameter exceptions include: parameter is empty, more or less parameters, wrong parameters
Data exception
Data exception: data type error, non-null parameter is empty, length does not conform to the design, data out of range, illegal member, special character or sensitive character, abnormal parameter data with associated relationship, etc.
2. Business logic
Like UI-based functional testing, interface testing also needs to understand the business logic behind the interface. For the processing logic of the business process, we can consider from different dimensions such as the constraints of input parameters, the operation object of the event, and the state transition of the business.
Constraints Analysis
① Restrictions on numerical values: dictionaries, grades, industry-related restrictions, amount restrictions, score restrictions, etc.
② Status restrictions: valid | invalid, online | offline, blackout | whitewashing, etc.
③ Restrictions on relationship: existence or non-existence, binding or unbinding, etc.
④ Permission restrictions: administrators, ordinary users, etc.
object analysis
Object analysis mainly operates on legal and illegal objects. For example, when a bank card user recharges a card, there may be: User A recharges with a card other than User A; User A recharges with his own card, and the card has expired ; User A uses his own card to recharge, and the card is blacklisted or lost.
Analysis of state transitions
For example, in the payment business, if the payment is successful first, the order will be refunded after canceling the order. If the payment is unsuccessful again, the payment has failed. Is the switching between the states normal? Controllable, whether there is an abnormal state, how to deal with empty state business, etc.
Timing Analysis
In some complex activities, an activity is performed by a series of actions in a specified order. These actions form an action flow. Only by executing in this order in order to wait for the expected result, other branch actions that occur during the execution process. What will the program do?
3. Output
When considering exceptions, we usually think of normal cases and invalid cases, but not necessarily covering all error codes, and the error codes returned by the interface definition can help us supplement the use cases in this part, such as network exceptions, invalid rules, invalid parameters, invalid business IDs, invalid tasks, server exceptions, etc., adding the value of errorcode can design more use cases
This design use case based on output can find out whether the front-end and back-end output results normally, whether the prompt is friendly, whether there is sensitive information, etc.
4. Database operation
Whether the business data storage is normal, whether there is duplicate data storage, and whether there are garbled characters
Whether the data update is normal, especially the time field, whether the time is in 24-hour format
Whether the fields in the table are as expected
5. Security
Whether sensitive information is encrypted (such as username, bank account number, password, transfer amount)
6. Performance
The maximum number of concurrency the interface supports
How many transactions per second (TPS) the interface can handle
Average Response Time (RT) of the interface
Interface consumption of server resources (CPU, memory, network, disk)
7. Compatibility
The interface test does not need to consider the compatibility of the client, mainly the compatibility of the data. For example, whether the historical data of the old interface is compatible, and whether the old data can be processed normally with the new interface.
8. Others
Idempotency: that is, the result of one request or multiple requests initiated by the user for the same operation is consistent, and there will be no side effects due to multiple clicks.
Take the simplest example:
That is payment. The user pays after purchasing the product, and the payment is deducted successfully, but when the result is returned, the network is abnormal. At this time, the money has been deducted, and the user clicks the button again. At this time, the system should refuse the payment and prompt "Cannot repeat the payment". The equivalent of a second payment will have no effect. When doing interface testing, for some interfaces that have idempotency requirements, it is necessary to test for idempotency.
Usually, Jmeter can be used to continuously call the interface twice for payment, submission and other operations to test idempotency.