軟件測試實用教程-方法與實踐（第2版）課件ch04黑盒測試案例實踐

第4章黑盒測試案例實踐高等學校計算機類系列教材軟件測試實用教程——方法與實踐01保險金案例實踐案例說明(1)基本保險費率為1000元/年；(2)年齡系數(shù)和安全駕駛折扣見表4.1;(3)投保人必須是年滿16歲，且不足80歲的人；(4)投保人駕照上的分數(shù)初始為12分，每當違反交通規(guī)則時，將以整數(shù)為單位扣掉1分或若干分；(5)如果投保人駕照上的當前分數(shù)高于門限分數(shù)(見表4.1)，則投保時可給予其安全駕駛折扣；(6)如果投保人駕照上的當前分數(shù)被扣至達到甚至低于零分，則該投保人的駕照被吊銷。保險金問題主要是為投保人計算其需要購買的車險，一年內(nèi)的保險金計算公式為(注意，該公式與我國實際計算車險的方式并不一致，不可作為實際車險計算的依據(jù)):保險金=基本保險費率x年齡系數(shù)-安全駕駛折扣且車險的計算還需滿足如下條件：要求根據(jù)保險金的計算公式計算某投保人在一年內(nèi)應繳納的保險金。案例說明測試分析

保險金案例是一個典型的函數(shù)級別的案例。保險金問題沒有明顯的業(yè)務流程，無須使用基于場景的測試，可直接選擇邊界值、等價類、決策表等測試方法設計測試用例。保險金問題的輸入條件包括：投保人的年齡(以下簡稱年齡)和投保人駕照上的當前分數(shù)(以下簡稱分數(shù))。通過分析年齡和分數(shù)這兩個輸入條件之間的關系，可以看出，它們之間是存在相互關聯(lián)的。因此，需要選用邊界值測試和基于決策表的測試方法來設計測試用例。同時還可以發(fā)現(xiàn)，雖然輸入為兩個輸入條件，輸出僅為一個結(jié)果，系統(tǒng)輸入與輸出很不相似，但輸出是完全依賴于輸入計算得到的。所以，僅需針對系統(tǒng)輸入域進行測試設計即可。測試用例設計

1.邊界值測試(1)邊界點的確定年齡的邊界可由需求描述第3條和表4.1方便地得出，分數(shù)的邊界則由需求描述第4～6條和表4.1而得到，如下：①年齡的邊界點(6個):16，25，35，45，60，80;②分數(shù)的邊界點(6個):0，5，7，9，11，12。測試用例設計

(2)測試數(shù)據(jù)的選擇根據(jù)年齡和分數(shù)的邊界點，按照一個單位長度的鄰域設置原則，并按xmin-a，xmmn，xmm+a的測試數(shù)據(jù)設置方法，可得到測試數(shù)據(jù)如下：①年齡的測試數(shù)據(jù)(18個):15，16，17，24，25，26，34，35，36，44，45，46，59，60，61，79，80，81;②分數(shù)的測試數(shù)據(jù)(13個):-1，0，1，4，5，6，7，8，9，10，11，12，13。需要注意的是：就理論而言，每個邊界點附近應能找到3個測試數(shù)據(jù)，但分數(shù)的邊界點太過于靠近，每個邊界附近的鄰域點也可能本身就是邊界點，因此，在分數(shù)這個輸入條件的邊界附近只能得到13個測試數(shù)據(jù)。(3)測試用例的設計根據(jù)單缺陷假設，可得到邊界值測試用例的數(shù)量為18×(6-1)+13×(6-1)=155個。測試用例設計

由于測試用例數(shù)量太多，在此僅以年齡的一個測試數(shù)據(jù)25和分數(shù)的一個測試數(shù)據(jù)9為例，給出測試用例的設計，見表4.2。測試用例設計針對年齡和分數(shù)的邊界值測試用例如圖4.1所示。注意，當針對年齡的邊界及邊界附近的測試數(shù)據(jù)設計測試用例時，分數(shù)應取每兩個相鄰邊界點之間的正常值(即中值)，但對于11和12這兩個邊界點來說，它們屬于分數(shù)這個輸入條件的兩個相鄰邊界點，二者的中值無法取到，此時，只能取二者任意一個值作為正常值來設計測試用例。測試用例設計(1)等價類的劃分根據(jù)表4.1，可很自然地得到年齡和分數(shù)的等價類劃分如表4.3所示。其中，分數(shù)的等價劃分先按最大最小值得到初始有效等價類，并以此為基礎，通過使用不同的門限分數(shù)，將各等價類劃分出來。具體過程不再給出。2.基于決策表的測試測試用例設計(2)決策表的構(gòu)建和化簡根據(jù)有效等價類的劃分構(gòu)建決策表并化簡，結(jié)果如表4.4所示。對應的測試用例見表4.5。測試用例設計3.基于整體輸入域的等價類測試

實際上，保險金問題并不是一個很復雜的系統(tǒng)，若就整體輸入域進行等價類劃分，測試用例的設計會更加簡單。此時的整體輸入域是一個由年齡和分數(shù)構(gòu)成的二元組<年齡，分數(shù)>，其最大的有效等價類為AS={<年齡，分數(shù)>}16≤年齡<80，且0≤分數(shù)<12}。接著，按照是否給予安全駕駛折扣的原則，可將整體有效等價類劃分為有安全駕駛折扣、無安全駕駛折扣兩個有效等價類，再利用不同的年齡段，分別針對有安全駕駛折扣和無安全駕駛折扣的有效等價類繼續(xù)進行有效等價類的劃分，最終得到的有效等價類如表4.6所示。以這樣的等價劃分設計得到的測試用例同表4.5，但相比基于決策表的測試而言，測試用例的設計工作量小多了。測試用例設計測試小結(jié)保險金問題是一個函數(shù)層面的案例，主要特點是：(1)包含的功能點很單一，不涉及業(yè)務流程，但包含復雜的輸入/輸出計算關系，需要針對輸入域和輸出域進行關鍵數(shù)據(jù)的覆蓋測試。(2)該案例的測試用例設計以測試數(shù)據(jù)的選擇為主，測試重點在于如何選擇典型數(shù)據(jù)來測試所有情況下的計算，難點是如何高效地設計測試用例，達到測試的完備和無冗余。(3)該案例的測試應盡量考慮以自動化測試為主，可基于單元測試工具來輔助完成測試腳本的開發(fā)。02信息采集系統(tǒng)案例實踐案例說明信息采集系統(tǒng)來源于某和諧校園項目，該系統(tǒng)的主要功能是以學校為單位(僅針對中小學)，采集該校所有在校學生的基本信息和照片信息，并進行自動校驗，找出所有不符合要求的信息，提醒學校負責信息采集的人員(簡稱管理員)進行手動修改，若校驗通過，系統(tǒng)將自動按照規(guī)范的要求，對全校信息進行匯總和規(guī)格化處理。該系統(tǒng)以VisualStudio2008為開發(fā)平臺，采用C++語言開發(fā)實現(xiàn)。案例說明1.軟件需求跟蹤矩陣表4.7截取了軟件需求跟蹤矩陣的一部分內(nèi)容。案例說明2.系統(tǒng)需求規(guī)格說明下面給出系統(tǒng)需求規(guī)格說明書的一部分內(nèi)容。其中，有關版權(quán)聲明、幫助、用戶操作提示等功能及非功能需求不再給出，被刪除的功能需求也不再列出。案例說明案例說明案例說明案例說明案例說明案例說明案例說明案例說明測試分析(2)存在明顯的業(yè)務流程，且對應這些業(yè)務流程涉及多個功能點的測試問題，可使用基于場景的測試方法。(3)該系統(tǒng)的核心是對相關數(shù)據(jù)進行校驗，即查錯的過程，因此，測試的重點是如何考慮到所有的無效輸入情況，并構(gòu)建對應的測試數(shù)據(jù)文件。若系統(tǒng)能夠查找出測試數(shù)據(jù)文件中植入的所有錯誤情況，才證明系統(tǒng)的校驗能力是符合用戶需求的。這是與常規(guī)系統(tǒng)最大的差別所在。從功能需求來看，信息采集系統(tǒng)案例是一個功能較為簡單的軟件系統(tǒng)，它不再是一個單純用函數(shù)就可以實現(xiàn)的軟件。因此，它是一個系統(tǒng)層面的案例，其測試方面的要求如下：(1)有兩個主要的系統(tǒng)界面，需要考慮與用戶輸入、輸出相關的易用性問題，需對應進行用戶界面的功能測試和易用性測試。對于信息采集系統(tǒng)案例，要解決的核心問題包括：(1)如何規(guī)劃測試內(nèi)容，即有哪些方面需要進行測試；(2)如何選擇測試數(shù)據(jù)，即如何盡可能多的考慮到系統(tǒng)的無效情況，以覆蓋無效域；(3)如何運行測試用例，即采用手動測試，還是使用自動化測試。圍繞上述問題，一般的測試用例設計思路如下：測試用例設計(1)根據(jù)系統(tǒng)需求，分功能模塊進行功能點的測試，并結(jié)合邊界值、等價類劃分等測試方法設計功能測試用例：(2)分析業(yè)務流程，基于場景法，分析系統(tǒng)主流程，針對每個流程進行子流程分析，構(gòu)建需要測試的場景，并針對場景設計測試用例；(3)分析系統(tǒng)界面，針對各個主要界面，分不同的界面區(qū)域進行用戶界面測試。1.基于模塊的功能測試就系統(tǒng)功能來說，可按照業(yè)務流程，分為不同的功能模塊進行測試，需測試的功能包括：(1)系統(tǒng)登錄；(2)文件導入(包括照片文件和信息文件的導入);(3)文件校驗(包括照片文件和信息文件的校驗及結(jié)果查看);(4)文件導出(包括照片文件和信息文件的導出);(5)其他功能(包括版權(quán)聲明、幫助等)。下面以文件校驗為例，分析功能測試的設計，其他功能模塊的測試可參照此思想自行設計。測試用例設計測試用例設計文件校驗涵蓋的功能點有照片文件校驗、查看照片文件校驗結(jié)果、信息文件校驗、查看基本信息校驗結(jié)果，對應被測功能特性如表4.8所示。測試用例設計根據(jù)等價劃分的思想，以測試項F1.3照片文件校驗為例，照片文件校驗即為照片文件格式的校驗，可分為照片文件類型、文件存儲位置、文件名格式、文件存在性、文件重復性這幾個輸入條件，其中，有效等價類分別是這些輸入條件合法的情況，無效等價類分別為輸入條件非法的情況，由此得到測試項F1.3對應的測試需求如表4.9所示。測試用例設計測試用例如表4.10～表4.15所示。測試用例設計測試用例設計測試用例設計2.基于場景的業(yè)務流程測試在各個功能點的測試中，主要基于獨立性原則設計測試用例，以避免各功能點之間的相互影響。而對于整個系統(tǒng)來說，其業(yè)務的實現(xiàn)往往是包含多個功能點的，必須針對業(yè)務流程進行測試，也可以看做交叉功能測試。此時可采用基于場景的測試方法。測試用例設計對于復雜的系統(tǒng)來說，若將整個系統(tǒng)的業(yè)務流程全部繪制在一張圖中是很不現(xiàn)實的，可行的策略是按照分層分析的思想，先分析頂層主業(yè)務流程，然后對該流程中的每個業(yè)務節(jié)點，再分析該節(jié)點的業(yè)務流程，直至達到無須繼續(xù)細分的程度為止。(1)頂層的主流程分析信息采集系統(tǒng)涉及的主要界面只有登錄界面和系統(tǒng)主界面，而登錄界面僅包含系統(tǒng)登錄這個功能點，其他功能均在系統(tǒng)主界面實現(xiàn)，因此，基于場景法分析系統(tǒng)業(yè)務流程時，可針對系統(tǒng)登錄的流程進行單獨測試，而將其他流程作為重點進行測試。測試用例設計通過對需求的分析得到頂層的基本流和備選流如圖4.4所示(本圖不包含登錄的流程)。其中，基本流的初始狀態(tài)是用戶已成功登錄系統(tǒng)，基本流的步驟包括：①設置學校目錄；②設置導出文件目錄；③進行數(shù)據(jù)校驗；④進行數(shù)據(jù)導出。測試用例設計備選流1:學校目錄設置錯誤。在基本流步驟①處觸發(fā)，校驗學校目錄時發(fā)現(xiàn)目錄設置非法，包括目錄為空、目錄格式非法等情況，需回到步驟①重新設置學校目錄。備選流2:導出文件目錄設置錯誤。在基本流步驟②處觸發(fā)，校驗導出文件目錄時發(fā)現(xiàn)目錄設置非法，包括目錄為空、目錄格式非法等情況，需回到步驟②重新設置導出文件目錄。備選流3:數(shù)據(jù)校驗不通過。在基本流步驟③處觸發(fā)，對照片文件和信息文件校驗時發(fā)現(xiàn)錯誤，需手動對被校驗文件進行修改后，回到步驟③重新進行校驗。測試用例設計(2)第二層的主流程分析頂層主流程中的每個節(jié)點大多包含多個功能點，例如，設置學校目錄實際包含了2個功能點，即照片文件導入和信息文件導入；數(shù)據(jù)校驗則包含照片文件校驗、查看照片文件校驗結(jié)果、信息文件校驗、查看基本信息校驗結(jié)果這4個功能點。為了對這些功能點進行進一步分析，可選擇重要的節(jié)點繼續(xù)展開流程分析，并基于場景進行測試。為了對這些功能點進行進一步分析，可選擇重要的節(jié)點繼續(xù)展開流程分析，并基于場景進行測試。為此，選擇數(shù)據(jù)校驗和數(shù)據(jù)導出節(jié)點進行主流程分析，結(jié)果如圖4.5所示。關于基本流和備選流的描述不再給出。值得注意的是：盡管在本例中，測試重點是對導入的照片文件和信息文件進行校驗，即針對數(shù)據(jù)有錯誤的情況進行測試，但一般情況下，基本流仍然是包含正常輸入的流程，因此，在第二層的主流程分析中，設計的基本流是對應數(shù)據(jù)文件完全正確的情況，備選流是包含文件格式及內(nèi)容錯誤的情況。測試用例設計根據(jù)第二層主流程分析得到的基本流和備選流，可得到場景如下：①場景1(所有數(shù)據(jù)文件格式和內(nèi)容正確，且成功導出):基本流；②場景2(數(shù)據(jù)格式錯誤，內(nèi)容正確，且不修改錯誤);基本流+備選流1+備選流3+備選流5;③場景3(數(shù)據(jù)格式正確，內(nèi)容錯誤，且不修改錯誤):基本流+備選流2+備選流3+備選流5;④場景4(數(shù)據(jù)格式錯誤，內(nèi)容正確，手動修改錯誤后成功導出):基本流+備選流1+備選流3+備選流4+基本流；⑤場景5(數(shù)據(jù)格式正確，內(nèi)容錯誤，手動修改錯誤后成功導出):基本流+備選流2+備選流3+備選流4+基本流；⑥場景6(數(shù)據(jù)格式和內(nèi)容均有錯誤，且不修改錯誤):基本流+備選流1+備選流2+備選流3+備選流5+基本流。測試用例設計(3)不可行場景問題如果將主流程分析得到的基本流和備選流看做一個有向圖，則場景(基本流+備選流1)是一個完全可行的場景，但從實際的節(jié)點含義來看，該場景是不可能存在的。即當文件格式存在錯誤時，“是否余留錯誤”節(jié)點不可能沿著基本流往下執(zhí)行。因此，當構(gòu)建場景時，不僅要考慮該場景盡量簡單，在該場景中應盡量避免同時覆蓋多個備選流，還應注意場景的可行性，應在保證場景可行性的前提下，選擇使得場景盡量簡單的事件流的組合。測試用例設計(4)測試用例的設計根據(jù)場景分析流程中每個節(jié)點，提煉出系統(tǒng)的輸入和輸出，結(jié)合邊界值、等價類劃分等測試方法即可設計測試用例。以場景2為例，該場景包含了除登錄系統(tǒng)、版權(quán)聲明、幫助之外的所有功能點，因此對應該場景的測試，只需根據(jù)前面功能點的測試結(jié)果來考慮即可，不再贅述。測試用例設計3.基于界面的用戶界面測試除了單一功能測試、業(yè)務流程測試之外，對于一個包含用戶交互的系統(tǒng)而言，還需要針對用戶界面進行測試。對于界面不多的情況，可針對每個主要界面，分不同的界面區(qū)域進行用戶界面測試。而當界面較多時，例如，諸如一些網(wǎng)站類的軟件系統(tǒng)，頁面數(shù)目較多，則仍按功能模塊進行劃分，對應不同的功能模塊，考慮其功能的完成所涉及的所有界面，再對各個界面分為不同界面區(qū)域進行GUI測試。信息采集系統(tǒng)的界面主要包括登錄界面、信息校驗界面和消息窗口。下面分別予以討論。(1)登錄界面的測試系統(tǒng)登錄界面見圖4.6，可分為標題區(qū)、信息區(qū)和登錄區(qū)。測試用例設計(2)信息校驗界面的測試信息校驗界面如圖4.7所示，可分為標題區(qū)、目錄區(qū)、圖片格式區(qū)、信息校驗區(qū)、動作區(qū)和版權(quán)區(qū)。測試用例設計(3)消息窗口的測試當某個功能完成后，或者用戶輸入錯誤時，系統(tǒng)需要分別給出相關消息提示，針對這些消息窗口，應給出統(tǒng)一的格式要求。測試時也應注意覆蓋。消息窗口主要包括任務成功的提示和任務失敗的提示，如圖4.8所示。測試用例設計測試小結(jié)信息采集系統(tǒng)是一個系統(tǒng)層面的案例，主要特點是：(1)包含了多個功能點，涉及一些業(yè)務流程，且包含用戶界面來接受輸入和提供處理結(jié)果的輸出，需要進行單個功能點的測