Practical guidance for interface automation testing (Part I): what preparations should be made for interface automation

1. Why interface automation

1.1 What is interface testing ？

Interface test is a test to test the interface between system components . The interface test is mainly used to detect the interaction points between the external system and the system as well as between the internal subsystems . The focus of the test is to check the exchange of data , Transfer and control the management process , And the mutual logical dependence between systems .

--- The above is the concept from Baidu Encyclopedia

Here , Let's start with a question ： What are the differences between interface testing and interface automation ？

Don't answer here first , You can read the following content with this question , I believe we will naturally get the answer to this question .

1.2 The reason for interface automation

If you want to list the reasons one by one, you will list many , Here I think There are several important reasons List the following ：

• Now more and more systems adopt the front-end and back-end separation architecture 、 Microservice architecture , More services realize information exchange through various interfaces , Test the interface directly , It can cover all kinds of test scenarios more comprehensively

• If you only rely on testing through the front end , Because the front end has some logic control over the input parameter data , Some test scenarios cannot be tested , In particular, some security testing scenarios cannot be covered

• Agile testing requires high testing efficiency , The proportion of test automation should be much larger than that of manual testing , In order to better meet the requirements of agile

• In general practical work , The implementation of interface automation should take priority over interface automation , Because in practice , The maintenance cost of interface automation script is lower than that of interface automation , Stability is also much better

• Nowadays, the complexity of business system is getting higher and higher , Rely solely on manual regression , The cost will increase sharply and the test efficiency will decrease significantly , Interface automated testing is a very good solution , In addition, there are many tools to support , Interface automation has become a must in many project tests

1.3 Test the layered model

Do interface automation , Let's get familiar with the test hierarchy model first , From the figure, we can know that the interface test is at the... Of the pyramid 2 layer .

For the business logic automation test layer , It is mainly divided into Interface automation and Interface automation .

Judging from the test volume , Interface automation is greater than interface automation , This is the comprehensive test cost 、 Results of various considerations such as test effectiveness .

In actual projects , More is a spindle shaped test layered model , The biggest part in the middle is interface automation , Because unit tests often have poor landing effect , The quality improvement of the project depends more on interface automation .

2. What preparations are needed

The preparation of interface automatic test basically includes the following ：

2.1 Automatic tool selection

Before we conduct interface automation test , First of all, choose the appropriate testing tools , Sharpening a knife never misses a woodcutter , The tools are selected , The later testing work is also easy to carry out .

The selection of tools is not the focus of this article , It's just to expand .

For students who have just come into contact with interface testing , Can be based on easy to use 、 Suit oneself 、 Meet the needs of the project to choose .

At present, the commonly used testing tools are as follows ：

Suggest ：

If you First contact with interface automation , You can choose Postman Carry out interface automation , The tool is simple to use and easy to get started .

Of course, use the tool more deeply , It still takes some time to study , The functions supported by this tool are still very powerful .

The actual example of this article will adopt Jmeter To display , Because the test tool used in the project demonstrated by the author is Jmeter.

When you read this article , Focus on How to organize the test ideas , The implementation form of specific interface use cases can be ignored , The implementation form of different tools is different .

2.2 Test environment preparation

Test environment preparation can be divided into two parts ：

• Environment preparation of the tested system

• Test client environment preparation

1） Environment preparation of the tested system

This environment is the running environment preparation of the system under test , Before the test , We must You need to know which system to test , What is the access address of this system , In this way, we can carry out subsequent testing .

The test environment is best maintained by testers , This avoids relying on developers , It can also strengthen the control of testers over the test environment , Avoid the environment being changed at will , Affect the test work .

The initial test environment deployment , It's best to consult the developer , Try to ensure that all configurations of the test environment are basically consistent with the production , Avoid different configurations , Omit some bug.

Of course, a configuration such as a database must use a configuration dedicated to the test environment , Connect to the test database , Never connect directly to the production database for testing .

2） Test client environment preparation

The preparation of this environment is relatively simple , Is to deploy the client environment with testing tools , The simplest way is to deploy and install testing tools natively .

Of course, there are also relatively complex client environment preparations , If you want to do continuous integration testing , May be integrated Jenkins, The environment deployment will be much more complicated , Beginners can ignore .

Due to different testing tools , The client environment preparation will be different , Prepare specifically according to the test tools you use .

notes ：

At present, the testing tool I use is Jmeter, The preparation of the client environment is relatively simple , Just install it java Running environment , Download from official website Jmeter Unzip the installation package and use it .

2.3 Get interface documentation

After the test tools and test environment are ready , Then the next step is to start the test , Of course not yet , According to normal thinking , You need to know what to test , Based on what to test , Only by understanding these can we start the next test .

In the traditional waterfall software process , When the tester is doing the manual function test of a system , Testers will first get it from business people or developers The requirements document 、 System design document .

Learn about the tested system through these documents , Test cases will also be written according to these documents .

If your project adopts agile development mode , Although there are not many documents , But you can still get it from the product manager Product design prototype 、PRD file etc. , Based on this, we can understand the system under test , Analyze and write use cases .

Said the above , Just to give you a comparison , For interface testing , You also need to get some documents first , Understand the tested interface according to these documents , And use case analysis and writing .

But be careful , There are various forms of interface documents , Some project teams may adopt word file , It is more likely to adopt a system maintenance interface document （ Such as ：RAP、eolink etc. ）, Some groups also adopt  Swagger  Tool generation .

At present, the most tests are http Class interface （ General with RESTful API Mostly ）, Also have WebService The class interface , This presentation will be in  RESTful API Style http Class interface .

2.4 Actual project presentation

At present, this project adopts  eolink  This tool is used to maintain interface documents , It is very convenient to use this tool to maintain interface documents .

The project uses the old version  eolink, The new version  eolink  It enriches many functions that are easier to use , See the end of the article for more function descriptions .

The details are as follows ：

• The interface list shows

• “ Delete app ” Interface maintenance content display

3. Test data preparation and test case design

When the above content is ready , You can start the design of interface test cases , After the use case is designed, you only need to prepare some initial test data , You can start debugging and testing the interface .

Test data preparation and test case design can be carried out synchronously , Speaking of test data preparation , What should we prepare , This depends on the specific project .

for instance ： If your project requires user login , At least you should prepare your test users . Of course, you should be clear , Not all data should be prepared before testing .

Many test data may be prepared while testing , Because only a certain interface is tested , Just know what data you need to prepare , For data preparation , It can be handled flexibly according to the actual situation .

The test data can be considered from the following three perspectives according to my own summary ：

3.1 Test data preparation ideas

Personally, I think the most troublesome part of interface automation is Preparation and planning of test data .

The robustness of the script is greatly affected by the preparation of test data , Often because of test data problems , Cause the use case to fail , Affect the effectiveness of interface automation .

For test data preparation , My general test data is divided into two categories ：

① Dead data ;

② Live data .

1） Dead data

Dead data refers to the test data prepared before the test , These data are often prepared manually in the tested system , It is directly used as the initialization parameter of the script .

This part of the data Don't suggest too much , Otherwise, it will take a long time to prepare .

Data that can be prepared as dead data , The suggestions are It's fixed 、 Data that are not easy to change in subsequent tests .

Data like user name and password , It is not easy to change in subsequent tests , The cost of subsequent data maintenance will not be too large .

2） Live data

It is suggested that more test data be prepared in the form of live data , This can improve the automation rate of scripts , Reduce subsequent manual intervention , There are many ways to prepare live data .

I mainly use the following methods ：

• To write SQL Check the library

• Extract the preparation by executing the relevant interface

• Writing scripts automatically generates

3.2 Test data preparation and practical demonstration

To help you better understand , Use it before taking it here Jmeter The data preparation case in interface automation is presented to you ：

Dead data

explain ：

The above figure is the dead data set by my current project , There are user data , Team data 、 Application data , These data are usually created manually , Generally, there will not be too many adjustments in the future .

Live data

• To write SQL Check the library

explain ：

In the figure SQL The script is used to get the user name of the deletion status , For later use cases （“ Error value check （ Pass in deleted username）, Interface returned failed ”） Test data for .

• Extract the preparation by executing the relevant interface

explain ：

In the figure, the number of tests is prepared by creating an application and querying the application list interface Applications with all environments id, Test for the following use cases .

• Writing scripts automatically generates

explain ：

In order to generate appName This field value , It was used Jmeter The built-in function of  ${__time(MMdd-HHmm-SSS,tt)}  To generate non duplicate application names .

Ensure that this field will not be repeated in subsequent tests （ The daemon does not allow this field to be repeated ）, So that the script can run successfully many times .

The above is the overall idea of what needs to be done in interface automation , Further reflection , Careful students will find out , Preparation for the early stage , Including interface documentation , Environment, etc , Need a platform management , This can greatly improve efficiency .

Including subsequent scripting ,Jmeter Although the tool is very simple and easy to use , It can also meet the needs , But the script structure is still too flexible , It is more suitable for individual combat , Not suitable for teamwork .

What about here? , We recommend a user-friendly one that can take into account the maintenance of interface documents 、 Environmental management , It can also be used as a test platform for interface automation ：eolink

Its official website ：https://www.eolink.com/, Latest version  eolink  It has rich and easy-to-use functions , Help the project team better respond to API Interface for management and testing .

Here is a brief introduction of the platform for API Interface design and maintenance 、 Environmental management 、 Test data maintenance 、Mock The function of ：

1）API Interface design and maintenance

The platform offers a variety of API Maintenance methods ： Manual form maintenance 、 Create from a template 、 Automatic generation API Documents, etc. , Also on API Management of stateful and historical versions .

For more information, see ：

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

2） Environmental management

In interface testing, it is often necessary to test in different environments , For the environment ,eolink It also provides the management module of the project environment , It is convenient to manage the environment in a unified way .

For more information, see ：

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

3） Test data maintenance

For a test platform , Test data maintenance function is necessary ,eolink It also provides a very easy-to-use test data management function , Here you can Add and maintain multiple groups of test data , And support dynamic assignment .

For more information, see ：

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

4）Mock function

In the development and joint commissioning Mock The most used functions , A few automated test scenarios also need Mock,eolink The platform provides senior Mock function , It can meet some complex scenes Mock demand .

For more information, see ：

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

because eolink The platform has rich functions , More other functions will be introduced in subsequent articles , Students who want to know more can go directly to the help center on the official website , There will be a more detailed introduction .

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 …….