軟體測試模型
軟體測試和軟體開發一樣，都遵循軟體工程原理，遵循管理學原理 。測試專家通過實踐總結出了很多很好的測試模型。這些模型將測試活動進行了抽象，明確了測試與開發之間的關係，是測試管理的重要參考依據。
V模型
模型是一個著名的、以測試為驅動的開發模型，該模型強調開發過程中測試貫穿始終，是瀑布模型的一個變體
需求分析： 使用者需求、業務需求、需求規格說明書
概要設計： 系統架構、模組劃分、模組與模組之間的介面
詳細設計： 模組內部實現的邏輯和方法。
編碼： 實現上面的設計
單元測試 ： 檢測程式碼的開發是否符合詳 細設計的要求
整合測試 ： 檢測此前測試過的各組成部分是否能完好地結合到一起
系統測試： 檢測已整合在一起的產品是否符合系統規格說明書的要 求
驗收測試 ： 檢測產品是否符合終端使用者的需求
優點：
V模型清楚地標識出了軟體開發的階段
它採用自頂向下逐步求精的方式把整個開發過程分成不同的階段， 每個階段的工作都很明確，因此便於控制開發過程。當所有的階段都完成之後，該軟體的開發過程也隨之結束
缺點：
V模型一大缺點正是它自身的順序性所導致的。到了測試階段，程式已經完成，錯誤已經產生，很多前期的錯誤一直到測試階段才 發現，甚至無法發現，往往無從修改了
同時實際的開發過程中，在需求階段很難把使用者的需求完全明確下來，因此，當需求變更時將會導致階段反覆，而且都要重複需 求、設計、編碼、測試等過程，返工量非常大，模型靈活性比較低
W模型
W模型由Evolutif公司提出：開發一個V，測試一個V，組合的W模型
優點：
開發強調測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求和概要設計同樣要測試
更早地接入測試，可以發現開發初期的缺陷，那麼可以用更加低的成本進行缺陷修復。同樣是分階段的工作，便於控制專案過程
缺點：
依賴於軟體開發和軟體測試依 然保持一前一後的線性關係， 依然無法支援迭代、自發性和需求等變更調整
對於當前很多專案，在執行的過程中根本不產生文件，那麼W模型基本無法適用，使用起來技術複雜度很高，對於需求和設計的測試要求很高，實踐起來困難
H模型
人們發現雖然軟體開發中需求、設計、編碼等活動被分階段執行、 但是實踐中，他們並不是完全序列的，它們之間更多時候是交叉進行的，更多的是迭代執行。為了解決上面的問題，有專家專門提出了H模型，它將測試活動完全獨立出來，形成一個完全獨立的流程，同時將測試準備和測試執行也清晰表現出來
優點：
開發的H模型揭示了軟體測試除測試執行外，還有很多工作
軟體測試完全獨立，貫穿整個生命週期，且與其他流程併發進行
軟體測試活動可以儘早準備、儘早執行，具有很強的靈活性
軟體測試可以根據被測物的不同而分層次、分階段、分次序的執行，同時也是可以被迭代的
缺點：
管理型要求高：由於模型很靈活，必 須要定義清晰的規則和管理制度，否則測試過程將非常難以管理和控制
技能要求高：H模型要求能夠很好的定 義每個迭代的規模，不能太大也不能太小；
測試就緒點分析困難：測試很多時候， 你並不知道測試準備到什麼時候是合適的，就緒點在哪裡，就緒點的標準 是什麼，這就對後續的測試執行的啟 動帶來很大困難
對於整個專案組的人員要求非常高： 在很好的規範制度下，大家都能高效的工作，否則容易混亂。例如：你分了一個小的迭代，但是因為人員技能不足，使得無法有效完成，那麼整個專案就會受到很大的干擾
總結：
v模型適用於中小企業
w模型適用於中大型企業（因為人員要求高）
h模型人員要求非常高，很少有公司使用