Error message here!

Hide Error message here!


Error message here!


Hide Error message here!


Error message here!



The most detailed interface test case of the whole network! [full text 57000 words] Xiaobai must see!

Programmer two black 2022-01-15 04:45:16 阅读数:7 评论数:0 点赞数:0 收藏数:0

I have some recent questions , Are quite representative .

  • As a preliminary test , Want to learn interface testing , But I don't have a clue . Ask the great God for advice , Are there any good books or tools to recommend ?- You know

  • How to do interface testing ? What are the tools for interface testing - You know

  • What is the general process of interface testing ?- You know

When I first started the introductory test , Also confused about interface testing , And there were few good materials on the market at that time , In the process of self-study, I also took many detours . So I decided to use an article to tell you about interface testing .

The full text 5700 word , It's all a summary of my practical work experience , Multi map early warning , If it's helpful to you, please give me a compliment !

The most common misunderstanding of interface testing

Some time ago , A friend switched to a company as a test and development engineer on the service side , The monthly salary has gone up 50%

I sent him my sincere wishes for the first time , At the same time, he asked about his work in the new company .

He told me. , At present, he is mainly responsible for the interface test of an e-commerce platform and starts to build an interface automation test platform .

Because the colleague used to test the mobile terminal , Never heard of , He has experience in interface testing . So out of curiosity , I asked : How does he conduct interface testing at present .

He may not be well prepared for the problem , It is also possible that he has no relevant experience in interface testing before , He gave me the answer , In fact, the answer is similar to that found on the Internet :

adopt Postman / Jmeter / Code calls Wait for the test tool , To simulate network requests .

  1. Verify whether the interface parameters are reasonable ( Less biography / Missed transmission / Multiple transmission / The boundary value / Parameter type verification, etc ).

  2. Test whether the response result will return the agreed data format , Are there any fields not distributed or distributed incorrectly .

  3. Verify whether the interface has security problems , Authentication or not .

For this answer , I'm not surprised , That's what most online replies say .

But for a pure server-side test , Just adjust the parameters , Can you really complete the interface test ?

NO, This is just the tip of the iceberg of interface testing , Interface testing is not as simple as you think !

that , What are the main aspects of interface testing ?

By convention , Go to the old man first (nao) chart :

Next , I will test the actual combat with an in-depth interface , Let's share , How do I do interface testing .

Interface testing 10 Two practical steps

Next, we take the search interface of e-commerce platform as a case , Explain the steps of interface testing step by step .

「 First step : Sort out the upstream and downstream call chains 」

1) Why comb the upstream and downstream call chains ?

At present, the back-end services of Internet products , They are basically distributed deployment , One interface may call other interfaces , It may also be called by other interfaces , Interface to interface , With countless dependencies .

If we test the interface we are responsible for purely as a black box , Not a confidant ;

If we are only familiar with our own interfaces , Unclear dependencies on other interfaces , It's not like knowing the other ;

The so-called know yourself and know your enemy , Only in this way can a hundred battles be won .

therefore , Sorting out upstream and downstream call chains is the first thing to do .
 Insert picture description here
When we were testing , It is likely to only pay one-sided attention to the interface opened by the search gateway to the front-end call ,

But just draw the whole call link and process , We will find that the search gateway actually depends on a lot of services .

such as :

  • The search gateway needs to call the price tag system , To get promotional prices ;

  • The search gateway needs to call the recommendation system , To get the recommended products in the search scenario ;

  • The search gateway needs to call the commodity system , To get real-time product information ;

  • The search gateway needs to call the search service , Go to ES Recall goods 、 Get search sorting information, etc .

The front end searches for a keyword in the search box , Initiate a search gateway HTTP request , In fact, there are many processes behind this request .

If it's just a separate tuning parameter , I just want to do a good job of interface testing , It's obviously impossible .( Development can be adjusted by itself (tiao) Interface parameters , And test what to do ?)

Whether the business logic behind the interface is handled correctly 、 Whether the services that the backend depends on are robust 、 Whether the interface performance meets the standard .

2) How to sort out the upstream and downstream call chains ?

1、 See the project wiki、 Product documentation and development documentation .

2、 Look at the code written by the developer , Reading the code , Of course, it's the first choice :JetBrains Family bucket (Java use IDEA;Python use Pycharm)

3、 After sorting out the upstream and downstream call relationship , Draw a system flow chart by hand , If there is any ambiguity , You can find PM、 Development communication confirmation .

「 The second step : Write interface test cases 」

Interface test cases are similar to ordinary test cases , There are not many requirements and restrictions . Because many times in the testing work, the interface is not specially tested , So this step doesn't have to be done .

But you should know what you want to measure , If you are doing interface testing for the first time , I still suggest writing an interface test case , And file it well .

If you want to do interface automation , Interface test cases are also very helpful .

Here is a case of interface test case :

「 The third step : Test interface documentation & Debug interface 」

Interface document is very important in the process of software project development , Interface document is a bridge between front-end development and back-end development .

At the beginning of project development , Front end development and back-end development will jointly agree on a set of interface specifications , Then the back-end developer writes the interface document , Then the front and back end can carry out collaborative development according to the agreement .

There are many ways to manage and edit interface documents :

Some teams are used to using wiki Or write interface documents online ;

Some teams like to use professional interface documentation tools , such as :Swagger、Yapi Wait to generate interface documents .

Our company is used to using silk stockings (swagger) To maintain interface documents .

swagger For multiple programming languages / frame Both provide good access schemes . take Java Come on , Just introduce the corresponding jar package , Add the corresponding... On the interface api Document notes , You can automatically generate the interface document of the web version .

And you can debug the interface through the interface document , Greatly improved development efficiency .

But no matter how to manage and maintain interface documents , Interface documents are required

Test interface documents can refer to the following test points :

  • Ensure that interface documentation must be provided for development . If developers don't have the habit of writing interface documents , Should be push Develop and write interface documents .
  • Check whether the format and content of the interface document are complete , Include :URL、 Request method 、Header、 Enter the reference 、 Return value 、 Example Demo etc. .
  • Check whether the interface design complies with the company's specifications . Including interface naming 、 Interface format 、 Field naming 、 Field type 、 Response status code 、 Interface fault tolerance 、 Is the field redundant 、 Whether the interface is authenticated 、 Whether to distinguish versions, etc .

「 Step four : Front end interface test &Mock data ( Interface level testing )」

The previous steps just use the test tool to initiate network requests , To simulate interface calls .

But in the real scene , The interface of the search gateway is actually provided to APP/WEB/ Applet Calling .

We also need to pay attention to whether the front-end calling process is normal .( You need to wait until the front-end development is completed , To intervene in the test )

You can use Charles To capture the request sent by the front end ,

  • Verify whether the parameters of the front-end calling interface are correct ;
  • Verify whether the interface response of the back-end is as expected ;
  • After the front end gets the data , Interaction and UI Whether the presentation is correct .

When some data has multiple states , And when the data is difficult to construct , We can go through Mock Data to test .

common Mock The way of data is :

  • use Fiddler perhaps Charles To tamper with requests and responses .
  • If it is PHP perhaps Python Isodynamic language , You can change the conditions directly in the back-end code .
  • Modify data in the database .
  • With professional Mock Tools to construct data , Such as :EasyMock、TestableMock、Mockjs etc. .

A faster way , Directly, of course Charles To simulate .

If only a small amount of response data is changed , for instance : Change the copy of a label , Look at the front-end display . This situation is very suitable for Charles To simulate data .

however Charles Simulation also has a drawback , That is, if the data structure issued by the interface is complex , Changes involving multiple fields , use Charles Go to Mock Data is more troublesome .

「 Step five : Back end interface test & Business logic coverage ( Log 、 Look at the code )」


During business testing , We need to keep an eye on the backend log status .

Sometimes the interface response data is normal , But the back-end log may be reporting errors ,

such as :

It is common for search results pages to return empty arrays , Generally speaking, the search keyword does not recall any goods .

But I once tested , Find the same keyword , Under the same conditions , Sometimes recall 0 A commodity , Sometimes recall multiple items .

It was strange at first , Later, check the back-end log , Only then did I find that the recall of goods timed out .

Look at the code

It is recommended that you do interface testing , Be sure to read the developed source code .

Read the source code to understand the business logic implementation more deeply .

in addition , Some conditions , It's hard to simulate in manual testing , But by reading the source code , Even unit tests , Can easily simulate .

Another advantage of reading the source code is , Play a restrictive role in development , Because the code is public , If you find a lot from the code level Bug Words , The face of development can't pass .

About reading the source code , We can pull the code locally , use IDEA Wait for tools to check the source code

What if the amount of code is large ?

Tell you a little trick : When the developer submits the code , We can do it in Gitlab Look at his Commit Record , Or make a comparison between his development branch and the branch of production environment diff, So we can know what he has changed .

Here's another case in real work :

Here's another case in real work :

The screening process :

(1) First in APP Try to reproduce

(2) Look at the response time returned by the interface by capturing packets , A request cost 3.69s

(3) adopt Arthas Of trace Check the reasons for slow interface response step by step :

Get into Arthas Command line

java -jar arthas-boot.jar

trace Methods called by the interface

trace Class name Method name

Finally, it is found that it may be very slow to call the price tag .

Finally, the reason was found :

A method that invokes a dependent service is no longer maintained in the test environment , But the code exists bug, Call will continue , Causes the call to time out .

After optimization , The response speed of search gateway is from 3s Shorten to 300ms about .

「 Step seven : Interface exception mechanism (Chaosblade)」

Because the interface depends on many services , It is often necessary to call other interfaces . If the dependent service has an exception , We need to consider whether our interface is fault-tolerant , Or downgrade .

It can be used Chaosblade To inject exceptions .( Not necessary , But there are better )

Chaosblade It is an open source chaos engineering tool of Alibaba , If you are interested, you can get to know :

「 Step eight : Interface version control &diffy」

Because the interface depends on many services , It is often necessary to call its

Generally, interfaces will distinguish between versions , If the interface is not very standard , Or change some general logic , At this time, you need to perform a regression test on the old version .

The stupidest way is to take two of the old and new versions app Contrast test . We can also use diffy This tool is used for regression testing .

「 Step nine : Start interface automation 」

Interface automation is commonly used for online patrol inspection 、 Test smoke and other scenarios .

Interface automation , There are several common ways :


python+pytest+requests, The company is doing it this way .

( Small and beautiful , Convenient customization )

pytest Generated test report :

( utilize an instrument , Highest efficiency , But it's not very convenient to customize )

(3) Traffic recording and playback

( Low code implementation , But the implementation cost is quite high )

 Insert picture description here
Common traffic recording and playback tools :gor

Attached below is a brain map I sorted out

I hope you can follow this system in 1-2 We will complete the construction of such a system within the year . so to speak , It's a process that's going to kill you , But as long as you get through it . Life will be much easier in the future . It's just that it's hard at the beginning , Just take the first step , You're halfway there , The ancients said well “ Short step , A thousand miles .” When we look back on this journey after it's finished , You're bound to feel a lot .

 Insert picture description here
If you don't want to experience it again, you can't find information when you study on your own , No one answers the question , If you insist on giving up after a few days , Sure Follow my public number 【 Programmer two black 】 Get the software test resource package , The reply learning route can obtain the original diagram of the knowledge architecture system of the development direction of the test engineer , You can also join our group ,785128166 Let's talk about it , There are also various software testing materials and technical exchanges .

Come on! , Testers ! If you need to improve planning , Then act , Better on the road than at the starting point .

In the future, you will surely thank yourself for your hard work now !

Copyright statement
In this paper,the author:[Programmer two black],Reprint please bring the original link, thank you