軟體測試的分類--敏捷測試：基於指令碼的測試-SBT、探索式測試（ET）、基於風險的測試--RBT、基於模型的測試--MBT
敏捷測試：Agile Testing--遵循敏捷宣言的一種測試實踐
個體與互動 重於 過程和工具
可用的軟體 重於 完備的文件
客戶協作 重於 合同談判
響應變化 重於 遵循計劃 在每隊比較中，後者並非全無價值，但我們更看重前者
敏捷測試特點：強調從客戶角度進行測試
重點關注迭代測試新功能，不在強調測試階段
儘早測試，不間斷測試，具備條件即測試
強調持續反饋
預防缺陷重於發現缺陷
敏捷測試 VS 傳統測試
|
傳統測試 |
敏捷測試 |
|
·測試是質量的最後保護者 ·嚴格的變更管理 ·預先的計劃和細節的準備 ·重量級文件 |
·開發和測試人員是緊密合作，大家都有責任對軟體負責 ·變更是可接受的，擁抱變更 ·計劃隨著進展時常調整 ·只需要絕對必要的文件 |
敏捷測試 VS 傳統測試（2）
|
傳統測試 |
敏捷測試 |
|
·各階段測試嚴格的入口和出口標準 ·更多在迴歸測試時進行重量級的自動化測試 ·嚴格依賴流程執行 ·測試團隊和開發團隊是相對獨立的 |
·各迭代之間已經沒有明顯的入口和出口標準 ·所有階段都需要自動測試，每個人都需要做，是專案整合的一部分 ·流程不再需要嚴格執行 ·團隊合作是無縫隙合作 |
敏捷測試：整個測試是持續不斷地質量反饋的一個過程，從研發生命週期的開始，需求階段，就把測試過程中相關的問題持續不斷地反饋給開發人員、產品經理，及時發現產品現狀，及時改正，更多體現一種價值觀，一種流程思想。
基於指令碼的測試-SBT
Script-based Testing
Scripted Testing(ST)
Exploratory Testing(ET)
探索式測試（ET）
完全拋開測試指令碼的測試
它是一種測試風格、思維而不是一種測試技術
ST VS ET
|
ST |
ET |
|
·系統性強 ·容易管理、控制 ·設計在先，執行在後 ·主要是驗證自己的思路 ·可預見性 |
·自由靈活 ·和ST是互補的 ·執行和設計（思考）並行 ·不斷和系統互動，帶著問題測試 ·學習的過程 |
探索式測試的優點
1、更能激發測試人員的創造性和工作樂趣
2、增加了發現新的或較深入Bug的可能性
3、在較短的時間內找到更多Bug以及對SUT作一個快速的評估
4、有利於更加有效地實施自動化
5、更加適用於敏捷專案
6、減少了在簡單、繁複上用例的無畏編碼時間
探索式測試的缺點
1、測試管理上有侷限性，較難協調和控制
2、對於Bug的重複利用和重現上作用有限
3、對測試人員的測試技能和業務知識深度依賴較大
4、只有在SUT已完全可用的前提下才更有作用
5、ET的生產率很難定義
6、ET本身較難進行自動化
區域性探索式測試
全域性探索式測試
執行探索式測試
基於風險的測試--RBT
Risk-based Testing：一種基於對軟體失效的風險評估並以此指導測試計劃、設計、執行、結果評價的軟體測試型別
哪些風險？
1、質量風險：例如軟體的功能、易用性、效能，軟體功能的缺失，資料的轉換等導致的問題
2、管理風險：人員的技能不足，專案的人力不足，測試環境不具備，被測系統的需求不夠清晰，被測系統關聯的第三方系統有問題導致沒法進行聯調，這類問題為管理風險
風險級別 = 風險可能性 * 風險嚴重度
識別風險
|
可能性 |
嚴重程度 |
|
·複雜度 ·時間壓力 ·高變更率 ·技能水平 ·地理分散度 |
·使用頻率 ·失效可視性 ·商業損失 ·組織負面影響和損害 ·社會損失和法律責任 |
風險要素 = Sum（單項權重*得分）
RBT的優點
基於模型的測試--MBT
主要的MBT工具
