This article is reproduced from:
https://www.cnblogs.com/simple1025/p/11149838.html
Question: The idea of summarizing interface testing comes from the recruitment of last year. Every interview will ask some questions about interface testing. It can be said that "there are a thousand Hamlets in the eyes of a thousand readers", and every tester has them Different understandings of interface testing, because of the recruitment process at that stage last year, I have successively sorted out the main points of server interface testing and use case analysis, supplemented and archived, and I have this document, welcome Friends who read make suggestions.
For server interface testing, we generally start testing from functions, such as the verification of request and response parameters, the verification of business logic or business rules, and the verification of database operations. After the function is normal, safety-related inspections, performance tests, and a series of extended tests will be performed as needed, such as compatibility tests with historical versions, interface timeout verification, and design rationality verification. Use case design is also analyzed and designed from these aspects , The following mind map is a summary test focus direction:
The details are as follows:
For input
The input mainly refers to the input parameters of the interface. In our usual tests, we will first consider the normal input parameters and the abnormal input parameters. The abnormal conditions include: parameter abnormalities and data abnormalities. The use case design is equivalent Class division and boundary value analysis
A. Normal entry
Normal input parameters are well understood, that is, according to the input standard 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
B. Abnormal parameters
Parameter exceptions include: parameter is empty, more or less parameters, wrong parameters
C. Abnormal data
Data abnormality: data type error, non-null parameters are empty, length does not meet the design, data not in the dictionary range, illegal members, special or sensitive characters, abnormal parameter data with correlation, etc.
For processing logic
Before interface testing, R&D will generally provide interface design documents or business-related design drawings and flowcharts. For the processing logic of the business process, we can switch from the restriction conditions of the input parameters, the operation object of the event, and the state of the business
A. Analysis of restriction conditions
Numerical restrictions: dictionary, level, industry-related restrictions, amount restrictions, score restrictions, etc.
Status restrictions: valid|invalid, online|offline, blacked|washed white etc.
Relational restrictions: existence or non-existence, binding or unbinding, etc.
Limitations of permissions: administrators, ordinary users, etc.
B. Object analysis
Object analysis is mainly to operate on legal and illegal objects. For example, if a bank card user recharges the card, it may exist: User A uses a card other than user A to recharge; User A uses his own card to recharge, and the card has expired ; User A uses his card to recharge, the card is blacklisted or lost, etc.
C. Analysis of state transition
For example, for payment services, the first payment is successful, and the order will be refunded after the order is cancelled. If the payment is unsuccessful, the payment has failed. Is the switching between the statuses normal? When the normal business operation is not performed smoothly, how does the status display? Controllable, whether there is an abnormal state, how to deal with the empty state business, etc.
D. 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. They are executed in this order in order to wait for the expected result, then other branch actions that occur during the execution What will the program do
For example, in the Zebra parking risk control business, what should be done if the vehicle turns around and does not enter the high-speed business after entering the station?
For output
When considering exceptions, we usually think of normal situations and invalid situations, but they may not cover all error codes. The error codes returned by the interface definition can help us supplement this part of the use cases, such as network exceptions, invalid rules, and invalid Parameters, invalid business IDs, invalid tasks, server exceptions, etc., add the value of errorcode to design more use cases
This kind of design use case based on output can find out whether the front and back ends normally output results, whether the prompt is friendly, whether sensitive information appears, etc.
Database operation
A. Whether the database operation is frequent, whether it will take up a lot of CPU during the writing of the database, and whether the process is released after the writing of the database is completed
B. Whether the business data storage is normal, whether there is duplicate data storage, whether there are garbled characters; whether the log data storage is normal
C. Whether the data update is normal, especially the time field, and whether the time is in 24-hour format
D. Whether data deletion and backup are normal
safety
Whether sensitive information is encrypted (such as bank account number, password, transfer amount)
Performance related
A. Under what circumstances will the interface be concurrency, what is the concurrency scenario, and under what circumstances will concurrency cause problems
B. Maximum concurrency, response time, throughput, resource consumption
Interface timeout
The interface normally returns, so what if the interface does not return? Therefore, the processing after the interface timeout is also a part of the test that needs to be considered. If the timeout is not handled properly, it may cause the process to be blocked, or the interface return is received after the timeout, resulting in logical confusion
Compatibility analysis with historical version
Obsolete protocols or interfaces, and the code is not commented. Under certain circumstances, it may trigger the obsolete protocols or interfaces of historical versions, causing unexpected problems and losses after users use or call functions.
When the interfaces between different services in the same system call each other, is the new interface affected by the historical interface, especially the new and old interfaces both deal with a certain function, and whether there is a problem of business incompatibility?
This requires the tester to test a system for a long time, so you may think of this kind of scenario, you will clearly know when and which version was refactored, those interfaces were abandoned, those interfaces were added, and which scenarios would trigger history A certain rule of the interface
Reasonable interface design
Whether the interface fields are redundant, whether the interface returns the information expected by the caller, whether the interface definition meets the needs of all callers, whether the interface is convenient to call, whether the interface is extensible, whether the interface parameters are convenient to use, and whether the business rules of the interface are correct , The interface is the use of the entire service will have those effects
Author: simplesally Source: https: //www.cnblogs.com/simple1025/: This article belongs to the author and blog Park total, welcome to reprint and to make recommendations, but without the author's consent declared by this section must be retained, and obviously in the article page The location gives the original link, otherwise the right to pursue legal responsibility is reserved.