微软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两个值。天数考虑在边界值36五、36六、367，三个边界值在数轴上划片，而后取值。而后再和年份进行组合，就能够获得须要的测试用例。

一块儿来~FunTester