Test pits - what test points should be paid attention to when adding fields to existing interfaces (or database tables)?

At the time of testing , Encountered several typical problems , All in the original interface （ Or in the database table ） When iterating on requirements , What happened . Let me summarize a little , As a lesson for subsequent testing .

Question 1 、 New fields in the database table , But the development set these fields to non empty fields , And SQL There is no default value in the statement .

Problem phenomenon ： When the interface is online , The backend is online first , The front end is not online , There's a big problem , Many data cannot be written to database tables , Caused a large number of interface exceptions .
Solution ： New fields , Not set to non empty , And set default values for fields in the database .

Question two 、 New fields in the database table , But I didn't notice the maximum value of this field

Problem phenomenon ： A new one has been added to the database modify_user Field , Save who modified the data , But the development is in the design of database fields , The length of the field setting is too small , It simply cannot meet the needs of the longest user name .
Solution ： Increase the length of fields in the database .

Question 3 、 New return field in the interface , Association queries data from other tables , But I didn't notice the maximum value of this field

Problem phenomenon ： The problem is similar to the above , This is a new field in the interface , This field needs to query data from an existing table . At this time, we must pay attention to the maximum possible length of this field in the database table . During this test , It is found that the data type of this field in the interface is INT type , And in the database , The maximum possible value of this value is much greater than INT, So when the database median exceeds 2147483647 when , Interface error , Unable to return data .
Solution ： Modify the data type of this field in the code .

Question 4 、 New return field in the interface , Association queries data from other tables

Problem phenomenon ： This is the case , from A Query basic data in the table , But you need B Table Association queries another corresponding id And so on. . Speaking from the normal business logic ,A A piece of data , It must correspond to B A piece of data . But in production , Unfortunately, there is dirty data ,A A piece of data , stay B Table has 3 Data corresponds to , The data queried by the interface is wrong . Although it is dirty data that causes , But it also shows that the logic is not rigorous , It needs to be reprocessed .
Solution ：1） How to avoid dirty data .2） Even if dirty data appears , There should also be a plan , The correct data can be queried .