一个数据库字段长度不足的bug

今天喜提一个线上bug，对于一个在软件测试行业工作了几年的人来说，确实不应该出现。

于是决定把这个bug的前身今生仔细回顾一遍。

这个事还要追溯到春节前的一个需求。

我司某平台有个业务经理希望给一部分逾期用户发催收短信，由业务人员在订单系统筛选出来目标用户，15分钟后，由系统异步处理短信发送任务。
业务希望在发送短信时，要剔除当前已经结清的订单，于是开发在设计时，把业务做的筛选条件和短信内容存到了数据库某个字段中，然后等任务需要执行时，再根据筛选条件实时筛选符合条件的用户。
这个需求是我负责测试的，因为涉及到大批量短信推送，对用户影响风险很大，于是非常谨慎，所幸上线后没有业务反馈任何问题，算是平安上线。

此是背景。

一个多月后，另一平台觉得这个功能挺好，于是决定平移过去。
既然上一个平台已经平稳运行这么长时间了，除了个别差异化配置，平移过去应该很轻松也很安全。
于是带着这种潜意识，我验证完基本功能后就安排上线了，在线上也测试了一个用户，短信发送及展示均正常。
看来到这里，又圆满完成了一次上线任务。

然而，就在大家都已经move on，在交付给业务方一周之后的今天，业务突然说功能不可用。

我这个暴脾气，我测试的东西，已经上线这么久了，也做了线上验证，怎么可能有问题呢？！
于是我有些嚣张的回复了业务方，让他表述清楚问题，还咔咔贴出几张图，内心就想着，是不是你不会用，这不挺正常的吗？！
然而，等15分钟之后，任务执行了，但是用户确实没有收到短信，我开始慌了。
赶紧去排查数据，这才发现这个自己一直忽略的问题。

前面说到，开发设计时是把筛选条件保存在数据库里的，而我发现业务反馈的问题涉及的数据，数据库中筛选条件记录的并不完整，因为业务配置的短信内容特别长，数据表字段长度不够！！！
所以后续就无法去判断目标用户是谁，用户当然也不可能收到短信了。

我傻眼了。

这次的主要教训是：

如果开发选择把重要参数保存在数据库，并且后面还要读取使用，而且这个参数来源是人为输入的，内容长度不可控时，那就一定要考虑字段长度啊！！！！

同时，因为这件事也对现在自己思维的局限性感到羞愧，在上一家公司也遇到过这种问题，当时都能考虑到这种风险，然而这半年自己却退化严重，很多浅显的问题都忽略了。