微軟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