軟體測試模式

軟體測試按測試模式分類：
1.瀑布模型： 
專案計劃 （制定總體的研發計劃，確定主要的里程碑節點－輸出專案計劃書）
需求分析（明確使用者需求定義，並對定義進行清晰描述，充分理解需求，描述產品功能－ 輸出產品需求規格說明）
軟體設計－根據需求定義，設計產品的實現方案，包括定義軟體硬體的結構、元件、實現方法、介面、介面、資料－輸出概要設計、詳細設計
程式開發－根據概要和詳細設計具體實現，根據程式設計規範構建各類元件模組，輸出產品版本。
軟體測試－通過獨立的測試小組評估產品是否滿足需求定義－輸出測試報告
整合維護－交付使用者，根據使用者使用情況進行維護及升級

優：
強調需求、設計的作用，保證使用者需求有一個充分的瞭解
階段分工明確
按階段劃分檢查點，里程碑清晰
文件規範
缺：
難以適應需求變化
專案週期後段才能看到成果
強制里程碑、完成時間點，對變化不容易適應
產生大量文件，工作量大
從測試角度不能體現測試的價值和地位

 

V模型

是瀑布模型的變種
明確表明測試過程的不同級別，階段 單元測試－整合測試－系統測試－驗收測試
並且描述了各個階段與開發過程各個階段的對應關係 
優點：
v模型 強調軟體開發的協作和速度，反應測試活動和分析設計的關係，軟體的實現和驗證有機結合
缺點：
僅把關係明確對應，忽略了對需求分析的驗證，對需求和功能的測試到驗收測試才能發現；沒有很好的體現測試的及時性

 

w模型

 

v模型的改進
增加了開發各個階段的驗證，測試的物件不再是物件，對需求和分析都有測試過程
有利於及於發現專案的風險，線性的相互關係，序列
不能很好的支援像迭代這樣的模式

 

x模型

針對v模型的改進，主要解決交接和頻繁週期的問題，左邊是針對單獨的程式片段所進行的相互分離的編碼和測試，然後進行頻繁的交接，再通過整合，最終合成可執行的程式，x模型還可以探索性測試，不進行事先計劃，可以發現過多的錯誤

 

H模型

把測試當成一個完全獨立的流程 便於儘早的完成測試，與其他流程併發進行，可以是任何流程，可交叉

2.敏捷測試 

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

敏捷宣言：個體與互動 重於 過程和工具
可用的軟體 重於 完備的文件
客戶協作 重於 合同談判
響應變化 重於 遵循計劃 

敏捷測試：強調從客戶角度測試
重點關注迭代測試新功能，不在強調測試階段
儘早測試，不間斷測試，具備條件即測試
強調持續反饋
預防缺陷重於發現缺陷

敏捷測試VS傳統測試：

傳統測試                                                                                             敏捷測試
測試是質量的最後保護者                                       開發和測試人員緊密合作，大家都有責任對軟體負責
嚴格的變更管理                                                     變更可以接受
預先的計劃和細節準備                                           計劃隨著進展時常調整
重量級文件                                                            只需要必要的文件
各階段測試嚴格的入口和出口標準                          各迭代之間沒有明顯入口和出口標準，更多在迴歸測試                                                                               時進行重量級自動化測試 所有階段都要自動測試，每個                                                                               人都需要做，是專案整合一部分
測試 開發 相對獨立                                                合作


3.基於指令碼的測試 

基於指令碼的測試 SBT script-based testing 和ET【探索性測試】 互補
ST                                                                                                    ET
系統性強                                                                                       自由靈活
容易管理控制                                                                                和ST互補
設計在先，執行在後                                                                   執行和設計並行
主要是驗證自己的思路                                                     不斷和系統互動，帶著問題測試
可預見                                                                                            學習的過程
4.基於風險的測試

基於風險的測試：RBT risk based testing一種基於對軟體失效的風險評估並以此指導測試計劃，設計，執行，結果評價的軟體測試型別
風險包括 質量風險 管理風險 

風險級別=風險可能性*風險嚴重度
5.探索式測試

 

探索式測試更適用於敏捷專案。測試管理上有侷限性。只有在SUT完全可用下更有作用。生產率難定義。

輸入 狀態 程式碼路徑 使用者資料 執行環境 

區域性探索式測試
輸入：接受輸入，產生輸出，儲存資料，進行運算；
測試時：輸入順序，輸入內容，輸出異常
狀態：臨時狀態（執行時有效，截斷時有效）和永久狀態（資料庫儲存，檔案儲存）
程式碼路徑：對程式碼的覆蓋，白盒測試
使用者資料：最好真實；
執行壞境：軟體執行的系統，網路拓撲，系統的配置資料，跟系統互動的第三方系統，執行系統的硬體裝置

全域性探索測試： 漫遊測試法


基於模型的測試：MBT model based testing 對需求功能點建模 自動化
主要MBT工具：Spec Explorer  GraphWalker  Tcases  modeljunit

結語：

最後跟大家推薦一個學習資料分享群：175317069，裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！

人生是一個逆水行舟的過程，不進則退，我們們一起加油吧！