Author: Liu Yan

Team: Tencent Mobile Quality Center (TMQ)

Introduction:

With the development of test analysis and layered testing, “interface testing” appears more and more frequently. So what are the common methods of interface test use case design? This article will describe it in detail.

1 Interface Test

1.1 Interface Test

Interface: Mainly the part of a submodule or subsystem that interacts and interacts with each other.

The interface here is a broad, protocol between the client and the background service; Interface for communication between plug-ins; Interface between modules; As small as a method provided by a class; Both can be thought of as interfaces.

Interface test: is a pointer to a module or system interface test.

1.2 Typical problems found in interface tests

Common bugs and problems encountered in interface testing are as follows:

(1) Improper processing of incoming parameters leads to program crash;

(2) Type overflow, resulting in inconsistent data read and write;

(3) Because the object permission is not verified, sensitive information of other users can be accessed;

(4) Improper processing of the state, resulting in logic disorder;

(5) The logic check is not perfect, the use of loopholes to obtain improper interests, etc.

2 interface test case design


The figure above shows a typical interface. An interface usually has input and output. The input is the common input parameter, and the output sometimes has and sometimes does not. Invoke the related interface, which performs the related processing logic.

Interface test use case design, mainly from the input and interface processing two aspects:

1) For input, it can be designed according to parameter types;

2) For interface processing, use case design can be carried out according to logic;

3) For the output, analysis and design can be carried out according to the results.

2.1 Design for input


For an interface, the input is the input parameter. Common parameter types are as follows:

(1) Numeric (int,long,float,double, etc.)

(2) String type

(3) Arrays or linked lists

(4) Structure


A struct is a combination of elements that are actually numeric, string, array, or linked list.

The following details the use case design of three parameter types: numeric, string, array or linked list.

2.1.1 numeric

The design of numerical parameters mainly considers the following aspects:


If the parameter specifies the value range, consider the value boundary within and outside the value range of the equivalence class. If necessary, each value within the value range may be traversed.

Taskchecker. checkTask(int taskID) The value of taskID ranges from 1 to 35.

  • Values within and outside the range of 1-35;
  • Boundaries from 1 to 35:0,1,35,36;
  • The special value of type: -1,0
  • Boundary values of data types: the minimum value of int the maximum value;
  • Because the 1-35 code has a different permission ID, you may need to iterate through each value of 1-35.

Faqs and Risks:

  • Improper handling of special values leads to abnormal exit of the program;
  • Type boundary overflow
  • Error information is not returned for values outside the value range

2.1.2 A string

String arguments, which take into account the length and content of the string:


For example, dateutil.getDayOFdDHh (String DDHH) is used to set the alarm clock interface.

  • The length is 4 bits, less than 4 bits, more than 4 bits;
  • Boundary value: the maximum length of String;
  • Special values: null characters;
  • Type of string content to consider: numeric, non-numeric;
  • Special characters.
  • If the content is input by the user and visible to other users, you need to consider whether sensitive words are normally filtered.

Possible problems and risks:

  • An incoming nonspecific program exits unexpectedly
  • Excessively long characters are not processed, which leads to storage and display exceptions
  • Sensitive words that are visible to other users

2.1.3 Array or linked list types

When the parameter type is array or linked list, the use case can be considered:


For example, the interface submitTask(int[] taskID) for batch submission of tasks, parameter use case design considers:

  • Normal value: 1 to 5 rights. Out of the range: 6 rights.
  • Boundary value: the boundary value between 1 and 35, the maximum and minimum value allowed by the request;
  • Special value: 0;
  • Valid ID and illegal ID;
  • Duplicate ids, etc.

Possible problems and risks:

  • When 0 items, the program abnormally exits;
  • The duplicate item is not duplicated during processing, resulting in abnormal results, etc.

2.2 Design for logic


Interfaces need some logical processing, so the use case of logical design can be analyzed from the following perspectives.

2.2.1 Analysis of constraints

(1) Numerical limits: score limits, gold limits, level limits, etc.

For example: The q-coin exchange activity requires more than 50 points to participate.

(2) State restriction: login state, etc.

For example, you need to log in to the system before synchronizing user information.

(3) Relationship restriction: binding relationship, friend relationship, etc.

For example, the help family anti-fraud function queries only incoming calls of bound family members.

(4) Permission restrictions: administrators, etc.

Testing of constraints is often encountered in functional testing, but is even more important in interface testing. Its significance lies in that when a user performs an operation, constraint conditions can already be imposed on the front end of the operation. Therefore, the user cannot directly trigger the request to the interface. In practice, however, if there are other means, such as a bug in the UI or a direct call to the interface through technical means, then it is important that the interface is restricted against these conditions.

For example, it takes 200 points to exchange 5Q coins, but I don’t have enough points, so the exchange button is gray and cannot be clicked:


Normal users cannot operate it, but exchange is actually an interface in the background. What if we bypass the restriction of the page button and directly call the background interface exchange? Is it exchangeable? Expectations, of course, are not convertible. This numerical limit of integration is therefore important to test against the interface.

Other constraints are similar:

  • Time constraint: before 22:00;
  • Numerical constraint: integral 200; Limited to 5;
  • Status constraints: Log in to the mobile phone manager;
  • And so on, the constraints are similar.

Common problems and Risks:

  • Lack of judgment of constraint conditions leads to users can obtain benefits through special means

2.2.2 Operation Object Analysis

An operation is usually performed on an object. For example, a user is bound to a phone number. The phone number is the operation object, and the call fee and traffic of the phone number are also objects.


Object analysis is to perform operations on legitimate and illegitimate objects. For example:

  • User A queries the phone number P1.
  • User A queries the traffic of phone P1.
  • User A queries the call fee of phone P2.
  • User A queries the traffic of phone P2.

Background logic processing: If a call has been bound, the call charges and traffic of the call can be queried from the background. However, on the user side, user A can query the call fee of the phone that is bound to user A. Therefore, testing similar objects is also essential.

Common problems and Risks:

  • Users can access other user information and sensitive information that is not within their authority, so as to make use of this information to seek profits.

2.2.3 Status transition Analysis

The logic under test can be abstracted into a state machine, and each state can switch from one state to another state according to the functional logic. If we disrupt this order, switching from one state to another that is not in its next set of states, the logic will be scrambled and logic problems will occur.


As shown in the figure above, changing from a state to a new state depends on the transition interface. For a transition interface whose input state is deterministic, such as Fun23, this function can only convert state 2 to state 3, but not state 1 to state 3. Then the test point could be:

(1) When the state is state 2, the interface Fun23 () is called and the state changes to state 23;

(2) if the state is 1,3, etc., interface Fun23 () is called, and the state cannot be switched.

For example, when doing a task, the task has three states: unclaimed, received and unsubmitted, and completed in three states.


Then it can be designed like this:

(1) Normal state switching: unclaimed state, changed to received state after receiving the task; Received meets the task conditions after submission, becomes the completed state; The task can be picked up again after completion.

(2) Abnormal state switching: the task is submitted directly without receiving the task and meeting the task conditions; Reclaiming tasks when already claimed, etc.

Common problems and Risks:

Can achieve the original cannot through special means of the state, so as to seek profits.

2.2.4 Time series analysis

In some complex activities, an activity is a series of actions carried out in a specified order. These actions form a flow of actions, and only by executing them in this order can the expected result be achieved.

In normal flow, these actions are performed sequentially and without disruption according to program calls, and during interface testing, you need to consider whether there is a problem if sequential execution is not installed.

For example, client data synchronization is triggered by the client and cannot be interfered by the user. When functional testing is done, we can see that the synchronization process actually involves a set of actions:


It can be seen from the sequence diagram that there are three interfaces in the background: login to obtain user ID, report local data, and report local conflict. The three interfaces need to be invoked in sequence to complete synchronization. Then in the interface test, we can consider disrupting the order of execution of the above interface to execute, what kind of result will happen, whether there will be exceptions. For example, local conflict is reported instead of local data after the user ID is obtained.

Common problems and Risks:

  • After non-sequential execution, data is abnormal and other program exceptions may occur
  • Gain by disordering

2.3 Design for output


Design for output is really about analyzing the results returned by the interface.

2.3.1 For the output results

The interface may handle only one result correctly, but the error exception returns many cases with many values. If you know that there are many different results returned, you can design use cases for different results. For example, when we submit integral task, we usually think of returning correct and error. Error may think of invalid task and invalid login state, but it may not be able to completely cover all error codes, and the return code defined by the interface return can be designed in more cases:


Overwriting return codes is also an idea in use case design.

Faqs and Risks:

(1) Insufficient front-end processing of errors, resulting in front-end abnormalities;

(2) Improper handling of error prompts, resulting in obscure error codes;

(3) Improper error prompt leads to users not knowing where the problem is and how to solve it.

2.3.2 The interface timed out

An interface normally returns something, but what if it doesn’t? That is to say, the handling of the interface timeout is also a part of the test to be considered. If the timeout is not handled properly, the following problems may occur:

(1) The whole process is blocked due to the failure of timeout processing

(2) The interface returns after timeout, resulting in logic disorder

2.4 Other test designs

2.4.1 Obsolete Interface Test

A protocol that has been defined before is not used in the current version due to requirements change or other reasons. These interfaces are no longer used, but it is possible that the code was not removed in time. Additional benefits may be obtained if these interfaces are invoked by technical means.

For example, if a task is preceded by a cleanup task, replace the cleanup task with a download task in a release requirement. In the new version, the client no longer calls the interface that completes the cleaning task. However, if the interface is not closed, the user can continue to request the submitTask(int taskID) interface to complete the cleanup task for credits.

Therefore, when the new version is compatible with the old version, it is necessary to check relevant abandoned interfaces to avoid additional benefits for users.

2.4.2 Analysis of rationality of interface design

Whether the interface definition is reasonable can be analyzed from the following aspects:

(1) Whether the interface field is redundant;

(2) Whether the interface is redundant;

(3) whether the interface returns the information expected by the caller;

(4) Whether the interface definition can meet all call requirements;

(5) Whether the interface definition is convenient to call.

2.5 A complete example

Here is a complete example of how to design use cases for interfaces using the above approach.

A module provides an interface to other modules for users to request tasks. The interface is defined as follows:


2.5.1 Design for input

DialogDetailText (dialogButtonText is similar)

The length of the

1) Normal: Please operate as prompted;

2) Boundary: one word: please; Very long: there is no suspension window permission, which may affect XX function cannot be used. Please start suspension window permission, so as to obtain better user experience; Even longer;

3) Special: empty string.

content

1) Specific types: Chinese, English, numbers, etc.

2) Special characters: /n/r/t,.><? * $& ^ % ~ “ஜ ღ ℡ ♬ euro ✎, etc.;

3) Sensitive characters: non-user Settings, not involved.

TaskID (requestType is similar)

Equivalence class

Value range: 1,5,10, etc.

Outside the value range: 0,99.

Boundary method

Value range: 0,1,38,39,40

Data type boundary: -2147483648,2147483648

Special values: 0,-1, etc.

Traversal: 1,2,3,4,5… 38 and 39 correspond to different ids.

2.5.2 Design for logic

(1) Analysis of constraint conditions

To boot a feature requires: unfinished task, task has task data.


The use case could be:

1) When task data has not been used;

2) When no task data is used;

3) When task data has been used;

4) When no task data has been used.

If there are other constraints similar to the design.

(2) Operation object analysis

After the request interface is invoked, the corresponding task is bootloaded based on the task data. Task data, task operation mode, and task function can all be objects.


1) Task data

  • Data type: local, cloud, etc
  • Data validity: Correct data, wrong data

2) Operation mode

Methods: Install, download, open, etc.

3) Task functions

Function: The user operates the function, but does not operate the function normally. Do nothing; Complete a task function; Complete multiple tasks; Order of use of task functions and so on.

Object: You also need to pay attention to whether the operation will be performed on illegal objects, such as task data and function mismatch.

(3) State transition analysis

A feature has four states: completed, unfinished, and unknown. The state diagram is as follows: Here are the state transitions involved in the product:


For this state:

1) Normal state transition: whether the unfinished status request and the completion of the task can become completed state; Incomplete status The request is not completed, or the state is not completed.

2) Unreachable status path: unknown and completed status request task, the task cannot be performed.

(4) Time sequence analysis

From the perspective of timing, the following two steps are required before invoking the request interface:

1) Pull task data;

2) Judge the task status.


The use cases derived from timing are:

  • Normal timing: request 1, 2, 3 according to normal timing;
  • Missing sequence
  • Lack of movement 1 to 2 to 3; Lack of movement 2 to 1 and 3; Lack of direct tone of action 1 and 2.
  • Disordered sequence
  • Scrambled sequence: 2, 1, 3, and also 1, 3, 2, 3, 1, 1, 2, 3, 2, 1.

In the design of processing logic, it is possible to use one or several ways to cover the use cases, so in actual use, it may not be all used, as long as the most appropriate way to cover the use cases can be found.

2.5.3 Output analysis

The data returned by the request task interface is the completed result of the task, that is, the completed state is returned, and the incomplete state is returned (unknown is returned as completed).

From the results we can consider traversal:

1) Unfinished

2) complete

3) Completed – unknown

From the analysis of interface processing time, consider: after the request to return quickly, a long time to return, or even no return results.

3 summary

In the interface use case design method, the design for input and output is universal, which can be used in interface design. For the design of interface logic, one or more suitable methods may be applied. In the design of interface use cases, the most suitable method should be selected to cover the logic under test.

What are the differences and connections between interface testing and traditional functional testing? Welcome to say what you think.

Pay attention to wechat public number Tencent mobile Quality center TMQ, get more test dry goods to share!