單元測試 單元測試工具
單元測試是在軟件開發過程中要進行的最低級別的測試活動，單元測試是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。它是軟件動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。因為單元測試需要知道內部程序設計和編碼的細節知識，一般應由程序員而非測試員來完成，往往需要開發測試驅動模塊和樁模塊來輔助完成單元測試。因此應用系統有一個設計很好的體系結構就顯得尤為重要。
一個軟件單元的正確性是相對于該單元的規約而言的。因此，單元測試以被測試單位的規約為基準。單元測試的主要方法有控制流測試、數據流測試、排錯測試、分域測試等等。
在一種傳統的結構化編程語言中，比如Java、C++這樣的面向對象的語言中，要進行測試的基本單元是類，尤其是一些公用類;而C，則要進行測試的單元一般是函數或子過程。對Ada語言來說， 開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。
單元測試不僅僅是作為無錯編碼的一種輔助手段在開發過程中使用。單元測試也應該是可重復的， 無論是在軟件修改， 或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟件系統的生命周期中進行維護。
經常與單元測試聯系起來的另外一些開發活動包括代碼走讀(Code Walkthrough/Review)、代碼審查(Code Inspection)、 靜態分析(Static Analysis)和動態分析(Dynamic Analysis)。 靜態分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，并不需要對代碼進行編譯和執行。而動態分析就是通過觀察軟件運行時的動作，來提供執行跟蹤，時間分析，及測試覆蓋度方面的信息。
在明確了什么是單元測試以后，我們列出了一些反對單元測試的普遍的論點，通過這些看起來。
然后用充分的理由來證明這些論點是不足取的。
3.1 浪費時間
一旦編碼完成， 開發人員總是會迫切希望進行軟件的集成工作， 這樣他們就能夠看到實際的系統開始運行了。能看到實際的工作成果總是令人振奮的，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。
在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的缺陷。 在實踐中，這樣一種開發步驟常常會導致這樣的結果：軟件甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導致在軟件集成為一個系統時增加額外的工期，
而且當這個系統投入使用時也無法確保它能夠可靠運行。
在實踐工作中， 進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。 一旦完成了這些單元測試工作， 很多Bug將被糾正，在確信他們手頭擁有穩定可靠的部件的情況下， 開發人員能夠進行更高效的系統集成工作。 這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效的利用。 而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。
使用Junit Framework和Jtest這樣的支持工具可以使單元測試更加簡單和有效。 但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。
3.2 它僅僅是證明這些代碼做了什么
文章來源于領測軟件測試網 http://www.kjueaiud.com/
