测试平台系列(146) 修复一个隐藏的bug

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第30天，点击查看活动详情

大家好~我是米洛！
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的教程，希望大家多多支持。
欢迎关注我的公众号米洛的测开日记，获取最新文章教程!

回顾

上一节我们彻底完成了录制生成相关的功能，但其实在越来越多的人知道pity以后，有不少人遇到了部署相关的问题。

所以卫衣哥出面帮我编写了一个docker配置，里面不仅包含了MySQL，还包含了Redis，大大降低了部署中遇到的问题。

不过就在他制作镜像的时候，遇到了一个奇葩问题：页面一直重复登录。

这可把我难倒了，我们总结一下现象: 页面好像判断用户已经登录了，又判断用户没登录，所以一下让用户到主页，一下又切到登录页，后端接口则一直在无限重复请求。

于是我开始梳理登录这块的逻辑，视图找到问题的关键所在:

我一开始想到的是redis，因为我们的用户数据会缓存一层。如果redis开启，数据库没值，也会校验通过，但卫衣哥说redis早就清空缓存了。

不过他又给了我个提示: 他的数据库是没数据的。

我反复检查了前端代码，基本判断不存在死循环的问题。那也就是说，只有这一种可能了？

token校验通过了，但是没有给出具体的返回，或者说没有报错，导致前端认为token还是ok的，进入主页再次校验，发现没拿到数据库的用户信息，就导致2个步骤，1个对1个不对，无限循环了？

我们看看后端代码，就恍然大悟了:

之前没有这多余的2行，由于卫衣哥传入的token是确凿的，我们系统能解析的，解析完毕之后拿到了user_info，我们这边去db二次校验获取user，我们也没有检查user是否存在，也就是说接口并不报错。

最终就导致了悲剧的发生: 小区大门保安让进了，小区单元楼不让进，让你去保安那拿钥匙，无限循环了。但一般情况不会出现，所以很难发现。

所以改善的地方就是: 加一个用户是否存在的判断即可:

if user is None:
    return PityResponse.failed("用户不存在")
    # 或者直接抛出异常
    # raise Exception("用户不存在")

还要记得，我们是有一个Depends的中间件的: Permission，这个里面同样需要改造一下:

这里我们也是只解析了用户token，没有校验数据库是否真有这个用户。

也就是我们把__call__改成async模式，接着对用户查询一次即可。

今天就是本节的bug案例了，最新的部署文档和代码都已经提交了，欢迎大家鞭打~其实这之后我又发现我们的response提取参数用不了了，我真的会谢。

                                                          不愧是bug王子

我只想说：回归测试真的很重要，有时候我改着改着老功能就不行了，尽管你对系统再熟悉，也有疏忽的时候呀！！！

希望大家引以为戒，认真对待测试~~