軟件測試中不可忽略的階段[3] 軟件測試工具
What-How-Do
對于傳統的瀑布生命周期模型來說，V模型常被錯誤地認為是要求開發和測試保持一種線性的前后關系，需要有嚴格的指令表示上一階段完全結束，才可正式開始下一個階段。這樣就無法支持迭代，自發性以及變更調整。例如，Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一書的作者)在“測試過程新模型”一文中提到，“V模型的問題在于一定要將系統開發過程分為具有嚴格邊界的階段，這使人們無法在這些邊界之間交接和交換測試信息�！�
情況其實并不是這樣的，嚴格規定不是有效的開發人員和測試人員在應用各種模型過程中所采用的方式。實際上，各種模型只是簡單地提醒我們，有必要定義一些必須要做什么(需求)--What，然后描述如何做(設計)--How，然后花很多力氣來實現(編碼)--Do。V模型所做的是強調每一個開發級別都有一個與之相關聯的測試級別，并且建議測試應該在各級別之前進行設計。
各模型并沒有規定工作量大小。有效的開發人員總是能將項目分解為可操作的小階段，例如在迭代式開發中整個項目被分解為很多小片斷，并忽略了各片段的實際大小。此時，模型的what-how-do順序對于按時交付就具有重要意義，而且對于保證每一個階段目標的實現也非常重要。
V模型所不能做的
V模型適用于所有類型的開發過程，但并不一定適用于開發和測試過程的所有方面。不管是GUI還是批處理、大型機還是Web、Java還是Cobol，都需要單元測試、集成測試、系統測試和驗收測試。但是，V模型本身并不會告訴你如何定義單元測試或集成測試的內容、以如何順利工作、如何進行具體的測試設計，以及該輸入怎樣的數據，輸出怎樣的輸出結果才是正確的。
有些測試者認為：“是否使用V模型要看該所應用的項目。有些項目需要應用V模型，而有些項目不需要�？梢灾辉谛枰猇模型的項目中采用�！边@樣的做法實際上對任何模型都是有害的。我們應該盡可能地去應用模型中對項目有實用價值的方面，但不強行地為使用模型而使用模型，否則也沒有實際意義。
例如，V模型的反對者經常聲稱V模型只有對需求非常明確，已經文檔化了的項目才有用，因為所有的開發人員和測試人員都需要嚴格定義好的需求和設計來開展工作。對于當前很多文檔需要事后補充，或者根本沒有文檔的做法下(這已成為一種開發的文化)，開發人員和測試人員都面臨同樣的困惑。在這種情況下，V模型的概念仍然是有用的，但在需求不明確的情況下更難應用，因為不管要開展什么工作，要測試什么，首先需要明確知道開發了什么。
V模型的反對者可能會聲稱V模型不適用于極限編程(XP)，在XP中提倡快速開發，結對編程，在編碼之前就已完成測試用例。首先，我們提倡同時應用這兩種方法，另外，也需要指出的是XP方法也強調在編程之前盡可能發現需求。
V模型沒有明確說明需求和設計文檔應如何定義，要定義多少文檔，同時V模型也沒有說明在各測試階段如何進行測試設計。在采用XP策略的開發過程中，V模型的支持者認為，可以將單元測試應用于所劃分的各個代碼片段上，但V模型沒有定義各單元測試之間應如何匹配。只在必要的時候，才需要進行集成測試，而最終意義上的集成測試也就是系統測試。盡管一些XP工作者將這些測試看作為“驗收測試”，其實際目的只是希望降低讓用戶進行測試的必要性，同時又希望能確保系統在功能上滿足用戶業務的需要。
V模型的替代品--X模型? 軟件測試
也許是由于V模型存在已有了一段時間，它曾帶來過一定程度上的濫用，尤其是在那些Internet時代比較緊急的項目中。
Marick認為："我們對V模型的需要就象是魚對自行車的需要一樣。"在他的文章中提出了測試過程的新模型。他認為，有些測試要比商業行為更早些，而另外一些測試則要在更晚的時候得以進行。而且，V模型使人很難對不同階段的系統描述進行綜合。
V模型的支持者則認為，雖然在顯示面前沒有一個模型表現得無可挑剔，但在實踐過程中，有些模型還是比較有用的。在下一篇中，我們將審視Marick所提倡的X模型。
文章來源于領測軟件測試網 http://www.kjueaiud.com/