1. What is an interface?
Interface: Mainly the part that interacts and interacts between sub-modules or subsystems.
The interface mentioned here is broad, the protocol between the client and the back-end service; the interface for communication between plug-ins; the interface between modules; the methods provided by a class can be understood as interfaces.
Interface test: refers to the test of the interface between modules or systems.
2. Bugs and problems often encountered in interface testing
(1) Improper handling of the incoming parameters, causing the program to crash;
(2) Type overflow, resulting in inconsistent data reading and writing;
(3) The object permissions have not been verified, Can access sensitive information of other users;
(4) Improper handling of the state, leading to confusion in logic;
(5) Incomplete logic verification, and exploiting loopholes to obtain illegitimate benefits.
3. Use case design ideas The use case design of
interface testing mainly considers three aspects of input and interface processing, and output:
(1) For input, it can be designed according to the parameter type;
(2) For interface processing, it can be designed according to logic;
(3) For output, analysis and design can be carried out based on the results.
3.0 Use Case Template
3.1 Design for Input
For an interface, input is an input parameter. Common parameter types are:
(1) Numerical type (int, long, float, double, etc.)
(2) String type
(3) Array or linked list
(4) Structure
structure (struct) is a combination of some elements, the actual elements It is also numeric, string, array or linked list.
The following describes in detail the use case design of three parameter types: numeric, string, array, or linked list.
3.1.1 Numerical
parameters Numerical parameters mainly consider the following aspects of design:
if the parameter specifies the value range, you need to consider the value range of the equivalence class, outside the value range, and the value boundary. If necessary, It may traverse the values in the range of values.
For example, the interface for checking permissions: TaskChecker.checkTask(int taskID) The value range of taskID is 1-35, then the design considers:
1-35范围内和范围外的值；
1-35的边界：0，1,35,36；
**类型的特殊值：-1,0
数据类型的边界值：int的最小值最大值；**
因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
Common problems and risks:
Improper handling of special values causes the program to exit abnormally; the
type boundary overflows the
value outside the value range does not return correct error information, etc.
3.1.2 String type
String type parameters mainly consider the length and content of the string :
for example, the interface DateUtil.getDayOfDDHH(String ddhh), which is the interface conversion setting alarm clock, can be considered
for use cases: the length is 4 digits, which is less than 4 digits. More than 4 digits;
boundary value: the maximum length of the String;
special value: empty character; the
type of string content can be considered: number, non-number;
special character.
**如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。**
Possible problems and risks: The
incoming non-specific type of program exits abnormally. The
ultra-long characters are not processed, resulting in abnormal storage and display.
Other sensitive characters that can be set by users
3.1.3 Array or linked list type
When the parameter type is an array or a linked list, use cases can be considered:
for example, the interface submitTask (int[] taskID) for batch submission of tasks, parameter use case design considerations:
normal value: 1-5 permissions, out of range: 6 permissions;
boundary value : The boundary value of 1-35, the request allows the maximum and minimum values;
special value: 0;
legal ID and illegal;
duplicate ID, etc.
Possible problems and risks: The
program exits abnormally when there are 0 items; the
result is abnormal if the duplicate items are not de-duplicated during processing.
3.2 For logic design If the
interface needs some logic processing, then the logic design use case can be analyzed from the following perspectives.
3.2.1 Analysis of constraint conditions
(1) Numerical restrictions: score restrictions, gold coin restrictions, level restrictions, etc.
For example: the exchange of Q coins requires points>50 to participate.
(2) Status restriction: login status, etc.
For example: To synchronize user information, you need to log in to your account first.
(3) Relationship restrictions: bound relationship, friendship relationship, etc.
For example, the anti-fraud function for family members can only query the incoming call information of bound family members.
(4) Permission restrictions: administrators, etc.
Constraint testing is often encountered in functional testing, and is more important in interface testing. Its significance is that when the user performs an operation, the restriction condition may have been performed at the front end of the operation, so the user cannot directly trigger the request for this interface. But in fact, if there are other means: for example, UI has bugs or the interface is directly called through technical means, then whether the interface is restricted for these conditions is particularly important.
For example, a common example: It takes 200 points to exchange 5Q coins, but I don’t have enough points, so the redemption button is gray and cannot be clicked:
Normal users can't operate it, but the exchange is actually an interface of the backend. If you bypass the restriction of the page buttons and directly call the backend interface to exchange? Can it be exchanged? Expectations are of course not convertible. Therefore, the numerical limit of integral needs to be tested for the interface, and it is very important.
Other constraints are similar:
time constraint: before 22:00;
numerical constraint: 200 points; limit of 5;
status constraint: log in to the mobile phone manager;
and other constraints are similar.
Common problems and risks:
Insufficient judgment of constraint conditions, leading users to obtain benefits through special means
3.2.2 Operation target analysis
Operation is usually targeted at the target, for example, the user binds a phone number, the phone number is the target of the operation, and the call charges and traffic of this phone number are also the target.
Object analysis is mainly to operate on legal and illegal objects. For example, the following use case:
User A inquires about the phone bill of P1:
User A inquires about the phone P1 traffic;
User A inquires about the phone P2 phone bill;
User A inquires about the phone P2 traffic.
In the background logic processing, if a phone has been bound, the phone bill and traffic can be queried from the background point of view. But on the user side, it should be the phone bound to A, so that A can inquire about the call charge of the phone. Therefore, testing of similar objects is also essential.
Common problems and risks:
Users can access other user information and sensitive information that are not within the authority, so as to use this information for benefits
3.2.3 State transition analysis
The logic under test can be abstracted into a state machine, and each state switches from one state to another according to the functional logic. If we disrupt this sequence and switch from one state to another state that is not in its next state, then the logic will be disrupted and logic problems will occur.
Changing from a certain state to a new state depends on the transition interface. For a conversion interface, the input state is determined, such as Fun23, this function can only convert state 2 to state 3, but not state 1 to state 3. Then the test points can be:
(1) When the state is state 2, call the interface Fun23(), and the state switches to state 3;
(2) When the state is 1, 3, etc., call the interface Fun23(), and the state cannot be switched.
For example, when doing a task, the task has three states: not received, received but not submitted, and completed.
Then it can be designed like this:
(1) Normal state switching: unclaimed state, after receiving the task, it becomes the received state; after receiving the task and submitting it, it becomes the completed state; after completion, you can receive the task again.
(2) Abnormal state switching: submit the task without receiving the task and meet the task conditions; receiving the task again when it has been received, etc.
Common problems and risks:
Special methods can be used to achieve an otherwise impossible state, thereby seeking benefits.
3.2.4 Time sequence analysis
In some complex activities, an activity is carried out by a series of actions in a specified order. These actions form an action flow. Only by executing in this order can the expected result be obtained.
In the normal process, these actions are carried out sequentially according to the program call, and will not be disrupted. In the interface test, it is necessary to consider whether there will be problems if the timing is not installed.
For example, client data synchronization is triggered by the client, during which the user cannot intervene in the synchronization. What can be seen during the functional test is whether the synchronization can be performed normally, and further analysis, the synchronization process actually involves a set of actions:
It can be seen from the sequence diagram that there are 3 interfaces in the background: login to obtain the user ID, report local data, and report local conflicts. The three interfaces need to be called and executed in sequence to complete synchronization. Then in the interface test, you can consider disrupting the execution sequence of the above interfaces to execute, what will be the result, and whether there will be an exception. For example: After obtaining the user ID, the local data is not reported but the local conflict is directly reported.
Common problems and risks: After
non-sequential execution, the data will be abnormal, and other abnormalities of the program may also appear.
Obtain benefits by disrupting the sequence
3.3 Designing for output Designing
for output is actually analyzing the results returned by the interface.
3.3.1 For the output result There
may be only one correct result of interface processing, but there are many cases and many values in the return result of error exception. If you know that there are many types of results, you can design use cases for different results. For example, when submitting an integral task, we usually think of returning correctness and error. Errors may think of: invalid task, invalid login status, but it may not be able to completely cover all error codes, and the interface returns the defined return code to design more Example:
Overriding the return code is also an idea of use case design.
Common problems and risks:
(1) Insufficient front-end processing of errors leads to front-end exceptions;
(2) Improper handling of error prompts causes users to see obscure error codes;
(3) Improper error prompts cause users to not know what went wrong, How to solve.
3.3.2 Interface timeout
Interface can return under normal circumstances, so what if the interface does not return? That is to say, 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 following problems:
(1) No timeout processing was performed, which caused the entire process to be blocked
(2) After the timeout, the interface returned was received, resulting in logic confusion
3.4 Other test design
3.4.1 Obsolete interface test
Obsolete protocol refers to the previous definition, but due to changes in requirements or other reasons, the current version is not used. Although these interfaces are no longer used, it is possible that the code was not deleted in time. If you use technical means to call these interfaces, you may get additional benefits.
For example, if there is a cleanup task before the task, replace the cleanup task with a download task in a version requirement. In the new version of the client, the interface for completing the cleanup task is no longer called; but if the interface is not closed, the user can continue to request the submitTask(int taskID) interface to complete the cleanup task to earn points.
Therefore, while considering compatibility with the old version, the new version should also check related obsolete interfaces to prevent users from gaining additional benefits.
3.4.2 Analysis of the rationality of interface design
Whether the interface definition is reasonable can be analyzed from the following aspects:
(1) Whether the interface fields are redundant;
(2) Whether the interface is redundant;
(3) Whether the interface returns the information expected by the caller ;
(4) whether the definition of the interface to meet the needs of all calls;
(5) whether the call convenient interface definition.
3.5 A complete example
The following is a complete example to analyze how to use the interface design through the above method.
A module provides an interface to other modules, and users request tasks. The interface is defined as follows:
4. Summary
In the interface use case design method, the design for input and output is universal, and both are available during interface design. For the design of interface logic, one or more suitable methods may be applied. When designing interface use cases, the most suitable method needs to be selected to cover the logic under test.