无奈而又苦逼的二分版本回退法定位新引入的bug！！！

       昨天测试人员和开发人员都发现， 某新版本有严重的bug.  群里已经开始嚷嚷了， 但没有谁知道是谁引入的问题。本来呢， 这个问题不应该是由我去定位， 但主管让我帮定位一下， 毕竟时间太紧急， 必须尽快解决， 开始的时候， 我还是有些压力的跟有经验的员工讨论后， 也没有比较好的办法， 所以， 只能自己想办法了。为了方便叙述， 下面我会对实际场景进行抽象。

       经我亲自验证发现， 100版本绝对ok,  300版本却有问题， 也就是说， 是这个之间的某个版本引入了bug.   因为这个问题比较难以定位， 所以查看配置库的修改记录就成了当前唯一可行的办法。 

       但是， 仔细反复看了这个区间的修改记录， 没有发现有可疑的异常情况， 所以只能采取二分查找验证了， 只是每次验证都至少要15-20分钟， 而且每一个步骤都不能出错。问题是， 模块较多， 是回退某一模块还是回退所有模块呢？ 根据bug的现象， 确实难以分析出出问题的模块所在。

       怎么办？ 我和另外一个有经验的员工首先分析了出问题可能性最大的两个模块， 昨天下午开始， 对其中的一个模块（第三方库）进行版本回退测试， 没有发现有异常， 而且单一模块回退多了， 很容易造成编译不过（其他模块不回退）， 各种郁闷和苦逼啊 搞到凌晨还是没有搞出来， 好吧， 太累了， 先回家睡觉。

       今天呢， 我必须单独搞定这个问题， 于是我对另外一个可疑模块进行回退测试（其余模块都采用最新代码和库）。 边回退， 边记录结果。我取这个可疑模块的第200个版本进行测试， 发现ok,  这个时候， 就有点高兴了知道问题基本就锁定在这个模块了， 于是花了3个多小时进行二分回退验证， 搞了7， 8次吧， 最后锁定了修改引入问题的版本， 铁证如山。结果查看修改记录后， 傻眼了， 该代码提交人仅仅改了一个单词。 好吧， 虽然我不清楚问题的具体原因， 但我证据充分地定位到了问题， 让对应的人修改（最后他发现， 也确实有问题）。

       二分版本回退法是最无奈的办法。 哥们， 以后修改问题要注意啊， 不要引入新的问题搞我辛苦一大天， 还搞到凌晨。

       最后，要强调一下： 定位问题， 思路很重要， 不然搞几天都有可能搞不出来， 自己误导自己。  这次定位bug, 虽然过程很繁琐很苦逼，但还是很开心的， 定位出了一个严重的bug, 能让版本顺利发布。

       噢耶

       补充说明： 有的网友反馈， 你可以加日志定位啊。 其实， 原bug的现象就是： 该系统没有日志输出