2010年軟考軟件評測師軟件測試流程及步驟(5)

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

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

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

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

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

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

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

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

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

　　V模型分析<2>

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

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

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

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