程序员的踩坑经验总结（一）：如何把Bug的偶现变必现

程序员的踩过的坑也是可以分类的，很常见又很难解决的一类是偶然的现象，表现起来比较怪异。

而把一个问题Bug的偶现变成必现，是开发人员的一种能力。我认为也应该是测试人员的一种能力，但是各个公司要求不一样吧。我在华为做过测试，虽然时间过去很久了，但是当时学到的方法影响至今。总之还是那句话，对你要求高的才让你成长更快，所以不要辜负对你严格的人！

 

最近有几个Bug和小伙伴成功的从偶然的现象变成必然的现象，所以还是记录下这种有成就感的心情吧。早在华为测试的时候就可以帮开发定位问题了，后面到现在公司也时不时的把Bug的偶现变成必现，而现在带人了更多的是传授经验。

 

案例一

应该在去年最后一个季度，我们有个现场的Bug很怪异。时不时的有些文件出现乱码，我们是音视频文件，很大几百M，有特定的格式以便于读取。这些乱码的文件就是不按规则来，导致整个文件读不了！也不是所有的目录下，也不是一个目录下所有的文件，就是时不时冒出来捣乱！初看，就像是个非常顽皮孩子和你躲猫猫！

我和小伙子说，看日志吧。“日志都很正常”小伙子回答。我又说“那就加日志吧”，小伙子一脸懵懂。我对日志应该用“高度重视”这个词，我认为日志是除了代码外第二大武器，调试和定位的强大武器。有时间可以写写日志！当然这个见仁见智了，有人喜欢gdb、windbg，这都没问题。不过话又说回来，日志在系统软件还是应用软件都是遍地开花！你看着办：）回到正题，我和小伙子一番讨论后，小伙子加了日志。我记得小伙子第一次对文件和缓冲区进行读写操作，很是陌生，因为代码还是我们老一代人写的。文件怎么循环读，缓冲怎么循环写，哈哈。现在应该都没问题了。所以有Bug没什么，我认为快速锻炼一个人有两种途径，项目开发和改Bug。日志慢慢的能用上了，重新编库、替换库、运行和等待。小毛孩终于被逮住了。

原因是和视频源的操作有关系，这个视频源带有音频，而且时不时的被操作和被修改！而就在修改的时候，文件的偏移量也被重置了。懂文件的知道了，一旦偏移量错乱了，后面全跟着变了。这里的关键是日志如何加，需要根据文件的特点，我们文件大部分是顺序写，有一部分是随机写。日志的添加就是要根据变化的时候，记录各个变量。而这个Bug还有一点点规律，就是乱码从除了文件头信息后的地方开始错乱的。所以每次变化的时候重新seek文件，是否从这个位置开始的，一旦使这里开始就加ERROR级别的日志。只要后面一旦出现就可以逮捕了！

后面再回到看代码，发现确实是seek出问题了！查历史记录，有改动，考虑新加驱动库和元数据类型两种的情况，却没有考虑通用的情况！好吧，而改动之时我正在休产假了。通用的情况都忘了考虑，怎么会偶现呢？问题的根源还是和音频有关，在我们行业音频一般用的不多，绝大部分是视频业务。所以，按一般常规的测试，再加上新加代码估计都没有进行回归测试，更不用说有音频的回归测试了，问题就这样拖到了现场。

只要原因找到了，后面解决起来就当然容易了。而这个时候，我再看了下原来的日志，其实是有提示音频的变化的，只是级别不高。所以当时我再次叮嘱”多看日志“！

  

案例二

最近，有个现场的项目在视频回放的时候出现了崩溃！也没发现规律，正常操作都不会，无规律非常频繁的操作控制视频回放偶尔出现。

用gdb分析CORE文件，崩溃的位置是回放退出时释放内存的时候。“嗯，内存越界了！”当时我意识到。可是小伙子开始对着释放内存的函数左思右想，和我探讨，是不是该处指针用的不对。但是从代码分析，上下文都很很正常。“你想想正常情况下，这里没问题，对吧。出现越界不一定是最后的指针的问题，而是之前就被其他给破坏了，真正要释放时发现该处内存无法访问了。所以还需要看其他变量的值”我于是说。小伙子再次打印this指针下各个变量的值，发现帧长度明显不对，竟然长达6M多。事实上一般较长的I帧也就200K左右，相差几个数量级。

看日志，其实已经有打印帧长度达到6M多了（再次论日志的重要性）！下一个问题，原因是什么，为什么会有6M多呢，基本不可能的事。搜索有关帧长度所有的变量使用。原来是从网络接收的时候，大小端变化的函数被改变了位置，往后挪了！先使用了变量（这时的变量就是一个异常的值）再转换。那不出问题才奇怪呢！那为啥正常情况下没有？这段代码是后面加的需求，我们的帧类型加多了。所以这是不同一般的帧类型，是智能元数据。当然可以再总结下，论代码审查的重要性！而上面的Bug也是因为新加代码导致的。

其实内存越界不太好查，有点神出鬼没，不知道哪个时候就破坏了内存。这次其实还算好！日志有打印6M的异常。而且崩溃的堆栈显示几次都是同一个地方，说明局部性原理用的还可以。

 

写到这里有人会说，你没有把偶像变成必现了！哈哈，都找到原因了，需要重现还不容易吗？

偶现变必现其实是把测试输入范围或者说输入条件缩小甚至是固定到某个条件或者某种情况。

不是模模糊糊的，对输入条件一问三不知，“我就测试出问题了！？”测试还怼开发。我曾经还多次碰到过测试提的问题，结果发现是测试环境都搞错了。好了，不吐槽了。造成这种现象和公司氛围有很大关系。

再回到开发，其实回来再看上面两个问题，现象很怪异，但是结果和原因都很简单。所以总结一句：怪异现象的背后总有一个愚蠢的初级Bug。这句话引自一位高人，我深以为然。自己常说的是，看上去越诡异的现象，背后的原因往往越简单。事实上，我们经常碰到一些：配置项不对，乱象丛生的问题，有时甚至系统都跑不起来。

所以也不用太担心，多分析日志，当然前提是：多做代码审查、多加有效的日志！

对测试的建议是多了解业务背后的原理和逻辑，可以多去参与问题的分析和定位。

希望对你排查问题有所帮助！