Interface use case design

Objective: To test the correctness and stability of the interface;

Principle: Simulate the process that the client sends a request message to the server, the server processes the corresponding message after receiving the request message and returns a reply to the client, and the client receives the reply;

Key points: check the management process of data exchange, transmission and control, including the number of processing;

Core: Continuous integration is the core of interface testing;

Advantages: It brings efficient defect monitoring and quality supervision capabilities to highly complex platforms. The more complex the platform, the larger the system, and the more obvious the effect of interface testing.

Focus of use case design: Usually, the outermost two types of interfaces are mainly tested: data input system interface (this system uses the parameters of calling external systems) and data output system interface (verification system? Whether the data after unified processing is normal);

Input parameters are mainly designed from the following aspects:

Required project inspection

There is a description about whether it is needed in the interface document. Please refer to the interface documentation.

Parameter length check

Please refer to the interface documentation.

Validity check of c parameter value

Therefore, the verification of parameters needs to be combined with actual business scenarios to determine which data are true and valid, and it needs to ensure that all true and valid data can be verified.

D parameter combination check

Different parameter combinations may have different business scenarios;

E. If the parameter is an enumeration value, various enumeration values must be tested, because different enumerations may adopt different business processes;

Verification of default value of f parameter value

Please refer to the interface documentation.

Some parameters have specific generation rules. If you want to design use cases for generating rules alone, you must ensure that real and valid data can be verified.

The design method I use for interface logic is branch coverage-; Path coverage-"; Scenario coverage also needs to be combined with actual business scenarios, and business scenarios that do not happen at all are invalid test cases.

A. The first step is to draw the business process first;

B. According to the branches in the road map, different branches have different scenarios, so abnormal scenarios should be considered here; Such as interface timeout, abnormal interface, success or failure of interface request, how to deal with it after success, whether to continue the process after failure, and how to deal with data after failure;

After completing the C test logic design, you should think about how to test different business scenarios and who needs assistance.

For example, how to test interface timeout, how to test request duplication and how to test request concurrency.

Input results: normal output and abnormal output. The common method is error inference (list possible errors or anomalies in the program and select test cases according to them).