The whole network is the most complete. How to do interface automation test? Proficient in interface automation test details

One 、 Preface

Generally speaking, the interface is a bridge for transmitting data between the front end and the back end , Be careful ： Not every project has an interface , Some large projects are front-end and back-end separated , So how do they deliver and return data ？ Generally speaking, there is an analog parameter data in both the front end and the back end

Two 、 Design of interface automation test " can "

1、 The goal of interface automation

• For the project API Layer of HTTP Functional logic verification of the interface
• Reduce manual testing work （ Regression test ; Cross module verification ）
• Realize the verification that cannot be done by manual verification （ For example, the interface involves sorting and comparison of a large amount of data ）
• Functional logic that is difficult to fully verify by hand （ For example, the functional verification of the interface involves a large amount of data ）

P.S. In actual projects , What is the fundamental purpose of interface automation ？
Personally, I think it's time to run , Can monitor interface , When the interface fails to function , Can discover in time , To discover Bug. therefore , Code coverage can be used to evaluate the integrity of interface automation , But it's more important to find the problem

2、 Interface automation Case Use case design principles

Bear in mind ：

• Don't automate for the sake of automation , The primary goal is when problems arise , Can find out for the first time
• The code coverage statistics in automation can be used as a reference , But you can't start with improving coverage , fall into Case In design

Be careful ： Good interface automation Case Design , Depend on Case The designer's functional understanding （ The skill of manual test ）+ Function coverage point

principle ：

1. Convert manual test points into automated use cases
Case Design attention ： The standard that the verification case passes — Refer to a function point that is prone to problems . Or say , There must be no problem in explaining this function point through a use case ; conversely , There must be something wrong .

2. Covering manual testing is not easy to check ／ Too time-consuming inspection
such as ：

• One HTTP Interface design, when comparing a large amount of data
• Interface json When returning, you cannot directly check whether the function point is correct （ Need to call another interface json For indirect verification ）
• An interface json Return needs to be associated with the interfaces of other modules ” Mutual verification “（ Need to call the interfaces of other modules json, Two json To verify each other's correctness ）

3.“ Marginal ” Functional check of This mainly refers to regression verification
If the system involves marginal functional verification , Automate use cases at the design level of such functions

4. Degree of interface verification
Verification of interfaces ： That is, the standard to judge whether an interface is normal . Be careful ： Interface parameters ” reasonably “ Combine

5.DB Data update check
（ If necessary ） Pay attention to check from the perspective of interface DB Update of data ：

• Update the data of other systems to the system to be tested DB Data in
• The system to be tested is updated to... Every day due to user operation DB Data in

6. Data preparation for interface automation
About whether you need to automate the interface , Deliberately DB Prepare the required data in , Depending on the degree of need . principle ： Unless necessary , Otherwise, you don't have to prepare . If you don't prepare data , Unable to complete the validation of the interface , Then you can prepare the data yourself

Be careful ： Once you prepare your own data , Evaluate the impact on other functional verification . Make sure DB Data volume and authenticity in （ The simulated data needs to be sufficient , And it should not be too different from the real data ）

3、 Interface automation use cases run regularly

Automation usually chooses to run regularly every day . One thing to pay attention to here is the timing of regular running

Points for attention in time selection ：
1） When running online , Pay attention to the impact on the online interface （ General requirements ： Online regression verification can run at any time ）

2） If you want to check DB Relevant logic of data update , Pay attention to the stability of the data ( For example, when the number of users is small )

3） At testing time （ Non-production environment ）, The interface involves reading , Write DB, Consider whether you need to run regularly

3、 ... and 、 Design of interface automation test " You can't "

First , Interface automation is not everything , There are always times when it can't be covered . Know the of automation ” You can't “ The place of , In order to better cooperate with the manual test

Automated ” You can't “ The points are as follows ：
1）HTTP Sudden pressure problem at the interface （ Early pressure measurement ）

2）Web Manual testing at level ( When the new features come online , When returning to the original function , The interface still needs to be verified automatically , Manual testing Web Page functions )

3） Abnormal situation （ If a third party is required API Hang up ／ Timeout scenario ）

1、 The difficulty of interface automation

1） Realize change vs Maintenance workload vs Check the level of detail

Check the level of detail ： Compare yourself to yourself ; Compare the same index with similar interfaces （ Because the caliber is inconsistent , Or implement changes internally , Subsequent maintenance is required ）

Experience ： Compare yourself to yourself , Good expansion and compatibility （ Dynamic parameters + Complete the function check ）; Compared with other interfaces It depends on demand （ Before and after interface test Data accuracy check comparison reference ）;

P.S. A little bit smaller , Execution time and frequency

purpose ： Found dysfunctional , Function not available ;

2） Interface monitoring —— Execution time and frequency

• Check the level of detail vs Execution time and frequency ( Only with yourself )
• Check the level of detail vs Call the police frequently （ How is an interface normal , Return non 200+ Function is normal ）

3） Data reports
The correctness of the data ： Statistical caliber （ The caliber of the business party + Multiple interfaces ／ The difference of module caliber leads to the inconsistency of business parties ）

2、 Pain point of interface automation

Of course, the pain point comes from the difficulty ：

• When the implementation of the interface itself changes frequently 、 The inspection of the interface is too detailed 、 When development and repair are slow , Then the constant alarm will come
• Unreasonable automation design and maintenance scheme , When the cost of automation is greater than the benefit of Automation , Interface automation becomes insignificant

The experience in the actual project is ： Automation for automation . Especially when the test scenario is too complex , When the cost of automation is much greater than the cost of manual testing , There is no need to automate testing

be relative to UI In terms of Automation , Interface automation has greater value

In order to optimize the transformation path or improve the user experience ,APP/web The button controls and layout of the interface will change once in almost every version , Frequent code changes that lead to automation , It didn't reduce the workload

Once the interface is developed , Post refactoring / The frequency of substantial modification is lower . Therefore, the cost performance of interface automation is still very high , For the regression of old functions in iterative versions ,beta test , Online regression can get twice the result with half the effort

---