程序员的踩坑经验总结（一）：如何把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。这句话引自一位高人，我深觉得然。本身常说的是，看上去越诡异的现象，背后的缘由每每越简单。事实上，咱们常常碰到一些：配置项不对，乱象丛生的问题，有时甚至系统都跑不起来。

因此也不用太担忧，多分析日志，固然前提是：多作代码审查、多加有效的日志！

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

但愿对你排查问题有所帮助！