讓軟件測試也可以變得有趣的措施2

第第頁讓軟件測試也可以變得有趣的措施[2]讓軟件測試也可以變得有趣的措施[2]

發(fā)表于：2023-01-29來源：：點擊數(shù)：標簽：軟件測試措施

讓軟件測試也可以變得有趣的措施[2]軟件測試單元測試與功能測試單元測試向開發(fā)人員表明代碼正確執(zhí)行操作;而功能測試向開發(fā)人員表明代碼執(zhí)行正確的操作。單元測試單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執(zhí)行一系列特定的任務(wù)。

讓軟件測試也可以變得有趣的措施[2]軟件測試

單元測試與功能測試

單元測試向開發(fā)人員表明代碼正確執(zhí)行操作;而功能測試向開發(fā)人員表明代碼執(zhí)行正確的操作。

單元測試

單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執(zhí)行一系列特定的任務(wù)。每個測試都確保只要給定輸入，方法將輸出預(yù)期的結(jié)果。

如果沒有測試框架，編寫一套可維護的自動化單元測試幾乎是不可能的。在開始編寫測試之前，請選擇一個小組公認的框架。您將經(jīng)常性地使用這個框架，因此您最好對它有點好感。極限編程網(wǎng)站提供了幾個單元測試框架(請參閱參考資源)。我最熟悉的框架是JUnit，它專門用來測試Java代碼。

功能測試

功能測試是從用戶的角度編寫的。這種測試確保系統(tǒng)執(zhí)行用戶期望它執(zhí)行的工作。

很多時候，系統(tǒng)開發(fā)好比建筑房屋。盡管這種類比不很恰當，但為了理解單元測試與功能測試的區(qū)別，我們可以擴充這種類比。單元測試好比房屋建筑現(xiàn)場的建筑監(jiān)理員。他關(guān)心房屋的各個內(nèi)部系統(tǒng)，如地基、構(gòu)架、供電系統(tǒng)和管道設(shè)備等。他確保(測試)房屋每一部分的工作都安全、正常，即符合建筑說明。這種情況下，功能測試類似于視察同一建筑現(xiàn)場的房主。他假定內(nèi)部系統(tǒng)將正常運作，并假定建筑監(jiān)理員在執(zhí)行其任務(wù)。房主關(guān)心的是住在這所房子里將會怎樣。他關(guān)心房子的外觀如何，各個房間的大小是否合適，房子能否滿足家庭的需要，以及窗戶的位置是否有利于采光。房主對房子執(zhí)行功能測試。他從用戶的角度考慮問題。建筑監(jiān)理員對房子執(zhí)行單元測試。他從建筑工人的角度考慮問題。

就像單元測試一樣，如果沒有測試框架，編寫一套可維護的自動化功能測試實際上是不可能的。JUnit非常適合編寫單元測試;但是，當試圖編寫功能測試時，它就顯得力不從心了。就功能測試而言，沒有與JUnit相當?shù)目蚣?。也有幾種用于功能測試的產(chǎn)品，但我從來沒見過它們應(yīng)用于生產(chǎn)環(huán)境。如果找不到滿足您的需要的框架，您就必須創(chuàng)建一個。

無論我們多么擅長于構(gòu)建手頭的項目，也不管我們正在創(chuàng)建的系統(tǒng)多么靈活，如果我們的產(chǎn)品不合用，那我們就是白費時間。因此，功能測試是開發(fā)最重要的部分。

由于兩種測試都必不可少，您就需要了解編寫它們應(yīng)遵循的原則。

如何編寫單元測試

剛開始編寫單元測試時很容易恢心。最佳的入手方式就是為新代碼創(chuàng)建單元測試。(盡管為現(xiàn)有代碼創(chuàng)建單元測試比較困難，但并非無法實現(xiàn))。首先從新代碼著手，待您習慣了整個過程以后，再針對現(xiàn)有代碼創(chuàng)建測試程序。

如上文所述，應(yīng)該首先編寫單元測試，然后再編寫這些單元測試要測試的代碼。如何為尚不存在的代碼編寫測試呢?問得非常好。掌握這一方法需要90%的思維加10%的技術(shù)。我的意思是，您只需假定您正在為其編寫測試的類已經(jīng)存在。接下來的任務(wù)就是編寫測試。起初會犯很多語法錯誤，但您先別管它。這一步您要做的就是定義該類要實現(xiàn)的接口。下一步就是運行您的單元測試，修正語法錯誤(即，編寫一個類，使它實現(xiàn)您的測試剛定義的接口)，并再次運行測試。重復(fù)這一過程，每次僅編寫修正故障的代碼。運行測試，直到測試全部通過為止。一旦通過全部單元測試，代碼也就完成了。

一般而言，類的每個公共方法都應(yīng)有一個單元測試。但是，功能簡單的方法(例如，getter方法和setter方法)不需要單元測試，除非它們以某種特別的方式進行獲取和設(shè)置。應(yīng)該遵循下面這條很好的原則：即只要您認為有必要對代碼中的某個行為加注，就編寫一個單元測試。如果您像其他許多程序員一樣不喜歡為代碼加注，則單元測試是記錄代碼行為的一種方法。

將單元測試與被測試的相關(guān)類放在同一個包內(nèi)。這種組織方式使每個單元測試都能訪問被測試類中帶有package或protected訪問修飾符的方法和引用變量。

在單元測試中避免使用域?qū)ο?。域?qū)ο笫翘囟ㄓ谀硞€應(yīng)用程序的對象。例如，一個電子表格應(yīng)用程序可能包含一個注冊對象;這個注冊對象就是一個域?qū)ο?。如果您有一個已知這些域?qū)ο蟮念悾瑒t在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域?qū)ο蟮念?，在測試中就不要將這些對象聯(lián)系到該類上。應(yīng)該避免這種情形完全是因為代碼重用。為某一項目創(chuàng)建的類經(jīng)常要用于其他項目。重用這些類可能很簡單。但是，如果對重用類的測試中用到了另一個項目的域?qū)ο?，則使測試能夠正常運行這一工作就會相當耗時。通常情況下，這個測試將被刪除或重寫。

這些機制為您提供很好的幫助，但是如果您不運行這些測試，一套綜合的單元測試就變得一文不值。盡早運行測試通常使您在任何時候都對代碼充滿信心。您將隨著項目進展不斷添加功能。運行這些測試將會通知您剛剛實現(xiàn)的新功能是否對系統(tǒng)造成了破壞。

在您掌握了編寫單元測試的技巧之后，我們再來看看現(xiàn)有代碼。為現(xiàn)有代碼編寫測試可能是個挑戰(zhàn)。不要為測試而測試。當您發(fā)現(xiàn)有必要對一個未經(jīng)很好測試(或者根本就沒有測試)的類進行修改時，請“隨時”編寫測試?，F(xiàn)在是添加測試的時候了。像往常那樣，該類的單元測試應(yīng)該捕獲其每個方法的功能。找出應(yīng)該進行哪些測試的最容易的方法之一是：查看現(xiàn)有代碼中的解釋。任何解釋都應(yīng)在單元測試內(nèi)捕獲。將位于方法開頭、說明該方法所起作用的解釋塊翻譯為單元測試。

如何編寫功能測試

盡管功能測試很重要，但它卻沒有受到足夠的重視。多數(shù)項目都有單獨的一個組來做功能測試。通常有一大群人不斷地與系統(tǒng)交互，以確定系統(tǒng)是否正確工作。這種觀念和設(shè)置專門的功能測試小組的做法很不明智。

對功能測試的處理與對單元測試的處理不應(yīng)該有太大的區(qū)別。只要您編寫的代碼用來產(chǎn)生要求用戶與之交互的組件(如對話框)，就要編寫測試，但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務(wù)，都要在功能測試框架中描述此任務(wù)。您的開發(fā)工作將繼續(xù)向前發(fā)展，當添加新代碼時，請執(zhí)行單元測試。當所有的單元測試