服务器重启后,Bug又重现了

作为测试人员,你碰到过难重现的Bug吗?在你提交一些Bug后没碰到重现,一定听过开发的这些“小讽刺”吧?捕风捉影、神经过敏、看花眼了、你设备的兼容问题……

一旦问题多次未能重现,会被关闭掉,也就渐渐被忽视,被遗忘。不定时炸弹埋在了代码里,指不定上了生产,某一天会悄悄地爆发了。

我们有一个PC客户端,用户登录后有一个列表,列明了当前可用的“房间”,房间后面跟着“进入房间”按钮,用户点击按钮,则进入到房间。类似于QQ棋牌类游戏,那种在大厅里点击某个座位就可以到棋牌间了。

业务这块本身很简单,预期结果就是点击按钮后能进入到房间。但是在测试时,就有那么一次,点击了“进入房间”按钮,突然软件“闪退了”。是的,桌面应用也闪退了;不过查看任务栏管理器发现该软件的进程还在。可惜,当时测试没有保护现场,立即杀了进程后重新登录;再点击后,发现又成功进入了房间。

重试多次,一直都是能成功进入,未能重现问题。于是,这个问题也就得不到重视,淹没在忙碌的项目进度中,优先级逐步降低。最终,把“软件可能闪退”写到风险中,带着遗憾让系统上线了。

上线后自己多次尝试,包括用户一直也在使用,结果都没有碰到类似问题。忐忑不安的心,也就渐渐平静下来,也许当时只是电脑的操作系统抽风了呢(一般碰到了无法解释的现象,把问题推给底层的操作系统总是一个不错的策略)。

只是该来的问题也许会迟到,但是不会缺席。不知道该说是真巧还是真不巧,有那么一天,多台设备突然都碰到了上述问题。而且杀进程重新登录后,也还是不能解决。

排查日志后,发现停在mqtt连接这里,后续日志就断了;因为没有成功打开房间,所以日志停在了这里,也算是一种说法,但是对于解决问题没有帮助。

而同时在公司内部打开软件使用,发现竟然是正常的。那么,有理由怀疑:被用户电脑的杀毒软件屏蔽了,或者网络不稳定等。

开始调接口排查,可是发现相关接口其中有一个无法访问。

继续检查服务器,服务器运行是正常的,也没有给出过预警。可为什么外网的情况下就访问有问题呢?工作日志表明mqtt的这台服务器不久前重启过。服务器重启,并未改代码未改架构,为什么会影响了现有软件?

心底一阵激动:离真相应该越来越近了~~

多方会诊之后发现:原来防火墙设置开机自启动,服务器重启自动打开了防火墙,而且防火墙级别很高,把所有外网的访问都屏蔽了。导致在公司内部使用软件一切正常,但是在客户方使用时就是打不卡房间。临时解决方案是把防火墙级别修改了一下,这样软件什么都没有改动,又可以正常使用了。而后开发在配置文件中把对应的mqtt由IP访问改为域名访问,提高稳定性,重新打包软件发版。

由于项目时间紧张,大部分时候对功能本着“已经能用了”就Release出去,缺乏精雕细琢。而经过时间的洗涤,一些异常会在无法预料地时候出现,之前没考虑周全欠下的债,终究还是要还的。

测试和开发回头再看这个问题,其实最佳的重现方法是通过白盒测试,如果把mqtt服务的返回设为异常,就可以看到问题。在测试过程中,也可以尝试把mqtt服务关掉,再到PC端进行进入房间的操作,不能假设mqtt的服务一直能成功连接这么“理想”。再拓展一下,进入房间还依赖了很多第三方的服务,如果第三方的服务异常,也应该及时提示,明确提示,而不是让软件突然不明不白地消失了。“不要让别人的错成为你的错”,不能因为依赖的服务不可用而让自身的程序变成有问题;涉及第三方调用时,一定要假设服务不可用时“保住自身”,不能影响自己的软件。

而从测试的角度,也有几点启发:

仔细对待每个功能,由点拓展到面,对功能上的设计逻辑也要了解一些,在测试用例的设计和实际操作中,异常的情况多考虑些进去,及时发掘出隐患。

可以敦促开发多记录一些Log、对服务进行持续监控、对服务器的基本设置与网络的访问一定要处理好,方便后续追踪定位问题。

面对问题,一定要有寻根究底的毅力和勇气,推动团队一起把问题解决于上线之前。

测试人员需要对软件的健壮性和可靠性多多关注。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180320B19OMR00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励