Interface test actual project 03: execute test cases

 

This time, , We began to test the interface according to the test cases .

Before the test , Let me start with a little ：

This set of project provides a complete test case , But if you want to master interface testing skills , I suggest you read the interface document first , Then write a test case by yourself , Then compare with standard use cases , Leak filling ,100% It's good for you

The test case

 

Open the test case . The use case has four major scenarios （ Inquire about 、 newly added 、 to update 、 Delete ）, common 57 Use cases （ Query college information 28 individual , Add college information 15 individual , Update college information 11 individual , Delete college information 3 individual ）.

In the actual interface test , When you finish writing test cases, you need to execute them one by one , Ensure that each use case passes , If it doesn't go through , Then you will find one bug.

We won't talk about every use case here , Because simple interface testing is really not very difficult , Whenever you can use a computer , Can follow the gourd and draw gourds .

See Postman Screenshot （ We usually use Postman Do interface tests ）：

GET request （ Query college information ）

 

POST request （ Add college information ）

 

PUT request （ Update college information ）

 

DELETE request （ Delete college information ）

 

reflection

In practice , Do you have such trouble ：

01 Some use cases , Very annoying operation

 

For example, these three ,

In the first use case , You need to create a new one T01、T02 college ;

In the second use case , You need to delete one of the Colleges before you can request ;

In the following third use case , You need to delete two more colleges before you can request .

Think about how to solve ？

When you are familiar with the business , Your use case can actually be changed to ：

First step , verification T01,T02 Two empty scenes ;

The second step , newly added T01, verification T01 There is ,T02 A scene that doesn't exist ;

The third step , newly added T02, Verify that both scenarios exist .

In the end , Your data , yes T01 and T02 All in , You can use the existing data to verify other scenarios , For example, update and delete , Instead of passively following the use case as before , Did a lot of repetitive work .

02 Repeat the test

After a hard test , Development suddenly tells you ： I changed the code a little , You need to retest .

For the first time, you may accept , But after more times , you 100% Will be upset , I think the test work is very boring , meaningless .

Think about how to solve ？

automated testing .

This is the original intention of automated testing —— Reduce repetitive work （ Worth reducing ）, Improve work efficiency （ Reduce energy input ）.

therefore ： Think while working , To keep you improving .

above , success ！ If you need a full set of projects, you can contact me , In case of problems , You can leave a comment below .