功能測試恰好填充了在單元測試和向項目小組提交的代碼依據之間的空隙。單元測試會漏過許多的bug。它可以給出代碼中你所需的所有有效部分，它也會給你所需的整個系統。功能測試可以使單元測試里漏掉的問題曝光。一系列可維護的，自動化的功能測試也會有漏網的情況，但是它至少比獨立地進行最全面的單元測試要有用得多。
單元測試VS 功能測試
單元測試告訴開發者代碼使事情正確地被執行，而功能測試所說的則是代碼在正確地發揮功效。
單元測試
單元測試是從開發者的角度來編寫的。它們確保類的每個特定方法成功執行一系列特定的任務。每一個測試都要保證對于給定的一個已知的輸入應該得到所期望的輸出。
編寫一系列可維護、自動化、沒有測試框架的單元測試幾乎是不可能的。在你開始之前，選擇一個項目小組都認可的框架。不斷地應用它，逐漸地喜歡它。在極端編程的介紹網頁上(見資源一節)，有很多適用的單元測試框架。我喜歡用的是Juint 來進行Java 代碼的測試。
功能測試
功能測試則是從用戶的角度來編寫的。這些測試保證系統能夠按照用戶所期望的那樣去運行。很多時候，開發一個完整的系統更像是建造一座大樓。當然，這種比喻并不是完全地恰當，但我們可以擴展它，來理解單元測試和功能測試之間的區別。
單元測試類似于一個建筑檢查員對房屋的建設現場進行檢查。他注重的是房屋內部不同的系統，地基，架構設計，電氣化，垂直的線條等等。他檢查房屋的某個部分，以確保它在安全狀態下，正確無誤地工作，即是說，直接針對房屋的代碼。功能測試在這個劇本里類似于房屋的主人在檢查同樣的建設場地。他所期望的是房屋的內部系統正常地運轉，并且房屋檢查員執行了他的任務。房屋的主人看重的是生活在這樣的房屋中會是什么樣子。他關注這間房屋的外貌，不同的房間有合適的空間，房屋適用于家庭的需要，窗戶恰好位于最佳采光的位置。房屋的主人運行的是對房屋的功能測試，他站在用戶的角度上。房屋檢查員運行的是單元測試，他是站在建設者的角度上。
象單元測試一樣，編寫一系列可維護、自動化、沒有測試框架的功能測試幾乎是不可能的。Junit在單元測試方面做得很好;然而，它在試圖編寫功能測試時就顯得比較松散。Junit 不等同于功能測試�，F在已經有滿足這個功能的產品問世了，但是我還沒有看到它們被應用于開發產品過程里。如果你不能找到一個測試框架的話，就只好自己創建一個了。無論我們在建立一個項目時多么聰明，建立的系統多么靈活，如果我們的產品不能用，我們就是在浪費時間。結論是，功能測試是開發進程中最重要的一部分。
因為兩種類型的測試都是必要的，你會需要編寫它們的指南。
如何編寫單元測試
在你開始編寫單元測試很容易被激動的情緒感染。最簡單的起步方式就是為新的代碼創建單元測試。為已經存在的代碼創建單元測試是一種比較有難度的開始方式，但是也是可行的。)從新的代碼開始，習慣了這樣的步驟后，還要堅持重新閱讀現有代碼，并為它們創建一套測試程序。
就像前面提到過的一樣，你應該在你編寫要測試的代碼之前編寫單元測試。如何做到為還不存在的事物編寫測試呢?好問題!掌握這個能力需要90%的智力和10%技巧。我的意思是你只需假裝是在為已有的類編寫測試。接下來，進行編寫的工作。最初，你將出現很多語法錯誤，但是let it be，不要理會它。緊接著進行單元測試，修改語法錯誤(即是說，只用你自己定義的測試接口來實現類)，再一次進行測試。重復這個過程，每一次都寫下充足的代碼去修改錯誤，進行測試直到它們通過為止。當所有的單元測試都通過時，代碼才算真正地完成了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
