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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而从测试的角度，也有几点启发：

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

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

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

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