一個假想的子系統(tǒng)

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

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

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

　　 單元及其外部的驅(qū)動模塊和樁模塊

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

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

　　子系統(tǒng)內(nèi)部各單元間的測試執(zhí)行軌跡

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

　　V模型分析<2>

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

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

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

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