軟件測試：V模型問題分析[2] 軟件測試
V模型有著很吸引人的對稱外形，并且把很多人都帶入了歧途。本文將集中討論它在單元測試和集成測試中引起的問題。
為了說明的方便，這里專門制作了以下圖片，圖中包括一個單獨的單元，以及一個單元組，我稱之為子系統(subsystem)。
圖4 一個假想的子系統
對于一個單元應該多大才最為合適的問題，已經有過很多的討論，究竟一個單元僅僅是一個函數，一個類，還是相關的類的集合?這些討論并不影響我在這里所要闡述的觀點。我們權且認為一個單元就是一個最小程度的代碼塊，開發人員可以對進行獨立地討論。
V模型認為人們首先應該對每一個單元進行測試。當子系統中所有的單元都已經測試完畢，它們將被集中到一起進行測試，以驗證它們是否可以構成一個可運行的整體。
那么，如何針對單元進行測試呢?我們會查看在詳細設計中對接口的定義，或者查看源代碼，或者同時對兩者進行查看，找出符合某些測試設計中的有關準則的輸入數據來進行輸入，然后檢查結果，看其是否正確。由于各單元一般來說不能獨立地運行，所以我們不得不另外設計樁模塊(Stub)和驅動模塊(Driver)，如下圖所示。
圖5 單元及其外部的驅動模塊和樁模塊
圖中的箭頭代表了測試的執行軌跡。這就是大多數人所說的“單元測試”。我認為這樣的方法有時候是一種不好的方法。
同樣的輸入也可以有同一子系統中的其它單元來提供，這樣，其它的單元既扮演了樁模塊，又扮演了驅動模塊。如下圖所示：
圖6 子系統內部各單元間的測試執行軌跡
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/