微软Zune闰年BUG分析

最近在网上看到一篇帖子，得知了当年微软zune 的历史留名的 bug，具体事件的起因发展和结果我就不多说了。找到了出现 bug 的源码，分享出来。

while (days > 365) {
      if (IsLeapYear(year)) {
        if (days > 366) {
          days -= 366;
          year += 1;
        }
      } else {
        days -= 365;
        year += 1;
      }
    }

这段代码是zune 内置的日期更新驱动里面的，作用是处理一下由于闰年引起的年份更新问题。结果非但没解决问题，还造出了一个历史留名的 bug。

方法的设计思路是这样的。当天数大于365时进入 while 循环，如果年份是闰年，则判断是否超过366，然后进行年份和天数的增减。非闰年情况直接进行年份和天数的增减。

程序员的想法完全没有问题，但在判断是闰年后，选择是否增减的条件却是有点异想天开了。因为在外层的 whlie 循环的days 的值是大于365，但是 while 循环的内部，处理的 days 值却是大于366。在当闰年 dsys=366的情况并没有处理，结果就导致了此次历史级的 bug 的产生。

虽然无法复盘 bug 是如何产生的，但却给测试提了个醒：越是基础的测试、越不能丢。因为这个 bug 的影响范围足够大，产生 bug 的代码足够简单，测试难度足够低，所以在历史上留名也不足为奇。

再次多说一些边界值。如果要测试这段代码，在设计用例时，考虑两个因素。一个年份一个天数。年份暂且考虑IsLeapYear()的 false 和 true两个值。天数考虑在边界值365、366、367，三个边界值在数轴上划片，然后取值。然后再和年份进行组合，就可以得到需要的测试用例。

点击阅读原文，有兴趣的童鞋可以一起交流