單元測試與JUNIT(2)

　　JUnit就是對程序代碼進行單元測試的一種Java框架。通過每次修改程序之后測試代碼，程序員就可以保證代碼的的少量變動不會破壞整個系統。官方對JUnit的定義是“JUnit is a simple framework to write repeatable tests.”。

　　1.5.2. 自己編寫測試框架的弊病

　　自己編寫測試框架進行單元測試一般有兩個方法。第一種方法是在要測試的類的main()方法中編寫測試代碼。隨著程序越變越大，這種開發方法很快就開始顯現出了缺陷：

　　(1)混亂。類接口越大，main() 就越大。類可能僅僅因為正常的測試就變得非常龐大。

　　(2)代碼膨脹。由于加入了測試，所以產品代碼比所需要的要大。

　　(3)測試不可靠。main() 是代碼的一部分，main() 就對其他開發者通過類接口無法訪問的私有成員和方法享有訪問權。出于這個原因，這種測試方法很容易出錯。

　　(4)很難自動測試。要進行自動測試，必須創建另一程序來將參數傳遞給 main()。第二種方法是編寫一個測試類框架，它雖然能夠克服上個方法的缺陷，但增加了開發組織維護這個測試類框架的工作量，為立即大規模的重用設置障礙。而且，由于這個測試框架是內部開發的，存在著與業界難于交流和溝通的弊病。

　　1.5.3. JUnit的優勢

　　(1)需要編寫自己的框架。

　　(2)它是開放源代碼，因此不需要購買框架。

　　(3)開放源代碼社區中的其他開發者會使用它，因此可以找到許多示例。

　　(4)可以將測試代碼與產品代碼分開。

　　(5)易于集成到構建過程中。

　　2. 單元測試設計

　　2.1. 單元測試的一般過程

　　單元測試過程分為計劃、設計、實現、執行、評估等幾個步驟，各步驟的任務如下：

　　2.1.1. 計劃

　　單元測試計劃需明確如下目標：

　　(1)明確單元測試的測試對象，確定測試需求及測試通過的標準，明確活動的輸出。

　　(2)明確測試方法和需要運行的工具需求。

　　(3)對工作量進行估計，確定測試所用資源(包括人力資源和設備資源)，創建測試任務的時間表，必要時需將一個單元測試任務分解成更細化的子任務進行明確。

　　(4)對測試風險進行分析，制定相應的應急措施。

　　(5)明確測試優先級，制定測試取舍策略。

　　(6)輸出單元測試計劃文檔。

　　2.1.2. 設計

　　單元測試的設計主要是完成方案和模型的確認，包括如下幾方面內容：

　　(1)測試需求的進一步細化，必要時需追溯到詳細設計文檔中的單元設計目標。

　　(2)設計單元測試模型，包括與模型相關的工具的選用。

　　(3)制定測試方案，包括模型的設計和實現、定義測試規程和用例的實現和組織。

　　(4)輸出單元測試方案文檔。

　　2.1.3. 實現

　　單元測試實現主要是針對用例的實現，包括如下幾個方面：

　　(1)參考測試模型和測試方案，制定具體的測試用例，創建可重用的測試腳本。

　　(2)輸出單元用例文檔。

　　2.1.4. 執行

　　根據單元測試的方案、用例對單元進行測試，驗證測試的結果并記錄測試過程中出現的缺陷，主要保留執行過程數據以備問題定位的回歸對比。

　　2.1.5. 評估

　　對單元測試的結果進行評估，主要有如下幾個方面：

　　(1)實際測試過程的記錄，描述與計劃的差異和原因，包括補充或裁剪的測試項目清單。

　　(2)對測試過程完備性以及被測單元質量的評價，包括用例執行情況清單和匯總分析。

　　(3)主要從需求覆蓋和代碼覆蓋的角度進行測試完備性的評估。

　　(4)遺留問題記錄和可能的分析。

　　(5)輸出單元測試報告。

　　2.2. 單元測試用例設計方法

　　測試用例的設計在單元測試中占有非常重要的地位，測試用例設計的好壞直接影響到測試的效果。確定測試用例之所以很重要，原因有以下幾方面：

　　(1)測試用例構成了設計和制定測試過程的基礎。

　　(2)測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，對產品質量和測試流程也就越有信心。判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。

原文轉自：http://www.uml.org.cn/Test/201405272.asp