軟件測試的新模型

　　通常情況下，一個軟件模型說明的內容主要包括，在測試過程中你應該考慮到哪些問題，如何對測試進行計劃，測試要達到什么目標，什么時候開始，在測試中你要用到哪些信息資源。一個好的模型可以引導你對問題進行思考，而不好的模型則只能使你誤入歧途。

　　這里我要宣稱的是，目前的大多數軟件測試模型都是不好的模型。這是因為這些測試模型僅僅是軟件開發模型的一些裝飾和補充而已。

　　人們一直在苦苦尋找軟件開發的模型，在創建了新的模型后，就把測試作為一個階段放在模型的后面部分。因此測試總被作為一種事后行為，測試總是被開發所驅動?？偟膩碚f，我們是在檢測他們的完成品。但是，作為事后處理的測試，其驅動方式是不正確的。實際上它顯而易見地和開發過程中各種行為之間有關，測試沒有起到應有的平衡作用。這樣的測試只是檢測了開發人員做了什么，而并沒有檢測到他們是否按照規則做了什么，這樣的做法割裂了本該緊密聯系的行為，剩下的只有那些匆忙而草率的想法所帶來的傷害。

　　而這樣做的結果就是效果很差的、效率很低的測試。效果很差的測試將導致很多bug沒有被發現，而效率很低的測試所浪費的是成本。

　　在本文中，我要做2件事，其一，我要否定一個不好的模型，即V模型。我希望通過論述來表明，“單元測試”和“集成測試”這2個詞匯可以從我們的詞匯表中取消了。其二，我將描述一個更好的模型。不過首先我認為，要真正擁有一個充分合理的模型還為時尚早。我僅僅是描述了一些新模型應該符合的重要的要求。這些要求將在本文末尾處列舉。

　　V模型有什么問題呢?

　　在本文中我要把V模型作為不好的模型的典型來進行分析。我選擇V模型作為分析的典型是因為V模型是最廣為人知的測試模型。

　　最典型的V模型版本一般會在其開始部分對軟件開發過程進行描述，如下圖所示：

　　(圖1--V模型的各級開發階段)

　　這是古老的瀑布模型。作為開發模型，它有很多問題，不過這里不作討論。盡管它的各種狀態是我們接著要討論的大家最熟悉的V模型的基礎。我的批評意見同時也針對其它的裝飾在一些更好的開發模型之上的測試模型，例如螺旋模型[Boehm88]。

　　在V模型中，測試過程被加在開發過程的后半部分，如下圖所示：

　　(圖2--V模型示意圖)

　　單元測試所檢測的是，代碼的開發是否符合詳細設計的要求。集成測試所檢測的是，此前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測的是，已集成在一起的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。

　　對于測試設計，顯而易見的是，V模型的用戶往往會把執行測試與測試設計分開對待。在開發文檔準備就緒后，就可以開始進行相關的測試設計。如下圖所示，相應的測試設計覆蓋在了相關的開發過程之上：

　　(圖3--將測試設計覆蓋了開發過程后的V模型)

　　V模型有著很吸引人的對稱外形，并且把很多人都帶入了歧途。本文將集中討論它在單元測試和集成測試中引起的問題。

　　為了說明的方便，這里專門制作了以下圖片，圖中包括一個單獨的單元，以及一個單元組，我稱之為子系統(subsystem)。

　　(圖4--一個假想的子系統)

　　對于一個單元應該多大才最為合適的問題，已經有過很多的討論，究竟一個單元僅僅是一個函數，一個類，還是相關的類的集合?這些討論并不影響我在這里所要闡述的觀點。我們權且認為一個單元就是一個具有最小程度的代碼塊，開發人員可以對進行獨立地討論。

　　V模型認為人們首先應該對每一個單元進行測試。當子系統中所有的單元都已經測試完畢，它們將被集中到一起進行測試，以驗證它們是否可以構成一個可運行的整體。

　　那么，如何針對單元進行測試呢?我們會查看在詳細設計中對接口的定義，或者查看源代碼，或者同時對兩者進行查看，找出符合某些測試設計中的有關準則的輸入數據來進行輸入，然后檢查結果，看其是否正確。由于各單元一般來說不能獨立地運行，所以我們不得不另外設計樁模塊(Stub)和驅動模塊(Driver)，如下圖所示。

原文轉自：http://www.uml.org.cn/Test/test47.htm