對於學習軟體測試這一方面的朋友肯定對「模型」這個詞不陌生吧
下面來介紹一下它的常用模型方面。
瀑布模型是乙個專案的開發架構，開發的過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 「返回」上乙個階段並進行適當的修改，專案開發程序從乙個階段「流動」到下乙個階段，這也是瀑布模型名稱的由來。
模型流程圖如下：
瀑布模型的優點：
（1）為專案提供了按階段劃分的檢查點。
（2）當前一階段完成後，您只需要去關注後續階段。
（3）可在迭代模型中應用瀑布模型。增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生乙個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。
（4）它提供了乙個模板，這個模板使得分析、設計、編碼、測試和支援的方法可以在該模板下有乙個共同的指導。
瀑布模型的缺點：
瀑布模型有以下缺點
（1）各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。
（2）由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
（3）通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
（4）瀑布模型的突出缺點是不適應使用者需求的變化。
（5）成本較高，一旦初階段方向錯誤，容易直接崩掉。
什麼是快速原型模型：
快速原型模型又稱原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造乙個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。快速原型模型的第一步是建造乙個快速原型，實現客戶或未來的使用者與系統的互動，使用者或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。
模型流程圖如下：
快速原型模型的優點：
克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險。
這種模型適合預先不能確切定義需求的軟體系統的開發。
成本低，耗時低
快速原型模型的缺點：
缺點：所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。
使用這個模型的前提是要有乙個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。
螺旋模型它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。
螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個迭代階段構建原型是螺旋模型用以減小風險的途徑。
螺旋模型更適合大型的昂貴的系統級的軟體應用
詳細介紹：
螺旋模型（spiral model）採用一種週期性的方法來進行系統開發。這會導致開發出眾多的中間版本。使用它，專案經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為中心，在每個專案階段使用瀑布模型法。
這種模型的每乙個週期都包括需求定義、風險分析、工程實現和評審4個階段，
由這4個階段進行迭代。軟體開發過程每迭代一次，軟體開發又前進乙個層次。採用螺旋模型的
螺旋模型基本做法是在「瀑布模型」的每乙個開發階段前引入乙個非常嚴格的風險識別、風險分析和風險控制，它把軟體專案分解成乙個個小專案。每個小專案都標識乙個或多個主要風險，直到所有的主要風險因素都被確定
（1）設計上的靈活性,可以在專案的各個階段進行變更。
（2）以小的分段來構建大型系統,使成本計算變得簡單容易。
（3）客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
（4）隨著專案推進,客戶始終掌握專案的最新資訊 , 從而他或她能夠和管理層有效地互動。
（5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
很難讓使用者確信這種演化方法的結果是可以控制的。
建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
螺旋模型的專案適用：
對於新近開發，需求不明確的情況下，適合用螺旋模型進行開發，便於風險控制和需求變更
成本高，耗時長
增量模型是把待開發的軟體系統模組化，將每個模組作為乙個增量元件，從而分批次地分析、設計、編碼和測試這些增量元件。運用增量模型的軟體開發過程是遞增式的過程。相對於瀑布模型而言，採用增量模型進行開發，開發人員不需要一次性地把整個軟體產品提交給使用者，而是可以分批次進行提交。
增量模型是瀑布模型和原型進化模型的綜合，它對軟體過程的考慮是：在整體上按照瀑布模型的流程實施專案開發，以方便對專案的管理；但在軟體的實際建立中，則將軟體系統按功能分解為許多增量構件，並以構件為單位逐個地建立與交付，直到全部增量構件建立完畢，並都被整合到系統之中交付使用者使用
（1）將待開發的軟體系統模組化，可以分批次地提交軟體產品，使使用者可以及時了解軟體專案的進展。
（2）以元件為單位進行開發降低了軟體開發的風險。乙個開發周期內的錯誤不會影響到整個軟體系統。
（3）開發順序靈活。開發人員可以對元件的實現順序進行優先順序排序，先完成需求穩定的核心元件。當元件的優先順序發生變化時，還能及時地對實現順序進行調整。
要求待開發的軟體系統可以被模組化。
如果待開發的軟體系統很難被模組化，那麼將會給增量開發帶來很多麻煩。
適用於具有以下特徵的軟體開發專案：
（1）軟體產品可以分批次地進行交付。
（2）待開發的軟體系統能夠被模組化。
（3）軟體開發人員對應用領域不熟悉，難以一次性地進行系統開發。
（4）專案管理人員把握全域性的水平較高
軟體測試模型
線性模型 優點 即包含底層測試又包含高層測試 開發階段界定清晰 便於控制開發過程 缺點 風險後延,失去及早糾正的機會 錯誤的傳遞蔓延 返工量非常大,模型靈活性低 測試伴隨整個開發周期 優點 測試伴隨整個開發周期 更早的介入測試，降低成本 開發階段界定清晰 缺點 小型專案不適用 技術要求高，實踐困難 ...
軟體測試 基礎篇
需求分析 測試計畫 測試設計 測試開發 測試執行 測試評估 1 發現問題的版本 開發人員需要知道出現問題的版本，才能夠獲取對應版本的 來重現故障。並且版本的標識也有利於統計和分析每個版本的質量.2 問題出現的環境 描述問題重現的最短步驟.4 預期行為的描述 要讓開發人員指導怎麼樣才是正確的，尤其要以...
軟體測試 基礎篇
1.軟體測試的生命週期 需求分析 測試計畫 測試設計 測試開發 測試執行 測試評估 2.軟體測試 軟體開發生命週期 1 需求階段 測試人員了解需求，對需求進行分解，得出測試需求 2 計畫階段 根據需求編寫測試計畫 測試方案 3 設計階段 測試人員搭建測試用例框架，依據需求和設計編寫一部分測試用例 4...