Interface Test--the next chapter, with the/note/readnotes interface as an example of how to do the interface

Interface Test--preface, How does the interface come about?
Interface test--Medium, a Notepad interface via Django
Interface Test--the next chapter, with the/note/readnotes interface as an example of how to do the interface
Interface testing--Tools for automating interface

So through the study of the last two articles, we understand the basic knowledge of interface development, next is to enter the text, how to test these interfaces.

The process of interface testing is actually the same as the process of our actual functional testing:

Requirements analysis--use case writing--performing tests

Our testers for the interface to get things, usually interface documents and requirements of the document, this article will be the implementation of the Django interface to perform an interface test, first pull the project from Git to run (of course, if your machine installed MySQL and generated the corresponding table):
Python manage.py runserver
This allows the local debug server to be OK. Interface Description

So in the previous article we implemented a total of 4 interfaces, in order to explain in more detail, we only take an interface to illustrate how to test this interface--/note/readnotes

In the previous article we have roughly written the interface call document, we re-edit here:
Catalog:/note/readnotes
Request method: Get mode
Parameters: Header with token (optional), UID (optional)
Example of return Data:
{
"Code": 0,
"Data": [
{
"CID:": 5,
"Content": "ASDASDASD",
"Public": True
}
]
} Description: The token and UID exist at the same time, then the UID is preferred. If neither is required, then all public data is queried. With token only, then query all of your own note data.

OK, here is an interface description, next we analyze and test the interface document Analysis

The first thing you need to do when you get a document is to analyze the document and in the documentation we need to make a few points clear:
1. How is this interface defined, in order to get what data to meet the needs of
2. What are the request parameters for this interface, whether the parameters are optional or required, if you need to log in, whether you need to encrypt
3. What is the structure of the returned data, what is the mark of success, what is the mark of failure?

With these questions, and then read, we get the following information:
So this is a note-taking interface, which has two functions, 1. Get notes from a user or all users; 2. Get all your notes. There are two request parameters, token and UID, which are optional. The data structure is composed of the status code and content, we need to judge the code=0, and the data back packet information, if the error, we need to judge the code and errmsg information.
use case authoring and execution testing

After analyzing the corresponding interface document and requirement document, it is the design of use case, the use case design of interface test is also inseparable from the interface document and requirement document, the interface generally verifies two points:
1. Parameter Exceptions and validation
2. Does the business logic meet the requirements

Based on the above principles, you begin to design the interface use case and attach the execution effect:
1) Default parameters are not filled, get data, see whether it is shared public notes

We see that the value of the returned public is true, the description is publicly available, and sometimes pulic does not come out, and we can log in to the database to execute the query and make the result comparison:

Consistent with the query results of the SQL statement, the test passes

2) Just fill in the token, get the data, and see if all the data I've posted is displayed.

Similarly, query the database:

Ok, and also correct, test pass
3) Only the UID, query results
4) All fill in, query results
5) Only the UID is filled in, but the UID does not exist

6) Fill in token, but token does not exist

7) New registered users, execute queries, and verify

There are so many test cases altogether.

And then in the example above, we found that we carried out parameter validation and business logic validation, verification points corresponding to the parameters of the server parameter exception handling and business logic filtering, we take the first use case to see the corresponding processing code:

If not UID and not token:
    items = Note.objects.all ();
    RESP = [] for
    item in items:
        if item.public:
            resp.append ({"CID:": Item.cid, "content": item.content, "public ": Item.public});
    If resp = = []:
        return C_response ( -203, ' ', ' no content ');
    else:
        return C_response (0,RESP)

In fact, the code processing is relatively simple, here the processing is not with any parameters, take out the database all the data, and then two if abnormal judgment, no, the other use cases corresponding to the logical branch is similar, well, do not rule out the interface I write is the most basic. Summary

Well, how to test the interface after reading this article I think probably all understand, because this thing you understand the server is not very difficult after processing, in the next article we will explain how these use cases to do interface automation.