軟件測試培訓之解析單元測試與功能測試區(qū)別分享
2018-02-24 10:42:25
1745瀏覽
本文探究單元測試與功能測試之間的區(qū)別。并概述了在日常開發(fā)中使用這兩種測試的方法。
測試與開發(fā)過程
測試對于開發(fā)人員極為重要，您必須在開發(fā)過程中不斷進行測試。測試不應該只屬于開發(fā)周期的某個特定階段。它絕不應該是您將系統(tǒng)交給客戶前要完成的最后一項任務。如何才能知道您何時就完成了所有任務呢?如何才能知道對一個小錯誤的修正是否破壞了系統(tǒng)的主要功能呢?目前想像中的系統(tǒng)如何才能演化為實實在在的系統(tǒng)呢?單元測試和功能測試都應該是開發(fā)過程中不可分割的一部分。
單元測試應成為您編寫代碼的核心環(huán)節(jié)，當您所做的項目時限很緊并且您希望控制開發(fā)進度時尤其如此。由于單元測試是如此重要，所以您應該先編寫測試，再編寫代碼。
一套適當?shù)膯卧獪y試具有以下功能：
●說明可能的最實用設計
●提供類文檔的最佳格式
●確定一個類何時完成
●增強開發(fā)人員對代碼的信心
●作為快速重構(gòu)的基礎
單元測試創(chuàng)建隨系統(tǒng)自然發(fā)展的設計文檔。再讀一遍上一句話。文檔隨系統(tǒng)自然發(fā)展，這是軟件開發(fā)的“圣杯”。有什么方法比通過提供一個用例編碼集來記錄一個類效果更好呢?那就是單元測試：一系列記錄類所做工作的用例代碼，提供輸出控制。這樣，由于單元測試必須通過，所以設計文檔總是最新的。
您應該首先編寫測試，然后再編寫代碼。這樣就為要測試的類提供了一種設計，這種設計使您每一時刻都只需集中考慮一小塊代碼。這種做法也使設計變得不再復雜。您沒有試圖為以后著想而實現(xiàn)一些不必要的功能。先編寫測試還使您知道該類何時完成。一旦通過所有測試，任務也就完成了。
最后，單元測試可使您高度自信，這又會轉(zhuǎn)化為開發(fā)人員的滿意度。如果只要更改代碼即運行單元測試，您立即就能發(fā)現(xiàn)您所做的更改是否對系統(tǒng)造成了破壞。
功能測試比單元測試更重要，因為功能測試將驗證系統(tǒng)是否可以發(fā)行了。功能測試以一種有用的方式對您的工作系統(tǒng)進行說明。
一套適當?shù)墓δ軠y試具有以下功能：
●以有效方式捕獲用戶需求
●增強小組(用戶和開發(fā)人員)在系統(tǒng)滿足用戶需求方面的信心
功能測試以有效方式捕獲用戶需求。傳統(tǒng)開發(fā)通過用例來捕獲需求。通常，人們討論用例并花很長時間對它們進行細化。他們最后所得到的只是一紙空文。功能測試就像自驗證式用例。極限編程方法可解釋這一概念。XPStories將成為未來用戶與開發(fā)人員進行溝通的協(xié)議。功能測試便是這種溝通的結(jié)果。未經(jīng)功能測試的Stories不可能很完善。
功能測試填補單元測試留下的空白，并可增強小組對代碼的信心。單元測試漏掉許多錯誤。盡管它可以提供您所需的全部代碼，但它可能無法提供您所需的全部系統(tǒng)功能。功能測試將暴露單元測試遺漏的問題。一套適當?shù)淖詣踊δ軠y試也不可能捕捉到每個錯誤，但是它能比最好的單一單元測試捕捉更多的錯誤。
單元測試與功能測試
單元測試向開發(fā)人員表明代碼正確執(zhí)行操作;而功能測試向開發(fā)人員表明代碼執(zhí)行正確的操作。
單元測試
單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執(zhí)行一系列特定的任務。每個測試都確保只要給定輸入，方法將輸出預期的結(jié)果。
如果沒有測試框架，編寫一套可維護的自動化單元測試幾乎是不可能的。在開始編寫測試之前，請選擇一個小組公認的框架。您將經(jīng)常性地使用這個框架，因此您最好對它有點好感。極限編程網(wǎng)站提供了幾個單元測試框架(請參閱參考資源)。我最熟悉的框架是JUnit，它專門用來測試Java代碼。
功能測試
功能測試是從用戶的角度編寫的。這種測試確保系統(tǒng)執(zhí)行用戶期望它執(zhí)行的工作。
很多時候，系統(tǒng)開發(fā)好比建筑房屋。盡管這種類比不很恰當，但為了理解單元測試與功能測試的區(qū)別，我們可以擴充這種類比。單元測試好比房屋建筑現(xiàn)場的建筑監(jiān)理員。他關心房屋的各個內(nèi)部系統(tǒng)，如地基、構(gòu)架、供電系統(tǒng)和管道設備等。他確保(測試)房屋每一部分的工作都安全、正常，即符合建筑說明。這種情況下，功能測試類似于視察同一建筑現(xiàn)場的房主。他假定內(nèi)部系統(tǒng)將正常運作，并假定建筑監(jiān)理員在執(zhí)行其任務。房主關心的是住在這所房子里將會怎樣。他關心房子的外觀如何，各個房間的大小是否合適，房子能否滿足家庭的需要，以及窗戶的位置是否有利于采光。房主對房子執(zhí)行功能測試。他從用戶的角度考慮問題。建筑監(jiān)理員對房子執(zhí)行單元測試。他從建筑工人的角度考慮問題。
就像單元測試一樣，如果沒有測試框架，編寫一套可維護的自動化功能測試實際上是不可能的。JUnit非常適合編寫單元測試;但是，當試圖編寫功能測試時，它就顯得力不從心了。就功能測試而言，沒有與JUnit相當?shù)目蚣堋Ｒ灿袔追N用于功能測試的產(chǎn)品，但我從來沒見過它們應用于生產(chǎn)環(huán)境。如果找不到滿足您的需要的框架，您就必須創(chuàng)建一個。
無論我們多么擅長于構(gòu)建手頭的項目，也不管我們正在創(chuàng)建的系統(tǒng)多么靈活，如果我們的產(chǎn)品不合用，那我們就是白費時間。因此，功能測試是開發(fā)最重要的部分。
由于兩種測試都必不可少，您就需要了解編寫它們應遵循的原則。
如何編寫單元測試
剛開始編寫單元測試時很容易恢心。最佳的入手方式就是為新代碼創(chuàng)建單元測試。(盡管為現(xiàn)有代碼創(chuàng)建單元測試比較困難，但并非無法實現(xiàn))。首先從新代碼著手，待您習慣了整個過程以后，再針對現(xiàn)有代碼創(chuàng)建測試程序。
首先編寫單元測試，然后再編寫這些單元測試要測試的代碼。如何為尚不存在的代碼編寫測試呢?問得非常好。掌握這一方法需要90%的思維加10%的技術。我的意思是，您只需假定您正在為其編寫測試的類已經(jīng)存在。接下來的任務就是編寫測試。起初會犯很多語法錯誤，但您先別管它。這一步您要做的就是定義該類要實現(xiàn)的接口。下一步就是運行您的單元測試，修正語法錯誤(即，編寫一個類，使它實現(xiàn)您的測試剛定義的接口)，并再次運行測試。重復這一過程，每次僅編寫修正故障的代碼。運行測試，直到測試全部通過為止。一旦通過全部單元測試，代碼也就完成了。
一般而言，類的每個公共方法都應有一個單元測試。但是，功能簡單的方法(例如，getter方法和setter方法)不需要單元測試，除非它們以某種特別的方式進行獲取和設置。應該遵循下面這條很好的原則：即只要您認為有必要對代碼中的某個行為加注，就編寫一個單元測試。如果您像其他許多程序員一樣不喜歡為代碼加注，則單元測試是記錄代碼行為的一種方法。
將單元測試與被測試的相關類放在同一個包內(nèi)。這種組織方式使每個單元測試都能訪問被測試類中帶有package或protected訪問修飾符的方法和引用變量。
在單元測試中避免使用域?qū)ο?。域?qū)ο笫翘囟ㄓ谀硞€應用程序的對象。例如，一個電子表格應用程序可能包含一個注冊對象;這個注冊對象就是一個域?qū)ο?。如果您有一個已知這些域?qū)ο蟮念悾瑒t在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域?qū)ο蟮念?，在測試中就不要將這些對象聯(lián)系到該類上。應該避免這種情形完全是因為代碼重用。為某一項目創(chuàng)建的類經(jīng)常要用于其他項目。重用這些類可能很簡單。但是，如果對重用類的測試中用到了另一個項目的域?qū)ο?，則使測試能夠正常運行這一工作就會相當耗時。通常情況下，這個測試將被刪除或重寫。
這些機制為您提供很好的幫助，但是如果您不運行這些測試，一套綜合的單元測試就變得一文不值。盡早運行測試通常使您在任何時候都對代碼充滿信心。您將隨著項目進展不斷添加功能。運行這些測試將會通知您剛剛實現(xiàn)的新功能是否對系統(tǒng)造成了破壞。
在您掌握了編寫單元測試的技巧之后，我們再來看看現(xiàn)有代碼。為現(xiàn)有代碼編寫測試可能是個挑戰(zhàn)。不要為測試而測試。當您發(fā)現(xiàn)有必要對一個未經(jīng)很好測試(或者根本就沒有測試)的類進行修改時，請“隨時”編寫測試。現(xiàn)在是添加測試的時候了。像往常那樣，該類的單元測試應該捕獲其每個方法的功能。找出應該進行哪些測試的最容易的方法之一是：查看現(xiàn)有代碼中的注釋。任何注釋都應在單元測試內(nèi)捕獲。將位于方法開頭、說明該方法所起作用的注釋塊翻譯為單元測試。
如何編寫功能測試
盡管功能測試很重要，但它卻沒有受到足夠的重視。多數(shù)項目都有單獨的一個組來做功能測試。通常有一大群人不斷地與系統(tǒng)交互，以確定系統(tǒng)是否正確工作。這種觀念和設置專門的功能測試小組的做法很不明智。
對功能測試的處理與對單元測試的處理不應該有太大的區(qū)別。只要您編寫的代碼用來產(chǎn)生要求用戶與之交互的組件(如對話框)，就要編寫測試，但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務，都要在功能測試框架中描述此任務。您的開發(fā)工作將繼續(xù)向前發(fā)展，當添加新代碼時，請執(zhí)行單元測試。當所有的單元測試都結(jié)束以后，運行最初的功能測試，看看它是否能夠通過，或者是否需要修改。
從理論上講，功能測試小組的概念該消失了。開發(fā)人員應與用戶共同編寫功能測試。在對系統(tǒng)所做的一系列功能測試結(jié)束之后，開發(fā)組中負責功能測試的成員就應該用初始測試的各種變化形式來轟擊系統(tǒng)。
單元測試與功能測試的界限
通常單元測試與功能測試之間并沒有明確的界限。老實說，有時我也不清楚這個界限在什么位置。在編寫單元測試時，我根據(jù)以下原則來確定當前編寫的單元測試實際上是否是功能測試：
●如果單元測試跨越類邊界，則它就可能是功能測試。
●如果單元測試很脆弱(也就是說，雖然它是一個有效測試，但它必須不斷改變以處理不同的用戶組合)，則它可能是功能測試。
●如果編寫單元測試比編寫其所測試的代碼更難，則它可能是功能測試。
請注意“它可能是功能測試”這一措辭。本文無法提供硬性而快速的規(guī)則。單元測試與功能測試中之間有一個界限，但界限的具體位置要由您來確定。您用單元測試用得越熟練，某個特定測試是單元測試還是功能測試的界限就越明顯。
小結(jié)
單元測試是從開發(fā)人員的角度出發(fā)編寫的，并且關注的是所測試的類的特定方法。當編寫單元測試時，請使用以下這些原則：
●首先編寫單元測試，然后再編寫要測試的類代碼
●在單元測試中捕獲代碼注釋。
●測試所有執(zhí)行“令人感興趣的”功能(即，不是getter和setter，除非它們以某種獨特的方式執(zhí)行獲取和設置操作)的公共方法。
●將每個測試實例與它要測試的類放在同一個包內(nèi)，以獲得對包成員和保護成員的訪問權。
●避免在單元測試中使用特定于域的對象。
●功能測試是從用戶的角度出發(fā)編寫的，并且關注用戶感興趣的系統(tǒng)行為。找一個優(yōu)秀的功能測試框架，或者開發(fā)一個測試框架，并使用這些功能測試識別用戶的真實需求。這樣，功能測試人員即可獲得一種自動化工具以及使用這一工具的著手點。
●使單元測試和功能測試成為您開發(fā)過程中的中心環(huán)節(jié)。如果您這樣做了，您將對系統(tǒng)的運行及擴展充滿信心。如果您沒有這樣做，您對系統(tǒng)就沒有十足的把握。測試可能不那么有趣，但在開發(fā)過程中進行單元測試和功能測試。
以上就是關于軟件測試培訓之單元測試與功能測試的區(qū)別的詳細介紹，最后想要了解更多關于軟件測試培訓發(fā)展前景趨勢，請關注扣丁學堂官網(wǎng)、微信等平臺，扣丁學堂IT職業(yè)在線學習教育平臺為您提供權威的軟件測試視頻教程系統(tǒng)，通過千鋒扣丁學堂金牌講師在線錄制的軟件測試在線視頻教程，讓你快速掌握軟件測試從入門到精通開發(fā)實戰(zhàn)技能。
【關注微信公眾號獲取更多學習資料】
查看更多關于“軟件測試技術資訊”的相關文章>>
標簽:
軟件測試培訓
軟件測試工程師
軟件測試在線視頻
軟件測試視頻教程
軟件測試教程
單元測試
功能測試
返回頂部