在軟件測試工具中認識單元測試與JUNIT
前言
考察目前關于單元測試和JUnit的文章，要么是介紹單元測試的理論，要么是通過一個簡單的HelloWorld例子介紹工具的使用。這樣很容易使讀者在實際應用中無從下手。因為只有工具而沒有理論的指導，將嚴重消弱了工具的作用，最終只能是沙灘建樓，達不到預期的目標；只有理論而沒有工具的支持，也使得理論難有很好的著力點，最終使理論流于空泛。本文試圖通過先講解單元測試理論，進而將這些理論結合到JUnit的使用當中，最后通過對一個實用的、可以重用的時間操作類采用JUnit進行單元測試來完整闡述單元測試的思想、方法、以及工具的使用。作者相信，只有通過這樣，才能讓讀者真正把單元測試做好。
1.簡介
1.1. 為什么要進行單元測試
一個特定的開發組織或軟件應用系統的測試水平取決于對那些未發現的Bug的潛在后果的重視程度。這種后果一方面常常會被軟件的開發人員所忽視，而另一方面卻有可能損害組織的信譽，并且會導致對未來的市場產生負面的影響。相反地，一個可靠的軟件系統的良好的聲譽將有助于一個開發組織獲取未來的市場。
很多研究成果表明，無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產品進行測試將使效率和質量得到最好的保證。Bug發現得越晚，修改它所需的費用就越高，因此從經濟角度來看，應該盡可能早的查找和修改Bug。在修改費用變得過高之前，單元測試是一個在早期抓住Bug的機會。
相比后階段的測試，單元測試的創建更簡單、維護更容易，并且可以更方便的進行重復。 從全程的費用來考慮，相比起那些復雜且曠日持久的集成測試，或是不穩定的軟件系統來說， 單元測試所需的費用是很低的。研究顯示高達50%的維護工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發階段被排除掉的話，那么工作量就可以節省下來。當考慮到軟件維護費用可能會比最初的開發費用高出數倍的時候，這種潛在的對50%軟件維護費用的節省將對整個軟件生命周期費用產生重大的影響。
1.2. 什么是單元測試
單元測試是對最小的可測試軟件元素（單元）實施的測試，它所測試的內容包括內部結構（如邏輯和數據流）以及單元的功能和可觀測的行為。這里的單元不一定是指一個具體的函數或一個類的方法，“單元”是：
（1）可測試的、最小的、不可再分的程序模塊。
（2）有明確的功能、規格定義。
（3）有明確的接口定義，清晰地與同一程序的其他單元劃分開來。
在具體實現時，單元測試也可能對應的是多個程序文件中的一組函數。在一種傳統的結構化編程語言中，比如C，要進行測試的單元一般是函數或子過程。在象C++這樣的面向對象的語言中，要進行測試的基本單元是類。單元測試的原則同樣被擴展到第四代語言(4GL)的開發中，在這里基本單元被典型地劃分為一個菜單或顯示界面。
1.3. 單元測試的一般方法
單元測試的方法一般分為兩類：白盒方法和黑盒方法。白盒方法通常是分析單元內部結構后通過對單元輸入輸出的用例構造，達到單元內程序路徑的最大覆蓋，盡量保證單元內部程序運行路徑處理正確，它側重于單元內部結構的測試，依賴于對單元實施情況的了解。
黑盒方法通過對單元輸入輸出的用例構造驗證單元的特性和行為，側重于核實單元的可觀測行為和功能，并不依賴于對單元實施情況的了解。進行單元測試必須綜合使用上述兩個方法，否則，單元測試很可能就是不成功、不完整和不徹底的。
1.4. 單元測試的目標
單元測試要達到的目標，總體來說就是保證單元內部的處理是正確的、沒有遺漏和多余功能。細分而言，單元測試要達到以下幾個目標：
（1）信息能否正確地流入和流出單元。
（2）在單元工作過程中，其內部數據能否保持其完整性，包括內部數據的形式、內容及相互關系不發生錯誤，也包括全局變量在單元中的處理和影響。
（3）在為限制數據加工而設置的邊界處，能否正確工作。
（4）單元的運行能否做到滿足特定的邏輯覆蓋。
（5）單元中發生了錯誤，其中的出錯處理措施是否有效。
1.5. 為什么要使用JUnit進行單元測試
1.5.1. 什么是JUnit
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）易于集成到構建過程中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/