How to design an interface test case simply

Interface Testing:

Interface: The part that interacts and interacts with submodules or subsystems.

The interface here is a generalized protocol between the client and the backend service; interface for communication between plug-ins; interfaces between modules; down to the methods provided by a class; can be understood as interfaces. Therefore, it can be analyzed that the interface between systems consists of three parts: input, processing logic, and output.

Interface test: refers to the test of the interface between modules or systems.

Analyze an interface:

Get Interface Documentation: Like black-box test elimination, we dig out test points from the requirements document and design test cases. For interface testing, there is also a corresponding interface document.

Analyze the interface documents and extract the test points:

1) Input: which parameters are accepted, the types of parameters, optional parameters and required parameters, etc.; According to the input parameters, the equivalence class and boundary value analysis method are used for design.

2) Business logic: For an interface, different input parameters or combinations, the process or state transition is different, and the flow chart or state transition diagram can be drawn according to the business logic to ensure that each state is accessed at least once.

3) Output: According to the imitation of the volt-bridge specified in the document, the test data is reversely designed, so that all the output states are included;

Test cases: When considering inputs, business logic, and outputs at the same time, there will definitely be redundancy of use cases, and the optimal set of use cases will be selected to cover the business functions and rules to the greatest extent. At the same time, you need to consider the anomaly data and scenarios.

Typical issues found by interface testing:

1) Improper processing of incoming parameters, resulting in program crash;

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

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

4) Improper state handling, resulting in logic confusion;

5) The logical verification is not perfect, and loopholes can be exploited to obtain improper benefits.

Use case design: 1: Input parameter type:

Numeric type: If the parameter specifies a range of values, you need to consider the boundaries of the values within the range of values of the equivalence class, outside the range of values, and if necessary, you may iterate over the values within the range of values.

Special value of type: -1,0

The boundary value of the jujube ruler type: the minimum and maximum value of int;

Improper handling of special values leads to abnormal exit of the program;

Type boundary overflow.

Values outside the range of values do not return the correct error message.

String: A string-based parameter that considers the length and content of the string

Special values: stool front high-altitude characters;

Boundary value: the maximum length of the string;

String content can be considered for types: numeric, non-numeric;

Special characters. Ultra-long characters are not processed, resulting in exceptions such as storage and display.

Array or linked list type.

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

For example, the interface of submitting tasks in batches: submittask(int taskid), and the parameter use case design considerations:

Normal values: 1-5 permissions, out-of-range: 6 permissions;

Boundary value: the boundary value from 1 to 35, the maximum and minimum value allowed by the request;

Special values: 0;

legal ID and non-legal;

duplicate IDs, etc.

Possible Problems and Risks:

When there are 0 items, the program is abnormal, and the base refers to exit;

Duplicate items are not deduplicated during processing, resulting in abnormal results, etc.

2: Designed for logic.

Constraint analysis.

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

For example, the activity of exchanging Q coins requires 50 points to participate.

2) Status restrictions: login status, etc.

For example, you need to log in to synchronize user information.

3) Relationship restrictions: bound relationships, friend relationships, etc.

For example, the anti-fraud function can only query the call information of the bound family members.

4) Permission restrictions: administrators, etc.

3: For the output result.

There may be only one result that the interface handles correctly, but there are many cases where an error exception returns a result. If you know that there are many different types of results returned, you can design use cases for different results. For example, when submitting an integral task, we can usually think of returning correct and incorrect, and the wrong may think:

Overriding return codes is also an idea for use case design.

Frequently Asked Questions and Risks:

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

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

3) The error prompt is improper, resulting in the user not knowing that there is a problem and how to solve it.

4: The interface timed out.

1) The timeout process is not processed, resulting in the blockage of the entire process.

2) After the timeout, the interface is returned, resulting in logic disorder.

Let's say you're testing an "object". The following analysis is carried out with the object as the target, so as to form the necessary test cases.

The test design is carried out around the implementation method of the object, the scope of application, and the purpose to be achieved by the object.

1. What methods are used to implement the object, how reliable are these methods, and whether there are limitations.

2. What are the requirements for the use of the object, and test these requirements. For example, a pressure container, what kind of liquid it contains, how resistant to corrosion, and the requirements for liquid and ambient temperature...

3. Test for the purpose of the object. As above: whether its maximum bearing pressure meets the requirements, whether the volume meets the requirements of the index...

The above is only a general description, which plays the role of throwing bricks and guiding ideas. When it comes to software testing, there are many more factors to consider (from architecture, implementation, algorithms, optimal design, to the final output).

Hope it works for you.