設計測試案例技術

方法、技術
動態測試 - 需要執行程式碼
黑箱測試、白箱測試
靜態測試 - 不需要執行程式碼、人工檢視
規格文件
測試、步驟
動 單元測試
態 整合測試

試 系統測試
驗收測試

開發人員
開發人員、測試工程師
測試工程師、硬體工程師
PM、使用者

軟體品質屬性
 可靠性
 正確性
 可重複使用性
 可維護性
 安全性
 可使用性
 效能 (必須到 系統測試 階段後才能驗證)
單元測試
整合測試
系統測試
驗收測試

-

切割模組、單一模組
所有軟體模組、algorithm
整個軟體、硬體配合
真正使用、需要的使用方式

單元測試的重點:正確性、可使用性
可以使用量化的方式驗證 ( bugs/ 1000 lines、 crash / 1000 hrs)
軟體設計
架構設計 –
MVC - 使修改更有彈性
Model - 內部資料模組
View - 使用者 UI
Control - 輸出 UI
Layer
細部設計 – Design Pattern
測試腳本
1. 測試步驟、流程
2. 測試輸入資料 (測試案例 TestCase)
區隔問題
一次測一個模組
呼叫其他模組 (stub)
被其他模組呼叫 (driver)
驅動程式:
1. Load input data 進 test case

2. 執行待測模組 - 取得執行結果
3. 比對執行結果
設計案例
User case model
Sequential diagram

分析
設計

Test Driven Development
先設計測試案例
驅動程式
開發模組
Refactoring
1. 針對每一個類別、每一個 Method 測試
2. 整合測試
測試覆蓋
嚴謹度
最低

敘述覆蓋

Statement Coverage (最低要求)

分支決策覆蓋

Branch/Decision Coverage

條件覆蓋

Condition Coverage

多重條件組合覆蓋

Multiple-condition Combination Coverage

最高

全面路徑覆蓋

All-Paths Coverage

白箱測試 (步驟)
 基本路徑測試
 資料流測試
缺點:成本過高
只用在重要的模組 (或無法找出錯誤時)
黑箱測試 (原則)
 等價劃分原則
 input/output
 pre-condition/post-condition
 變數情況特性
1. 找出劃分原則 (要分成有效/無效)
2. 設計出條件
3. 做出數據
測試劇本
複雜物件可以用 state diagram (UML) 設計生命週期
用狀態圖或使用案例設計測試劇本
測試劇本來自於需求(規格)
繼承無法減少子類別的測試
 不論父類別是否做過測試、子類別必須測試所有 Methods,包含繼承自父類別的所
有 Methods

- Summary
白箱測試 - 最少必須包含 statement coverage,只用在重要模組
黑箱測試 - 利用 UML、設計規格、需求,設計測試劇本
物件導向測試 - 完整測試包含父類別的所有 Methods

Sign up to vote on this title
UsefulNot useful