安測試模式來分類：

瀑布模型、敏捷測試、基於指令碼的測試、基於風險的測試、探索式測試等

常用的測試模型

1、傳統的瀑布模型——最早出現的軟體開發模型

專案計劃——需求分析——軟體設計——程式開發——軟體測試——整合維護。

每一個階段都是以上個階段的輸出作為下個階段的輸入。

專案計劃：制定專案總體的研發計劃，確定主要的里程碑節點。輸出專案的技術書。

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

軟體設計：根據需求的定義來確定產品實現方案。輸出概要設計、詳細設計等。

程式開發：開發團隊具體實現。

軟體測試：通過獨立測試團隊評估產品是否滿足需求的定義。輸出測試結果、測試報告。

整合維護：根據使用者使用對產品進行必要的需改升級。

優點：

強調需求、設計的作用

前一階段完成後，只需關注後續階段

為專案提供了按階段劃分的檢查點，里程碑清晰

文件規範

缺點：

難以適應需求的頻繁變化

專案週期後段才能看到成果

強制的里程碑、完成時間點

文件工作量大

2、V模型——目前使用最廣泛的模型（瀑布模型的變種）

表明了測試過程的不同階段和開發各個階段的對應關係

需求分析                                                             驗收測試（確定軟體是否滿足使用者的最終需求和合同的有關規定）

      概要設計                                              系統測試（軟體在功能、效能這些質量特性上是否滿足系統要求）

               詳細設計                              整合測試（檢測程式是否滿足設計程式的要求）

                      軟體編碼           單元測試（檢測程式是否滿足設計程式的要求）

V模型強調了軟體開發的協作和速度，反映測試活動和分析設計的關係，將軟體的實現和驗證有機結合起來

侷限性：將需求分析放在了最後

3、W模型——測試伴隨著開發週期進行

有利於儘早發現問題，改進了V模型

使用者需求            驗收測試設計                                           交付             驗收測試

       需求分析             系統測試設計                              實施          系統測試

             概要設計                 整合測試設計                整合        整合測試

                    詳細設計                  單元測試設計

                                                 編碼                    單元測試

侷限性：不能很好的支援迭代開發

4、X模型——針對V模型的改進

程式片段1                                                    封版

       測試設計                                         執行測試

              工具配置                             測試設計

                    執行測試                 工具配置

                           編碼完整    迭代1....n

                    執行測試                   探索式測試

               工具配置

         測試設計                                        執行測試

程式片段n

左邊：針對單獨的片段進行的測試和編碼，此後進行頻繁的交接、整合

探索式測試：不進行事先計劃的特殊測試，在測試計劃之外發現更多錯誤

5、H模型——貫穿在整個軟體生命週期

測試準備   測試就緒點   測試執行

                                                        測試流程

                                                        其他流程

其他測試模型

1、敏捷測試

Agile Testing——遵循敏捷宣言的一種測試實踐

敏捷宣言

個體與互動  重於  過程和工具

可用的軟體  重於  完備的文件

客戶協作      重於  合同談判

響應變化      重於  遵循計劃

在每對比較重，後者並非全無價值，但我們更看重前者

敏捷測試

強調從客戶角度進行測試；

重點關注迭代測試新功能，不在強調測試階段

儘早測試，不間斷測試，具備條件即測試

強調持續反饋

預防缺陷重於發現缺陷

敏捷測試VS傳統測試

傳統測試：測試是質量的最後保護者；嚴格的變更管理；預先的計劃和細節的準備；重量級文件；各階段測試嚴格的入口和出口標準；

                    更多在迴歸測試時進行重量級的自動化測試；嚴格依賴流程進行；測試團隊和開發團隊是相對獨立的

敏捷測試：開發和測試人員是緊密合作，大家都有責任對軟體負責；變更是可接受的，擁抱變更；計劃隨時隨著僅佔市場調整；只需要絕對必要的文件；

                   各迭代之間已經沒有明顯的入口和出口標準；所有階段都需要自動測試，每個人都需要做，是專案整合的一部分；流程不在需要嚴格執行；團隊合作是無縫隙合作

2、基於指令碼的測試——SBT

script-based Testing

Scripted Testing(ST)

Exploratory Testing(ET)探索式測試：完全拋開測試指令碼的測試

          是一種測試風格、思維而不是一種測試技術

ST：系統性強；容易管理、控制；設計在先，執行在後；主要是驗證自己的思路；可預見性

ET：自由靈活；和ST是互補的；執行和設計（思考）並行；不斷和系統互動，帶著問題測試；學習的過程

探索式測試優點：

更能激發測試人員的創造性和工作樂趣

增加了發現新的或較深入Bug的可能性

在較短時間內找到更多Bug以及對SUT做一個快速的評估（SUT：soft ware and test）

有利於更加有效地實施自動化

更加適用於敏捷專案

減少了在簡單、繁複上用例的無謂編寫時間

缺點：

測試管理上有侷限性，較難協調和控制

對於BUg的重複利用和重現上作用有限

對測試人員的測試技能和業務知識深度依賴較大

只有在SUT已完全可用的前提下才更有作用

ET的生產率很難定義

ET本身較難進行自動化

測試方法上分為：區域性探索式測試和全域性探索式測試（漫遊測試法）

區域性探索式測試五大要素：輸入、狀態、程式碼路徑、使用者資料、執行環境

全域性探索式測試六大區

執行探索式測試：Know you Mession ——learning Session——Coverage Session——Deep Session——Close Session 

3、基於風險的測試——RBT（Risk-based Testing）

一種基於對軟體失效的風險評估並以此指導測試計劃、設計、執行、結果評價的軟體測試型別

哪些是風險？

質量風險、管理風險

風險級別=風險可能性*風險嚴重度

識別風險

可能性：複雜性、時間壓力、高變更率、技能水平、地理分散度

嚴重程度：使用頻率、失效可視性、商業損失、組織負面影響和損害、社會損失和法律責任

風險要素風=sum（單項權重*得分）

4、基於模型的測試-MBT