測試用例設計-場景法

1、測試用例設計-場景法（個人見解與學習）時間：2010-11-19編寫人時間修復時間龍文2010-11-192010-12-9目錄1、引言 32、基本測試 32.1、測試優(yōu)缺點 32.2、黑盒功能測試分解法 32.3、個人簡介篇 33、場景法用例 41、什么是場景法？ 42、場景法特點 43.1、基本流 63.2、分支流 63.3、驗證流 73.4、異常 73.4.1、個人簡介 74、場景法用例設計 7文檔中紅色字體的為理解的重點 黃色背景的為個人簡介和思路 同時提出：這里只是說明一組方法。具體如何使用，可以結合自己的標準來做。1、引言文檔屬于個人的見解，個人看法。因為我當時看到同樣的一個項目，

2、一個軟件需求。就 是使用方法不一樣；我們就寫的用例覆蓋率就出現(xiàn)了這么多的偏差。2、基本測試如按照如下的方法去分解：功能測試、界面測試、性能測試、安全測試、數(shù)據(jù)庫測試等等測試2.1、測試優(yōu)缺點能夠按照軟件的功能塊，一組一組的來做相應的模塊測試。但對整體業(yè)務場景考慮的不是很好，可能遺漏模塊 A與模塊B之間的用例，因為該方法是從軟件本身出發(fā)。實際做測 試時需要考慮的不是軟件本身，還有對應的系統(tǒng)場景等情況。不容易做回歸測試， 一旦回歸需要考慮到用例的回歸量。后續(xù)測試時間會很長。2.2、黑盒功能測試分解法在任何情況下都必須使用邊界分析發(fā)，經驗表明用這種方法設計出的測試用例發(fā)現(xiàn) 程序錯誤的能力最強（邊界法

3、）必要時用等價類劃分方法補充一些測試用例（等價類法）用錯誤推測法再追加一些測試用例（錯誤推測法）如果程序的功能說明中含有輸入條件的組合情況，則已開始可選用因果圖法（因果 圖法）對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆 蓋標準，應當再補充足夠的測試用例（功能圖）其實這個經驗就是方法，以上是一套方法。2.3、個人簡介篇上面的做法其實需要我們前期對功能的分解細密， 在后期考慮到執(zhí)行或者回歸的時候。 安排 妥當，不然每次回歸或者執(zhí)行測試都需要執(zhí)行那么多用例，人員安排上不行，時間上也是不 允許。通俗點來解釋：基本流：就是正常的，正確場景備選流：分支流+中斷3、場景法用例1

4、、什么是場景法?現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形 成了場景，而同一事件不同的觸發(fā)順序和處理結 果就形成事件流。這種在軟件設 計方面的思想也可引入到軟件測試中，可以比較生動地描繪出事件觸發(fā)時的情 景，有利于測試設計者設計測試用例，同時使測試用例更容易理解和執(zhí)行。（由此會產生很多組場景）2、場景法特點測試用例的設計方法 不是單獨存在的，具體到每個測試項目里都會用到 多種方法，每種類型的軟件有各自的特點，每種測試用例設計的方法也有各自的 特點，針對不同軟件如何利用這些黑盒方法是非常重要的，在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆蓋度，這就需要認真

5、掌握這 些方法的原理，積累更多的測試經驗，以有效提高測試水平例如：（2010年軟件評測師考試最后一題）-IBjaj:陸卩LldUL.a試聽一 <15閱讀下列說明.艸答問題1至問題乙將髀祥填入答題尿的對應欄內說蹈】/場JS法是熬逾測試屮41嬰惱陽試用啊設計力法冃前多效軟件系統(tǒng)郝是用筋件融狡 來控制業(yè)務酸7傘科濁發(fā)時的惴景便形底r場球，場最的不少玻（K序構成陽例場 損法通過場矗述業(yè)錚流理（包括基本流（基本流程）和爺彌血支流程）人設計用例 遍歷軟件系統(tǒng)功能驗證苴止確性圖1描i£TH化的中心層' 省幣民*地岡層二級的“公文ifi轉"業(yè)務擁鵝我J描 述了眷市層（國1陰慝

6、部分）業(yè)務的基本流和備選謊公文的狀態(tài)包摳：已下發(fā)*未下發(fā)、已接收、弱搖收円祥公文流轉”業(yè)務流釋圖：/I LrJKl ft Lr jr地區(qū)熾I"二圖丨公文流轉”業(yè)務流程圖«|省市層業(yè)勢流|業(yè)務T輪號* 1_ 一說明/!丄-二匚丄1H-基本流八；孑申也公文下發(fā)省市層按收申心去丈卜下健到地憧展iT- - -4餉建公文理接卜發(fā)WWM新趨處文彩羈斥岌到地槌忌11 C保存騎建公文釗區(qū)旳專朮駁齡1£公文.適當時下發(fā)到地淇 層> =r_leD修或薪建公文慨改布市層新建的公文E陽除新連公文劇除智市總廚建的公文空冗年下節(jié)呂軟幹評楠怖卜午試垂35 2 131< Jfr可以看

7、看上面的場景法設計用例圖形，其實在每個功能里面是可以生產N多條用例。以上的功能就是實現(xiàn)了一個公文的發(fā)送過程。引用軟件評測考試題1、基本流備選流是按照功能邏輯上的分解（滿足基本的需求功能）2、 對業(yè)務上異常情況的處理還未考慮（滿足：中心層、省市層、地區(qū)層出現(xiàn)的異常情況此處未考慮中心層和地區(qū)層如果出現(xiàn)異常。這個文件也是無法下達的。°)3、平常對界面，控件的驗證未做考慮 (如：驗證下拉框中數(shù)據(jù)，驗證搜索功能的列表顯示)也如網站測試按照場景流程考慮可分為：基本流、分支流、異常流、驗證流等劃分方式以下截圖說明：3害戶邈登謙(84)田二IE城本應棍3)出口02分支詭梅朝)岀口酮異常甑段(25)出

8、 口4 UI臉證8)田亡I02遲出0)出CJ肪竜出(7)3.1、基本流主要是編寫一個功能的正常的測試用例，當然日后開發(fā)人員也可以使用該用例做功能驗證或者是冒煙，測試方面回歸測試可做驗證。其實每個人使用的時候寫法是不同的，基本場景就是正常的操作登錄°如：上面例子中的基本流(A流程和B流程)后期開發(fā)可以使用這個基本流程來驗證他們的開發(fā)質量，當作冒煙測試用例使用。 保證我們測試的產品基本的功能邏輯是通的，不會出現(xiàn)很多用例阻塞， 提高了我們在用例執(zhí)行時的質量。3.2、分支流除了正常操作以外程序做的處理，需要程序做非法判斷處理的，比如輸入輸出錯誤或者不滿足規(guī)則的測試用例。如：上面例子中的備選流

9、其實如果在后期做回歸的時候對用例的處理量會有一個優(yōu)先級別的劃分，而此處可在前幾輪回歸的時候多多的關注程序的判斷邏輯。這個也就是功能實現(xiàn)是否完善前期第一輪做測試也可以把重點放在這里處理，因為冒煙測試開發(fā)會做一組或者幾組預測側重點也就是對程序基本功能的驗證，完善功能實現(xiàn)。如：前幾輪做測試可能多關注功能實現(xiàn)，這里的用例就是測試的中心3.3、驗證流此處和界面測試有點相似主要分：整體界面測試、界面元素測試、控件操作驗證過整體界面測試：就是去驗證整體的界面是否和設計圖一致界面元素測試：這個一般在做網站時候需要，比如查看HTML的網頁元素是否加載完成或者是理解網頁中是否缺少這個元素。（一般加載圖片的時候，無

10、法正常顯示）控件操作驗證：如對控件能否操作、操作是否正常的驗證。一般會檢查下拉框，輸入框。至于操作提交是否正確，這個屬于實現(xiàn)的功能應該放在分 支里面去驗證這個功能。在這里做出驗證，關鍵是對整體的界面驗證，或者是功能修改以后，一些控件沒法使用。3.4、異常整體的去考慮場景上對功能的影響，特意的去構造一些異常的場景。這部分用例可能不會去關注，也有些會很難去捕捉。但是站在客戶和測試的角度這些用例是一定會存在的，只是我們這些用例執(zhí)行的優(yōu)先級別會放低，也就是執(zhí)行難度大。需要考慮到很多外界因素和實際執(zhí)行環(huán)境。包括測試數(shù)據(jù)的準備時，會把很多執(zhí)行難度大的用例放在日后去做處理。如：上面的這個公文發(fā)布流程中，它可

11、能存在的異常情況1、公文發(fā)布在中心層就出現(xiàn)了某些情況？2、公文發(fā)布到省市層，出現(xiàn)了刪除、修改等情況？3.4.1、個人簡介可以把屬于數(shù)據(jù)的驗證放在這里，其實測試的時候有很多地方需要對數(shù)據(jù)進行驗證。比如我們刪除數(shù)據(jù)以后， 前端雖然相應了我們的刪除操作，也刪除成功。但是我們在做處理的時刻需要去檢查數(shù)據(jù)情況， 而當時環(huán)境又不允許， 在異常里放上這么一組用例。 可以做到后 續(xù)執(zhí)行時去驗證數(shù)據(jù)。4、場景法用例設計測試用例設計方法按照不同的規(guī)則可以將測試用例分為四個部分：場景用例（用戶場景）、系 統(tǒng)用例（用戶場景的細化）、功能用例（基于業(yè)務規(guī)則、界面）、設計指標（基 于環(huán)境、性能、安全等）。用戶場景用例：按

12、照用戶的實際操作與業(yè)務邏輯設計用例，不必涉及很 復雜的操作或邏輯， 把用戶最常用的、 正常的操作流程作為一個場景設計測試用 例 系統(tǒng)用例：是用戶場景的細化，包含正常場景、分支場景和異常場景， 是兩個或多個有關聯(lián)的功能組合而成的場景。 功能用例：用于驗證各功能點的業(yè)務規(guī)則，包括界面元素和各功能的業(yè) 務規(guī)則驗證。主要針對單個功能點。 設計指標：系統(tǒng)所需要達到的各級指標。主要包含環(huán)境、性能、安全等 方面的指標。第一步：用戶場景用例（關鍵字：模擬用戶實際操作）描述用戶的主要業(yè)務目標， 包含完整的系統(tǒng)級場景和模擬用戶實際操作的不 同場景，幾個功能點的組合也算是用戶場景，這類的用例不宜過多。第二步：系統(tǒng)各

13、角色的系統(tǒng)用例將系統(tǒng)劃分多個角色， 再將每個角色分解為多個任務， 每個任務就是一個系 統(tǒng)用例。系統(tǒng)用例分別正常流程、異常流程，分支流程，以場景的形式描述。系統(tǒng)用例命名原則：正常（異常、分支）流程 _描述第三步：功能用例描述單點功能的邏輯規(guī)則及頁面元素， 分層描述邏輯規(guī)則， 對邏輯規(guī)則細化 可直接作為用例的操作步驟描述。第四步：設計指標設計指標包含三種類型的用例： 環(huán)境測試用例、 性能測試用例、安全性用例。環(huán)境測試用例可依照操作系統(tǒng)版本， 瀏覽器版本不同劃分為多個用例。 每個 用例下可直接調用已有的用戶場景用例、 系統(tǒng)用例、 功能用例， 可無須單獨編寫 用例。4、用例設計規(guī)則規(guī)則如下：1）每個用例需要選擇優(yōu)先級，分為高、中、低三種每個用例需要關聯(lián)項目。2）需要特別強調的是，用戶場景用例，一定要