軟件單元測試中的異常處理 軟件測試
記得一個牛人曾經說過(實在想不起來誰也搜不到)，大概的意思就是“處理一個問題的最好的辦法就是不去處理它”。我不知道當時他講這句話的具體場景是什么，不過我覺得這句話用在單元測試的異常處理中還是比較合適的。
首先來看看兩條關于異常處理的原則：
● 如果無法處理某個異常，那么就不要捕獲它
● 如果捕獲到一個異常，那么不要胡亂處理它
單元測試的代碼和開發的生產代碼，雖然同是程序代碼，但是他們存在的意義是不一樣的。前者是驗證程序的正確性，屬于為程序服務的;后者是實現某種功能，屬于為客戶服務的。然后在看上面的兩條異常處理的原則。
● 作為測試代碼，如果捕獲到一個異常，其實是無法處理它的。從某種角度來看，測試代碼和被測代碼是不在一個系統中，AUT所拋出的異常，測試代碼無法處理，其實也無需處理。
● 假如測試代碼捕獲了一個異常，那么唯一能做的事情就是把這個異常重新包裝一下，或者直接重新拋出給單元測試框架，然后由單元測試框架打印到界面上或者是執行結果中。但是其實我們什么都不做(不用Try…Catch)也能達到這樣的效果。
可能會有這樣的一些測試用例：在輸入某些數據的情況下，該函數會拋出某異常。測試工程師就是要驗證有異常的拋出。如果是這樣的情況，可以用 ExpectedException的Attribute(.NET)來標識出該測試代碼必須要拋出該異常，如果沒有拋出，該測試就是失敗。
所以在單元測試的代碼中出現Try…Catch其實是沒有必要的，如果是真的覺得要使用Try…Catch才能完成某些用例，那么我覺得可以重新設計測試用例，或者測試用例的實現。Try…Catch增加了測試代碼的不確定性，而這樣的不確定性會導致詭異的自動化測試腳本的出現。在回歸測試的過程中就有可能出現運行10次測試，有2次失敗8次成功的情況。
不過在單元測試(集成測試)中Try…Finally語句的使用還是很有必要的，例如我們會把數據庫鏈接釋放的代碼放在Finally語句塊中，保證測試運行無論成功還是失敗，都能釋放數據庫鏈接，或者其他昂貴的系統資源。
總結：在單元測試(集成測試等……)中，盡量不要使用Try…Catch代碼塊;如果需要釋放昂貴或者有限的系統資源、做清理工作，可以把相關的代碼放在Finally代碼塊中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
