軟件開發模型和軟件測試模型
V模型、W模型、瀑布模型、 H模型、快速原型模型（敏捷開發）、X模型
軟件開發模型
邊寫邊改模型
當一個軟件產品格說明或主要設計的情況下被開發時，開發者往往不得不重新對產品編碼多次直到他們得到正確穩定的產品。這種開發模型就是邊做邊改模型。
開發者們首先開發出一個產品的最初版本給客戶驗收，然後開發團隊開發一個新的版本再次給客戶驗收。這個過程一直持續到客戶感覺產品滿意爲止
瀑布模型
瀑布模型規定了各項軟件工程活動，包括制定開發計劃、需求分析說明、軟件設計、程序編碼、測試和運行維護，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級落下。它具有以下特徵：
1.從上一項活動接受本項活動的丄作對象作爲輸入
2.利用這一輸入實施本項活動應完成的工作
3.給出本項活動的工作結果，作爲輸出傳遞給下一項活動
對本項活動實施的工作進行評審，若工作得到確認則繼續進行下一項活動，否則返回前一項活動，甚至更前項工作進行返工
瀑布模型的優缺點
優點
- 開發的各個階段比較清晰
- 強調早期計劃及需求調查
- 適合需求穩定的產品開發
缺點
- 依賴於早期的需求調查，不適應需求的變化；
- 單一流程不可逆；
- 風險往往延至後期才顯露，失去及早糾正的機會；
- 問題在項目後期纔開始暴露；
- 前面未發現的錯誤會傳遞並擴散到後面的階段，可能導致項目失敗。
快速原型模型
快速原型模型又稱爲敏捷開發模型。其核心是以人爲本，適用變化。
在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。
第一步是建造一起快速原型，實現用戶與系統的交互，用戶對原型進行評價，進一步細化開發軟件的需求。通過逐步調整原型使其滿足用戶的要求，開發人員可以確定用戶的真正需求是什麼。
第二步是在第一步的基礎上開發出用戶滿意的軟件產品。
| 優點 | 1. 克服瀑布模型的缺點，更好地滿足用戶的需求並減少由於軟件需求不明確帶來的項目開發風險。 2. 適合預先不能確切定義需求的軟件系統的開發。 |
|---|---|
| 缺點 | 1. 不適合大型系統的開發（適合開發小型的、靈活性高的系統）。 2. 前提要有一個展示性的產品原型，因此在一定程度上可能會限制開發人員的創新。 |
螺旋模型
螺旋模型將瀑布模型和原型模型結合起來，不僅體現了兩個模型的優點，而且還增加了兩個模型都忽略了的風險分析，彌補了兩者的不足。沿螺旋線向外每旋出一圈便開發一個更爲晚上的新的軟件版本，並且進行風險評估。
| 軟件開發模型 | 優缺點 | 適用場景 |
|---|---|---|
| 邊寫邊改模型 | 1. 缺少規劃和設計環節，軟件的結構隨着不斷的修改越來越糟，導致無法繼續修改； 2. 忽略需求環節，給軟件開發帶來很大的風險； 3. 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。 |
某些場合這種簡單的方式非常有用。對需求簡單和容易明白，軟件期望的功能行爲容易定義，實現的成功或失敗容易檢驗的工程可以使用這種模型 |
| 瀑布模型 | 1. 爲項目提供了按階段劃分的檢査點； 2. 當前一階段完成後，只需要去關注後續階段。 3. 可在迭代模型中應用瀑布模型。 1. 在項目的各個階段極少有反饋； 2. 只有在項目生命週期的後期才能看到結果；3. 通過過多的強制完成日期和里程碑來跟蹤各個項目階段。 |
a. 用戶的需求非常清楚全面，在開發過程中沒有或很少變化： b. 開發人員對軟件的應用領域很熟悉 c. 用戶的使用環境非常穩定； 4. 開發工作對用戶參與的要求很低。 |
| 快速原型模型 | 1. 可以得到比較良好的需求定義，容易適應需求的變化； 2. 有利於開發與培訓的同步 3. 開發費用低、開發週期短且對用戶更友好。 1. 客戶與開發者對原型理解不同； 2. 準確的原型設計比較困難； 3. 不利於開發人員的創新。 |
a. 對所開發的領域比較熟悉而且有快速的原型開發工具； b. 項目招投標時，可以以原型模型作爲軟件的開發模型； c. 進行產品移植或升級時，或對已有產品原型進行客戶化工作時。 |
| 螺旋模型 | 1. 設計上的靈活性，可以在項目的各個階段進行變更； 2. 以小的分段來構建大型系統，使成本計算變得簡單容易； 3. 客戶始終參與每個階段的開發，保證了項目不偏離正確方向以及項目的可控性； 4. 隨着項目推進，客戶始終掌握項目的最新信息，從而能夠和管理層有效地交互 5. 採用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目中，如果未能及時識別風險，勢必造成重大損失 6. 過多的迭代次數會增加開發成本，延遲提交時間 |
螺旋模型只適合於大規模的軟件項目 |
軟件測試模型
V模型
V模型：需求分析-概要設計-詳細設計-編碼-單元測試-集成測試-系統測試-驗收測試
V模型的優缺點
| 優點 | 1. 包含了底層測試（單元測試）和高層測試（系統測試）； 2. 清楚地標識了開發和測試的各個階段，每個階段都與開發的各個階段相對應； 3. 每個階段分工明確，便於整體項目的把控。 |
|---|---|
| 缺點 | 1. 測試工作只在需求分析、系統設計及編碼之後，不能及時發現並修改錯誤； 2. 測試的對象僅僅是程序，忽略了需求分析，系統設計的測試驗證，很可能到最後的驗收測試才發現需求和系統設計的錯誤； 3. 過程是線性的，不能反覆迭代和測試 |
W模型
W模型：用戶需求-需求分析-概要設計-詳細設計-編碼-單元測試-集成測試-驗收測試-單元測試設計-集成測試設計-系統測試設計-驗收測試設計-集成-實施-交付。
W模型的優點和侷限性
| 優點 | 1. 測試伴隨着整個開發週期，需求和設計同樣要測試; 2. 更早的介入測試，可以發現初期的缺陷，修復成本低； 3. 分階段工作，方便項目整體管理。 |
|---|---|
| 侷限性 | 1. 需求、設計、編碼等活動被視爲串行的，開發和測試依然是線性的關係，上一階段工作完全結束，纔可正式開始下一個階段工作； 2. 每一階段都要有文檔，沒有文檔根本無法執行w模型； 3. 對於需求和設計、項目組成員的技術的要求很高，實踐起來困難。 |
H模型
H模型：測試準備-測試就緒點-測試執行-測試流程-其他流程。
H模型是爲了解決V模型和W模型存在的問題，尤其是線性問題，導致無法重複迭代和測試的問題。
特點：
- 它將測試活動完全獨立出來，形成一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。測試貫穿整個生命週期，與其他流程併發地進行。
- 軟件測試不僅僅指測試的執行，還包括很多其他的活動(如計劃、需求分折、用例設計、環境搭建、提交缺陷、評估總結等)
當某個測試時間點就緒時，軟件測試即從測試準備階段進入測試執行階段。 - 軟件測試要儘早準備，儘早執行。
- 軟件測試是根據被測物的不同而分層次進行的，不同層次的測試話動可以是按照某個次序先後進行的，但也可能是反覆的。
優點：
（1）介入早，與開發並行，更早的發現問題
（2）測試過程是獨立於開發過程，更客觀和主動的
X模型
X模型：程序片段1-測試設計-工具配置-執行測試-編碼完成-執行測試-工具配置-測試設計-程序片段N；封版-執行測試-測試設計-工具配置-迭代1…N-探索式測試-執行測試
X模型是對V模型的改進。
X模型左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過集成最終合成爲可執行的程序。
右上半部分，這些可執行程序還需要進行測試。已通過集成測試的成品可以進行封版並提交給用戶，也可以作爲更大規模和範圍內集成的一部分。
多根並行的曲線表示變更可以在各個部分發生。
X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。
軟件筆試題經常會看到V模型上的幾種測試方法。
測試階段
軟件測試按測試階段可以劃分爲以下幾個測試，這個也是
1、單元測試
又稱模塊測試，針對軟件設計中的最小單位-- 樁模塊，進行正確性檢查的測試工作。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。
單元測試的粒度最小，一般由開發小組採用白盒方式來測試，主要測試單元是否符合“設計”。
2、集成測試
又叫組裝測試。集成測試主要用來測試模塊與模塊之間的接口，同時還要測試一些主要業務功能。重點測試不同模塊的接口部分。
集成測試界於單元測試和系統測試之間，起到“橋樑作用”，一般由開發小組採用白盒加黑盒的方式來測試，既驗證“設計”，又驗證“需求”。
3、系統測試(system testing)：
系統測試是將整個軟件系統看爲一個整體進行測試，包括對功能、性能、以及軟件所運行的軟硬件環境進行測試。
系統測試在系統集成完畢後進行測試，前期主要測試系統的功能是否滿足需求，後期主要測試系統運行的性能是否滿足需求，以及系統在不同的軟硬件環境中的兼容性等。
系統測試的粒度最大，一般由獨立測試小組採用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。
4、驗收測試
α測試：Alpha是內測版本，即現在所說的C8。通常只在軟件開發者內部交流，α測試主要看有沒有功能缺失或系統錯誤。也有很少一部分發布給專業測試人員。
β測試：Beta是公測版本，是對所有用戶開放的測試版本。主要是看用戶對軟件外觀、使用方便等的反應。給用戶測的目的一方面是使最終產品儘可能地滿足用戶的需要，另一方面也儘量成少了軟件中的bug。
λ測試：Camma版本，指的是軟件版本正式發行的候選版。該版本已經相當成熟了，與即將發行的正式版相差無幾，成爲正式反布的候選版本。
簡單來說，α測試主要是測試人員在開發環境下的測試，β測試是在實際環境中的測試。
從測試設計方法可以劃分爲
黑盒測試不考慮程序內部結構和邏輯結構，主要是用來測試系統的功能是否滿足需求規格說明書。一般會有一個輸入值，一個輸入值，和期望值做比較。
白盒測試主要應用在單元測試階段，主要是對代碼級的測試，針對程序內部邏輯結構，測試手段有：語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋。
灰盒測試介於黑盒和白盒之間