開源軟件測試模型(4)

　　3. 將時間因素考慮進來;

　　4. 與其它技術結合。

　　例如，用戶線索，容量線索，基于風險的線索。典型情況下，線索測試通過“場景”來定義。所謂“場景”，就是一步一步的詳細指令序列，它描述了哪些數據要輸入哪些字段，以及要按下什么按鈕等。一般應包含：(1)該場景使用的數據描述(2)描述該場景的前提：那些動作必須在之前執行;(3)動作序列描述：如，按下“確認”按鈕，在用戶號字段內輸入456等;(4)預期結果描述;(5)與某功能有關的場景可能要跨越“幾天”時間：數據進入系統后可能今天后結果才有效，后續動作也才能執行。“場景”應當覆蓋系統所有應完成的功能。

　　用戶測試——模擬真實用戶的操作方式、數據

　　1. 確定用戶分類;

　　2. 確定每一類用戶要做什么、如何做以及怎樣評價;

　　3. 獲得真實的用戶數據，或讓真實用戶進行測試;

　　4. 否則，系統化地模擬真實用戶的行為(注意：不要誤以為自己就是真實用戶)。

　　回歸測試——對于變更及影響部分的重復測試

　　1. 確定哪些產品元素發生變更;

　　2. 確定哪些元素受到這些變更的影響;

　　3. 選擇測試內容，比如最近修復的錯誤，以前修復的錯誤，新代碼，敏感代碼，或所有代碼。

　　基于風險的測試——依據產品潛在風險的高低確定測試重點，首先發現重大錯誤

　　1. 分析測試環境、產品元素和質量準則以確定各種風險源;

　　2. 將測試集中在具有潛在高風險的領域;

　　3. 利用測試結果來精練風險分析結果;

　　4. 注意不要完全忽視低風險領域——因為風險分析結果可能是錯誤的。

　　聲明測試——驗證每一個與產品有關的聲明

　　1. 確定那些包括產品聲明(顯式的和隱式的)的參考資料;

　　2. 分析每一個聲明，澄清模糊的聲明;

　　3. 驗證每個聲明;

　　4. 如果是利用顯式的規格說明進行測試，保證它與產品本身保持一致。

　　探索式測試——在不斷探索的過程中(迭代和并發行為)進行測試設計和執行

　　1. 產品探索，發現和記錄產品目標、功能、處理的數據類型和潛在不穩定域;

　　2. 測試設計，確定產品操作、觀察和評估的策略;

　　3. 測試執行，操作產品，觀察結果，并使用這些信息形成產品應如何工作的假設;

　　4. 啟發式規則，利用各種指導性原則幫助決定應做什么;

　　5. 可評審的結果，探索式測試是一個結果導向的過程，應確保測試結果可被評審以資證明。

原文轉自：http://www.uml.org.cn/Test/201106012.asp