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

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

    這是古老的瀑布模型。作為開發模型，它有很多侍猓?還?飫鋝蛔魈致?。尽管?母髦腫刺?俏頤墻幼乓?致鄣拇蠹易釷煜さ腣模型的基礎。我的批評意見同時也針對其它的裝飾在一些更好的開發模型之上的測試模型，例如螺旋模型[Boehm88]。

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

圖2 V模型示意圖

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

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

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

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

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

圖4 一個假想的子系統

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

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

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

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

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

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

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

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

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

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

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

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

    在上圖右邊的方塊中，最好要改成為“執行某些適當的測試并得到相應的結果”。

    圖中的左邊會怎樣？考慮一下系統測試設計，它的主要根據和信息來源是是規格說明。假設你知道有2個單元處在一個特定的子系統中，它們在運行時相互聯系，并且要執行規格說明中的一個特定的聲明。為什么不在該子系統被集成時立即對此規格說明中的聲明進行測試，就象是在設計完成后立即開始測試的設計一樣呢？如果該聲明的執行和子系統外的子系統沒有任何關系，為什么還要等到整個系統完成以后再測試呢？難道越早發現bug成本越低不對嗎？

    在上一張圖片中，我們用了向上指的箭頭（更有效，但在時間上有延遲）。這里還可以把箭頭往下指（在時間上提前）：
 

圖8 新的方法：在不同階段上提前進行測試設計

    在這種情況下，左邊的方塊中最好被標記為：“在當前信息條件和情況下可以做的任何測試設計”。這樣，當測試設計得自于系統中某一個組件的描述時，模型必須允許這樣的測試在組件被裝配之前被執行。我必須承認我的圖片非常難看，這些箭頭指得到處都是，對此我有2點說明：

    1. 我們所討論的事情不是創造美，而是想要發現盡可能多的嚴重錯誤，同時盡可能地降低成本。

    2. 難看的部分原因也是因為必須按照某些次序來執行的結果，亦即開發人員先提供系統描述文檔，然后測試和這些文檔進行關聯。這些文檔就象是堅實的老橡樹，而測試設計則象是細細的枝條纏繞在樹上。如果我們采用不同的原理來進行組織，圖片可能就會變得好看些。但復雜性仍不可避免，因為我們要討論的問題本身就很復雜。

    V模型失敗的原因是它把系統開發過程劃分為具有固定邊界的不同階段，這使得人們很難跨過這些邊界來采集測試所需要的信息。有些測試應該執行得更早些，有些測試則需要延后進行。而且，它也阻礙了你從系統描述的不同階段中取得信息進行綜合。例如，某些組織有時執行這樣的做法，即對完成的工作進行簽署。這樣的規定也擴展到系統測試的設計。簽署表示已經過評估，該測試設計工作已經完成，除非對應的設計文檔改變，否則就不會被修訂。如果同這些測試相關的信息后來被重新挖掘和認識，例如，架構設計表明有些測試是多余的，或者，詳細設計表明有一個內部的邊界可以和已存在的系統測試組合在一起進行測試的話，那么實際上還需要繼續調整原來的系統測試設計。

    因此，模型必須允許利用不同來源的綜合信息進行個別的測試設計。另外，模型還應該允許在新的信息來源出現后重新進行測試的設計。