一個假想的子系統

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

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

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

　　 單元及其外部的驅動模塊和樁模塊

　　圖中的箭頭代表了測試的執行軌跡。這就是大多數人所說的“單元測試”。我認為這樣的方法有時候是一種不好的方法。

　　同樣的輸入也可以有同一子系統中的其它單元來提供，這樣，其它的單元既扮演了樁模塊，又扮演了驅動模塊。如下圖所示：

　　子系統內部各單元間的測試執行軌跡

　　到底選擇哪一種方法，這需要一種折衷和權衡。設計樁模塊和驅動模塊要付出多少代價?這些模塊如何進行維護?子系統是否會由此而掩蓋了一些故障?在整個子系統范圍內進行排錯的困難程度有多大?如果我們的測試直到集成測試時才真正開始，那么一些bug可能較晚才被發現。由此造成的代價同設計樁模塊和驅動模塊的代價如何比較?

　　V模型分析<2>

　　V模型沒有去考慮這些問題，當單元開發完成后就執行單元測試，而當自系統被集中在一起后就執行集成測試，僅此而已。令我奇怪和沮喪的是，人們從不去做一些權衡，他們已經受制于他們的模型。

　　因此，一個有用的模型應該允許測試人員考慮節省并推遲測試的可能性。

　　一個測試，如果要發現一個特定的單元中的bug，最好是在該單元保持獨立的情況下執行，并且在其外部輔以特定的樁模塊和驅動模塊。而另一種方法則是讓它作為子系統的一部分來進行測試，該測試的設計主要是為了發現集成的問題。由于一個子系統本身也需要樁模塊和驅動模塊來模擬該子系統和其它子系統的聯系，因此，單元測試和集成測試可能被推遲到至少整個系統已經部分集成的時候。在這種情況下，測試者可能通過產品的外部接口同時進行單元測試、集成測試和系統測試，同樣的，其主要目的還是為了減少總體生命周期的成本，對測試成本和延期進行測試及由此造成延期發現bug的代價成本進行權衡。據此而言，“單元測試”、“集成測試”和“系統測試”的區別已經大大削弱了。其結果可參考下圖：

　　 新的方法：在部分階段延遲進行單元測試和集成測試