在開發過程中怎樣利用單元和功能測試 軟件測試
在過去的幾年中，單元測試逐漸成為我編寫軟件的核心內容，在這里要感謝一種叫做極端編程-XP(注1)(見“資源”一節)的簡便程序設計方法。這種方法要求我為新加入的每個函數都編寫單元測試，并且維護這些測試。沒有通過單元測試，我就不能將任何一個的代碼加到模塊中。在代碼基數增長的同時，這些測試允許開發者有依據地將改變集成起來。起初，我認為這些單元測試就足以應付全局，沒有必要涉及到功能測試。噢，又錯了。功能測試和單元測試完全不同的兩者。我花費了很長的時間才理解到兩者的區別，以及如何將它們結合起來，用以改進開發進程。
本文探討了單元測試和功能測試之間的差別，同時介紹在你的日常開發的過程中如何來利用它測試和開發過程作為一個開發人員，測試如此之重要，以至于你甚至應該花費幾乎所有的時間來完成它。它不僅需要只被劃分為開發過程中的某個特定階段。顯然，它不該是在你把系統交付給客戶之前完成的最后一項任務。然而，你又如何得知它在何時結束呢?或是你如何得知是否因為修改一個微小的bug而破壞了系統的主要功能呢?或是系統可能會演化成超乎現在想象的模樣?測試，單元的和功能的都應該是開發的過程中的一部分。
單元測試應成為你編寫代碼的核心環節，尤其當你在從事一個項目時，緊張的時間約束你的開發進度，你也很想讓它是在可控的有序下進行。我希望測試也是在你編寫代碼之前編寫測試時的重要內容。
一套適用的單元測試應具備以下功能：
說明可能的最佳適用設計
提供類文檔的最佳格式
判斷一個類何時完成
增強開發人員對代碼的信心
是快速重構的基礎
在系統中自然要包含單元測試所需的設計文檔。重新閱讀它，你會發現這是軟件開發進程中的圣杯，文檔跟隨系統的變化而逐步演化。為每一個類提供完備的文檔比起為它提供一系列的使用框架，或是一系列可控的輸入要好得多。這樣，設計文檔就會因為單元測試的逐步通過而隨時更新。
你應該在你編寫代碼之前完成編寫測試的工序。這樣做會為測試所涉及的類提供設計方案，并促使你關注代碼中更小的程序模塊。這種練習也會使設計方案變得更加簡單。你不能試圖去了解將來的情形，去實現不必要的功能。編寫測試工作也會讓你清楚類會在什么時間結束�？梢哉f，當所有的測試通過時，任務也就完成了。
最后，單元測試會提供給你更高級別的依據，這絕對會滿足開發者的。如果你在改動代碼的同時，進行單元測試，你就會在你破壞的同時立即察覺到事態的發生。
功能測試甚至比單元測試更加重要，因為它們說明了你的系統就要預備發布了。功能測試將把你的工作系統放置于一個可用的狀態中。
一套適用的功能測試應具備以下功能：
有效地掌握用戶的需求
向項目組成員(包括用戶和開發者)給出系統面臨這些需求的依據
功能測試要在有效地情況下掌握用戶的需求。而傳統的開發者是在使用的過程中發現需求的。通常，人們贊同使用項目工程并且花費相當的時間去重新定制它們。當它們被完成時，它們所得到的僅僅是一堆廢紙。功能測試雷同于自行生效的使用項目的情況。極端程序設計方法(ExtremeProgramming)能夠說明這種概念。XP 的說法就是對未來發生在用戶和開發者之間的交流技巧的描述。功能測試也是這種交流的結果。而沒有功能測試，這種說法也不會建立起來的。
文章來源于領測軟件測試網 http://www.k11sc111.com/
