【原创】二麻子,听说你出 Bug 了?

2021-11-11  sylan215 

“二麻子,听说昨天你系统上线后出了个大 Bug?”

“真是好事不出门,坏事传千里,你这么快就知道了?”

“必须的呀,我对其他事情不敏感,但是对 Bug 有天生的感知力。”

“切!”

“赶紧说说出了啥 Bug,好让我乐乐。”

“简单的说,就是页面提交的 Bug,就是前端提交数据到后台时,没有保证数据的一致性。”

“还是一头懵,再说详细点吧。”

“那我给你说下测试步骤应该就知道了:

1、打开系统某一个任务的编辑页面,并启动编辑;
2、接着再打开同一个任务的另一个编辑页面,并且在编辑完内容后提交到后台;
3、返回到第一步打开的页面中继续进行编辑,提交完成后检查操作结果。
预期结果是在第二步更新完的基础上更新了步骤三的结果,但实际上步骤二的结果完全被步骤三给覆盖了。”

“嗯,这么说我就明白了,这是典型的并发冲突的问题吧,应该是前端在启动编辑的时候从后台拉取了数据,然后提交的时候没有去检查后台是否更新,就直接把前端数据提交了,这个过程中如果没有其他并发,是完全没问题的,一旦有其他并发操作,必然出问题。”

“对对,就是这个问题,后来我看了下代码实现,就是在展示的时候拉取了数据,编辑后,直接把展示时拉取的数据又全部提交了,这么做就是为了省事,因为数据库设计时,是把整个表单的内容存放在一个字段里面的,如果只更新其中某一部分内容,还需要把这个字段进行拆分解析。”

“这么说最终是数据库设计不合理了?”

“问题肯定还是前端(后台接口)实现的问题,再麻烦也不能出问题是吧,至于说数据库,设计上确实可以优化,如果用 MongoDB,因为有格式化存储,一个表单存放在一起还是可以接受的,如果是 MySQL,最好还是分表存储更清晰易操作。”

“那最后是怎么修改的呢?”

“两步走:第一步先把本次问题解决了,就是只把修改内容传到后台,后台从数据库中获取内容并更新,再塞回数据库;第二步,把数据库迁移到了 MongoDB,这样后面更新任意字段数据时,都可以快速单独操作更新了,简化了后台对数据处理的复杂度。”

“嗯,感觉这个场景还是挺常见的,后面所有涉及表单提交的地方,都需要考虑这种并发操作的用例了。”

“是呀,和这个类似的,我还可以提供一个典型案例供参考。”

”好呀好呀,我就喜欢一线的实际案例。“

”大家都知道 MySQL 的数据记录有一个自增 id 的功能,特别方便,MongoDB 也有这样一个 field,但是 ObjectId 类型,可读性不太好,所以有些设计会额外增加一个 id 的 field,只是这个 field 不会自动自增,需要每次插入数据时显式指定。“

”听起来这没毛病呀,会有啥问题?“

”这么用是没毛病,但是这个自增 id 在什么时候计算直接关系到它是否会出毛病。“

“愿闻其详。”

“比如还说表单提交吧,一般这时候是新建表单,如果是 Bug 管理系统,那就是新建 Bug 的步骤,如果我们在点击新建 bug 按钮时,就去获取数据库中最新的 id,并 +1 后当作本次 id,这样就有问题了,比如这个 Bug 还在编辑,其他人也点击了新建 Bug,同时获取了 id,糟糕,这两个新建操作的 id 就重复了。”

“哦……明白了,但是这么明显的问题,应该没人会犯吧。 ”

“那可说不定哦,特别是当前端和后台开发人员不是一个人时,出现这种错误的概率会更高。”

“嗯,不管怎么样,这个用例都是肯定要覆盖的了。”

“如果用 MySQL 的话,基本不会出现这个问题,它的 id 是自己管理,不需要显式传入,但是 MongoDB 就得特别关注了,所以可以根据不同数据库,针对这个用例设置不同的优先级。”

“对对,我得赶紧回去问问我们开发用的哪个数据库。”

“别急呀,是你的 Bug 它也跑不了,先把我文章转发朋友圈让更多人看到。”

“得,必须的。”

以上,我通过两个简单的场景,说明了 Web 表单提交时,常见的一类问题,一般稍有点经验的开发,都不会犯这种低级错误,但是作为测试,我们不能忽略任何一个可疑点不是?欢迎留言说说你是否碰到过类似的问题。

当然, 如果你认同我的观点,欢迎分享文章到朋友圈 + 点个「在看」让更多人看到,谢谢。

55°|558 人阅读|0 条评论
登录 后发表评论