测试踩坑 - 当已有接口（或数据库表中）新增字段时，都需要注意哪些测试点？

最新在测试的时候，遇到了几个典型问题，都是在原有接口（或数据库表中）进行需求迭代时，出现的问题。我稍微总结一下，作为后续测试的经验教训。

问题一、数据库表中新增字段，但开发将这几个字段设置成了非空字段，且SQL语句中无默认值。

问题现象：接口上线时，后端先上线了，前端没有上线，出现了大问题，很多数据都无法写入到数据库表中，造成了大量接口异常。
解决方案：新增字段，不设置成非空的，且在数据库中为字段设置默认值。

问题二、数据库表中新增字段，但未注意到该字段的最大值

问题现象：数据库中新增了一个modify_user字段，保存一下是谁修改了数据，但是开发在数据库字段设计的时候，字段设置的长度太小了，根本无法满足最长的用户名需要。
解决方案：增加数据库中字段长度。

问题三、接口中新增返回字段，关联从其他表中查询数据，但未注意到该字段的最大值

问题现象：问题与上面的是类似的，这次是接口中新增字段，此字段需要从一个已有表中查询数据。此时一定要关注数据库表中该字段的最大可能长度是多少。这次测试的时候，发现接口中该字段数据类型用的是INT型，而数据库中，该值的可能最大值远大于INT，所以当数据库中值超过2147483647时，接口报错，无法返回数据。
解决方案：修改代码中该字段数据类型。

问题四、接口中新增返回字段，关联从其他表中查询数据

问题现象：此情况是这样的，从A表中查询基础数据，但需要B表关联查询另一个对应的id之类的。从正常的业务逻辑上来讲，A的一条数据，一定对应B的一条数据。但在生产中，偏偏出现了脏数据，A的一条数据，在B表中有3个数据相对应，导致接口查询的数据出现错误。虽然是脏数据导致，但也体现出来逻辑不够严谨，需要重新处理一下。
解决方案：1）如何避免出现脏数据。2）即使出现脏数据，也要有方案，能够从中查询到正确的那条数据。