軟件測試：V模型問題分析[3] 軟件測試
到底選擇哪一種方法，這需要一種折衷和權衡。設計樁模塊和驅動模塊要付出多少代價?這些模塊如何進行維護?子系統是否會由此而掩蓋了一些故障?在整個子系統范圍內進行排錯的困難程度有多大?如果我們的測試直到集成測試時才真正開始，那么一些bug可能較晚才被發現。由此造成的代價同設計樁模塊和驅動模塊的代價如何比較?
V模型沒有去考慮這些問題，當單元開發完成后就執行單元測試，而當自系統被集中在一起后就執行集成測試，僅此而已。令我奇怪和沮喪的是，人們從不去做一些權衡，他們已經受制于他們的模型。
因此，一個有用的模型應該允許測試人員考慮節省并推遲測試的可能性。
一個測試，如果要發現一個特定的單元中的bug，最好是在該單元保持獨立的情況下執行，并且在其外部輔以特定的樁模塊和驅動模塊。而另一種方法則是讓它作為子系統的一部分來進行測試，該測試的設計主要是為了發現集成的問題。由于一個子系統本身也需要樁模塊和驅動模塊來模擬該子系統和其它子系統的聯系，因此，單元測試和集成測試可能被推遲到至少整個系統已經部分集成的時候。在這種情況下，測試者可能通過產品的外部接口同時進行單元測試、集成測試和系統測試，同樣的，其主要目的還是為了減少總體生命周期的成本，對測試成本和延期進行測試及由此造成延期發現bug的代價成本進行權衡。據此而言，"單元測試"、"集成測試"和"系統測試"的區別已經大大削弱了。其結果可參考下圖：
圖7 新的方法：在部分階段延遲進行單元測試和集成測試
在上圖右邊的方塊中，最好要改成為“執行某些適當的測試并得到相應的結果”。
圖中的左邊會怎樣?考慮一下系統測試設計，它的主要根據和信息來源是是規格說明。假設你知道有2個單元處在一個特定的子系統中，它們在運行時相互聯系，并且要執行規格說明中的一個特定的聲明。為什么不在該子系統被集成時立即對此規格說明中的聲明進行測試，就象是在設計完成后立即開始測試的設計一樣呢?如果該聲明的執行和子系統外的子系統沒有任何關系，為什么還要等到整個系統完成以后再測試呢?難道越早發現bug成本越低不對嗎?
在上一張圖片中，我們用了向上指的箭頭(更有效，但在時間上有延遲)。這里還可以把箭頭往下指(在時間上提前)：
圖8 新的方法：在不同階段上提前進行測試設計
文章來源于領測軟件測試網 http://www.k11sc111.com/