單元測試VS功能測試 軟件測試
一、單元和功能測試的利用
在過去的幾年中，單元測試逐漸成為我編寫軟件的核心內容，在這里要感謝一種叫做極端編程-XP（注1）（見“資源”一節）的簡便程序設計方法。這種方法要求我為新加入的每個函數都編寫單元測試，并且維護這些測試。沒有通過單元測試，我就不能將任何一個的代碼加到模塊中。在代碼基數增長的同時，這些測試允許開發者有依據地將改變集成起來。起初，我認為這些單元測試就足以應付全局，沒有必要涉及到功能測試。噢，又錯了。功能測試和單元測試完全不同的兩者。我花費了很長的時間才理解到兩者的區別，以及如何將它們結合起來，用以改進開發進程。
本文探討了單元測試和功能測試之間的差別，同時介紹在你的日常開發的過程中如何來利用它測試和開發過程作為一個開發人員，測試如此之重要，以至于你甚至應該花費幾乎所有的時間來完成它。它不僅需要只被劃分為開發過程中的某個特定階段。顯然，它不該是在你把系統交付給客戶之前完成的最后一項任務。然而，你又如何得知它在何時結束呢？或是你如何得知是否因為修改一個微小的bug而破壞了系統的主要功能呢？或是系統可能會演化成超乎現在想象的模樣？測試，單元的和功能的都應該是開發的過程中的一部分。
單元測試應成為你編寫代碼的核心環節，尤其當你在從事一個項目時，緊張的時間約束你的開發進度，你也很想讓它是在可控的有序下進行。我希望測試也是在你編寫代碼之前編寫測試時的重要內容。
一套適用的單元測試應具備以下功能：
說明可能的最佳適用設計
提供類文檔的最佳格式
判斷一個類何時完成增強開發人員對代碼的信心
是快速重構的基礎
在系統中自然要包含單元測試所需的設計文檔。重新閱讀它，你會發現這是軟件開發進程中的圣杯，文檔跟隨系統的變化而逐步演化。為每一個類提供完備的文檔比起為它提供一系列的使用框架，或是一系列可控的輸入要好得多。這樣，設計文檔就會因為單元測試的逐步通過而隨時更新。
你應該在你編寫代碼之前完成編寫測試的工序。這樣做會為測試所涉及的類提供設計方案，并促使你關注代碼中更小的程序模塊。這種練習也會使設計方案變得更加簡單。你不能試圖去了解將來的情形，去實現不必要的功能。編寫測試工作也會讓你清楚類會在什么時間結束�？梢哉f，當所有的測試通過時，任務也就完成了。
最后，單元測試會提供給你更高級別的依據，這絕對會滿足開發者的。如果你在改動代碼的同時，進行單元測試，你就會在你破壞的同時立即察覺到事態的發生。
功能測試甚至比單元測試更加重要，因為它們說明了你的系統就要預備發布了。功能測試將把你的工作系統放置于一個可用的狀態中。
一套適用的功能測試應具備以下功能：
有效地掌握用戶的需求
向項目組成員（包括用戶和開發者）給出系統面臨這些需求的依據
功能測試要在有效地情況下掌握用戶的需求。而傳統的開發者是在使用的過程中發現需求的。通常，人們贊同使用項目工程并且花費相當的時間去重新定制它們。當它們被完成時，它們所得到的僅僅是一堆廢紙。功能測試雷同于自行生效的使用項目的情況。極端程序設計方法（ExtremeProgramming）能夠說明這種概念。XP 的說法就是對未來發生在用戶和開發者之間的交流技巧的描述。功能測試也是這種交流的結果。而沒有功能測試，這種說法也不會建立起來的。
功能測試恰好填充了在單元測試和向項目小組提交的代碼依據之間的空隙。單元測試會漏過許多的bug.它可以給出代碼中你所需的所有有效部分，它也會給你所需的整個系統。功能測試可以使單元測試里漏掉的問題曝光。一系列可維護的，自動化的功能測試也會有漏網的情況，但是它至少比獨立地進行最全面的單元測試要有用得多。
單元測試VS 功能測試
單元測試告訴開發者代碼使事情正確地被執行，而功能測試所說的則是代碼在正確地發揮功效。
單元測試
單元測試是從開發者的角度來編寫的。它們確保類的每個特定方法成功執行一系列特定的任務。每一個測試都要保證對于給定的一個已知的輸入應該得到所期望的輸出。
編寫一系列可維護、自動化、沒有測試框架的單元測試幾乎是不可能的。在你開始之前，選擇一個項目小組都認可的框架。不斷地應用它，逐漸地喜歡它。在極端編程的介紹網頁上，有很多適用的單元測試框架。我喜歡用的是Juint 來進行Java 代碼的測試。
功能測試
功能測試則是從用戶的角度來編寫的。這些測試保證系統能夠按照用戶所期望的那樣去運行。很多時候，開發一個完整的系統更像是建造一座大樓。當然，這種比喻并不是完全地恰當，但我們可以擴展它，來理解單元測試和功能測試之間的區別。
單元測試類似于一個建筑檢查員對房屋的建設現場進行檢查。他注重的是房屋內部不同的系統，地基，架構設計，電氣化，垂直的線條等等。他檢查房屋的某個部分，以確保它在安全狀態下，正確無誤地工作，即是說，直接針對房屋的代碼。功能測試在這個劇本里類似于房屋的主人在檢查同樣的建設場地。他所期望的是房屋的內部系統正常地運轉，并且房屋檢查員執行了他的任務。房屋的主人看重的是生活在這樣的房屋中會是什么樣子。他關注這間房屋的外貌，不同的房間有合適的空間，房屋適用于家庭的需要，窗戶恰好位于最佳采光的位置。房屋的主人運行的是對房屋的功能測試，他站在用戶的角度上。房屋檢查員運行的是單元測試，他是站在建設者的角度上。
二、單元測試與功能測試之間的區別
測試與開發過程
測試對于開發人員極為重要，您必須在開發過程中不斷進行測試。測試不應該只屬于開發周期的某個特定階段。它絕不應該是您將系統交給客戶前要完成的最后一項任務。如何才能知道您何時就完成了所有任務呢？如何才能知道對一個小錯誤的修正是否破壞了系統的主要功能呢？目前想像中的系統如何才能演化為實實在在的系統呢？單元測試和功能測試都應該是開發過程中不可分割的一部分。
單元測試應成為您編寫代碼的核心環節，當您所做的項目時限很緊并且您希望控制開發進度時尤其如此。由于單元測試是如此重要，所以您應該先編寫測試，再編寫代碼。
一套適當的單元測試具有以下功能：
說明可能的最實用設計
提供類文檔的最佳格式
確定一個類何時完成
增強開發人員對代碼的信心
作為快速重構的基礎
單元測試創建隨系統自然發展的設計文檔。再讀一遍上一句話。文檔隨系統自然發展，這是軟件開發的“圣杯”。有什么方法比通過提供一個用例編碼集來記錄一個類效果更好呢？那就是單元測試：一系列記錄類所做工作的用例代碼，提供輸出控制。這樣，由于單元測試必須通過，所以設計文檔總是最新的。
您應該首先編寫測試，然后再編寫代碼。這樣就為要測試的類提供了一種設計，這種設計使您每一時刻都只需集中考慮一小塊代碼。這種做法也使設計變得不再復雜。您沒有試圖為以后著想而實現一些不必要的功能。先編寫測試還使您知道該類何時完成。一旦通過所有測試，任務也就完成了。
最后，單元測試可使您高度自信，這又會轉化為開發人員的滿意度。如果只要更改代碼即運行單元測試，您立即就能發現您所做的更改是否對系統造成了破壞。
功能測試比單元測試更重要，因為功能測試將驗證系統是否可以發行了。功能測試以一種有用的方式對您的工作系統進行說明。一套適當的功能測試具有以下功能：
以有效方式捕獲用戶需求
增強小組（用戶和開發人員）在系統滿足用戶需求方面的信心
功能測試以有效方式捕獲用戶需求。傳統開發通過用例來捕獲需求。通常，人們討論用例并花很長時間對它們進行細化。他們最后所得到的只是一紙空文。功能測試就像自驗證式用例。極限編程方法可解釋這一概念。XP Stories 將成為未來用戶與開發人員進行溝通的協議。功能測試便是這種溝通的結果。未經功能測試的 Stories 不可能很完善。
功能測試填補單元測試留下的空白，并可增強小組對代碼的信心。單元測試漏掉許多錯誤。盡管它可以提供您所需的全部代碼，但它可能無法提供您所需的全部系統功能。功能測試將暴露單元測試遺漏的問題。一套適當的自動化功能測試也不可能捕捉到每個錯誤，但是它能比最好的單一單元測試捕捉更多的錯誤。
單元測試與功能測試
單元測試向開發人員表明代碼正確執行操作；而功能測試向開發人員表明代碼執行正確的操作。
單元測試
單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執行一系列特定的任務。每個測試都確保只要給定輸入，方法將輸出預期的結果。
如果沒有測試框架，編寫一套可維護的自動化單元測試幾乎是不可能的。在開始編寫測試之前，請選擇一個小組公認的框架。您將經常性地使用這個框架，因此您最好對它有點好感。極限編程網站提供了幾個單元測試框架（請參閱參考資源）。我最熟悉的框架是 JUnit，它專門用來測試 Java 代碼。
功能測試
功能測試是從用戶的角度編寫的。這種測試確保系統執行用戶期望它執行的工作。
很多時候，系統開發好比建筑房屋。盡管這種類比不很恰當，但為了理解單元測試與功能測試的區別，我們可以擴充這種類比。單元測試好比房屋建筑現場的建筑監理員。他關心房屋的各個內部系統，如地基、構架、供電系統和管道設備等。他確保（測試）房屋每一部分的工作都安全、正常，即符合建筑說明。這種情況下，功能測試類似于視察同一建筑現場的房主。他假定內部系統將正常運作，并假定建筑監理員在執行其任務。房主關心的是住在這所房子里將會怎樣。他關心房子的外觀如何，各個房間的大小是否合適，房子能否滿足家庭的需要，以及窗戶的位置是否有利于采光。房主對房子執行功能測試。他從用戶的角度考慮問題。建筑監理員對房子執行單元測試。他從建筑工人的角度考慮問題。
就像單元測試一樣，如果沒有測試框架，編寫一套可維護的自動化功能測試實際上是不可能的。JUnit 非常適合編寫單元測試；但是，當試圖編寫功能測試時，它就顯得力不從心了。就功能測試而言，沒有與 JUnit 相當的框架。也有幾種用于功能測試的產品，但我從來沒見過它們應用于生產環境。如果找不到滿足您的需要的框架，您就必須創建一個。
無論我們多么擅長于構建手頭的項目，也不管我們正在創建的系統多么靈活，如果我們的產品不合用，那我們就是白費時間。因此，功能測試是開發最重要的部分。
由于兩種測試都必不可少，您就需要了解編寫它們應遵循的原則。
如何編寫單元測試
剛開始編寫單元測試時很容易恢心。最佳的入手方式就是為新代碼創建單元測試。（盡管為現有代碼創建單元測試比較困難，但并非無法實現）。首先從新代碼著手，待您習慣了整個過程以后，再針對現有代碼創建測試程序。
如上文所述，應該首先編寫單元測試，然后再編寫這些單元測試要測試的代碼。如何為尚不存在的代碼編寫測試呢？問得非常好。掌握這一方法需要 90% 的思維加 10% 的技術。我的意思是，您只需假定您正在為其編寫測試的類已經存在。接下來的任務就是編寫測試。起初會犯很多語法錯誤，但您先別管它。這一步您要做的就是定義該類要實現的接口。下一步就是運行您的單元測試，修正語法錯誤（即，編寫一個類，使它實現您的測試剛定義的接口），并再次運行測試。重復這一過程，每次僅編寫修正故障的代碼。運行測試，直到測試全部通過為止。一旦通過全部單元測試，代碼也就完成了。
一般而言，類的每個公共方法都應有一個單元測試。但是，功能簡單的方法（例如，getter 方法和 setter 方法）不需要單元測試，除非它們以某種特別的方式進行獲取和設置。應該遵循下面這條很好的原則：即只要您認為有必要對代碼中的某個行為加注，就編寫一個單元測試。如果您像其他許多程序員一樣不喜歡為代碼加注，則單元測試是記錄代碼行為的一種方法。
將單元測試與被測試的相關類放在同一個包內。這種組織方式使每個單元測試都能訪問被測試類中帶有 package 或 protected 訪問修飾符的方法和引用變量。
在單元測試中避免使用域對象。域對象是特定于某個應用程序的對象。例如，一個電子表格應用程序可能包含一個注冊對象；這個注冊對象就是一個域對象。如果您有一個已知這些域對象的類，則在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域對象的類，在測試中就不要將這些對象聯系到該類上。應該避免這種情形完全是因為代碼重用。為某一項目創建的類經常要用于其他項目。重用這些類可能很簡單。但是，如果對重用類的測試中用到了另一個項目的域對象，則使測試能夠正常運行這一工作就會相當耗時。通常情況下，這個測試將被刪除或重寫。
這些機制為您提供很好的幫助，但是如果您不運行這些測試，一套綜合的單元測試就變得一文不值。盡早運行測試通常使您在任何時候都對代碼充滿信心。您將隨著項目進展不斷添加功能。運行這些測試將會通知您剛剛實現的新功能是否對系統造成了破壞。
在您掌握了編寫單元測試的技巧之后，我們再來看看現有代碼。為現有代碼編寫測試可能是個挑戰。不要為測試而測試。當您發現有必要對一個未經很好測試（或者根本就沒有測試）的類進行修改時，請“隨時”編寫測試�，F在是添加測試的時候了。像往常那樣，該類的單元測試應該捕獲其每個方法的功能。找出應該進行哪些測試的最容易的方法之一是：查看現有代碼中的注釋。任何注釋都應在單元測試內捕獲。將位于方法開頭、說明該方法所起作用的注釋塊翻譯為單元測試。
如何編寫功能測試
盡管功能測試很重要，但它卻沒有受到足夠的重視。多數項目都有單獨的一個組來做功能測試。通常有一大群人不斷地與系統交互，以確定系統是否正確工作。這種觀念和設置專門的功能測試小組的做法很不明智。
對功能測試的處理與對單元測試的處理不應該有太大的區別。只要您編寫的代碼用來產生要求用戶與之交互的組件（如對話框），就要編寫測試，但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務，都要在功能測試框架中描述此任務。您的開發工作將繼續向前發展，當添加新代碼時，請執行單元測試。當所有的單元測試都結束以后，運行最初的功能測試，看看它是否能夠通過，或者是否需要修改。
從理論上講，功能測試小組的概念該消失了。開發人員應與用戶共同編寫功能測試。在對系統所做的一系列功能測試結束之后，開發組中負責功能測試的成員就應該用初始測試的各種變化形式來轟擊系統。
單元測試與功能測試的界限
通常單元測試與功能測試之間并沒有明確的界限。老實說，有時我也不清楚這個界限在什么位置。在編寫單元測試時，我根據以下原則來確定當前編寫的單元測試實際上是否是功能測試：
如果單元測試跨越類邊界，則它就可能是功能測試。
如果單元測試很脆弱（也就是說，雖然它是一個有效測試，但它必須不斷改變以處理不同的用戶組合），則它可能是功能測試。
如果編寫單元測試比編寫其所測試的代碼更難，則它可能是功能測試。
請注意“它可能是功能測試”這一措辭。本文無法提供硬性而快速的規則。單元測試與功能測試中之間有一個界限，但界限的具體位置要由您來確定。您用單元測試用得越熟練，某個特定測試是單元測試還是功能測試的界限就越明顯。
小結
單元測試是從開發人員的角度出發編寫的，并且關注的是所測試的類的特定方法。當編寫單元測試時，請使用以下這些原則：
首先編寫單元測試，然后再編寫要測試的類代碼
在單元測試中捕獲代碼注釋。
測試所有執行“令人感興趣的”功能（即，不是 getter 和 setter，除非它們以某種獨特的方式執行獲取和設置操作）的公共方法。
將每個測試實例與它要測試的類放在同一個包內，以獲得對包成員和保護成員的訪問權。
避免在單元測試中使用特定于域的對象。
功能測試是從用戶的角度出發編寫的，并且關注用戶感興趣的系統行為。找一個優秀的功能測試框架，或者開發一個測試框架，并使用這些功能測試識別用戶的真實需求。這樣，功能測試人員即可獲得一種自動化工具以及使用這一工具的著手點。
使單元測試和功能測試成為您開發過程中的中心環節。如果您這樣做了，您將對系統的運行及擴展充滿信心。如果您沒有這樣做，您對系統就沒有十足的把握。 測試可能不那么有趣，但在開發過程中進行單元測試和功能測試
三、單元測試VS功能測試：軟件開發中運用
單元測試告訴開發人員我們的代碼正確執行了（Doing things right），功能測試告訴開發人員我們的代碼執行了正確的需求（Doing the right things）。
單元測試
單元測試一般是從一個開發人員的角度來寫的，他們要保證自己的代碼被正確（像自己預期的那樣）執行了，每一個測試都證實了我們的方法在接受某一個輸入的時候按照我們預期的那樣執行了。
沒有一個良好的平臺就想寫出一系列的可控的自動化單元測試無異于癡人說夢。當然在你選擇使用某一個測試平臺的時候，最好首先征得項目組人員的同意。你將會長時間使用這個工具，而且你也會逐漸喜歡上這個工具。在關于極限編程的站點有一些比較適合的軟件可以使用，我最喜歡的是用于java測試的JUnit（還用用于C#的NUnit以及用于Javascrīpt的JSUnit等工具，譯者注）。
功能測試
功能測試是從一個客戶的角度來看待問題的，它是用來檢驗我們的系統是否按照客戶預期的那樣來運行。
其實很多時候我們會發現一個系統的開發其實就想建一幢房子，雖然這種類比并不是很恰當，但是我們可以用這個來幫助我們來理解單元測試和功能測試，單元測試就像一個建筑物質檢人員，他更關心的是這個建筑五更加內在的東西：根基，取景，電力供應，以及一些對用戶有害物質（比如氡）的含量等等，他需要確保這間房子可以給人居住并且是安全的，也就是他需要接觸建筑物的本質部分。功能測試就是設想一下這間房屋的主人也來到這里之后，他首先確定這間房子已經是合格的了，因為質檢員已經幫他解決了這個后顧之憂了，設想這個房子應該是什么樣子的自己會比較滿意，他會設想自己在這間房子中怎么生活才會比較舒適，這間房子應該多大才合適，房子看起來是不是很舒服，房子是不是比較適合家庭的一些特殊需要，窗戶的位置是不是合適采光等等這些問題�？傊覀円獜目蛻舻慕嵌葋砜紤]問題，這就是作為功能測試所需要做的。
像單元測試一樣，我們也需要一個良好的平臺來來支持自動化的功能測試，但是這次JUnit就不行了，JUnit不適合用來做功能測試�，F在有一些工具可以用來做功能測試，但是這些工具都不是適用于所有的產品開發，所以當你找不到合適的工具的時候，還是自己開發一個比較好。
不管我們在做項目時候做的多么好，不管我們的產品是多么的優秀，如果我們的產品沒有用（在實際生活中的應用或者用戶需求），我們就只是在浪費我們自己的時間，也正因為如此，功能測試顯得如此的重要。
因為測試是這么的重要，所以我們需要一個指導方針之類的東西來完成測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/