譯文：在軟體開發流程中運用單元測試和功能測試(一)

原文發表於2007-12-26   

英文來源文件：http://www-128.ibm.com/developerworks/library/j-test.html

如需轉載請聯絡譯者chdwu@bestreme.com

    由於受到極限編程的影響，在最近的幾年時間裡單元測試逐漸成為我軟體開發過程中一個不可或缺的重要組成部分。極限編程要求我們對我們所完成的每一項功能都要進行單元測試並且要很好的管理這些測試，我們不應該在所有的單元測試通過之前去整合任何新的功能。這種做法的好處就是可以讓開發人員對自己所寫的代碼充滿信心（而不是盲目的毫無根據的自負）。
 
    最開始我認為既然已經有了單元測試了，就沒有必要再去花時間在功能測試上了，可我現在知道這是一個錯誤的想法：單元測試和功能測試是有很大的不同的。我花了很長的時間才瞭解到單元測試和功能測試的差異所在，我也知道了怎樣更好的運用單元測試和功能測試來完善我們的軟體開發流程。

   這篇文章探究了單元測試和功能測試的不同點以及我們可以怎樣運用這兩種測試來支援我們的軟體開發。

測試和軟體開發過程

    作為一個開發人員來講，測試是相當重要的，我們必須要堅持在整個軟體開發流程中測試我們的代碼，而不僅僅把測試作為軟體開發的一個特殊階段的產物：測試絕對不應該成為你在軟體提交前一天才開始的一個例行公事。你怎麼才能知道我們的軟體已經發行就緒了？你怎麼知道我修正了這個小bug的時候沒有引發一個更嚴重的系統bug？你怎麼知道當前的系統是否可以擴充一些現在沒有想到功能呢？測試！單元測試和功能測試必須成為我們在軟體開發流程中的一個有機組成部分。

    單元測試應該成為你寫代碼的一個核心部分，尤其是在項目時間比較緊張但是我們仍然要保證品質的時候。單元測試十分重要，你甚至應該在你的代碼寫出來之前就應該完成單元測試。

單元測試：
  -》有助於儘可能地重現最有效設計
  -》有助於提供一個最佳的檔案組織圖
  -》有助於確定一個類是否完成
  -》讓開發人員對自己的代碼充滿信心
  -》是快速重構的基礎

    單元測試有助於形成系統化的並可以不斷改進的設計文檔，這些文檔在軟體開發的過程中有著極其重要的意義。大多時候將用例文檔化形成一個類要比僅僅羅列一大堆編碼的實際用例好，看看單元測試：它提供一系列有規律的輸入或資料，用一系列的實際用例來告訴我們所寫的類做了些什麼。這樣的話這個設計文檔就總是最新的，因為我們必須通過單元測試。
 
    你應該在寫代碼之前寫單元測試，這樣做的好處就是為自己提供了一個可以測試的設計方案，這就可以協助你想的更加完善，這樣會使設計變得簡單。你不必擔心將來會怎樣，也不必花時間去實現一些不必要的功能。首先寫單元測試還有助於幫你瞭解代碼在什麼時候完成：當所有的測試都通過之後，我們的任務也就完成了。

   最後，單元測試讓你對自己代碼有高度的自信，這有助於我們做出更加好的產品。當你修改了自己的代碼之後，我們來運行我們的測試，如果有問題的話我們可以迅速找出來我們的修改產生了在什麼地方哪些破壞。

    功能測試甚至比單元測試更加重要，因為它是用來檢測我們的系統是否達到發行就緒的要求。功能測試是用來確定我們的系統是否是一個可用的系統。

功能測試：
  -》確定是否實現使用者需求的一個有效方法
  -》讓使用者和開發人員瞭解到我們的系統已經實現了這些使用者需求

    傳統的開發過程是從實際使用中確定是否實現使用者需求的，通常人們需要花費大力氣才可以搞清楚這些實際用例並設法概括它們，當他們完成了這些工作之後他們手中無非多了一張紙而已，而功能測試就像是自己確定實際用例一樣。極限編程闡述了這些觀念，極限編程需要提前定義這些功能（這一過程需要項目組和使用者共同完成），而功能測試就是它的產物，如果沒有功能測試的話，我們不可能完成的很漂亮。

    功能測試可以檢查出單元測試遺留下的一些軟體缺陷，讓開發人員對自己的代碼更加有信心，因為單元測試仍然會遺留下很多bug，它可能會覆蓋到代碼的各個部分但是卻不能覆蓋到系統的各個部分。功能測試可以揭露一些單元測試沒有涉及的問題。當然一個自動化的可持續啟動並執行功能測試不可能找出系統中的所有問題，但它可以找出更多的單元測試找不到的bug。