編號 | .001 注:“. 編號” 部分要從001編號開始一直到999,個人自行編號 |
程序設計人員 | 如:葛志春 |
測試人員 | 如:葛志春 |
測試目的 | 如:對錯誤邏輯輸入檢驗 |
測試內容描述 | 如:對于public int fun3(String p1, int p2 )的輸入檢驗,如果 p1 == null ,程序中檢驗到,應該記錄到系統 logfile, return –1; |
輸入期望 | P1 == null |
功能處理期望描述 | Logfile 多一條歷史記錄,方法return -1; |
輸出期望 | Return –1 |
單元測試結果 |
|
實際輸入數據 | P1 = null |
實際處理情況描述 | 程序沒有進行p1 == null 的驗證,沒有及時return –1,而是運行到 p1.aaa( ) 方法時出現 null pointer 異常。 |
實際輸出 | 沒有寫 logfile 文件; |
測試結論 | 正常 / 異常 |
表2
4.2 測試類設計
一個模塊或一個方法(Method)并不是一個獨立的程序,在考慮測試它時要同時考慮它和外界的聯系,用些輔助模塊與所測模塊相聯系的其他模塊。這些輔助模塊分為兩種:
1. 驅動模塊(driver):相當于所測模塊的主程序。它接收測試數據,把這些數據傳送給所測模塊,最后再輸出實際測試結果。
2. 樁模塊(stub):用于代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作,不需要把子模塊所有功能都帶進來,但不容許什么事情也不做。
所測模塊與它相關的驅動模塊及樁模塊共同構成了一個“測試環境”,如圖2。驅動模塊和樁模塊的編寫會給測試帶來額外的開銷。因為它們在軟件交付時不作為產品的一部分一同交付,而且它們的編寫需要一定的工作量。特別是樁模塊,不能只簡單地給出“曾經進入”的信息。為了能夠正確的測試軟件,樁模塊可能需要模擬實際子模塊的功能,這樣樁模塊的建立就不是很輕松了。
圖2 單元測試的測試環境
編寫樁模塊是困難費時的,其實也是完全可以避免編寫樁模塊的;只需在項目進度管理時將實際樁模塊的代碼編寫工作安排在被測模塊前編寫即可。而且這樣可以提高測試工作的效率,提高實際樁模塊的測試頻率從而更有效的保證產品的質量。但是,為了保證能夠向上一層級提供穩定可靠的實際樁模塊,為后續模塊測試打下良好的基礎,驅動模塊還是必不可少的。
對于每一個包或子系統我們可以根據所編寫的測試用例來編寫一個測試模塊類來做驅動模塊,用于測試包中所有的待測試模塊。而最好不要在每個類中用一個測試函數的方法,來測試跟蹤類中所有的方法。這樣的好處在于:
1. 能夠同時測試包中所有的方法或模塊,也可以方便的測試跟蹤指定的模塊或方法。
2. 能夠聯合使用所有測試用例對同一段代碼執行測試,發現問題。
3. 便以回歸測試,當某個模塊作了修改之后,只要執行測試類就可以執行所有被測的模塊或方法。這樣不但能夠方便得檢查、跟蹤所修改的代碼,而且能夠檢查出修改對包內相關模塊或方法所造成的影響,使修改引進的錯誤得以及時發現。
4. 復用測試方法,使測試單元保持持久性,并可以用既有的測試來編寫相關測試。
5. 將測試代碼與產品代碼分開,使代碼更清晰、簡潔;提高測試代碼與被測代碼的可維護性。
原文轉自:http://www.anti-gravitydesign.com