所謂的測試，是一種產品質量保證的手段。我遵循需求規格說明書制造了一件產品，那么誰來確保這個產品符合了需求規格的要求呢?就是測試。它會根據需求規格說明書設計一系列的場景和用例，來對產品進行測試，看看產品是不是真的符合所期望的需求。
要抵達這個主旨，其實并不十分的隨意，因為一個真正的系統，狀態十分復雜，里面充滿了數不清的分支、異常、邊界條件，甚至運行環境，將這些東西組合起來，發作的需要測試的點將會是一個天文數字，在有限的時間內做完一個短缺而可靠的測試，是不能夠的。
為了將短缺測試變得能夠，一個對照好的途徑就是分層測試。我在做運行測試或性能測試的時候，有一個前提，就是如果整個系統的集成運行已經沒有問題了，在運行測試或性能測試時，我將不再推敲“系統無法正常運行”這種場景。那么如何保證集成運行沒問題呢?我們用集成測試來考試。但是在做集成測試的時候，我們同樣要基于一個如果，就是各個模塊的功能都能夠如期正常義務。而這一點，又是通過模塊自身的功能測試來完成的�！@樣一層層往下推，每個層次就如果它所依賴的層次沒有問題，這樣就能夠增加很多場景以及由這些場景引出的額外的分支。將原先一個幾何級數的測試用例分解成能夠吸收的若干層次的算術級數的用例。這樣一來測試就變得有能夠做好了。
而單元測試，正是這些測試的最低層次——保證每個函數÷方法，或者說最小功能模塊的正確性的一種測試。
通過上面的描述，我們至少清晰了這樣幾件事情：1。 單元測試是一種測試，它不是代碼的一部分;2。 單元測試是最低層級的測試，它只保證函數的可靠性，不保證其它;3。 單元測試應該能保證每一個函數的可靠性。
單元測試是一種測試，所以，我們應該以一種測試的眼光去面對它——我們要測試正常狀態，邊界條件，要對它的測試主旨——函數做黑盒分析，白盒分析，選擇相宜的測試數據，構建測試場景和測試環境——總之，一切測試應該做的事情，單元測試都不應該省略。
實際上來說，單元測試和其他測試一樣，也是能夠純手工完成的：我們能夠寫一段某函數的測試代碼，然后輸入我們的測試輸入，觀察測試輸入，并跟期望值做對照——事實上這種人工測試，寫了一段時間代碼的人應該都不會陌生。但是，單元測試有一點特殊性，就是在一集系統中，函數會十分十分的多，變化也比軟件的功能頻繁的多。面對這么多的函數，這么頻繁的變化，純手工測試是不現實的。所以，我們必需要引入單元測試框架進行自動化測試。注意，這里的單元測試框架只是完成自動化測試的一個手段，對單元測試自身并不發作任何影響——沒有單元測試框架，單元測試一樣也是能夠進行的，只是會痛苦很多。
單元測試框架引入的主旨只是為了自動化單元測試，簡化單元測試的步驟。所以，關于測試代碼的編寫，我們的重點應該是：1、如何搭建測試環境、測試場景;2、如何選擇測試用例;3、如何校驗測試效果。關于測試代碼自身，應該盡能夠的簡單，能不要應用技術盡量不要應用，我們的主旨在于測試，如果測試自身過于復雜，我們不能保證測試的正確性，測試這個義務就白做了。
另外，剛剛提到單元測試是對函數的測試，因此，測試必須是以函數為單位的。每個函數應該擁有自己單獨的一個測試，但是在這個測試中，我們應該針對這個函數的各個方面：正常的、異常的、邊界的……等等，各個方面進行圓滿的測試，這樣我們才能保證這個函數的功能是如我們所愿的。但是單元測試不需要負責函數的組合義務狀態。那應該是(低層次)功能測試的義務，而不是單元測試的義務。這個功能測試就是在如果一切函數都義務正常的基礎之上，對這些函數組合造成的功能模塊進行測試。這種測試，視狀態而定，能夠應用單元測試框架，也能夠應用其他自動化測試方法或者甚至是應用純人工測試。
另外，我還想討論一下單元測試的編寫和運行。
絕大部分時候，單元測試的編寫，是由開發人員做的。我們在以前某次對單元測試的討論中，甚至有人認為，單元測試必須由開發人員完成，而不應該由獨立的測試人員完成。關于這個問題，我是這樣看的：測試是一種針對需求的驗證義務。如果這個需求十分清晰，清晰到開發人員之外的人都能夠隨意掌握(有些日本外包發出來的函數說明書就能抵達這一點)，這時單元測試能夠由獨立的測試人員完成。但是大部分狀態下關于函數級別，做不到這一點。這時最清晰函數需求的人就是開發人員自己，在這種狀態下當然就應該是開發人員自己編寫測試用例。但是開發人員必須搞清晰自己身兼兩個不同的角色：運發起(完成代碼)和裁判員(考試代碼)，在編寫測試用例的時候絕不能如果任何函數的完成，而應該完全遵循它應該有的需求來做。這樣才能做好單元測試這件事。很多時候單元測試形同虛設，就是因為開發人員沒有很好的轉換自己的角色造成的。
單元測試的運行，目前我們這個Python的項目對照隨意，直接運行模塊就是該模塊的單元測試，而以模塊形式import就是實際應用。關于像C 或者其他的一些語言來說，能夠沒有這樣方便的形式。我們能夠把測試寫在獨立的文件中，然后用makefile組合不同的項目和主函數來做到這一點。另外還有一點就是，實際運行過程中能夠會有一些環境，這些環境在測試時難以獲得，或者增加上去之后，就難以測試(比喻網絡環境、數據庫環境等等)，這時我們能夠采用一些虛擬的環境來做到。我們把運行時需要的環境做一個簡化的虛擬版本，然后以這個版本作為測試環境進行測試，關于Python來說，我們能夠完成這樣的一個庫在測試時import進來并且同時做一些環境初始化義務，在C 里，我們能夠專門為測試寫一些運行庫，在實際運行編譯和測試編譯時，鏈接不同的庫。這在自動化測試技術中有個專門的名稱叫做 Mock Object。關于這個，我就不再深入了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/