按測試模式來分類： 瀑布模型、敏捷測試、基於指令碼的測試、基於風險的測試、探索式測試等。

1、（傳統的）瀑布模型：

專案計劃->需求分析->軟體設計->程式開發->軟體測試->整合維護

專案計劃階段：主要是制定專案總體研發計劃，樹立專案里程碑節點，輸出專案計劃書；

需求分析階段：明確客戶的需求定義，並對這個定義進行清晰的描述，是充分理解客戶需求，描述產品功能的重要階段，這個階段會輸出產品的需求規格說明書；

軟體設計階段：則會根據需求的定義，來確定產品實現的方案，包括定義軟體硬體的結構，組建模組的實現方法，介面、介面、資料如何進行組織，這個階段會輸出包括概要設計，詳細設計在內的多份說明書；

程式開發階段：這個階段是開發團隊根據需求和設計具體實現我們的產品，來根據程式設計規範，構建我們的元件模組，最後輸出我們的產品版本；

軟體測試階段則是通過獨立的測試小組或者QI團隊評估我們的產品是否滿足需求的定義，最後輸出測試結果報告，

整合維護階段則是產品經過測試以後，交付給使用者，根據使用者的使用情況，再對產品進行維護，及必要的修改升級等操作。

優點：

1. 強調需求，設計的作用；
2. 前一階段完成後只需關注後續階段；
3. 為專案提供按階段劃分的檢查點，里程碑清晰
4. 文件規範

缺點：

1. 線性研發過程難以適應需求的頻繁變化，
2. 專案週期後段才可看到成果，使用者要到末期才能看到開發結果，增加了開發的風險
3. 強制的里程碑，對於開發過程中出現的變化，適應能力較差，
4. 文件工作量較大，測試在專案的後期，文件的開發帶來很大的工作量。

2、V模型（最廣泛）

需求分析->概要設計->詳細設計->軟體編碼->單元測試->整合測試->系統測試->驗收測試

瀑布模型的變種。

單元測試，整合測試：檢測程式是否滿足我們設計上的要求；

系統測試：在功能、效能這些質量特性上是否能夠滿足我們系統要求的指標；

驗收測試：確定軟體是否滿足使用者的一些需求，以及合同的一些規定；

優點：

在V模型裡，強調軟體開發的協作和速度，反應測試活動和分析測試的關係，並且將軟體的實現和驗證有機的結合了起來，V模型，明確的界定測試過程是存在不同階段的。

缺點：

但是V模型也有一定的侷限性,它僅僅把測試過程放在需求分析、系統設計、編碼之後的一個階段，忽視了測試對於需求的分析和驗證。我們對需求的驗證，對系統設計的驗證，到後期的驗收測試才有可能被發現，對於我們測試當中的測試需要儘早進行的原則在V模型中沒有體現，這是V模型的侷限。

3、W模型（雙V模型）

優點：開發與測試並行，有利於儘早發現問題，有利於及時的瞭解專案的測試風險，來及早的執行相應的應對方案，加快專案的進度。 

侷限性：需求、設計、編碼仍然是序列進行的，測試和開發保持線性的關係，上一個階段完成之後才能進行下一個階段，不能夠很好的支援迭代的開發模型。

4、X模型

解決交接和頻繁集成周期的問題

左邊描述的是針對單獨的程式片段相互分離的編碼和測試，此後進行頻繁的交接，再通過整合，最終合成可執行的程式，對這些程式進行測試，這些程式還是需要冀衡測試，已經通過的程式可以進行封板提交給使用者，也可以作為更大整合的一部分，X模型還定位了探索式測試，探索式測試是不進行事先計劃的特殊型別的測試，能夠幫助測試人員在測試計劃之外發現更多的錯誤。

5、H模型：

把軟體測試看成一個完全獨立的流程，與其他流程併發進行，比如設計流程，編碼流程，甚至是測試流程，

H模型強調把測試分為測試準備和測試執行兩個不同的階段，只要由於其他流程的進展引發了測試就緒點的到位，這時候，只要測試準備不能完成，測試執行活動就可以或者需要開展，在H模型當中，測試是一個完全獨立的模型，所以可以和其他的流程交叉地進行，也便於我們儘早的執行測試。

&n