最近在網(wǎng)上看到一篇帖子，得知了當(dāng)年微軟zune 的歷史留名的 bug，具體事件的起因發(fā)展和結(jié)果我就不多說了。找到了出現(xiàn) bug 的源碼，分享出來。

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

這段代碼是zune 內(nèi)置的日期更新驅(qū)動(dòng)里面的，作用是處理一下由于閏年引起的年份更新問題。結(jié)果非但沒解決問題，還造出了一個(gè)歷史留名的 bug。

方法的設(shè)計(jì)思路是這樣的。當(dāng)天數(shù)大于365時(shí)進(jìn)入 while 循環(huán)，如果年份是閏年，則判斷是否超過366，然后進(jìn)行年份和天數(shù)的增減。非閏年情況直接進(jìn)行年份和天數(shù)的增減。

程序員的想法完全沒有問題，但在判斷是閏年后，選擇是否增減的條件卻是有點(diǎn)異想天開了。因?yàn)樵谕鈱拥?whlie 循環(huán)的days 的值是大于365，但是 while 循環(huán)的內(nèi)部，處理的 days 值卻是大于366。在當(dāng)閏年 dsys=366的情況并沒有處理，結(jié)果就導(dǎo)致了此次歷史級(jí)的 bug 的產(chǎn)生。

雖然無法復(fù)盤 bug 是如何產(chǎn)生的，但卻給測試提了個(gè)醒：越是基礎(chǔ)的測試、越不能丟。因?yàn)檫@個(gè) bug 的影響范圍足夠大，產(chǎn)生 bug 的代碼足夠簡單，測試難度足夠低，所以在歷史上留名也不足為奇。

再次多說一些邊界值。如果要測試這段代碼，在設(shè)計(jì)用例時(shí)，考慮兩個(gè)因素。一個(gè)年份一個(gè)天數(shù)。年份暫且考慮IsLeapYear()的 false 和 true兩個(gè)值。天數(shù)考慮在邊界值365、366、367，三個(gè)邊界值在數(shù)軸上劃片，然后取值。然后再和年份進(jìn)行組合，就可以得到需要的測試用例。

一起來~FunTester

轉(zhuǎn)載于:https://my.oschina.net/u/3973795/blog/3082606

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。