一次深究Bug根源的案例

前段时间，一同事在修一个Bug。修的过程，我发现是一个很典型的案例，就拿出来和大家分享。

登录页面有一个业务逻辑，如果输入密码出现 4 次错误，第 5 次尝试登录时，你除了要输入用户名密码，还需要输入验证码。如下图：

但是，我们看到，验证码是个什么鬼东东，是个人都无法看懂。

接到这样的Bug，你该怎么下手呢？

以下是同事的排查过程，经整理如下：

1. 确认是否所有的环境都出现同样的问题：环境一没有问题，但是环境二有问题。

2. 确认验证码逻辑位于系统中的哪个模块？也就能找到该模块的代码仓库。

3. 找到正在运行的模块的代码版本。环境一和环境二运行的代码不一定是同一份代码。也就是可能是不同版本的代码。也要注意，环境二运行的可能不是最新代码。所以，具体运行的是哪个版本的代码，要不问人，要不登录到环境二的机器上查。如果有自动化构建和自动化部署，直接从部署记录中可以查到模块对应的代码。

4. 找到验证码相关逻辑代码，然后观察它的最后修改时间。如果是长时间没有被修改的代码，大概率说明它是没有问题的。因为它都运行几年了，还出问题？早出问题了。我们通过 IDEA 的 anotate 功能 

5. 然后发现代码真的很久没有人修改了，而且我们发现，逻辑也很简单，就几十行的代码。没有看出明显的问题。

6. 代码概率没有问题了，这时，我们就查环境的问题了。我们把环境二的包拿到环境一运行，验证码显示正常。这时可以确定代码本身是没有问题的。

7. 对比两个环境的差异：JDK 和 操作系统的版本都不一样。这时，然后，我们重新搭建了与环境二一样的环境，同样的 JDK 和操作系统。这时，依然没有重现问题。

8. 同事头大了。

9. 最后怀疑是字体的问题。查看了一下环境二的字体，只有两款字体。而自建的环境有不下10款字体。为了快速验证是否为字体的问题，同事直接把自搭建的环境下的所有字体拷贝到环境二。问题解决了。

深究Bug根源

虽然，同事是解决了环境二的问题，但是，将来部署到去环境三，环境四，可能会遇到同样的问题。

现实中，我们常常听到测试说：为什么在测试环境没有问题，一上生产就出问题。然后开发或者运维人员一查，发现问题是两个环境之间的配置不一致引起的。这类Bug 数不胜数。

如果不深究这类Bug的根源，并把问题根源铲除，这类Bug还会一再的出现。谁知道下次的Bug是不是因为环境二的机器 JDK 的小版本不一样。

想要根本解决此类问题，笔者认为需要在团队中做到以下几点：

1. 尽量保持所有的环境一致；

2. 环境之间实在做不到一致的地方应该是方便可查的。

至于具体怎么做？请关注微信公众号：老翟杂谈。