軟體測試的起點和源泉——七種測試驅動模式（方法論）

標籤：產品品質   軟體測試   需求   結構   設計   

（朱少民著作權 ?2014：任何引用和轉寄請註明真實來源）

在進行軟體測試時，總要有一個出發點吧？從哪裡開始分析？測試設計是基於什嗎？簡單地說，什麼驅動測試工作？這是一個基本問題，基於自己多年對軟體工程、產品品質和測試等的理解，總結出七類測試驅動模式（按推薦程度高低來排序）：朱少民著作權?2014

1)      業務/需求驅動測試；

2)      產品品質風險驅動測試；

3)      模型驅動測試；

4)      （系統）功能驅動測試；

5)      設計驅動測試；

6)      （程式/代碼）結構驅動測試；

7)      統計/經驗驅動測試

朱少民 著作權 ?2014

1. 業務/需求驅動測試：比較容易理解，一個軟體總是要解決使用者的某類業務問題。業務驅動測試就是從使用者的實際業務需求出發，分析營運目標、商務程序、使用者角色、商務規則、業務資料、業務發展等測試對象，針對這些對象確定測試範圍、測試方法和策略。測試是否充分，也是從商務程序和資料來衡量。軟體系統能否充分滿足業務需求，是業務/需求驅動測試最關切的問題，基於需求的驗證方法、基於使用者情境的測試方法，可以歸為這類測試。

朱少民 著作權 ?2014

2. 產品品質風險驅動測試：根據產品品質模型：內部品質-->外部品質 --> 使用品質來進行測試，強調全生命週期消除產品品質風險，從程式碼檢閱、代碼複雜度度量等工作開始，對內部品質進行評估以暴露品質風險，然後逐步擴充到系統外部品質、使用者使用品質的評估，持續揭示、反饋產品品質主要風險。在這類測試中，對產品品質的屬性分析會比較透徹，也強調靜態測試，包括人工程式碼檢閱和設計評審、使用代碼靜態分析或檢查工具。

朱少民 著作權 ?2014

3. 模型驅動測試針對現實問題進行抽象構建驗證模型，如UML建模、有限狀態機器、Petri網、Kripke結構等，系統屬性可用時序邏輯公式（如CTL，LTL）來描述。更廣泛的理解，決策表、因果圖、Pair-wise等也屬於測試建模。大規模的複雜應用系統的測試建模會受到很大挑戰，隨著軟體技術和建模技術的發展和融合，這些問題會逐步得到解決。但基於模型能自動產生測試案例和自動化指令碼，能夠更徹底地完成測試的自動化過程，而之前人們多數自動化測試局限於測試的執行，需要開發和維護大量的測試指令碼，手工比重不小，最多算半自動化。

朱少民 著作權 ?2014

4.（系統）功能驅動測試：許多人一談到軟體測試，就是功能測試、效能測試，這或多或少體現了“功能測試驅動”思想。功能驅動測試，就是從系統功能特性出發，根據軟體功能規格設計說明書（可能沒有），針對每個功能進行驗證，確定功能運行是否正常，是否和設計保持一致。一般會將功能進行分解，分為子功能、子功能的子功能，形成功能點列表，針對功能點進行測試案例設計和執行。

朱少民 著作權 ?2014

5.設計驅動測試（DDT）：DDT受TDD啟發，為測試事先進行分析與設計，測試是被設計驅動的。DDT具有下列這些特性：測試更靈活、更簡單，消除重複工作，測試案例指導測試計劃（和傳統測試相反），測試案例可轉換成測試代碼，包含業務需求測試和情境測試、控制器測試，測試對開發與測試團隊都很有用。關於設計驅動測試，已有專題論述的著作：設計驅動測試——讓程式員更輕鬆地進行測試http://product.dangdang.com/23407007.html

朱少民 著作權 ?2014

6.（程式/代碼）結構驅動測試：基本類似於：結構化測試、白盒測試。從程式結構來驅動測試，進行程式結構分析，逐步覆蓋程式的各個部分及其關聯關係，如基於組件測試、基於介面測試或基於API進行測試；從代碼結構進行測試，包括程式碼覆蓋、分支覆蓋、基本路徑覆蓋等。結構驅動測試的充分性度量會更客觀性，特別是基於程式碼涵蓋範圍分析，目前有大量工具支援。

朱少民 著作權 ?2014

7.統計/經驗驅動測試可以看作“經驗軟體工程”的組成部分，認可實際度量資料和經驗比各種理論模型更有價值。通過軟體測試過程中資料和經驗的收集，進行統計分析、歸納整理，產生經驗模型來開展測試。上下文驅動測試、探索式測試、缺陷預防、錯誤猜測法等可歸為這類，雖然不是很嚴謹，但都基本是從統計/經驗來驅動測試。

 

朱少民 著作權 ?2014：任何引用和轉寄請註明真實來源

 

軟體測試的起點和源泉——七種測試驅動模式（方法論）