Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

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 )」

Log

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 :https://chaosblade.io/docs

「 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 :

(1)coding:

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

( Small and beautiful , Convenient customization )

pytest Generated test report :
(2)postman+newman

( 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

编程之旅,人生之路,不止于编程,还有诗和远方。
阅代码原理,看框架知识,学企业实践;
赏诗词,读日记,踏人生之路,观世界之行;

支付宝红包,每日可领