測試用例設計-場景法（個人見解與學習）
時間：2010-11-19
目錄1、引言 3
2、基本測試 3
2.1、測試優缺點 3
2.2、黑盒功能測試分解法 3
2.3、個人簡介篇 3
3、場景法用例 4
1、什麼是場景法？ 4
2、場景法特點 4
3.1、基本流 6
3.2、分支流 6
3.3、驗證流 7
3.4、異常 7
3.4.1、個人簡介 7
4、場景法用例設計 7
文件中紅色字型的為理解的重點
黃色背景的為個人簡介和思路
同時提出：這裡只是說明一組方法。具體如何使用，可以結合自己的標準來做。
文件屬於個人的見解，個人看法。因為我當時看到同樣的乙個專案，乙個軟體需求。就是使用方法不一樣；我們就寫的用例覆蓋率就出現了這麼多的偏差。
如按照如下的方法去分解：
功能測試、介面測試、效能測試、安全測試、資料庫測試等等測試
能夠按照軟體的功能塊，一組一組的來做相應的模組測試。但對整體業務場景考慮的不是很好，可能遺漏模組a與模組b之間的用例，因為該方法是從軟體本身出發。實際做測試時需要考慮的不是軟體本身，還有對應的系統場景等情況。
不容易做回歸測試，一旦回歸需要考慮到用例的回歸量。。後續測試時間會很長。
在任何情況下都必須使用邊界分析發，經驗表明用這種方法設計出的測試用例發現程式錯誤的能力最強 （邊界法）
必要時用等價類劃分方法補充一些測試用例（等價類法）
用錯誤推測法再追加一些測試用例 （錯誤推測法）
如果程式的功能說明中含有輸入條件的組合情況，則已開始可選用因果圖法（因果圖法）
對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例 （功能圖）
其實這個經驗就是方法，以上是一套方法。。
上面的做法其實需要我們前期對功能的分解細密，在後期考慮到執行或者回歸的時候。安排妥當，不然每次回歸或者執行測試都需要執行那麼多用例，人員安排上不行，時間上也是不允許。
通俗點來解釋：
基本流：就是正常的，正確場景
備選流：分支流+中斷
現在的軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟體設計方面的思想也可引入到軟體測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。（由此會產生很多組場景）
測試用例的設計方法不是單獨存在的，具體到每個測試專案裡都會用到多種方法，每種型別的軟體有各自的特點，每種測試用例設計的方法也有各自的特點，針對不同軟體如何利用這些黑盒方法是非常重要的，在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆蓋度，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效提高測試水平
例如：（2023年軟體評測師考試最後一題）
可以看看上面的場景法設計用例圖形，其實在每個功能裡面是可以生產n多條用例。
以上的功能就是實現了乙個公文的傳送過程。
引用軟體評測考試題
1、 基本流備選流是按照功能邏輯上的分解（滿足基本的需求功能）
2、 對業務上異常情況的處理還未考慮（滿足：中心層、省市層、地區層出現的異常情況。此處未考慮中心層和地區層如果出現異常。這個檔案也是無法下達的。。）
3、 平常對介面，控制項的驗證未做考慮（如：驗證下拉框中資料，驗證搜尋功能的列表顯示）
也如**測試按照場景流程考慮可分為：
基本流、分支流、異常流、驗證流等劃分方式
以下截圖說明：
主要是編寫乙個功能的正常的測試用例，當然日後開發人員也可以使用該用例做功能驗證或者是冒煙，測試方面回歸測試可做驗證。其實每個人使用的時候寫法是不同的，基本場景就是正常的操作登入。
如：上面例子中的基本流（a流程和b流程）
後期開發可以使用這個基本流程來驗證他們的開發質量，當作冒煙測試用例使用。保證我們測試的產品基本的功能邏輯是通的，不會出現很多用例阻塞，提高了我們在用例執行時的質量。
除了正常操作以外程式做的處理，需要程式做非法判斷處理的，比如輸入輸出錯誤或者不滿足規則的測試用例。
如：上面例子中的備選流
其實如果在後期做回歸的時候對用例的處理量會有乙個優先順序別的劃分，而此處可在前幾輪回歸的時候多多的關注程式的判斷邏輯。這個也就是功能實現是否完善
前期第一輪做測試也可以把重點放在這裡處理，因為冒煙測試開發會做一組或者幾組**試。
側重點也就是對程式基本功能的驗證，完善功能實現。
如：前幾輪做測試可能多關注功能實現，這裡的用例就是測試的中心
此處和介面測試有點相似主要分：整體介面測試、介面元素測試、控制項操作驗證過
整體介面測試：就是去驗證整體的介面是否和設計圖一致
介面元素測試：這個一般在做**時候需要，比如檢視html的網頁元素是否載入完成或者是理解網頁中是否缺少這個元素。（一般載入**的時候，無法正常顯示）
控制項操作驗證：如對控制項能否操作、操作是否正常的驗證。
一般會檢查下拉框，輸入框。至於操作提交是否正確，這個屬於實現的功能應該放在分支裡面去驗證這個功能。
在這裡做出驗證，關鍵是對整體的介面驗證，或者是功能修改以後，一些控制項沒法使用。
整體的去考慮場景上對功能的影響，特意的去構造一些異常的場景。這部分用例可能不會去關注，也有些會很難去捕捉。但是站在客戶和測試的角度這些用例是一定會存在的，只是我們這些用例執行的優先級別會放低，也就是執行難度大。
需要考慮到很多外界因素和實際執行環境。
包括測試資料的準備時，會把很多執行難度大的用例放在日後去做處理。
如：上面的這個公文發布流程中，它可能存在的異常情況
1、公文發布在中心層就出現了某些情況？
2、公文發布到省市層，出現了刪除、修改等情況？
可以把屬於資料的驗證放在這裡，其實測試的時候有很多地方需要對資料進行驗證。比如我們刪除資料以後，前端雖然相應了我們的刪除操作，也刪除成功。但是我們在做處理的時刻需要去檢查資料情況，而當時環境又不允許，在異常裡放上這麼一組用例。
可以做到後續執行時去驗證資料。
測試用例設計方法
按照不同的規則可以將測試用例分為四個部分：場景用例（使用者場景）、系統用例（使用者場景的細化）、功能用例（基於業務規則、介面）、設計指標（基於環境、效能、安全等）。
◆ 使用者場景用例：按照使用者的實際操作與業務邏輯設計用例，不必涉及很複雜的操作或邏輯，把使用者最常用的、正常的操作流程作為乙個場景設計測試用例
◆ 系統用例：是使用者場景的細化，包含正常場景、分支場景和異常場景，是兩個或多個有關聯的功能組合而成的場景。
◆ 功能用例：用於驗證各功能點的業務規則，包括介面元素和各功能的業務規則驗證。主要針對單個功能點。
◆ 設計指標：系統所需要達到的各級指標。主要包含環境、效能、安全等方面的指標。
第一步：使用者場景用例（關鍵字：模擬使用者實際操作）
描述使用者的主要業務目標，包含完整的系統級場景和模擬使用者實際操作的不同場景，幾個功能點的組合也算是使用者場景，這類的用例不宜過多。
第二步：系統各角色的系統用例
將系統劃分多個角色，再將每個角色分解為多個任務，每個任務就是乙個系統用例。系統用例分別正常流程、異常流程，分支流程，以場景的形式描述。
系統用例命名原則：正常（異常、分支）流程_描述
第三步：功能用例
描述單點功能的邏輯規則及頁面元素，分層描述邏輯規則，對邏輯規則細化可直接作為用例的操作步驟描述。
第四步：設計指標
設計指標包含三種型別的用例：環境測試用例、效能測試用例、安全性用例。
環境測試用例可依照作業系統版本，瀏覽器版本不同劃分為多個用例。每個用例下可直接呼叫已有的使用者場景用例、系統用例、功能用例，可無須單獨編寫用例。
4、用例設計規則
規則如下：
1）每個用例需要選擇優先順序，分為高、中、低三種。
每個用例需要關聯專案。
2）需要特別強調的是，使用者場景用例，一定要脫離系統提供功能，站在使用者角度來設計用例，從使用者實際可能的操作場景考慮。
3）使用者場景及系統用例的劃分粒度。比如：註冊登入，其本身也算乙個使用者場景，但不是使用者關心的業務目標，所以把其劃分為系統用例中。
4）系統用例與功能用例的劃分粒度。功能點是測試用例設計的基本單位，是乙個不可再細分的完整操作，可以基於乙個表單或者多個表單，依照產品具體需求進行劃分。系統用例側重於場景，是兩個或兩個以上多個功能點的組合。
場景法設計測試用例
如何使用場景法設計測試用例 由安博測試空間技術中心提供 通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果。場景法一般包含基本流和備用流，從乙個流程開始，通過描述經過的路徑來確定的過程，經過遍歷所有的基本流和備用流來完成整個場景。為什麼場景法能如此清晰的描述整個事件？因為，現在的系統基本...
測試用例設計方法之因果圖法
一 因果圖法的 大家熟悉的等價類劃分法和邊界值分析法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯絡 相互組合等 但是，如考慮所輸入條件之間的相互組合，會由於組合情況數目相當大，需要大量的測試用例 因果圖法，是一種幫助人們系統地選擇一組高效率測試用例的方法。二 因果圖法的特點 考慮輸入條件間的組合...
功能測試測試用例設計
註冊 登陸測試用例 一 註冊測試用例 測試編號 001 測試目標 驗證系統是否對必填項為空時做出正確的響應 測試環境 windows xp作業系統和瀏覽器ie6.0 測試步驟 1 開啟瀏覽器，在瀏覽器的位址列中輸入 使用者註冊 頁面的url，單擊 轉到 按鈕 2 在 使用者註冊 介面什麼都沒有輸入，...