模板
教程
環境
性能
功能
管理
現代軟件工程講義 9 測試 關于閏年的測試(2)
被 100 整除, 同時被400 整除的年份
被 4 整除, 但是不被100 整除的年份
被 4 整除, 同時被100 整除的年份
偶數, 不被4 整除的年份
奇數年份
其它非法輸入的年份
程序員都知道程序經常在邊界條件附近出錯, 針對IsLeapYear(), 你可以得出下面兩個測試用例:
設計允許的最小的年份
設計允許的最大的年份
啊, 設計中沒有考慮這個? 那這個設計要出現問題。 在1950-70 年代, 很多程序用兩位數字表示年份 (00 – 99), 那些聰明的程序員認為這已經足夠了, 沒想到這些程序和設計影響了很多要和它們兼容的程序 (就像 Excel 要兼容 Lotus 1-2-3 那樣), 到了1990年代后期, IT 業花了很多人力物力來解決 Y2K 的千年蟲問題。 一些程序員非常鐘愛的 UNIX 操作系統 (32 位) 也有自己的千年蟲問題, 它會發生在 2038 年! 到時候人們還會用32位的機器么? 也許在一個大家想不到的關鍵部位, 一些老舊的, 嵌入式的 Unix 系統會悄悄地發作…
除了從外部的輸入/輸出來設計測試用例, 我們也可以從內部考慮, 看看這些測試用例是否把所有語句都覆蓋了。 但是要注意, 即使所有語句都被測試用例覆蓋了, 程序還是可能出錯!
例如, 我們測試 NumberToYear(), 分析它的各個條件, 我們推算出我們的數據要覆蓋下面一些情況:
輸入的 day 大于 365
輸入的 day 小于 365
輸入的 day 大于 366 并且1980 年到那一年中, 至少有一年是閏年, 例如輸入一個2008年的某一天。
輸入的 day 大于 366 并且1980 年到那一年中不包括閏年。
這樣是不是就把所有路徑都包括了? 程序就沒有錯了?
不巧的是, 這個程序用在了某著名公司的產品上, 出品的前兩年沒什么事, 到了2008 年的最后一天 (那一年有366 天), 出了一個問題:
年份一直增加到了 2008, 這時候, day == 366, 我們看看循環能做下去么?
if (IsLeapYear(year))
{
if (days > 366) //day == 366, 不滿足條件
{
days -= 366;
year ++;
}
所以 day 沒有減少, year 也沒有增加, 循環又繼續下去, 任何條件都沒有改變, 進入了死循環!
不幸的是, 這個程序經過了種種測試, 進入了市場. 于是, 在2008 年的最后一天, 許多用戶發現他們的 Zune Player (只限于 Zune 30 型號) 開機之后就進入死鎖狀態…
http://www.usatoday.com/tech/products/2008-12-31-zune-mystery_N.htm
http://www.zuneboards.com/forums/showthread.php?t=38143
官方的說法是 - 大家等到明天就好了!
如果你是一個測試人員, 你應該增加什么測試用例呢? 如果用邊界條件分析, 應該有至少 4 個新的測試用例:
閏年的第一天;
閏年的最后一天;
平年的第一天;
平年的最后一天
對于程序員, TA 應該如何修改代碼?
錯誤之三: 沒想到還有閏年
在IT 行業混了很多年的好處之一就是你可以看到不少 bug. 下面又來了一個:
Windows Home Server與客戶端connector第一次連接時，需要Server為connector頒發安全證書。出于某種實現上無法避免的原因，客戶端的證書日期一定要早于Windows Home Server，否則生成證書的函數會fail。Windows Home Server是2007年7月RTM的。為了方便起見，設計中規定，給客戶端生成證書的函數使用2006年作為年份。
<完整的故事 link: http://yishan.cc/blogs/lilei105/archive/2008/03/03/885.aspx>
作為一個程序員, 你如何實現這個設計呢? 一拍腦袋, 就取當天的日期, 然后把日期中的年字段改成 2006, 不就行了么?
然后到了 2008/2/29 這一天… 程序把日期改成了 2006/2/29. 然后就悲劇了.
軟件團隊在自問: 為啥我們當初沒測出來? 如果你是測試人員, 你會想到這個測試用例么?
原文轉自：http://www.anti-gravitydesign.com
