coach说让我写点东西，记录自己的工作经验，今天正好看到题为“我测了啊，我真测了”的博客，回忆起之前在隐私项目上遇到的问题，现在凭借回忆记录下来。
先简单介绍一下隐私项目的背景吧，2018年欧盟提出了最严格的数据保护条例GDPR（General Data Protection Regulation），为某大型运营商公司提供的隐私合规解决项目。今天聊到的问题，主要涉及向门店及供应商收集隐私合规信息的调查问卷这一环节。
对于需要填写调查问卷的用户，可以自行通过邮箱或手机号申请账号，而对这些账号规则的不熟悉，最终导致我们遇到了两个账号相关的线上问题。
第一个问题是在，在我们开发了一个月，完成了MVP功能后，第一次上线时暴露出来的。
经过了从周五到周日的难产式上线，终于在周一的早上开发通知我，可以进行线上回归验证了。由在开发现场的客户创建了一个调查问卷模版，另外的业务方赶去了最近的门店，指导一线人员填写问卷。而客户在门店反馈，填写问卷提交时，提示没有权限。我们在提交问卷时，做了权限校验，要求提交问卷的账号必须与系统中存储的门店员工账号一致。我们的第一反应是，找客户要了门店人员的账号，对比数据库中保存的账号，发现二者存在大小写不一致的情况。这个时候，幼稚的我建议客户，让一线人员修改账号的大小写后，重新登录。当然，还是提交失败了。
这个时候我才想到试着自己去申请账号，发现在申请账号时，的确不会做大小写的校验。你一定会问了，难道之前测试的时候，没有申请账号吗？
之前的测试中，我的确没有去申请账号，整个测试过程只使用了一个开发初期PM用手机号申请的账号，而这个账号本身是不包含字母的，当然也就不会涉及大小写字母的校验了。
至于为什么用户在提交调查问卷时获取的账号（账号1）与我们数据库中保存的账号（账号2）存在大小写不一致，由于数据来源不同，账号1源自账号系统，而账号2源自门店系统的信息。
对于这个问题，紧急补救措施是，去除了权限校验中完全一致的要求，对于账号的对比放开大小写限制。虽然问题从发现到解决并没有花费很长的时间，但是的确对我们的第一次上线带来了一定的影响，现在想来，当时客户对我们也是颇有微词。好在有惊无险，项目继续进行了下去。
经过第一次上线的乌龙事件，我在第一时间申请了多个包含不同字符的测试账号，在测试时也会有意识地替换账号进行测试，并且更新了给项目组全员分享的测试账号合集。自以为万无一失了，并且之后并没有关于账号的线上问题。
直到系统在线上开展了区域性的试用，用户的增加使得关于账号的新问题出现了。
业务人员反馈，某个用户在登录系统后并没有收到填写问卷调查的待办信息。我首先查询了数据库，确定的确有这个用户的待办数据。然后又指导用户通过chrome浏览器的检查功能查看接口返回，接口没有报错，返回体也的确为空。又是传说中的，只有生产环境才能出现的问题嘛？
我的分析行不通，只能让开发查看生产日志，终于发现了这个问题的原因。用户的账号信息存在两个唯一标识的字段，ID和username。待办相关的查询接口，在返回待办信息时，会根据账号做数据权限隔离。即用户只能看到自己名下的待办信息。数据库中保存的账号为用户的ID，用户登录后我们获取了用户的username，根据username去查询当前用户的待办事项。这难道就是传说中的骑驴找马？这个骑驴找马为什么能够正常运行一段时间呢？是因为系统中的多数账号，ID和username是一致的，其他一些通过特殊方式批量申请的账号，会存在ID和username不一致的情况。而使用这种账号的用户，在我们现在的实现逻辑下，当然是收不到自己的待办了。倒是有可能收到别人的待办。
第二个问题的暴露，让我们对之前所有涉及到的账号检验等等进行了分析，代码修复，验证。当然，我的测试账号又丰富了不少。
这两个关于测试账号的问题，可能只是我在测试过程中遇到的数据相关的两个代表性的问题。但是偶尔想起来，真的是警钟长鸣啊。
网友评论