How to write test cases? The most comprehensive interface test in history - use case writing design summary (test point)

Contents: Guide

foreword

The process of interface testing

Interface testing is also a functional test, so it is not much different from our previous functional testing process. The testing process is still:
1. Test interface documents (requirements documents)
2. Write test cases according to interface documents (use cases can be written according to the previous Rules to write, such as equivalence class division, boundary value and other design methods)
3. Execute the test to check whether the data returned by the interface meets expectations for different parameter requests.

Interface testing is the same as functional testing, and the process roughly follows the V model

Generally speaking, each company may have a different emphasis on each stage on the left side of interface testing. For example, some companies do not have the stage of requirements discussion and requirements review.

In any case, use case design is indispensable, and it is the key point, which takes time. Only by covering comprehensive interface test cases can we have better test interface coverage, find more interface bugs, and make the interface more stable later.

Why write use cases

Clarify ideas, avoid missing tests and repeated tests;
improve test efficiency;
follow up test progress;
tell leaders that they have done it;
follow up repetitive work;
better record problems, find problems, and reproduce problems;
at the same time, this is also an interface test an artifact (test case) in the process;

The above seven points, combined with the actual experience of testing, should be well understood and agreed.

There are useful cases, so you know what you know, don’t repeat a test point many times, have ideas, and avoid missing test points. Follow the use case test to avoid the purposeless test of random test and improve test efficiency.

There is a case where your superior asks you about your progress, and you can answer it with data. Use cases, used to mark the results of your execution, to prove that you have done the test.

To avoid problems in the future, people say that you have not tested, and you have data and evidence to speak. There are use cases to detect problems. You can easily surface the problems according to the use cases, so that you will not wait for your feedback or reproduce the problem, and you will forget how to operate before the problem occurs.

Interface testing also needs to be run repeatedly, several rounds, or run every day with automation. For such repetitive work, the use case can ensure that the same situation is repeated every time.

Interface main design use case points

Mainly design interface use cases from four aspects: function, logical business, exception, security

Function:
1. Whether the function is normal;
2. Whether the function is implemented according to the interface document;

Example:
For example, to write an article and add an essay, you need to log in to add it. That is, business requirements do not support the function of tourists adding essays. If you design a user who has not logged in and then test the interface for adding essays, if the interface can be added to essays, it means that the function is abnormal and does not meet the requirements and interface document description.

Logical business: whether it depends on the business;
for example: before calling this interface, the login interface needs to be called. If you do not log in, you can still request data, which does not comply with business rules.

Exception: Parameter exception and data exception
Parameter exception: keyword argument, empty argument, more, less argument, wrong argument

Data exception: keyword data, data is empty, length is inconsistent, wrong data
For example: regardless of data exception or parameter exception, the test points are similar, a parameter has key and value, key indicates the parameter, and value indicates the data.
First, see if the parameters and data can support keywords, such as reserved keywords in Java and so on.
The second is that the parameters and data are both empty, to see if a judgment has been made.
The third is more and less parameters. For example, for an interface with two parameters, you need to design a use case with three parameters and a use case with only one parameter.

The length of the data is inconsistent. For example, whether to design a very long string is supported, because the length of each field is set in the process of creating a table in the database. Entering wrong parameters and data, such as deliberately outputting words, etc.

Design of security test cases:
1. cookie: data can be obtained only with cookie, if there is information returned without cookie, there is a problem
2. header: normal interface has header information, delete the header to see if the data can be returned.
3. Unique identification code: App mobile phone identification code, which is generally unique.

Security testing mainly checks from the above three points. The third is the unique identification code, which mainly refers to the identification code of the mobile phone on the app, which is rarely used unless a very strict interface test, such as a bank app login, requires a fingerprint, and the fingerprint comes from a mobile phone, which generally has a mobile phone identification code Judgment process.

The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled