軟件測試的模型

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

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

項目計劃->需求分析->軟件設計->程序開發->軟件測試->集成維護

 

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

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

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

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

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

集成維護階段則是產品通過測試之後，交付給用戶，根據用戶的使用狀況，再對產品進行維護，及必要的修改升級等操做。

 

優勢：

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

缺點：

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

 

 

二、V模型（最普遍）

需求分析->概要設計->詳細設計->軟件編碼->單元測試->集成測試->系統測試->驗收測試

瀑布模型的變種。

 

 

單元測試，集成測試：檢測程序是否知足咱們設計上的要求；

系統測試：在功能、性能這些質量特性上是否可以知足咱們系統要求的指標；

驗收測試：肯定軟件是否知足用戶的一些需求，以及合同的一些規定；

優勢：

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

缺點：

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

 

 

三、W模型（雙V模型）

 

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

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

 

 

四、X模型

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

 

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

 

 

五、H模型：

把軟件測試當作一個徹底獨立的流程，與其餘流程併發進行，好比設計流程，編碼流程，甚至是測試流程，

 

H模型強調把測試分爲測試準備和測試執行兩個不一樣的階段，只要因爲其餘流程的進展引起了測試就緒點的到位，這時候，只要測試準備不能完成，測試執行活動就能夠或者須要開展，在H模型當中，測試是一個徹底獨立的模型，因此能夠和其餘的流程交叉地進行，也便於咱們儘早的執行測試。