讓軟件測試也可以變得有趣的措施[2] 軟件測試
單元測試與功能測試
單元測試向開發人員表明代碼正確執行操作;而功能測試向開發人員表明代碼執行正確的操作。
單元測試
單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執行一系列特定的任務。每個測試都確保只要給定輸入，方法將輸出預期的結果。
如果沒有測試框架，編寫一套可維護的自動化單元測試幾乎是不可能的。在開始編寫測試之前，請選擇一個小組公認的框架。您將經常性地使用這個框架，因此您最好對它有點好感。極限編程網站提供了幾個單元測試框架(請參閱參考資源)。我最熟悉的框架是 JUnit，它專門用來測試 Java 代碼。
功能測試
功能測試是從用戶的角度編寫的。這種測試確保系統執行用戶期望它執行的工作。
很多時候，系統開發好比建筑房屋。盡管這種類比不很恰當，但為了理解單元測試與功能測試的區別，我們可以擴充這種類比。單元測試好比房屋建筑現場的建筑監理員。他關心房屋的各個內部系統，如地基、構架、供電系統和管道設備等。他確保(測試)房屋每一部分的工作都安全、正常，即符合建筑說明。這種情況下，功能測試類似于視察同一建筑現場的房主。他假定內部系統將正常運作，并假定建筑監理員在執行其任務。房主關心的是住在這所房子里將會怎樣。他關心房子的外觀如何，各個房間的大小是否合適，房子能否滿足家庭的需要，以及窗戶的位置是否有利于采光。房主對房子執行功能測試。他從用戶的角度考慮問題。建筑監理員對房子執行單元測試。他從建筑工人的角度考慮問題。
就像單元測試一樣，如果沒有測試框架，編寫一套可維護的自動化功能測試實際上是不可能的。JUnit 非常適合編寫單元測試;但是，當試圖編寫功能測試時，它就顯得力不從心了。就功能測試而言，沒有與 JUnit 相當的框架。也有幾種用于功能測試的產品，但我從來沒見過它們應用于生產環境。如果找不到滿足您的需要的框架，您就必須創建一個。
無論我們多么擅長于構建手頭的項目，也不管我們正在創建的系統多么靈活，如果我們的產品不合用，那我們就是白費時間。因此，功能測試是開發最重要的部分。
由于兩種測試都必不可少，您就需要了解編寫它們應遵循的原則。
如何編寫單元測試
剛開始編寫單元測試時很容易恢心。最佳的入手方式就是為新代碼創建單元測試。(盡管為現有代碼創建單元測試比較困難，但并非無法實現)。首先從新代碼著手，待您習慣了整個過程以后，再針對現有代碼創建測試程序。
如上文所述，應該首先編寫單元測試，然后再編寫這些單元測試要測試的代碼。如何為尚不存在的代碼編寫測試呢?問得非常好。掌握這一方法需要 90% 的思維加 10% 的技術。我的意思是，您只需假定您正在為其編寫測試的類已經存在。接下來的任務就是編寫測試。起初會犯很多語法錯誤，但您先別管它。這一步您要做的就是定義該類要實現的接口。下一步就是運行您的單元測試，修正語法錯誤(即，編寫一個類，使它實現您的測試剛定義的接口)，并再次運行測試。重復這一過程，每次僅編寫修正故障的代碼。運行測試，直到測試全部通過為止。一旦通過全部單元測試，代碼也就完成了。
一般而言，類的每個公共方法都應有一個單元測試。但是，功能簡單的方法(例如，getter 方法和 setter 方法)不需要單元測試，除非它們以某種特別的方式進行獲取和設置。應該遵循下面這條很好的原則：即只要您認為有必要對代碼中的某個行為加注，就編寫一個單元測試。如果您像其他許多程序員一樣不喜歡為代碼加注，則單元測試是記錄代碼行為的一種方法。
將單元測試與被測試的相關類放在同一個包內。這種組織方式使每個單元測試都能訪問被測試類中帶有 package 或 protected 訪問修飾符的方法和引用變量。
在單元測試中避免使用域對象。域對象是特定于某個應用程序的對象。例如，一個電子表格應用程序可能包含一個注冊對象;這個注冊對象就是一個域對象。如果您有一個已知這些域對象的類，則在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域對象的類，在測試中就不要將這些對象聯系到該類上。應該避免這種情形完全是因為代碼重用。為某一項目創建的類經常要用于其他項目。重用這些類可能很簡單。但是，如果對重用類的測試中用到了另一個項目的域對象，則使測試能夠正常運行這一工作就會相當耗時。通常情況下，這個測試將被刪除或重寫。
這些機制為您提供很好的幫助，但是如果您不運行這些測試，一套綜合的單元測試就變得一文不值。盡早運行測試通常使您在任何時候都對代碼充滿信心。您將隨著項目進展不斷添加功能。運行這些測試將會通知您剛剛實現的新功能是否對系統造成了破壞。
在您掌握了編寫單元測試的技巧之后，我們再來看看現有代碼。為現有代碼編寫測試可能是個挑戰。不要為測試而測試。當您發現有必要對一個未經很好測試(或者根本就沒有測試)的類進行修改時，請“隨時”編寫測試�，F在是添加測試的時候了。像往常那樣，該類的單元測試應該捕獲其每個方法的功能。找出應該進行哪些測試的最容易的方法之一是：查看現有代碼中的注釋。任何注釋都應在單元測試內捕獲。將位于方法開頭、說明該方法所起作用的注釋塊翻譯為單元測試。
如何編寫功能測試
盡管功能測試很重要，但它卻沒有受到足夠的重視。多數項目都有單獨的一個組來做功能測試。通常有一大群人不斷地與系統交互，以確定系統是否正確工作。這種觀念和設置專門的功能測試小組的做法很不明智。
對功能測試的處理與對單元測試的處理不應該有太大的區別。只要您編寫的代碼用來產生要求用戶與之交互的組件(如對話框)，就要編寫測試，但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務，都要在功能測試框架中描述此任務。您的開發工作將繼續向前發展，當添加新代碼時，請執行單元測試。當所有的單元測試都結束以后，運行最初的功能測試，看看它是否能夠通過，或者是否需要修改。
從理論上講，功能測試小組的概念該消失了。開發人員應與用戶共同編寫功能測試。在對系統所做的一系列功能測試結束之后，開發組中負責功能測試的成員就應該用初始測試的各種變化形式來轟擊系統。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
