模板
教程
環境
性能
功能
管理
軟件測試，不可忽略的階段
軟件開發的幾十年歷程業已證明，在開發生命周期中劃分階段的做法是很有好處的。在經典的瀑布模型基礎上，還有螺旋模型和過程迭代方法，快速軟件開發(RAD)以及較新的Rational統一過程(RUP)，但在這些過程方法中，并沒有充分強調測試的價值，也沒有給測試以足夠的重視。
就象開發有開發模型一樣，測試也有測試模型，盡管這些方法鮮為人知。部分原因是因為很多測試人員已經在他們的工作中積累了大量的經驗，利用這些經驗就可以做好他們的工作?？偟膩碚f，測試往往要占據整個開發周期的時間，但即使在很多正規的大學中，也沒有為那些即將開始軟件生涯的學生們設置軟件測試課程。
軟件專家們不斷在提供新的開發模型，這也是實際開發需要使然，與此同時，在開發過程中也不斷感受到這些已存在的方法的不足，例如，還沒有比RUP更充分的方法，但RUP也存在一些明顯的不足，例如，RUP沒有對測試計劃進行定位。
V-模型
V模型只得到軟件業內比較模糊的認可。V-模型宣稱測試并不是一個事后彌補行為，而是一個同開發過程同樣重要的過程。V模型如下圖所示：
圖1：V模型示意圖
V模型最早由已故的Paul Rook在80年代后期提出，V模型被包含在英國國家計算中心文獻中發布，旨在改進軟件開發的效率和效果。V模型在歐洲尤其是英國被接受，并被認為是瀑布模型的替代品，而在美國則被誤解為是又一種瀑布模型。
在傳統開發過程中，僅僅把測試過程作為在需求分析、概要設計、詳細設計及編碼之后的一個階段，事實上，V模型的推出也是對此所進行的改進。在瀑布模型中，確實給人們造成了這樣的不良影響，即在很多重要開發活動完成后，測試只是收尾工作，而不是主要的過程，盡管有時測試會占據項目周期一半的時間，很多項目主管卻仍然還是堅持這么認為。
測試是一項意義顯著的工作
V模型描述了一些不同的測試級別，并說明了這些級別所對應的生命周期中不同的階段。如模型圖中所示，左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即各測試過程的各個階段。請注意在不同的組織中，對測試階段的命名可能有所不同。
在模型圖中的開發階段一側，先從定義業務需求開始，然后要把這些需求不斷地轉換到概要設計和詳細設計中去，最后開發為程序代碼。在測試執行階段一側，執行先從單元測試開始，然后是集成測試、系統測試和驗收測試。
V模型的價值在于它非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系：
· 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。
· 集成測試主要目的是針對詳細設計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。
· 系統測試主要針對概要設計，檢查了系統作為一個整體是否有效地得到運行，例如在產品設置中是否達到了預期的高性能。
· 驗收測試通常由業務專家或用戶進行，以確認產品能真正符合用戶業務上的需要。
在不同的開發階段，會出現不同類型的缺陷和錯誤，所以需要不同的測試技術和方法來發現這些缺陷。
發現缺陷的藝術
大多數測試人員比較容易接受V模型的觀點，即測試和開發在開發過程中是平等的。即使是開發人員也同樣很欣賞V模型所提出的測試級別和開發過程相對應的方式，但很少有人去充分利用V模型的全部威力。很多人認為測試只是在編碼或者系統某個部分完成后會發生什么，并且錯誤地將測試看作為“執行測試”。這樣，他們知道要開始執行測試的時候才真正想到了測試。
測試不僅僅是測試。測試過程還包括確定要測試什么(測試范圍和條件)以及產品如何被測試(制作測試用例)，建立測試環境，執行測試，最后再評估測試結果，檢查是否達到已完成測試的標準，并報告進展情況。而且，僅有這些還不夠，根據很多測試者的經驗，當你認為什么地方有問題時，你就很可能會在那里發現問題。如測試專家Boris Beizer在他經典的測試著作《Software Testing Techniques (Thomson Computer Press, 1990)》中所說，測試設計可以發現缺陷和錯誤。
而且，如果你把測試設計放在最后階段，就錯過了發現構架設計和業務邏輯設計中存在的嚴重問題的時機，到那時，要修復這些缺陷將很不方便，因為缺陷已經擴散到系統中去了，所以這樣的錯誤將很難尋找和修復，并且代價更高。
比較靈活的解釋，盡量提早的測試
V模型在歐洲，至少在英國很容易被解釋，但在美國卻比較難以被接受。例如，雖然V模型沒有明確說明早期的測試設計，而Graham則認為它體現在了處理過程中，并認為這是V模型的強大力量所在。V模型所沒有明確說明的這些其它的測試行為有時被演化為一種W模型，因為實際上開發是"V"，測試也是與此相重疊的"V"。不管V模型是否明確說明了早期的測試設計行為，測試設計確實是值得強調的。
根據V模型的要求，一旦有文檔提供，就要及時確定測試條件，以及編寫測試用例，這些工作對測試的各級別都有意義。當需求被提交后，就需要確定高級別的測試用例來測試這些需求。當概要設計編寫完成后，就需要確定測試條件來查找該階段的設計缺陷。
如果測試文檔能盡早提交，那么就有了更多的檢查和檢閱的時間，這些文檔還可用于評估開發文檔。另外還有一個很大的益處是，測試者可以在項目中盡可能早地面對規格說明書的挑戰(測試是一種接受挑戰的行為)。
這意味著測試不僅僅是評定軟件的質量，測試還可以盡可能早地找出缺陷所在，從而幫助改進項目內部的質量。參與前期工作的測試者可以預先估計問題和難度，這將可以顯著地減少總體測試時間，加快項目進度。
What-How-Do
對于傳統的瀑布生命周期模型來說，V模型常被錯誤地認為是要求開發和測試保持一種線性的前后關系，需要有嚴格的指令表示上一階段完全結束，才可正式開始下一個階段。這樣就無法支持迭代，自發性以及變更調整。例如，Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一書的作者)在“測試過程新模型”一文中提到，“V模型的問題在于一定要將系統開發過程分為具有嚴格邊界的階段，這使人們無法在這些邊界之間交接和交換測試信息?！?/P>
情況其實并不是這樣的，嚴格規定不是有效的開發人員和測試人員在應用各種模型過程中所采用的方式。實際上，各種模型只是簡單地提醒我們，有必要定義一些必須要做什么(需求)--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模型。
