軟件測試的新模型(2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文轉自：http://www.uml.org.cn/Test/test47.htm