讓軟件測試也可以變得有趣的措施[1] 軟件測試
討厭!我一直討厭做測試。測試(單元測試和功能測試)是防礙“真正”工作的事情。每個人都確信自己的代碼是完美的，不是嗎?在確實需要更改代碼的極少數事件中，注釋編寫得如此之好，以致每個人都能領會其中的含義。我需要提高(或許還需要作一些咨詢)。
在過去的幾年里，單元測試已成為我編寫軟件的核心環節，多虧了一種稱為極限編程 (XP) 的簡便編程方法(請參閱參考資源)。這種方法要求我為添加的每個函數編寫單元測試，并且要維護這些測試。如果單元測試失敗，我就無法整合任何代碼。隨著代碼庫的不斷增大，這些測試將使開發人員能夠很有把握地完成更改。
起初，我認為有了單元測試，就沒必要再進行功能測試。噢，又錯了。功能測試與單元測試相差甚遠。我花了很長一段時間理解二者的區別，以及如何結合使用兩者來改進開發過程。
本文探究單元測試與功能測試之間的區別。并概述了在日常開發中使用這兩種測試的方法。
測試與開發過程
測試對于開發人員極為重要，您必須在開發過程中不斷進行測試。測試不應該只屬于開發周期的某個特定階段。它絕不應該是您將系統交給客戶前要完成的最后一項任務。如何才能知道您何時就完成了所有任務呢?如何才能知道對一個小錯誤的修正是否破壞了系統的主要功能呢?目前想像中的系統如何才能演化為實實在在的系統呢?單元測試和功能測試都應該是開發過程中不可分割的一部分。
單元測試應成為您編寫代碼的核心環節，當您所做的項目時限很緊并且您希望控制開發進度時尤其如此。由于單元測試是如此重要，所以您應該先編寫測試，再編寫代碼。
一套適當的單元測試具有以下功能：
說明可能的最實用設計
提供類文檔的最佳格式
確定一個類何時完成
增強開發人員對代碼的信心
作為快速重構的基礎
單元測試創建隨系統自然發展的設計文檔。再讀一遍上一句話。文檔隨系統自然發展，這是軟件開發的“圣杯”。有什么方法比通過提供一個用例編碼集來記錄一個類效果更好呢?那就是單元測試：一系列記錄類所做工作的用例代碼，提供輸出控制。這樣，由于單元測試必須通過，所以設計文檔總是最新的。
您應該首先編寫測試，然后再編寫代碼。這樣就為要測試的類提供了一種設計，這種設計使您每一時刻都只需集中考慮一小塊代碼。這種做法也使設計變得不再復雜。您沒有試圖為以后著想而實現一些不必要的功能。先編寫測試還使您知道該類何時完成。一旦通過所有測試，任務也就完成了。
最后，單元測試可使您高度自信，這又會轉化為開發人員的滿意度。如果只要更改代碼即運行單元測試，您立即就能發現您所做的更改是否對系統造成了破壞。
功能測試比單元測試更重要，因為功能測試將驗證系統是否可以發行了。功能測試以一種有用的方式對您的工作系統進行說明。一套適當的功能測試具有以下功能：
以有效方式捕獲用戶需求
增強小組(用戶和開發人員)在系統滿足用戶需求方面的信心
功能測試以有效方式捕獲用戶需求。傳統開發通過用例來捕獲需求。通常，人們討論用例并花很長時間對它們進行細化。他們最后所得到的只是一紙空文。功能測試就像自驗證式用例。極限編程方法可解釋這一概念。XP Stories 將成為未來用戶與開發人員進行溝通的協議。功能測試便是這種溝通的結果。未經功能測試的 Stories 不可能很完善。
功能測試填補單元測試留下的空白，并可增強小組對代碼的信心。單元測試漏掉許多錯誤。盡管它可以提供您所需的全部代碼，但它可能無法提供您所需的全部系統功能。功能測試將暴露單元測試遺漏的問題。一套適當的自動化功能測試也不可能捕捉到每個錯誤，但是它能比最好的單一單元測試捕捉更多的錯誤。
文章來源于領測軟件測試網 http://www.kjueaiud.com/