測試是一件有趣的事情?真的嗎?

發表于:2007-08-09來源:作者:點擊數: 標簽:
測試。討厭!我一直討厭做測試。測試(單元測試和功能測試)是防礙“真正”工作的事情。每個人都確信自己的代碼是完美的,不是嗎?在確實需要更改代碼的極少數事件中,注釋編寫得如此之好,以致每個人都能領會其中的含義。我需要提高(或許還需要作一些咨詢)
測試。討厭!我一直討厭做測試。測試(單元測試和功能測試)是防礙“真正”工作的事情。每個人都確信自己的代碼是完美的,不是嗎?在確實需要更改代碼的極少數事件中,注釋編寫得如此之好,以致每個人都能領會其中的含義。我需要提高(或許還需要作一些咨詢)。

在過去的幾年里,單元測試已成為我編寫軟件的核心環節,多虧了一種稱為極限編程 (XP) 的簡便編程方法(請參閱 參考資源)。這種方法要求我為添加的每個函數編寫單元測試,并且要維護這些測試。如果單元測試失敗,我就無法整合任何代碼。隨著代碼庫的不斷增大,這些測試將使開發人員能夠很有把握地完成更改。

起初,我認為有了單元測試,就沒必要再進行功能測試。噢,又錯了。功能測試與單元測試相差甚遠。我花了很長一段時間理解二者的區別,以及如何結合使用兩者來改進開發過程。

本文探究單元測試與功能測試之間的區別。并概述了在日常開發中使用這兩種測試的方法。

測試與開發過程

測試對于開發人員極為重要,您必須在開發過程中不斷進行測試。測試不應該只屬于開發周期的某個特定階段。它絕不應該是您將系統交給客戶前要完成的最后一項任務。如何才能知道您何時就完成了所有任務呢?如何才能知道對一個小錯誤的修正是否破壞了系統的主要功能呢?目前想像中的系統如何才能演化為實實在在的系統呢?單元測試和功能測試都應該是開發過程中不可分割的一部分。

單元測試應成為您編寫代碼的核心環節,當您所做的項目時限很緊并且您希望控制開發進度時尤其如此。由于單元測試是如此重要,所以您應該先編寫測試,再編寫代碼。

一套適當的單元測試具有以下功能:

說明可能的最實用設計 提供類文檔的最佳格式 確定一個類何時完成 增強開發人員對代碼的信心 作為快速重構的基礎

單元測試創建隨系統自然發展的設計文檔。再讀一遍上一句話。文檔隨系統 自然發展,這是軟件開發的“圣杯”。有什么方法比通過提供一個用例編碼集來記錄一個類效果更好呢?那就是單元測試:一系列記錄類所做工作的用例代碼,提供輸出控制。這樣,由于單元測試必須通過,所以設計文檔總是最新的。

您應該首先編寫測試,然后再編寫代碼。這樣就為要測試的類提供了一種設計,這種設計使您每一時刻都只需集中考慮一小塊代碼。這種做法也使設計變得不再復雜。您沒有試圖為以后著想而實現一些不必要的功能。先編寫測試還使您知道該類何時完成。一旦通過所有測試,任務也就完成了。

最后,單元測試可使您高度自信,這又會轉化為開發人員的滿意度。如果只要更改代碼即運行單元測試,您立即就能發現您所做的更改是否對系統造成了破壞。

功能測試比單元測試更重要,因為功能測試將驗證系統是否可以發行了。功能測試以一種有用的方式對您的工作系統進行說明。一套適當的功能測試具有以下功能:

以有效方式捕獲用戶需求 增強小組(用戶和開發人員)在系統滿足用戶需求方面的信心

功能測試以有效方式捕獲用戶需求。傳統開發通過用例來捕獲需求。通常,人們討論用例并花很長時間對它們進行細化。他們最后所得到的只是一紙空文。功能測試就像自驗證式用例。極限編程方法可解釋這一概念。XP Stories 將成為未來用戶與開發人員進行溝通的協議。功能測試便是這種溝通的結果。未經功能測試的 Stories 不可能很完善。

功能測試填補單元測試留下的空白,并可增強小組對代碼的信心。單元測試漏掉許多錯誤。盡管它可以提供您所需的全部 代碼,但它可能無法提供您所需的全部 系統功能。功能測試將暴露單元測試遺漏的問題。一套適當的自動化功能測試也不可能捕捉到每個錯誤,但是它能比最好的單一單元測試捕捉更多的錯誤。





回頁首

單元測試與功能測試

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

單元測試

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

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

功能測試

功能測試是從用戶的角度編寫的。這種測試確保系統執行用戶期望它執行的工作。

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

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

無論我們多么擅長于構建手頭的項目,也不管我們正在創建的系統多么靈活,如果我們的產品不合用,那我們就是白費時間。因此,功能測試是開發最重要的部分。

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





回頁首

如何編寫單元測試

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

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

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

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

在單元測試中避免使用域對象。域對象是特定于某個應用程序的對象。例如,一個電子表格應用程序可能包含一個注冊對象;這個注冊對象就是一個域對象。如果您有一個已知這些域對象的類,則在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域對象的類,在測試中就不要將這些對象聯系到該類上。應該避免這種情形完全是因為代碼重用。為某一項目創建的類經常要用于其他項目。重用這些類可能很簡單。但是,如果對重用類的測試中用到了另一個項目的域對象,則使測試能夠正常運行這一工作就會相當耗時。通常情況下,這個測試將被刪除或重寫。

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

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





回頁首

如何編寫功能測試

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

對功能測試的處理與對單元測試的處理不應該有太大的區別。只要您編寫的代碼用來產生要求用戶與之交互的組件(如對話框),就要編寫測試,但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務,都要在功能測試框架中描述此任務。您的開發工作將繼續向前發展,當添加新代碼時,請執行單元測試。當所有的單元測試都結束以后,運行最初的功能測試,看看它是否能夠通過,或者是否需要修改。

從理論上講,功能測試小組的概念該消失了。開發人員應與用戶共同編寫功能測試。在對系統所做的一系列功能測試結束之后,開發組中負責功能測試的成員就應該用初始測試的各種變化形式來轟擊系統。





回頁首

單元測試與功能測試的界限

通常單元測試與功能測試之間并沒有明確的界限。老實說,有時我也不清楚這個界限在什么位置。在編寫單元測試時,我根據以下原則來確定當前編寫的單元測試實際上是否是功能測試:

如果單元測試跨越類邊界,則它就可能是功能測試。 如果單元測試變得很復雜,則它可能是功能測試。 如果單元測試很脆弱(也就是說,雖然它是一個有效測試,但它必須不斷改變以處理不同的用戶組合),則它可能是功能測試。 如果編寫單元測試比編寫其所測試的代碼更難,則它可能是功能測試。

請注意“它 可能是功能測試”這一措辭。本文無法提供硬性而快速的規則。單元測試與功能測試中之間有一個界限,但界限的具體位置要由您來確定。您用單元測試用得越熟練,某個特定測試是單元測試還是功能測試的界限就越明顯。





回頁首

小結

單元測試是從開發人員的角度出發編寫的,并且關注的是所測試的類的特定方法。當編寫單元測試時,請使用以下這些原則:

首先編寫單元測試,然后再編寫要測試的類代碼 在單元測試中捕獲代碼注釋。 測試所有執行“令人感興趣的”功能(即,不是 getter 和 setter,除非它們以某種獨特的方式執行獲取和設置操作)的公共方法。 將每個測試實例與它要測試的類放在同一個包內,以獲得對包成員和保護成員的訪問權。 避免在單元測試中使用特定于域的對象。

功能測試是從用戶的角度出發編寫的,并且關注用戶感興趣的系統行為。找一個優秀的功能測試框架,或者開發一個測試框架,并使用這些功能測試識別用戶的真實需求。這樣,功能測試人員即可獲得一種自動化工具以及使用這一工具的著手點。

使單元測試和功能測試成為您開發過程中的中心環節。如果您這樣做了,您將對系統的運行及擴展充滿信心。如果您沒有這樣做,您對系統就沒有十足的把握。測試可能不那么有趣,但是在開發過程中進行單元測試和功能測試使開發變得相當有趣。

原文轉自:http://www.anti-gravitydesign.com

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97