Practice Guide for interface automation testing (middle): what are the interface testing scenarios

In the first article   Practice Guide for interface automation testing （ On ）： What preparations should be made for interface automation I explained in detail to the partners what preparations need to be done for interface automation .【 At the end of the article, I share the interface automation test tutorial 】

The last step in the preparation is the design of interface test cases , Is the use case design good , It is directly related to our test quality .

How to design test cases , Here, I combine my own experience , Help you sort out the design ideas of interface test cases .

I hope it will help and improve your subsequent interface testing work .

1 Interface test scenario sorting

1.1 Design thinking

In the interface test , For the most part , Our test quality depends on the design of interface test scenarios , The interface test scenario is different from the traditional function test scenario .

Many test students can't convert well for a while , At first, the idea of interface testing will be confused .

Here, let's sort out the common test scenarios of the interface , And classified , Interested students suggest reading it several times , And think more .

notes ：

The actual test of performance and safety is much more complex than that of function .

This article focuses on the functional perspective test , Then write a special article to explain in detail how to conduct the performance and security testing of the interface .

1.2 Explain from the perspective of function

Functional division of interface test , According to different perspectives , There are many ways to divide .

At present, the test scenarios mainly used in my actual testing work can be divided into five categories ：

• Foundation inspection

• Normal multi angle

• Extremely multi angle

• Required item check

• Boundary value check

Pay attention to this sequence ：

Foundation inspection -> Normal multi angle -> Extremely multi angle -> Required item check -> Boundary value check

The priority is reduced in turn . Actually, when conducting interface test , It is suggested to design test cases in this priority order .

Not all interface tests need to be designed so comprehensively , Time cost needs to be comprehensively considered 、 The importance of interfaces is determined by multiple factors .

The following explains the classification of each scene from the perspective of function , It is beneficial for everyone to understand clearly ：

1） Foundation inspection

The main purpose of this angle is to verify the acceptability of the interface , Enter valid input parameters , Check that the interface returns to normal , It can be judged by returning the status code or key field .

But is the content returned correctly , Not within the inspection range of this angle .

2） Normal multi angle

This angle mainly verifies a variety of effective input parameter combinations , Check that all interfaces can return correct data that meets expectations .

Similar to ordinary function test , From the perspective of black box , Using the idea of equivalence , Divide the possible normal scenario combination values of each input parameter of the interface .

And check the correctness of the result returned by the interface , Whether it meets the expected results of our input settings .

3） Extremely multi angle

This angle mainly verifies a variety of invalid input parameter combinations , Check whether the interface returns the expected error message .

It should be noted that , This perspective is more about the abnormal scenarios from the business perspective .

Instead of testing for abnormal data of an input parameter , The abnormal data test for each parameter will be put more into the boundary value check scenario .

4） Required item check

This angle check is relatively clear , According to the interface document , Check whether each required input parameter is really set as a required item .

In scene design , It needs to be tested when only the required items are entered into the parameter , The interface should be able to return the information of successful processing , Otherwise, there is something wrong with the document , Or there is something wrong with the interface code logic .

5） Boundary value check

This angle is mainly checked from the perspective of the input element level , Carry out special character check for each input parameter of the interface 、 Length boundary value check, etc .

The inspection priority of this angle is the lowest , The reason is that the front end of the general system will have control , This kind of illegal data generally cannot be transferred to the back end .

But for better robustness of the interface , Although the front end is controlled , But the back-end interface also adds verification control , The security and robustness will be higher .

Of course, in the actual project , Back end developers often spend more time because of this processing , Often do not do too comprehensive control .

In this case , Our test can be based on specific system usage scenarios , Comprehensively evaluate the risks , If there is a big risk , Or specifically require developers to improve the background verification .

2 Use case design demonstration

For the maintenance of interface use cases , Here are two recommended tools :

One is a single soldier artifact Jmeter

One is free and very easy to use API Interface collaboration platform Eolink

Eolink The platform not only supports API Collaborative development of interfaces , More abundant interface testing functions , Support the testing of interfaces .

Eolink An example of interface test case maintenance is as follows ：

The picture below is for use Jmeter Maintain a set of interface test cases for creating application interfaces , Later, I will take this as an example to explain the interface test scenario mentioned in the above chapter .

explain ：

The picture above shows right Create an application interface Test cases written .

The use case of this interface is completely in accordance with 5 Design test cases by scenario classification , And when designing use cases , Use case design is carried out according to the classification priority of each scenario .

The advantage of this is that the whole design idea is relatively clear , Try to avoid omitting some scenario use case writing .

2.1 Basic inspection class use case display

explain ：

The use case input parameters are randomly set with a set of parameters that can make the interface return to normal .

explain ：

Assertion settings are also relatively simple , It is considered successful when the interface returns a key field .

2.2 Normal multi angle use case presentation

explain ：

This use case is mainly set to check whether applications of different construction types can be successfully created .

2.3 Abnormal multi angle use case display

explain ：

This use case is to check when language Field has a nonexistent value , Check the interface and return failure （ Such wrong data , The interface will return non 200 Error code ）.

2.4 Required inspection case display

explain ：

This use case is to check when language Field set to null after , The check interface returns the expected failure information , The failure message is ： You must choose his development language for your application .

2.5 Boundary value check case display

explain ：

This use case is to check tag There are many illegal fields to enter parameters , The check interface returns the expected failure information .

The failure message is ：

The project name can only contain letters 、 Numbers 、 Center line , And cannot start and end with a dash . length 2-50 Characters

Last , Let me introduce you to my friends again Eolink Magical features in test cases ：

Support the ability to automatically generate test cases .

This capability can intelligently generate test cases for a variety of scenarios , And realize the rapid generation of various normal types , Exception types , The boundary value , Use cases with mandatory values .

Interested partners suggest going to the official website to learn more ：

https://www.eolink.com/

In addition, the platform has rich and easy-to-use testing functions , Help the project team better respond to API Interface for management and testing .

Here are a few easy-to-use functions ：

1） Support online 、 Local 、 Client to test

eolink In addition to regular support for server-side test initiation , It also supports clients （ Local ）、 plug-in unit （ Local ） Launch the test , Meet the testing needs of many different scenarios .

Want to know more , You can see ：

https://help.eolink.com/#/tutorial/?groupID=c-628&productID=13

client （ Local ）：

Server testing （ On-line ）：

plug-in unit （ Local ）：

2） One click regression / Smoke testing

In the old ways of collaboration , Testers are always at the end of the line .

Unable to participate in project discussions , Can't do fast, wide-range regression testing , I can't even finish the test on time , Lead to project delay or go online with fear .

stay API In the R & D management platform , Because collaboration is based on API The document is in progress , When back-end developers will API After the document is written , The tester can step in right away .

stay API Write test cases based on documents , Move testing forward .

When API After development , The tester can push API All test cases are tested , And get detailed test reports .

Back end development only needs to see the test results to know its own API Whether the test requirements are met , If there is an exception, it can be targeted to improve .

Want to know more , You can see ：

https://help.eolink.com/#/tutorial/?groupID=c-469&productID=13

3） Rich and detailed test reports

The platform also provides rich and detailed test reports , It is convenient to view and analyze the test results .

Want to know more , You can see ：

https://help.eolink.com/#/tutorial/?groupID=c-469&productID=13

Let me know , The next article will introduce the idea of interface automation test assertion setting , Interested partners , It is suggested to keep an eye on .

Experience address ：

https://www.eolink.com/?utm_source=w2703

---

Learning resource sharing

Finally, thank everyone who reads my article carefully , Watching the rise and attention of fans all the way , Reciprocity is always necessary , Although it's not very valuable , If you can use it, you can take it

These materials , For thinking 【 Advanced automated testing 】 For our friends, it should be the most comprehensive and complete war preparation warehouse , This warehouse also accompanied me through the most difficult journey , I hope it can help you ！ Everything should be done as soon as possible , Especially in the technology industry , We must improve our technical skills . I hope that's helpful …….