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

2022/6/28 测试平台接口测试FastApiPythonReact

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

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

# 回顾

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

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

# 隐藏bug

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

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

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

    1. 当用户进入页面的时候,尝试获取用户的登录态,如果是未登录则弹到登录页面
    1. 如果是已登录,进入页面后我们会再度校验用户的token是否已经过期,如果过期则又把他弹回登录页,或者token不存在也是如此

# 反复检查

我一开始想到的是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("用户不存在")
1
2
3
4

# 还有问题

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

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

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

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

                                                          不愧是bug王子

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

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