開發和測試的目的相同都是為了制造出高質量的軟件；又有相輔相成的作用，開發經驗對測試有用，測試經驗對開發有用；但側重點不同，開發是偏重於從無到有，而測試是從有到優
一、開發模式
-
瀑布模型
-
特點
-
階段間具有順序性與依賴性
前一階段的輸出文檔就是后一階段的輸入文檔，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結果
-
推遲實現
對於規模較大的軟件項目來說，往往編碼開始的越早，最終完成開發所需時間越長。 因為前面階段的工作沒做或做的不扎實，過早地考慮進行程序實現， 往往導致大量返工，有時甚至發生無法彌補的問題
瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現
清楚的區分邏輯設計與物理設計，盡可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想
-
質量保證的觀點
為了保證所開發的軟件的質量，在瀑布模型的每一個階段都應堅持兩個重要做法 ①每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務 ②每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤 傳統的瀑布模型過於理想化，實際的瀑布模型是帶"反饋環"的。當在后面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品后再回來繼續完成后面階段的任務
瀑布模型是文檔驅動的模型，遵守這個約束可以使軟件維護變得比較容易一些，降低軟件預算
-
-
優缺點
- 優點
- 為項目提供了按階段划分的檢查點
- 當前一階段完成后，只需去關注后續階段
- 可以在迭代模型中應用瀑布模型
- 缺點
- 不適合需求模糊或需求經常變動的系統
- 由於開銷的逐步升級問題，它不希望存在早期階段的反饋
- 在一個系統完成以前，它無法預測一個新系統引入一個機構的影響
- 在用戶可能需要較長等等時間來獲取一個可供使用的系統，也許會給用戶的信任程度帶來影響和打擊
- 最終產品往往反映用戶的初始需求而不是最終需求
- 優點
-
-
快速原型
快速原型模型不帶反饋環，軟件產品的開發基本上是線性順序進行的 快速原型的本質是"快速"。開發人員應盡可能地建造出原型系統，以加速軟件開發過程，節約軟件開發成本 原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄
-
特點
快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集 快速原型模型是增量模型的另一種形式，在開發真實系統之前，迅速建造一個可以運行的軟件原型 ，以便理解和澄清問題，在該原型的基礎上，逐漸完成整個系統的開發工作 它允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現及測試、維護
-
優缺點
-
優點
克服瀑布模型的缺點，減少由於軟件需求不明確的帶來開發風險，適合預先不能確切定義需求的軟件系統的開發
-
缺點
所選用的開發和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量底下，使用前提是要有一個展示性的產品原型，一定程度上可能會限制開發人員的創新
-
-
-
增量模型
-
把瀑布模型的順序特征與快速原型法的迭代特征相結合 將軟件看作一系列相互聯系的增量，在開發過程的各次迭代中，每次完成其中的一個增量
-
優缺點
-
優點
能在較短的時間內向用戶提交可完成部分工作的產品 將待開發的軟件系統模塊化，可以分批次地提交軟件產品，使用戶可以及時了解軟件項目的進展 以組件為單位進行開發降低了軟件開發的風險。一個開發周期內的錯誤不會影響到整個軟件系統 開發順序靈活。開發人員可以對組件的實現順序進行優先級排序，先完成需求穩定的核心組件。當組件的優先級發生變化時，還能及時地對實現順序進行調整
-
缺點
由於各個構件是逐漸並入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化后分別開發的方法較適應於需求經常改變的軟件開發過程
-
作用
- 開發初期的需求定義只是用來確定軟件的基本結構，使得開發初期用戶只需要對軟件需求進行大概的描述；而對於需求的細節性描述，則可以延遲到增量構件開發時進行，以增量構件為單位逐個地進行需求補充。這種方式能夠有效適應用戶需求的變更
- 軟件系統可以按照增量構件的功能安排開發的優先順序，並逐個實現和交付使用。不僅有利於用戶盡早用上系統，能夠更好地適應新的軟件環境，而且在以增量方式使用系統的過程中，還能獲得對軟件系統后續構件的需求經驗
- 軟件系統是逐漸擴展的，因此開發者可以通過對諸多構件的開發，逐步積累開發經驗。實際上，增量式開發還有利於技術復用，前面構件中設計的算法、采用的技術策略、編寫的源碼等，都可以應用到后面將要創建的增量構件中去
- 增量式開發有利於從總體上降低軟件項目的技術風險。個別的構件或許不能使用，但一般不會影響到整個系統的正常工作
- 實際上，在采用增量模型時，具有最高優先權的核心增量構件將會被最先交付，而隨着后續構件不斷被集成進系統，這個核心構件將會受到最多次數的測試。這意味着軟件系統最重要的心臟部分將具有最高的可靠性，這將使得整個軟件系統更具健壯性
-
-
-
螺旋模型
-
描述
-
帶箭頭的點划線
長度代表當前累計的開發費用
-
螺旋線的角度值代表開發進度
-
螺旋線的每個周期對應於一個開發階段
-
四個象限代表了以下活動
- 制定計划：確定軟件目標，選定實施方案，弄清項目開發的限制條件
- 風險分析：分析評估所選方案，考慮如何識別和消除風險
- 實施工程：實施軟件開發和驗證
- 客戶評估：評價開發工作，提出修正建議，制定下一步計划
-
-
優缺點
螺旋模型在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定 螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而做出應有的反應，因此特別適用於龐大、復雜並具有高風險的系統
- 優點
- 設計靈活可以在項目各個階段進行變更
- 風險驅動,每個項目上線前都要進行風險分析
- 缺點
- 螺旋模型強調風險分析,需要相當豐富的風險評估經驗和專門知識,在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失
- 如果執行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義
- 優點
-
使用場景
適合使用大規模的軟件項目
-
二、測試模式
-
V模型
V模型和瀑布模型有一些共同的特性，V模型中的過程從左到右，描述了基本的開發 過程和測試行為
-
說明
- 單元測試：模塊測試，驗證軟件的基本組成單位的正確性
- 集成測試：模塊間的測試，測試接口是否正確
- 系統測試：包括冒煙測試、系統測試、回歸測試；檢測系統的功能、質量、性能能否滿足系統的要求，包括功能、性能、界面、可靠性、兼容性等
- 冒煙測試：主干流測試，確認軟件的基本功能能否正常，可以進行后續的測試工作
- 回歸測試：修改了舊代碼之后重新進行測試，確認修改后的代碼沒有引入新的錯誤或導致其它代碼產生新的錯誤
- 驗收測試：確保軟件的實現能否滿足用戶的需求或合同的需求
-
優缺點
-
優點
每個階段都清晰明了，便於控制開發的每個過程，即包含單元測試又包含系統測試
-
缺點
測試介入較晚，對於前期的一些缺陷無從發現和修改、測試和開發串行，總用時較長
-
-
-
W模型（雙V模型）
V模型的局限性在於沒有明確地說明早期的測試,無法體現“盡早地和不斷地進行軟件測試” 的原則。在V模型中增加軟件各開發階段應同步進行的測試，演化為W 模型（如下圖）。在模型中不難看出，開發是“V”，測試是與此並行的“V”。 W模型是V模型的發展，強調的是測試伴隨着整個軟件開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於盡早地發現問題
-
優缺點
-
優點
測試伴隨軟件的整個生命周期,例如,在需求分析結束后就可以進行需求分析測試、 測試於開發是並行獨立進行
-
缺點
對需求和測試技術要求高 適用於大中型企業
-
-
-
H模型
H模型中, 軟件測試過程活動完全獨立,貫穿於整個產品的周期,與其他流程並發地進行,某個測試點准備就緒時,就可以從測試准備階段進行到測試執行階段。軟件測試可以盡早的進行,並且可以根據被測物的不同而分層次進行
- 優缺點
- 優點
- 開發的H模型揭示了軟件測試除測試執行外，還有很多工作
- 軟件測試完全獨立，貫穿整個生命周期，且與其他流程並發進行
- 軟件測試活動可以盡早准備、盡早執行，具有很強的靈活性
- 缺點
- 管理型要求高：由於模型很靈活，必須要定義清晰的規則和管理制度，否則測試過程將非常難以管理和控制
- 技能要求高：H模型要求能夠很好的定義每個迭代的規模，不能太大也不能太小
- 測試就緒點分析困難：測試很多時候，你並不知道測試准備到什么時候是合適的，就緒點在哪里，就緒點的標准是什么，這就對后續的測試執行的啟動帶來很大困難
- 優點
- 優缺點