最近在網上看到一篇帖子，得知了當年微軟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，三個邊界值在數軸上劃片，然后取值。然后再和年份進行組合，就可以得到需要的測試用例。

一起來~FunTester

轉載于:https://my.oschina.net/u/3973795/blog/3082606

總結

以上是生活随笔為你收集整理的微软Zune闰年bug 分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。