3.4 账号关联过的手机号会一直收到短信验证码
就像现在很多注重用户安全的公司一样，小蔡的公司也决定对用户的账户增加一个强制的功能，就是需要用户绑定手机，这样能让用户第一时间得到异常登录的信息，还可以通过手机安全登录码进行二次验证，然后才能登录网站，如图3-8所示。
添加了绑定手机的功能，就意味着还需要添加修改绑定手机的功能，因为不能限制用户只使用同一个手机号。
在测试添加和修改绑定手机号的过程中，小蔡发现了一个有意思的问题：当用户第一次使用手机号绑定时，系统不会出错；如果这个手机号之前被绑定过，虽然已经取消了绑定，但是被重新绑定到别的账户时，系统会提示这个手机号已经存在，不能继续绑定。
小蔡明确记得在测试取消绑定时，系统返回解绑成功，在前台也看不到绑定的手机号了，所以问题就被缩小到后台解绑的处理过程中。
这一次小蔡并没有直接去找负责开发这一模块的人员寻求帮助，而是想锻炼自己定位和解决问题的能力，于是她使用SQL语句查询后台数据库里有关被解绑的手机号。经过一系列的查询，她发现解绑的手机号在保存用户信息的表里都被删除了，但是为用户发送登录码和异常登录信息的表里还存在有解绑手机号的记录。
当进行到这一步，小蔡大胆地推测，在解绑手机的时候，系统只是单纯地删除了用户信息表里的数据，就在前台提示用户处理成功，但是对于其他关联的数据，并没有处理。而在绑定手机的时候，系统逻辑会判断是否有重复的数据，这就造成了解绑的手机号不能重新被绑定。
当小蔡把这一发现汇报给老牛的时候，老牛敏锐地指出，其实这个问题还隐含了一个更大的风险：解绑的手机号依然可以收到系统发送的验证码，如果其他人别有用心，就可以利用这个漏洞，使用户蒙受损失。
好险，幸亏小蔡及时发现了这个问题。通过这个缺陷，小蔡意识到：对于增删改的操作，不仅需要验证前台返回的结果，同时需要在后台进行验证，确保前后台信息的一致性和完备性。而做到这一点，基本的SQL查询语句是测试人员需要熟悉的。