




版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
第六章白盒、黑盒和灰盒測試技術6.1白盒測試6.2黑盒測試6.3灰盒測試6.4三種方法比較6.5白盒測試用例設計6.6黑盒測試用例設計6.7綜合策略本章小結白盒測試、黑盒測試和灰盒測試是廣泛使用的三種測試方法。它們是傳統(tǒng)的測試方法,有著嚴格規(guī)定和系統(tǒng)的方式可供參考。黑盒與白盒測試方法是從完全不同的、完全對立的起點出發(fā),反映了事物的兩個極端,而灰盒測試方法介于黑盒和白盒測試方法之間。三種測試方法各有側重,在實際軟件測試中都是有效和實用的。人們不能指望其中的一個能夠完全代替另一個。在進行單元測試時大都采用白盒測試,在確認測試或系統(tǒng)測試中大都采用黑盒測試,而實際中經(jīng)常使用灰盒測試方法。下面分別介紹這三類測試方法,并介紹白盒和黑盒測試用例的設計方法及其實例。
白盒測試是根據(jù)被測程序的內部結構設計測試用例,把測試對象看成一個透明的盒子(見圖6.1),它允許測試人員利用程序內部的邏輯結構及有關信息,設計或選擇測試用例,對程序所有邏輯路徑進行測試。白盒測試涉及軟件設計的細節(jié),原則上只涉及被測源程序,但有時也會用到設計信息。測試人員可以看到被測的源程序,用以分析程序的內部構造,并且根據(jù)其內部構造設計測試用例,這時測試人員可以完全不考慮程序的功能。6.1白盒測試按結構測試來理解,白盒測試要求對某些程序的結構特性做到一定程度的覆蓋,或稱為“基于覆蓋的測試”,這是從最早所謂“測試整個程序”的原始概念發(fā)展而來的。重視測試覆蓋率的度量,可以減少測試的盲目性,并引導人們朝著提高覆蓋率的方向努力,從而找出那些已被忽視的程序Bug。
圖6.1白盒測試示意圖
1.白盒測試分類和應用范圍
白盒測試通常被認為是單元測試與集成測試的統(tǒng)稱,是軟件測試體系中的一個重要分支,測試對象是一行行可見程序代碼。如果代碼不可見,就不是白盒測試,而是黑盒測試。白盒測試概念是相對的,與當前項目遵循的研發(fā)流程有關,某些流程把白盒測試劃分為單元測試與集成測試;而另一些流程,把白盒測試劃分為模塊單元測試、模塊系統(tǒng)測試、多模塊集成測試,還有一些流程把單元測試與集成測試混為一體,統(tǒng)稱為程序集成測試。白盒測試的應用范圍限定在功能測試之前,針對程序源代碼行的所有測試,即被測對象是看得到的功能源碼,每個測試人員必須先獲得源碼才能實施測試。
2.白盒測試的目的
通過檢查軟件內部的邏輯結構,對軟件中的邏輯路徑進行覆蓋測試。在程序不同地方設立檢查點,檢查程序的狀態(tài),以確定實際運行狀態(tài)與預期狀態(tài)是否一致。
3.白盒測試的優(yōu)缺點
白盒測試依據(jù)軟件設計說明書進行測試,對程序內部細節(jié)嚴密檢驗,針對特定條件設計測試用例,對軟件的邏輯路徑進行覆蓋測試。
(1)優(yōu)點:適用于單元測試等,測試開始的時間較早;能夠對已完成的程序代碼進行詳盡、徹底、有重點的測試;更有可能捕捉到軟件Bug或人為設置的故障。
(2)缺點:不能驗證各種說明書是否正確;不能測試長的、復雜的程序工作邏輯;程序員易存在偏見,不能客觀的對軟件進行測試。一些程序員總是不愿承認自己辛辛苦苦編寫的程序代碼有問題,從而對其進行袒護,不能進行有效、客觀的測試,所以測試員一般應選擇第三方,不能由程序員進行自測。
4.應用白盒測試遵循的原則
(1)一個模塊中的所有獨立路徑至少被測試一次。
(2)所有邏輯值均需測試true和false兩種情況。
(3)檢查程序的內部數(shù)據(jù)結構,保證其結構的有效性。
(4)在取值的上、下邊界及可操作范圍內運行所有循環(huán)。
5.白盒測試內容
白盒測試方法對程序模塊進行如下主要測試:
(1)對程序模塊的所有獨立的執(zhí)行路徑至少測試一次。
(2)對所有的邏輯判定,取“真”與取“假”的兩種情況都至少測試一次。
(3)在循環(huán)的邊界和運行界限內執(zhí)行循環(huán)體。
(4)測試內部數(shù)據(jù)結構的有效性等。
6.白盒測試步驟
(1)測試計劃階段:根據(jù)需求說明書,制訂測試進度。
(2)測試設計階段:依據(jù)程序設計說明書,按照一定規(guī)范化的方法進行軟件結構劃分和設計測試用例。
(3)測試執(zhí)行階段:輸入測試用例,得到測試結果。
(4)測試總結階段:對比測試的結果和代碼的預期結果,分析Bug原因,找到并解決Bug。
7.白盒測試技術分析
在白盒測試中,最常見的程序結構覆蓋是語句覆蓋。語句覆蓋要求被測程序的每一可執(zhí)行語句在若干次測試中盡可能都測試一次。語句覆蓋是一種最弱的邏輯覆蓋準則,但它是一種必須做的最低限度的白盒測試。進一步則要求程序中所有判定的兩個分支盡可能得到測試,即分支覆蓋或判定覆蓋。當判定式含有多個條件時,要求每個條件的取值都得到測試,即條件覆蓋。在同時考慮條件的組合值及判定結果的測試時,人們又要進行判定/條件覆蓋。在只考慮對程序路徑的全面測試時,可使用路徑覆蓋準則。在進行獨立路徑測試(基本路徑測試)之前,先介紹流圖符號(見圖6.2)。
圖6.2五種流圖表示符號在圖6.2中,每一個圓表示流圖的節(jié)點,代表一個或多個語句,程序流程圖中的處理方框序列和菱形決策框可映射為一個節(jié)點,流圖中的箭頭,稱為邊或連接,代表控制流,類似于流程圖中的箭頭。一條邊必須終止于一個節(jié)點,即使該節(jié)點并不代表任何語句。如流程圖6.3中兩個處理方框交匯處是一個節(jié)點,邊和節(jié)點限定的范圍稱為區(qū)域。
圖6.3程序流程圖任何過程設計表示法都可被翻譯成流圖,圖6.4為一段程序流程圖,圖6.5為相應的流圖。
圖6.4程序流程圖
圖6.5圖6.4相應的流圖注意:程序設計中遇到復合條件時(如邏輯OR、AND、NOR等),生成的流圖變得更為復雜。此時必須為語句IfaORb中的每一個a和b創(chuàng)建一個獨立的節(jié)點,如圖6.6所示。
圖6.6復合條件下的流圖獨立路徑指程序中至少引進一個新的處理語句集合,采用流圖的符號,即獨立路徑必須至少包含一條在定義路徑之前不曾用到的邊。如圖6.5中所示流圖的一個獨立路徑集合為
路徑
1:1→11;
路徑
2:1→2→3→4→5→10→1→11;
路徑3:1→2→3→6→8→9→10→111;
路徑4:1→2→3→6→7→9→10→1→11。上面定義的路徑1、2、3、4包含了圖6.5流圖的一個基本集,如果能將測試設計為強迫運行這些路徑,那么程序中的每一條語句將至少被執(zhí)行一次,每一個條件執(zhí)行時都將分別取true和false(分支覆蓋)。應該注意到基本集并不唯一。實際上,給定的過程設計可派生出任意數(shù)量的不同基本集??梢酝ㄟ^如下三種算法來確定尋找路徑的條數(shù),即計算獨立路徑的上界:
V
=
E
-
N
+
2,E是流圖中邊的數(shù)量,N是流圖節(jié)點數(shù)量;
V
=
P
+
1,P是流圖G中判定節(jié)點的數(shù)量;
V
=
R,R是流圖中區(qū)域的數(shù)量。
如圖6.5流圖可以采用上述任意一種算法來計算獨立路徑的數(shù)量:流圖有4個區(qū)域,所以V
=
4,即
V
=
11條邊
-
9個節(jié)點
+
2
=
4;
V
=
3個判定節(jié)點
+
1
=
4。
由此為了覆蓋所有程序語句,必須設計至少4個測試用例使程序運行于這4條路徑。為取得被測程序的覆蓋情況,最常用的辦法是在測試前對被測程序進行預處理。預處理的主要工作是在其重要的控制點插入“探測器”。
必須說明,無論哪種測試覆蓋,即使其覆蓋率達到100%,也不能保證把所有隱藏的程序Bug都揭露出來。對于某些在規(guī)格說明中已有明確規(guī)定,但在實現(xiàn)中被遺漏的功能,無論哪一種結構覆蓋也是檢查不出。因此,提高結構測試覆蓋率只能增強人們對被測軟件的信心,但不是萬無一失。
黑盒測試是使用最多的、從用戶觀點出發(fā)進行測試的一種重要的測試技術,涵蓋了軟件測試的各個方面。黑盒測試是在程序接口進行測試,它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用,也被稱為用戶測試。6.2黑盒測試黑盒測試把測試對象(或系統(tǒng))看作一個“內部不可見的黑盒子”(見圖6.7),軟件的內部部件按照系統(tǒng)要求工作,測試人員完全不用考慮程序邏輯結構、內部結構和內部特性,而只要關心軟件的輸入與輸出。測試人員依據(jù)程序的需求規(guī)格說明書,檢查程序的功能是否符合它的功能說明。
圖6.7黑盒測試示意圖
1.優(yōu)缺點
(1)黑盒測試的優(yōu)點:適用于功能測試、可用性測試及可接受性測試;對照說明書測試程序功能;可測試長的、復雜的程序的工作邏輯,易被理解。
(2)黑盒測試的缺點:不可能進行完全的、毫無遺漏的輸入測試,有一些軟件Bug或人為設置的故障通過黑盒測試是無法檢測出來的。正是因為黑盒測試的測試數(shù)據(jù)來自規(guī)格說明書,這一方法的主要缺點是它依賴于規(guī)格說明書的正確性。實際上,人們并不能保證規(guī)格說明書完全正確。如在規(guī)格說明書中規(guī)定了多余的功能,或是漏掉了某些功能,這對于黑盒測試來說是完全無能為力的。
2.作用
黑盒測試主要檢查三種基本類型的Bug:與軟件功能路徑有關的Bug;與軟件完成的計算有關的Bug;與軟件可執(zhí)行的數(shù)據(jù)值范圍或字段有關的Bug。黑盒測試的內容主要是覆蓋軟件的全部功能,可以結合兼容、性能等方面進行測試,根據(jù)軟件需求,設計文檔,模擬客戶場景隨系統(tǒng)進行實際的測試。
黑盒測試方法是在程序接口上進行測試,主要是為了發(fā)現(xiàn)以下Bug:
●
是否有不正確或遺漏了的功能。●
在接口上輸入能否正確地接受;能否輸出正確的結果。
●
是否有數(shù)據(jù)結構Bug或外部信息(例如數(shù)據(jù)文件)訪問Bug。
●
性能上是否能夠滿足要求。
●
是否有初始化或終止性Bug。
用黑盒測試發(fā)現(xiàn)程序中的Bug,必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù),來檢查程序是否都能產(chǎn)生正確的輸出,通過下面例子說明這是不可能的。
假設一個程序P有輸入變量為X和Y,輸出量為Z。見圖6.8。
圖6.8程序圖在字長為32位的計算機上運行。若X、Y取整數(shù),按黑盒方法進行窮舉測試,可能采用的測試數(shù)據(jù)組有
多。如果測試一組數(shù)據(jù)需要1毫秒,一年工作365
×
24小時,完成所有測試需5億年。所以不可能測試所有可能的輸入。
3.黑盒測試方法劃分
黑盒測試方法主要有等價類劃分方法、邊界值分析方法、基于決策表的測試方法、因果圖法、Bug推測法以及健壯性測試等。
1)等價類劃分方法
等價類劃分方法是一種典型的黑盒測試方法,它完全不考慮程序的內部結構,而只是根據(jù)程序的說明和要求來進行測試用例的設計。
實際上,人們在計劃測試時,一般需要將整個系統(tǒng)分解。對一個復雜的系統(tǒng)來說,它可以被分解成一些相對獨立的子系統(tǒng)。如果使用某個等價類中的一個輸入代表值作為測試數(shù)據(jù)進行測試沒有查出Bug,那么這個等價類中的其他輸入數(shù)據(jù)同樣也有這種情況。因此,把全部輸入數(shù)據(jù)合理地劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量的、具有代表性的測試用例來取得較好的測試效果。正確的劃分子系統(tǒng)可以降低測試的復雜性,減少重復與冗余,更加方便設計測試用例。在測試時,測試人員同樣先要對需求規(guī)格說明書的各項需求,尤其是功能需求進行細致分析,同時,還要求對輸入要求和輸出要求區(qū)別對待和處理。
(1)等價類:等價類是指某個輸入域的子集合。在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的Bug都是等效的,并合理地假定:測試某等價類的代表值就等價于對這一類其他值的測試。
(2)等價類劃分:把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一等價類中任取一個數(shù)據(jù)作為代表進行測試來發(fā)現(xiàn)程序中的Bug,測試效果和取該等價類中的其他數(shù)據(jù)測試效果是等同的,這樣就可以避免很多不必要的重復,極大地提高測試效率。等價類劃分有兩種不同的情況:有效等價類和無效等價類。
①有效等價類是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構成的集合。利用有效等價類可檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能;
②無效等價類與有效等價類的定義恰巧相反。設計時要同時考慮這兩種等價類,因為軟件不僅要能接收合理的數(shù)據(jù),也要能經(jīng)受意外的考驗。
在設計測試用例時,要同時考慮有效等價類和無效等價類的設計。①等價類劃分法的優(yōu)缺點:優(yōu)點是用盡可能少的測試案例,發(fā)現(xiàn)盡可能多的Bug,很大程度上減少了重復性;缺點是缺乏特殊案例的考慮,同時需要深入了解系統(tǒng)知識,才能做到有效地處理。
②劃分等價類的標準。
●
完備測試、避免冗余。
●
集合的劃分,劃分為互不相交的一組子集,而子集的并是整個集合,保證劃分的完備性。
●
子集互不相交,保證一種形式的無冗余性?!?/p>
同一類中標識(選擇)一個測試用例,同一等價類中,往往處理相同,相同處理映射到相同的執(zhí)行路徑。
(3)確定等價類的原則:在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下,則可確定一個有效的等價類(輸入值或數(shù)在此范圍內)和兩個無效等價類(輸入值或個數(shù)小于這個范圍的最小值或大于這個范圍的最大值)。
假設輸入值是學生成績,則其范圍為0~100,則有效等價類是“0≤成績≤100”;而兩個無效等價類是“成績<0”和“成績>100”。在數(shù)軸上表示如圖6.9所示。
圖6.9學生成績劃分不同等價類后的數(shù)軸假設,在程序的規(guī)格說明中,輸入條件中有一句話:“……項數(shù)可以從1到999……”,則有效等價類是“1≤項數(shù)≤999”;而兩個無效等價類是“項數(shù)
<1”和“項數(shù)
>
999”。
如果輸入條件規(guī)定了輸入數(shù)據(jù)的集合,或規(guī)定了“必須如何”等的條件,而且程序對不同的輸入值分別做不同的處理,則每個允許輸入值是一個有效等價類,此處還有一個無效等價類(任何一個不允許的輸入值的集合)。如在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”,那么所有以字母打頭的構成有效等價類,而不在此集合內(不以字母打頭)屬于無效等價類。
在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下,可確立一個有效等價類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)。
如Pascal語言規(guī)定“一個語句必須以分號‘;’結束”。這時,可以確定一個有效等價類“以‘;’結束”,若干個無效等價類:“以‘:’結束”、“以‘,’結束”、“以‘’結束”、“以LF結束”等。如果規(guī)定了輸入數(shù)據(jù)的一組值(假定n個),且程序要對每個輸入值分別進行處理。這時可確立n個有效等價類和一個無效等價類。
如在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù),做相應的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教;一個無效等價類,它是所有不符合以上身份的人員的集合。
在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類。在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類。
如等價類劃分基于功能項的輸入和輸出,將其劃分成等價類,通常包括以下幾種組合:
①合法/非法的輸入和輸出;
②對數(shù)值型的值分為正數(shù)、負數(shù)和0;
③對于字符串型的分為空串和非空串。
如學生成績等級評定(A~D):總分(0~100)
=
考試分(0~75)
+
上課分(0~25);總分≥70,Grade
=“A”;總分≥50and<
70,Grade=“B”;總分≥30and<
50,Grade
=“C”;總分≥0and<
30,Grade
=“D”??荚嚦煽冊跀?shù)軸上表示如圖6.10所示。
圖6.10學生成績等級評定數(shù)軸
(4)設計測試用例:在確立了等價類后,可建立等價類表(見表6.1),列出所有劃分出的等價類:表6.1等價類表然后從劃分出的等價類中按以下三個原則設計測試用例:
①為每一個等價類規(guī)定一個唯一的編號。
②設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋的有效等價類。重復這一步,直到所有的有效等價類都被覆蓋為止。
③設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類。重復這一步,直到所有的無效等價類都被覆蓋為止。
2)邊界值分析方法
在軟件測試中,邊界值分析方法又稱為邊界條件測試,是對等價類劃分方法的補充。
邊界條件測試在單元測試中最后進行,也是最重要的一項任務。通常,軟件經(jīng)常在邊界上失效,采用邊界值分析技術,針對邊界值及其左、右設計測試用例,很有可能發(fā)現(xiàn)新的Bug。
(1)定義:對輸入或輸出等價類直接在邊界值上以及稍大于邊界值和稍小于邊界值的數(shù)據(jù)進行測試。注意:“稍大于邊界值”中的邊界值是指最小邊界值,而“稍小于邊界值”中的邊界值是指最大邊界值。通常邊界值分析法作為等價類劃分法的補充,其測試用例
來自等價類的邊界。邊界值分析法不具有隨機性,與等價類劃分法結合起來使用效果會更好。
實踐中人們會發(fā)現(xiàn),程序在處理大量中間數(shù)值時都是對的,但是在邊界處容易出錯。如對數(shù)組的[0]元素的處理:在Basic中定義一個10個元素的整數(shù)數(shù)組,如果使用Dimdata(10)AsInteger,則定義的是一個11個元素的數(shù)組,在賦初值時再使用Fori=1to10…來賦值,就會產(chǎn)生問題,因為程序忘記了處理i
=
0的0號元素。
長期的測試經(jīng)驗證明,大量的Bug發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部。因此,針對各種邊界情況設計測試用例,可以查出更多的Bug。使用邊界值分析方法設計測試用例,首先應確定邊界情況。通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況。應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。
(2)邊界條件和邊界值:邊界條件是指軟件計劃的操作界限所在的邊緣條件。在邊界條件測試中應考慮的特征:第一個/最后一個、開始/完成、空/滿、最慢/最快、相鄰/最遠、最小值/最大值、超過/在內、最短/最長、最早/最遲、最高/最低等。這些都是可能出現(xiàn)的邊界條件。根據(jù)邊界來選擇等價分配中包含的數(shù)據(jù)。然而,僅僅測試邊界線上的數(shù)據(jù)點往往不夠充分。提出邊界條件時,一定要測試臨近邊界的合法數(shù)據(jù),即測試最后一個可能合法的數(shù)據(jù),以及剛超過邊界的非法數(shù)據(jù)。
下面給出一些邊界值的例子:
①對16bit的整數(shù)而言32
768和
-32
767是邊界。
②屏幕上光標在最左上、最右下位置。
③報表的第一行和最后一行。④數(shù)組的第一個元素和最后一個元素。
⑤循環(huán)的第0次、第1次和倒數(shù)第2次、最后一次。
針對各種邊界情況設計測試用例,可以查出更多的Bug。如在做三角形計算時,要輸入三角形的三個邊長:A、B和C。
這三個數(shù)值應當滿足:A
>
0、B
>
0、C
>
0、A
+
B
>
C、A
+
C
>
B、B
+
C
>
A,才能構成三角形。但如果把六個不等式中的任何一個大于號“>”錯寫成大于等于號“≥”,就不能構成三角形。問題就出現(xiàn)在容易被疏忽的邊界附近。
(3)基于邊界值分析方法選擇測試用例的原則:
①如果輸入條件規(guī)定了輸入值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試用例的輸入數(shù)據(jù)。
②如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù),最小個數(shù),比最小個數(shù)少一,比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。
③對于輸出值同樣可以按照①和②兩條原則來設計測試用例。
④根據(jù)規(guī)格說明的每個輸出條件,使用原則①。⑤根據(jù)規(guī)格說明的每個輸出條件,應用原則②。
⑥如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應選取有序集合中的第一個元素和最后一個元素作為測試用例。
⑦如果程序中使用了一個內部數(shù)據(jù)結構,則應當選擇這個內部數(shù)據(jù)結構的邊界上的值作為測試用例。
⑧分析規(guī)格說明,找出其他可能的邊界條件。
測試用例的設計只要按照以上原則設計就可以取得較好的效果。
3)邊界值分析法與等價類劃分法的區(qū)別
邊界值分析要把每個等價類的邊界都作為測試數(shù)據(jù),而等價類劃分是在每一個等價類中任取一個作為代表進行測試。
邊界值分析是等價劃分的擴展,包括等價類加
+
劃分的邊界值,邊界值通常是等價類的界限,以正好小于、等于和大于界限的等作為邊界值。這里所說的邊界指:相當于輸入等價類和輸出等價類而言,稍高于其邊界值及稍低于其邊界值的一些特定情況。
4)基于決策表的方法
決策表是分析和表達多邏輯條件下執(zhí)行不同操作的工具。在程序設計發(fā)展的初期,決策表就已被當做編寫程序的輔助工具。由于它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。
基于決策表的方法是最嚴格的一種功能測試方法。決策表具有邏輯表達式的功能,能有效地運用于表示和分析復雜邏輯關系上。在描述不同條件集合下采取行動的若干組合的情況最適合采用決策表來構造測試用例。
(1)決策表通常由四個部分組成:
①條件樁:列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
②動作樁:列出了問題規(guī)定可能采取的操作。這些操作的排列順序沒有約束。
③條件項:列出針對它所列條件的取值即在所有可能情況下的真、假值。
④動作項:列出在條件項的各種取值情況下應該采取的動作。
(2)決策表的建立步驟(根據(jù)軟件規(guī)格說明):
①確定規(guī)則的個數(shù)。假如有n個條件,每個條件有兩個取值(0,1),則有2n種規(guī)則。
②列出所有的條件樁和動作樁。
③填入條件項。
④填入動作項,得到初始決策表。
⑤簡化、合并相似規(guī)則(相同動作)。
(3)適合使用決策表設計測試用例的條件如下:
①規(guī)格說明以決策表形式給出,或很容易轉換成決策表。②條件的排列順序不會也不影響執(zhí)行哪些操作。
③規(guī)則的排列順序不會也不影響執(zhí)行哪些操作。
④每當某一規(guī)則的條件已經(jīng)滿足,并確定要執(zhí)行的操作后,不必檢驗別的規(guī)則。
⑤如果某一規(guī)則得到滿足要執(zhí)行多個操作,這些操作的執(zhí)行順序無關緊要。
5)因果圖法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系和相互組合??紤]輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多。因此,必須考慮采用一種適合于描述對于多種條件的組合,相應產(chǎn)生多個動作的形式來考慮設計測試用例,這就需要利用因果圖(邏輯模型)。因果圖法是一種利用圖解法分析輸入數(shù)據(jù)的各種組合情況,從而設計測試用例的方法。它適合于檢查程序輸入條件的各種組合情況,是描述事物的結果與其相關的原因之間關系的結構圖。
因果圖法是從用自然語言書寫的程序規(guī)格說明的描述中找出因(輸入條件)和果(輸出條件或程序狀態(tài)的改變),通過因果圖轉換為決策表。決策表的好處就是考慮了多個輸入之間的相互組合、相互制約關系。因果圖方法最終生成的就是決策表。利用因果圖生成測試用例的基本步驟:
(1)分析軟件規(guī)格說明描述中哪些是原因(即輸入條件或輸入條件的等價類),哪些是結果(即輸出條件),并給每個原因和結果賦予一個標識符。
(2)分析軟件規(guī)格說明描述中的語義,找出原因與結果之間,原因與原因之間對應的關系。根據(jù)這些關系,畫出因果圖。
(3)由于語法或環(huán)境限制,有些原因與原因之間,原因與結果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況,在因果圖上用一些記號表明約束或限制條件。
(4)把因果圖轉換為決策表。
(5)把決策表的每一列作為依據(jù),設計測試用例。
(6)從因果圖生成的測試用例包括了所有輸入數(shù)據(jù)的取TRUE與取FALSE的情況,構成的測試用例數(shù)目達到最少,且測試用例數(shù)目隨輸入數(shù)據(jù)數(shù)目的增加而線性增加。
6)
Bug推測法和健壯性測試
(1)Bug推測法:Bug推測法是根據(jù)測試人員的經(jīng)驗和直覺推測程序中所有可能存在的各種Bug,從而有針對性地設計測試用例的方法。
Bug推測方法的基本思想:列舉出程序中所有可能的Bug和容易發(fā)生Bug的特殊情況,然后根據(jù)測試人員的經(jīng)驗做出選擇。Bug推測法不是系統(tǒng)測試方法,只能用作輔助手段。如在單元測試時曾列出的許多在模塊中常見的錯誤,以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等,這些都是經(jīng)驗的總結。又如輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況;輸入表格為空格或輸入表格只有一行,這些都是容易發(fā)生錯誤的情況。
(2)健壯性測試:健壯性測試又稱容錯性測試,是對邊界值分析方法的擴展,即在測試用例中增加一個略大于最大值(max+)和略小于最小值(min-)的取值。用于測試系統(tǒng)在出現(xiàn)故障時,是否能夠自動恢復或者忽略故障繼續(xù)運行。不具備容錯性能的系統(tǒng)不是一個好系統(tǒng)。一個好的軟件系統(tǒng)必須經(jīng)過健壯性測試后才能最終交付給用戶。
4.黑盒測試方法步驟
以功能測試為例,黑盒測試方法的步驟如下:
(1)確定參照體系,參照體系是軟件測試的判斷依據(jù)。在功能測試中,參照體系的角色通常是需求規(guī)格說明書。在更為細致深入的測試中,還可引入系統(tǒng)設計文檔等。
(2)編寫測試用例。測試用例是有條理、有組織的對測試行為的描述。測試用例描述執(zhí)行測試時,執(zhí)行者所應進行的具體操作。測試用例應嚴格按照需求文檔編寫。
(3)測試執(zhí)行。測試人員執(zhí)行測試時,應按照測試用例所描述的內容進行操作,并將得到的結果與測試用例中的描述進行對比,判斷測試結果是否正確。若測試未通過,測試人員應將該步驟的測試結果判定為失敗,將Bug提交給相應的開發(fā)人員,并在后續(xù)的測試中,追蹤該Bug的修復情況,直至該缺陷被修復。
(4)測試用例維護。測試用例不是一次性產(chǎn)品,應不斷進行調整與更新。一份維護良好的測試用例,不但可以極大加快后續(xù)回歸測試的速度,更可讓新入職的員工(不論測試還是開發(fā))更快、更方便的熟悉業(yè)務。
由于黑盒測試無法尋找到合適的邊界,而白盒測試又對測試人員和測試時間提出很高的要求,這時就出現(xiàn)了類似于邊界測試的灰盒測試方法。6.3灰盒測試
1.定義
灰盒測試介于白盒測試和黑盒測試之間,是黑盒測試和白盒測試的綜合,是測試員研究需求分析及與程序員交流理解系統(tǒng)內部架構的結合?;液袦y試技術在業(yè)界并不像黑盒測試和白盒測試那樣使用普遍,下面用灰盒測試空間示意圖來解釋(見圖6.11)。
圖6.11灰盒測試空間示意圖我們把圖6.11想象為一個方塊盒子,對于黑盒測試,人們看不到盒子內部,所以全都是黑色的。但對于灰盒測試,它仍有黑色方塊存在,但已出現(xiàn)一層層白線圍起來的方塊,表示看到了部分代碼的實現(xiàn),白線越密意味著關注的代碼越多,最深處幾乎為全白。
灰盒測試考慮了用戶端、特定的系統(tǒng)和操作環(huán)境,在系統(tǒng)組件的協(xié)同性環(huán)境中評價應用軟件的設計,主要用于集成測試階段,用于多模塊構成的稍微復雜的軟件系統(tǒng)。灰盒測試既利用被測對象的整體特性,又利用被測對象的內部具體實現(xiàn),它看不到具體函數(shù)的內部,但可以看到函數(shù)之間的調用。具體說來,灰盒測試是在了解代碼實現(xiàn)的基礎上,通過黑盒功能測試加以判斷,以驗證軟件實現(xiàn)的正確性。在灰盒測試中,重點在于軟件系統(tǒng)內部模塊的邊界(接口)。對于進程內的模塊,其接口可能是動態(tài)庫的導出函數(shù);對于進程級的模塊,其接口可能是各種進程間的通信機制;對于涉及數(shù)據(jù)庫的軟件系統(tǒng),其接口可能是數(shù)據(jù)庫的表結構?;液袦y試有一個灰度的問題,如果只能看到整體特性就變成黑盒測試,如果可以看到具體的內部結構就是白盒測試,趨于前者就深些,趨于后者就淺些。灰盒測試重點在核心模塊,相對黑盒測試的時間少,相對白盒測試需要付出的研發(fā)成本要低,所以灰盒測試有自己的優(yōu)勢,投入少,見效快。
2.作用和特點
(1)測試可以及早介入:由于黑盒測試把整個軟件系統(tǒng)當成一個整體來測試,如果系統(tǒng)的某個關鍵模塊還沒有完工,那測試人員就無法對整個系統(tǒng)進行測試,只好閑等著。而灰盒測試是針對模塊的邊界進行的,模塊開發(fā)完一個就測試一個。
(2)有助于測試人員理解系統(tǒng)結構:為了進行灰盒測試,測試人員首先要熟悉內部模塊之間的協(xié)作機制。在熟悉的過程中,也就對整個系統(tǒng)(及其結構)有一個初步的、宏觀的認識。這有助于測試人員發(fā)現(xiàn)一些系統(tǒng)結構方面的Bug。而對于黑盒測試來說,由于測試人員不清楚軟件系統(tǒng)的內部結構,則難以發(fā)現(xiàn)一些結構性的Bug。
(3)有助于管理層了解真實的開發(fā)進度:一些復雜系統(tǒng),經(jīng)常會發(fā)生開發(fā)進度失控的情況,因為很多開發(fā)人員有報喜不報憂的傾向。某個開發(fā)人員聲稱自己的工作已經(jīng)完成了90%時,往往意味著他還要花同樣多的時間來完成剩下的10%,這導致項目管理人無法了解開發(fā)的真實進度。
(4)可以構造更好的測試用例。如果僅僅用黑盒方式測試系統(tǒng)的外部邊界(通常是用戶界面),有很多軟件Bug是不容易發(fā)現(xiàn)的。
3.優(yōu)點
相對于黑盒測試,灰盒測試的優(yōu)點如下:
(1)能有效地發(fā)現(xiàn)黑盒測試盲點。通過了解代碼的內部實現(xiàn),補充功能測試用例。這需要灰盒測試人員在查看代碼之前,掌握需求,并清楚已有的功能測試用例。對某一功能點的實現(xiàn)進行代碼分析(白盒測試),然后與黑盒測試(功能測試)充分結合起來,相互彌補,這就是灰盒測試的精髓。
(2)可以避免過度測試,精簡冗余用例。如具有相同特點的某一功能,在進行功能測試時,不必每個界面或提示框、對話框都進行該功能的測試。
(3)能及時發(fā)現(xiàn)沒有來源的更改。特別是在產(chǎn)品的維護階段,每一行代碼的更改都必須要有更改來源,但實際開發(fā)過程中,并不是每個開發(fā)人員都能做到,也并不是每個人都能清楚意識到更改后沒有得到有效驗證所帶來的后果。
假設,一條指令的語法結構中最多可含有7個參數(shù),參數(shù)順序可任意調整:
Command(param1,param2,param3,param4,param5,param6,param7)理論上,一個測試人員能設計出7!=
5040個測試用例。如果測試員采用灰盒測試法,通過與程序員進行溝通、交流,了解分析語法結構、運算法則,并假定每一個參數(shù)都是獨立的話,那么只需要7個測試用例就可以。
相對于白盒測試,灰盒測試的優(yōu)點如下:
(1)灰盒測試人才容易招聘。在人才市場上,100個應聘的測試人員中,未必能夠找到一個合適的白盒測試人員。
(2)灰盒測試人才不需要太多培訓。白盒測試人才需要內部培養(yǎng)(或培訓),而且培訓周期長。
4.灰盒測試的缺點
灰盒測試的主要缺點如下:
(1)不適用于簡單的系統(tǒng)。所謂的簡單系統(tǒng),就是簡單到總共只有一個模塊。由于灰盒測試關注于系統(tǒng)內部模塊之間的交互,如果某個系統(tǒng)只有一個模塊,那就沒必要進行灰盒測試。
(2)對測試人員的要求比黑盒測試高。從上面介紹來看,灰盒測試要求測試人員清楚系統(tǒng)內部由哪些模塊構成,模塊之間如何協(xié)作,因此對測試人員的要求就有所提高,會帶來一定的培訓成本。
(3)不如白盒測試深入。灰盒測試不如白盒測試那么深入。不過考慮到灰盒測試相比白盒測試有顯著的成本優(yōu)勢,該缺點不太明顯。
三種測試方法從完全不同的角度反映了軟件測試思路的三個方面,適用于不同的測試階段。
1.白盒測試的必要性
下面通過一個例子來說明白盒測試的必要性。
如果所有軟件Bug的根源都可以追溯到某個唯一原因,那么問題就簡單了。然而,事實上一個Bug往往是由多個因素共同導致的,如圖6.12(a)所示。6.4三種方法比較
圖6.12多個選擇判斷語句的流程圖假設此時開發(fā)工作已經(jīng)結束,程序送交到測試組,沒有人知道代碼中有一個潛在的被0除的Bug,測試組采用測試用例按照圖6.12(b)所示兩條不同的虛線路徑進行測試,顯然測試工作似乎非常完善,測試用例覆蓋了所有執(zhí)行語句,被0除的Bug沒有發(fā)生。但是,當客戶在使用該產(chǎn)品的過程中,執(zhí)行了如圖6.12(c)中的虛線路徑時,Bug就發(fā)生了。
由本例可以看到,如果不對程序內部的邏輯結構做分析,則設計的測試用例可能無法發(fā)現(xiàn)內部潛在的Bug。獨立路徑測試可以保證所有語句至少被執(zhí)行一次,同時排除上述(X=0,Y=5/X)組合沒有被執(zhí)行的情況。對于一個具有多重選擇和循環(huán)嵌套的程序,不同的路徑數(shù)目可能是天文數(shù)字。假設給出一個小程序的流程圖(見圖6.13),它包括一個執(zhí)行20次的循環(huán),則其包含5層,不同
執(zhí)行路徑數(shù)多達條,對每一條路徑進行測試需要1毫秒,假定一年工作365
×
24小時,要想把所有路徑測試完畢,則需要3024年才能完成。由此可見,在實際測試過程中,白盒測試方法是必要的。
圖6.13包含多條選擇語句的程序流程圖
2.三種方法的區(qū)別
黑盒測試是以用戶的觀點,從輸入、輸出數(shù)據(jù)的對應關系出發(fā)進行測試,也就是根據(jù)程序外部特性進行測試,它完全不涉及到程序的內部結構。如果外部特性本身有問題或規(guī)格說明的規(guī)定有問題,用黑盒測試方法發(fā)現(xiàn)不了。白盒測試與黑盒測試完全相反,它只根據(jù)程序的內部結構進行測試,而不考慮外部特性,如果程序結構本身有問題,比如說程序邏輯有Bug,或是有遺漏,那就無法發(fā)現(xiàn)。可以從這一對比中看出它們各自的優(yōu)缺點,以及它們之間的互補關系。圖6.14為黑盒與白盒測試方法比較。
圖6.14黑盒測試與白盒測試示意圖由于實用軟件的測試情況數(shù)量巨大,采用哪種測試方法都不可能進行徹底的測試。黑盒測試法是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用,才能查出程序中所有的Bug。但實際測試情況有無窮多種,人們不僅要測試所有合法的輸入,而且還要對很多不合法但可能的輸入進行測試。白盒測試法是窮舉路徑測試,貫穿程序的獨立路徑數(shù)是天文數(shù)字,而且即使每條路徑都測試了仍然可能有Bug。由于窮舉測試工作量太大,所以實踐中一般是行不通的,這就注定了一切實際測試都是不徹底的,因此就不能夠保證被測試程序中不存在遺留的Bug。黑盒與白盒測試方法比較見表6.2。表6.2黑盒測試與白盒測試方法比較灰盒測試與黑盒測試的區(qū)別:如果某軟件包含多個模塊,使用黑盒測試時,只要關心整個軟件系統(tǒng)的邊界,無需關心軟件系統(tǒng)內部各個模塊之間如何協(xié)作;使用灰盒測試,需要關心模塊與模塊之間的交互關系。
灰盒測試與白盒測試的區(qū)別:在灰盒測試中,無需關心模塊內部的實現(xiàn)細節(jié)。對于軟件系統(tǒng)的內部模塊,灰盒測試把它當成一個黑盒來看待;而白盒測試則不同,還需要再深入地了解內部模塊的實現(xiàn)細節(jié)。
3.三種方法的結合
灰盒測試關注輸出對于輸入的正確性,同時也關注內部表現(xiàn),但這種關注不像白盒那樣詳細、完整。如果每次都通過白盒測試來操作,效率會很低,因此需要采取灰盒的方法。
灰盒測試結合了白盒測試和黑盒測試的要素,它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價應用軟件的設計,取材于應用程序的內部知識與之交互的環(huán)境,能夠用于黑盒測試以增強測試效率、Bug發(fā)現(xiàn)和Bug分析的效率。如果人們知道產(chǎn)品內部的設計并對產(chǎn)品有深入了解,就能夠更有效地、深入地測試它的各項性能。
對于灰盒測試,沒有高深的理論,更多的是在從實踐中總結出來的測試技巧。用黑盒測試的需求文檔、設計文檔,加上白盒測試的對代碼結構化的了解,就構成了推動黑盒測試的所有輸入要素。假如人們開發(fā)的是一個Web應用系統(tǒng),那么,這種系統(tǒng)的服務端多半會提供若干個Web接口供客戶端調用。若某個Web接口存在安全性問題/并發(fā)性問題/健壯性問題等,人們單純用黑盒測試的手段難以發(fā)現(xiàn),而灰盒測試就可以發(fā)現(xiàn)。
檢查下面一段程序:
ifmyemployeeIDexists.
depositregularpaycheckintomybankaccount.
else
depositanenormousamountofmoneyintomybankaccount.
eraseanypossiblefinancialaudittrails.
這段程序完成的操作:若員工的員工號存在,那么定期存放工資到他的銀行賬戶;若不存在,那么存放巨額錢款到他的銀行賬戶,并擦除其所有可能存在的財務記錄。很顯然,程序設計者是想通過在程序中加入這樣一段額外的程序代碼來達到中飽私囊的目的。在這種情況下,單靠黑盒測試很有可能無法完成測試的目的,因為測試員不接觸程序,程序設計者更不會告訴測試員這部分程序的功能。但結合灰盒測試就可以發(fā)現(xiàn)問題,達到測試目的。下面通過一個例子(流程圖見圖6.15)來說明在實際中白盒測試與黑盒測試是交叉執(zhí)行的。
圖6.15中基本上保證了每條路徑至少被執(zhí)行一次。在上述代碼中沒有循環(huán),只有三個if判斷語句,它表明程序代碼中的多路徑源,共形成了6條路徑,見表6.3。
圖6.15軟件測試示例表6.3多路徑源的形成表6.4多路徑期望結果在整個測試過程中,白盒測試和黑盒測試都是測試設計的方法,它們從完全不同且完全對立的兩個視角出發(fā)反映了事物的兩個極端,它們各有側重,不能替代。在現(xiàn)代測試理念中,常常會將兩種測試方法交叉使用,以達到更好的測試效果。表6.5為三種方法比較。表6.5三種測試方法比較
白盒測試主要關注程序結構,通過分析程序中的關鍵結構設計測試用例。但它不是識別語法Bug(語法Bug通常由編譯器發(fā)現(xiàn)),而是試圖找到更難于察覺、發(fā)現(xiàn)和糾正的Bug,即試圖發(fā)現(xiàn)邏輯Bug并驗證測試覆蓋率。它是按照程序內部的結構測試程序,通過測試來檢測產(chǎn)品內部動作是否按照設計規(guī)格說明書的規(guī)定正常進行,檢驗程序中的每條通路是否都能按預定要求正確工作。6.5白盒測試用例設計
1.設計思想
白盒測試是結構測試,所以被測對象基本上是源程序,以程序的內部邏輯為基礎設計測試用例,使用程序設計的控制結構導出測試用例。
采用白盒測試的目的主要保證:
●
一個模塊中的所有獨立路徑至少被執(zhí)行一次;
●
對所有的邏輯判定均需要測試真、假兩個分支;
●
在上、下邊界及可操作范圍內運行所有循環(huán);
●
檢查內部數(shù)據(jù)結構以確保其有效性。
2.設計方法
白盒測試用例的設計根據(jù)程序的控制結構設計,主要用于軟件驗證。測試人員要深入了解被測程序的邏輯結構特點,完全掌握源代碼的流程,才能設計出恰當?shù)挠美0缀袦y試技術主要有覆蓋測試、基本路徑測試、程序結構分析。最常見的是覆蓋測試,根據(jù)不同的測試要求,覆蓋測試可以分為邏輯覆蓋、語句覆蓋、判定覆蓋、條件覆蓋、判定或條件覆蓋、條件組合覆蓋和路徑覆蓋等。
1)邏輯覆蓋
邏輯覆蓋是以程序內部的邏輯結構為基礎設計測試用例的技術。程序內部的邏輯覆蓋程度,當程序中有循環(huán)時,覆蓋每條路徑一般是不可能的,需要設計覆蓋程度較高的或覆蓋最有代表性的路徑的測試用例。下面介紹六種常用的邏輯覆蓋技術。
(1)語句覆蓋。語句覆蓋是設計若干個測試用例,運行被測程序,使得每一可執(zhí)行語句至少執(zhí)行一次。為了提高發(fā)現(xiàn)Bug的可能性,在測試時應該執(zhí)行程序中的每一個語句。
缺點:對程序執(zhí)行邏輯的覆蓋率很低。
(2)判定覆蓋。判定覆蓋指設計足夠的測試用例,運行所測程序,使得被測程序中每個決策表達式至少獲得一次“真”值和“假”值,從而使程序的每一個分支至少都通過一次,因此判定覆蓋也稱分支覆蓋。
缺點:主要對整個表達式最終取值進行度量,忽略了表達式內部的條件取值。
(3)條件覆蓋。條件覆蓋指設計足夠的測試用例,使得決策表達式中每個條件的各種可能的值至少執(zhí)行一次。缺點:條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真,有一次為假,而不考慮所有的判定結果。
(4)判定/條件覆蓋。該覆蓋標準指設計足夠的測試用例,運行所測程序,使得決策表達式的每個條件的所有可能取值至少執(zhí)行一次,并使每個決策表達式所有可能的結果也至少執(zhí)行一次。缺點:判定/條件覆蓋的缺點是未考慮條件的組合情況。
(5)條件組合覆蓋。條件組合覆蓋是比較強的覆蓋標準,它是指設計足夠的測試用例,使得每個決策表達式中條件的各種可能值的組合都至少執(zhí)行一次。
缺點:判定語句較多時,條件組合值也比較多,從而線性地增加了測試用例的數(shù)量。
(6)路徑覆蓋。路徑覆蓋是指設計足夠的測試用例,覆蓋被測程序中所有可能的路徑。缺點:由于路徑覆蓋需要對所有可能的路徑進行測試,運行所測程序,需要設計大量、復雜的測試用例,使得工作量呈指數(shù)級增長。而在有些情況下,一些執(zhí)行路徑是不可能被執(zhí)行的。
例6.1在實際的邏輯覆蓋測試中,一般以條件組合覆蓋為主設計測試用例,然后再補充部分用例,以達到路徑覆蓋測試標準。下面是快速排序算法中的一個劃分算法代碼,其中datalist是數(shù)據(jù)表,它有兩個數(shù)據(jù)成員:數(shù)組V(類型為Element)和數(shù)組大小n。算法中用到兩個操作:(1)取數(shù)組V的元素V[i]的關鍵碼操作getKey();(2)交換兩數(shù)組元素內容的操作Swap()。
intPartition(datalist&list,intlow,inthigh)
//在區(qū)間[low,high]上以第一個對象為基準進行一次劃分,k返回基準對象回放位置
{
intk=low,Elementpit=list.V[low]; //基準對象
for(inti=low+1;i<=high;i++) //檢測整個序列,進行劃分
if(list.V[i].getKey()<pit.getKey()&&++k!=i)
Swap(list.V[k],list.V[i]); //小于基準的交換到左側去
Swap(list.V[low],list.V[k]); //將基準對象就位
returnk;
} //返回基準對象位置
試畫出它的程序流程圖(見圖6.16);試利用路徑覆蓋方法為它設計足夠的測試用例,循環(huán)次數(shù)限定為0次、1次、2次。
圖6.16快速排序算法程序流程圖分析:畫程序流程圖是設計測試用例的關鍵。首先要搞清楚流程圖中的邏輯關系,再畫出正確的流程圖。考慮測試用例設計要有測試輸入數(shù)據(jù),以及預期的輸出結果。對于此例,控制循環(huán)次數(shù)靠循環(huán)控制變量i和循環(huán)終值high。循環(huán)0次時,取low=high,此時一次循環(huán)也不做。循環(huán)一次時,取low
+
1=high,循環(huán)二次時,取low
+
2=high。
設計的測試用例見表6.6。表6.6快速排序測試用例根據(jù)開放源碼的高級NIDS系統(tǒng)策略,條件V[i]<pit&&++k≠i的約束集合為{(<,<),(<,=),(=,<),(>,<)}。因此,設計測試用例見表6.7。表6.7添加約束條件后的測試用例例6.2下面是一段簡單的C語言程序,作為公共程序段來說明5種覆蓋測試各自的特點。程序如下:
If(x>100&&y>500)then
score=score+1;
If(x≥1000||z>5000)then
score=score+5;
邏輯運算符“&&”表示“與”關系,邏輯運算符“||”表示“或”的關系。程序流程圖如圖6.17。
圖6.17程序流程圖
(1)語句覆蓋是指設計若干個測試用例,程序運行時每個可執(zhí)行語句至少被執(zhí)行一次。在保證完成要求的情況下,測試用例的數(shù)目越少越好。以下是針對公共程序段設計的兩個測試用例,稱為測試用例組1。
測試1:x=2000,y=600,z=6000;
測試2:x=900,y=600,z=5000。
采用測試1作為測試用例,則程序按路徑ace順序執(zhí)行,程序中的4個語句都被執(zhí)行一次,符合語句覆蓋的要求。采用測試2作為測試用例,則程序按路徑acd順序執(zhí)行,程序中的語句4沒有執(zhí)行,所以沒有達到語句覆蓋的要求(見表6.8)。表6.8語句覆蓋測試用例組1從表面上看,語句覆蓋用例測試了程序中的每一個語句行,好像對程序覆蓋得很全面,但實際上語句覆蓋測試是最弱的邏輯覆蓋方法。如第一個判斷的邏輯運算符“&&”錯誤寫成了“||”,或者第二個判斷的邏輯運算符“||”錯誤的寫成“&&”,這時如果采用測試1測試用例是檢驗不出程序中判斷邏輯錯誤的。如果語句3“If(x≥1000
||
z>5000)then”錯誤寫成“If(x≥1500&&z>5000)then”,測試1同樣無法發(fā)現(xiàn)錯誤之處。
根據(jù)上述分析可知,語句覆蓋測試只是表面上的覆蓋程序流程。沒有針對源程序各個語句間的內在關系,設計更為細致的測試用例。
(2)判斷覆蓋。在執(zhí)行被測試程序時,程序中每個判斷條件的真值分支和假值分支至少被執(zhí)行一遍。在保證完成要求的情況下,測試用例的數(shù)目越少越好。
測試用例組2:
測試1:x=2000,y=600,z=6000;
測試3:x=50,y=600,z=2000。
如表6.9所示,采用測試1作為測試用例,程序按路徑ace順序執(zhí)行;采用測試3作為測試用例,程序按路徑abd順序執(zhí)行。所以采用這一組測試用例,公共程序段的4個判斷分支b,c,d,e都被覆蓋了。表6.9測試用例組2測試用例組3:
測試4:x=2000,y=600,z=2000;
測試5:x=2000,y=200,z=6000。
如表6.10所示,采用測試4作為測試用例,程序沿著路徑ace順序執(zhí)行;采用測試5作為測試用例,程序按路徑abe順序執(zhí)行。顯然采用這組測試用例同樣可以滿足判斷覆蓋。表6.10測試用例組3實際上,測試用例組2和測試用例組3不僅達到了判斷覆蓋要求,也同時滿足了語句覆蓋要求。某種程度上可以說判斷覆蓋測試要強于語句覆蓋測試。但是,如果將第二個判斷條件((x≥1000)or(z>5000))中的(z>5000)錯誤定義成z的其他限定范圍,由于判斷條件中的兩個判斷條件式是“或”的關系,其中一個判斷式錯誤是不影響結果的,所以這兩組測試用例是發(fā)現(xiàn)不了問題的。因此,應該用具有更強邏輯覆蓋能力的覆蓋測試方法來測試這種內部判斷條件。
(3)條件覆蓋。在執(zhí)行被測試程序時,程序中每個判斷條件中的每個判斷式的真值和假值至少被執(zhí)行一遍。
測試用例組4:
測試1:x=2000,y=600,z=6000;
測試3:x=50,y=600,z=2000;
測試5:x=2000,y=200,z=6000。
現(xiàn)在把前面設計過的測試用例挑選出測試1、測試3、測試5組合成測試用例組4,組中的3個測試用例覆蓋了4個內部判斷式的8種真假值情況。同時這組測試用例也實現(xiàn)了判斷覆蓋。但是并不可以說判斷覆蓋是條件覆蓋的子集。測試用例組5:
測試6:x
=
50,y
=
600,z
=
6000;
測試7:x
=
2000,y
=
200,z
=
1000。
如表6.11~表6.13所示,其中表6.12表示每個判斷條件的每個判斷式的真值和假值,表6.13表示每個判斷條件的真值和假值。測試用例組5中2個測試用例雖然覆蓋了4個內部判斷式的8種真假值情況。但是這組測試用例的執(zhí)行路徑是abe,僅是覆蓋了判斷條件的4個真假分支中的2個。所以,需要設計一種能同時滿足判斷覆蓋和條件覆蓋的覆蓋測試方法,即判斷或條件覆蓋測試。表6.11測試用例組4表6.12測試用例組5(a)
表6.13測試用例組5(b)
(4)判斷/條件覆蓋。在執(zhí)行被測試程序時,程序中每個判斷條件的真假值分支至少被執(zhí)行一遍,并且每個判斷條件的內部判斷式的真假值分支也要被執(zhí)行一遍。
測試用例組6:
測試1:x=2000,y=600,z=6000;
測試6:x=50,y=600,z=6000;
測試7:x=2000,y=200,z=1000;
測試8:x=50,y=200,z=2000。如表6.14和表6.15所示,其中表6.14表示每個判斷件的每個判斷式的真值和假值,表6.15表示每個判斷條件的真值和假值。測試用例組6雖然滿足了判斷覆蓋和條件覆蓋,但是沒有對每個判斷條件的內部判斷式的所有真假值組合進行測試。條件組合判斷是必要的,因為條件判斷語句中的“與”和“或”,即“&&”和“||”,會使內部判斷式之間產(chǎn)生抑制作用。例如C=A&&B中,如果A為假值,那么C就為假值,測試程序就不檢測B了,B的正確與否就無法測試了。同樣,C=A||B,如果A為真值,那么C就為真值,測試程序也不檢測B了,B的正確與否就無法測試了。表6.14測試用例組6(a)表6.15測試用例組6(b)
(5)條件組合覆蓋。在執(zhí)行被測試程序時,程序中每個判斷條件的內部判斷式的各種真假組合可能都至少被執(zhí)行一遍。
測試用例組7:
測試1:x=2000,y=600,z=6000;
測試6:x=50,y=600,z=6000;
測試7:x=2000,y=200,z=1000;
測試8:x=50,y=200,z=2000。如表6.16和表6.17所示,其中表6.16表示每個判斷條件的每個判斷式的真值和假值,表6.17表示每個判斷條件的真值和假值。測試用例組7雖然滿足了判斷覆蓋、條件覆蓋和判斷/條件覆蓋,但是并沒有覆蓋程序控制流程圖中的全部4條路徑(ace,abe,acd,abd),只覆蓋了其中3條路徑(ace,abe,abd)。軟件測試的目的是盡可能地發(fā)現(xiàn)所有軟件Bug,因此程序中的每一條路徑都應該進行相應的覆蓋測試,從而保證程序中的每一個特定的路徑方案都能順利運行。能夠達到這樣要求的是路徑覆蓋測試。表6.16測試用例組7(a)表6.17測試用例組7(b)
(6)路徑覆蓋。路徑覆蓋要求設計若干測試用例,執(zhí)行被測試程序時,能夠覆蓋程序中所有的可能路徑。
測試用例組8:
測試1:x=2000,y=600,z=6000;
測試3:x=50,y=600,z=2000;
測試4:x=500,y=600,z=2000;
測試7:x=2000,y=200,z=1000。
如表6.18和表6.19所示,表6.18表示每個判斷條件的每個判斷式的真值和假值,表6.19表示每個判斷條件的真值和假值。測試用例組8可以達到路徑覆蓋。表6.18測試用例組8(a)表6.19測試用例組8(b)應該注意的是,上面6種覆蓋測試方法所引用的公共程序只有短短4行,是一段非常簡單的示例代碼。然而在實際測試程序中,一個簡短的程序,其路徑數(shù)目是一個龐大的數(shù)字,要對其實現(xiàn)路徑覆蓋測試是很難的。所以,路徑覆蓋測試是相對的,要盡可能把路徑數(shù)壓縮到一個可承受范圍。
當然,即便對某個簡短的程序段做到了路徑覆蓋測試,也不能保證源代碼不存在其他軟件問題了。其他的軟件測試手段也必要的,他們之間是相輔相成的。沒有一個測試方法能夠找盡所有軟件缺陷,只能說是盡可能多地查找軟件缺陷。例6.3以另一種方式介紹6種覆蓋測試各自的特點。程序如下(類似于例6.2):
If(A>1&&B=0)then
X=X/A;
If(A=2||X>1)then
X=X+1;
程序的流程圖見圖6.18。
圖6.18程序流程圖由圖6.18可以看出,該程序有4條路徑,記為L1、L2、L3和L4,分別描述如下,由此得到測試用例:
(1)語句覆蓋:在圖6.18中,所有的可執(zhí)行語句都在路徑L1:a→c→e上,所以選擇路徑L1設計測試用例,就可以覆蓋所有的可執(zhí)行語句。
測試用例的設計格式如下:輸入(A,B,X),輸出(A,B,X),為圖例設計滿足語句覆蓋的測試用例是:(2,0,4)、(2,0,3),覆蓋ace
—
L1。
(A=2)and(B=0)or(A>1)and(B=0)and(X/A>1)
(2)判定覆蓋:對于圖6.19,如果選擇路徑L1:a→c→e和L2:a→b→d(圖6.19中虛線),就可得滿足要求的測試用例:
(A=2)and(B=0)or(A>1)and(B=0)and(X/A>1)
(A≤1)and(X≤1)or(B≠0)and(A≠2)and(X≤1)
(2,0,4)、(2,0,3),覆蓋ace—L1;(1,1,1)、(1,1,1),覆蓋abd—L2。
如果選擇路徑L3:a→b→e和L4:a→c→d(見圖6.19中虛線),還可得另一組可用的測試用例:(2,1,1)、(2,1,2),覆蓋abe—L3;(3,0,3)、(3,1,1),覆蓋acd—L4;
(A>1)and(B=0)and(A≠2)and(X/A≤1)
(A≤1)and(X>1)or(B≠0)and(A=2)or(B≠0)and(X>1)
圖6.19程序流程圖(虛線為兩條測試路徑L3和L4)
(3)條件覆蓋:在圖中,人們事先可對所有條件的取值加以標記。例如
對于第一個判斷:條件A
>
1取真為T1,取假為;條件B
=
0取真為T2,取假為;
對于第二個判斷:條件A
=
2取真為T3,取假為;條件X
>
1取真為T4,取假為。
則測試用例—覆蓋分支條件取值如下:
2)基本路徑覆蓋
任何有關路徑分析的測試都可以稱為路徑測試。下面給出對路徑測試的簡單描述。
路徑測試指從一個程序的入口開始,執(zhí)行所經(jīng)歷的各個語句的完整過程。路徑測試是白盒測試中最為典型的方法,完成路徑測試的理想情況是做到路徑覆蓋。對于比較簡單的小程序實現(xiàn)路徑覆蓋是可以做到的,但是程序中如果出現(xiàn)多個判定、多個循環(huán)語句,路徑數(shù)目將會急劇增長,事實上一般不可能實現(xiàn)路徑覆蓋。路徑覆蓋的基本思想是測試用例設計者導出一個過程設計的邏輯復雜性測度,并使用該測度作為指南來定義執(zhí)行路徑的基本集,從該基本集導出的測試用例保證對程序中的每一條執(zhí)行語句至少執(zhí)行一次。
在程序控制流圖的基礎上,通過分析、控制構造的環(huán)路復雜性,導出基本可執(zhí)行路徑集合,從而設計測試用例,包括以下五個方面:
(1)程序的控制流圖:描述程序控制流的一種圖示方法。
(2)程序環(huán)路復雜性:從程序的環(huán)路復雜性可導出程序基本路徑集中的獨立路徑條數(shù),這是確定程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。
(3)導出測試用例。
(4)準備測試用例,確?;韭窂郊械拿恳粭l路徑的執(zhí)行。
(5)圖形矩陣:在基本路徑測試中起輔助作用的軟件工具,利用它可以實現(xiàn)自動地確定一個基本路徑集。
基本路徑覆蓋方法的步驟如下:
圖6.20控制流圖
(1)畫出控制流圖(如圖6.20所示):任何過程設計都要被編譯成控制流圖。圖6.20中的每一個圓稱為流圖的節(jié)點,代表一條或多條語句。流圖中的箭頭稱為邊或連接,代表控制流。程序代碼為下面的C語言函數(shù)代碼:
voidSort(intiRecordNum,intiType)
{
1intx=0;
2inty=0;
3while(iRecordNum--)
4{
5if(iType==0)
6x=y+2;
7else
8if(iType==1)
9x=y+10;
10else
11x=y+20;
12}
13}
圖6.21判定邏輯圖注意:如果在程序中遇到復合條件時,條件語句中的多個布爾運算符(邏輯or、and),為每一個條件創(chuàng)建一個獨立的節(jié)點。包含條件的節(jié)點稱為判定節(jié)點,從每一個判定節(jié)點引出兩條或多條邊。如:
1if(aorb)
2x
3else
4y
5
對應的邏輯如圖6.21所示。
(2)計算圈復雜度:圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量,將該度量用于計算程序的基本的獨立路徑數(shù)目,為確保所有語句至少執(zhí)行一次的測試數(shù)量的上界。獨立路徑必須包含一條在定義前不曾用到的邊。
計算圈復雜度有以下三種方法:
①流圖中區(qū)域的數(shù)量對應于環(huán)型的復雜性。
②給定流圖G的圈復雜度,定義為V(G)
=
E
-
N
+
2,其中E是流圖中邊的數(shù)量,N是流圖中節(jié)點的數(shù)量。
③給定流圖G的圈復雜度,定義為V(G)
=
P
+
1,其中P是流圖G中判定節(jié)點的數(shù)量。對應圖6.18中代碼的圈復雜度計算如下:
V(G)
=
10條邊
-
8節(jié)點
+
2
=
4;V(G)
=
3個判定節(jié)點
+
1
=
4。
可以看出,控制流圖中有四個區(qū)域。
(3)導出獨立路徑:根據(jù)上面的計算方法,可得出四個獨立的路徑:
①路徑1:3-13。
②路徑2:3-5-6-12-3-13。
③路徑3:3-5-7-8-12-3-13。
④路徑4:3-5-7-10-12-3-13。
(4)設計測試用例:根據(jù)上面的獨立路徑,設計輸入數(shù)據(jù),使程序分別執(zhí)行到上面四條路徑。如:
Sort(0,1)測試路徑1;Sort(1,0)測試路徑2;
Sort(1,1)測試路徑3;Sort(1,2)測試路徑4。
黑盒測試用例設計使用詳細設計導出測試用例。與白盒測試不同,黑盒測試法主要著眼于程序外部結構,不考慮程序內部邏輯結構,主要針對軟件界面、軟件功能、外部數(shù)據(jù)庫訪問及軟件初始化等方面進行測試。黑盒測試不僅能夠找到大多數(shù)其他測試方法無法發(fā)現(xiàn)的錯誤,而且一些外購軟件,參數(shù)化軟件包以及某些自動生成的軟件,由于無法得到源程序,在一些情況下只能選擇黑盒測試。6.6黑盒測試用例設計
1.黑盒測試用例的目的
采用黑盒測試用例的目的主要是:檢查功能是否實現(xiàn)或遺漏;檢查人機界面是否有錯;數(shù)據(jù)結構或外部數(shù)據(jù)庫訪問是否有錯;性能等其他特性要求是否滿足;初始化和終止是否有錯等。黑盒測試用例是一種確認技術,是確認“設計的系統(tǒng)是否正確”,黑盒測試是以用戶的觀點,從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系,也就是根據(jù)程序外部特性進行的測試,而不考慮內部結構及工作情況;黑盒測試用例技術注重于軟件的信息域(范圍),通過劃分程序的輸入和輸出域來確定測試用例:若外部特性本身存在問題或者規(guī)格說明的規(guī)定有誤,則應用黑盒測試方法是發(fā)現(xiàn)不了問題的。
黑盒測試用例的優(yōu)缺點:
(1)優(yōu)點:適用于各個測試階段;從產(chǎn)品功能角度進行測試;容易入手生產(chǎn)測試數(shù)據(jù)。
(2)缺點:某些代碼得不到
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 礦山會計面試題及答案
- 教學鏟車考試題及答案
- 清廉機關考試題及答案
- 國家部委面試題及答案
- Unit 4 單元綜合測評
- 句型轉換考試題及答案
- 2025年導航工程專業(yè)畢業(yè)設計開題報告
- 2025年工會干部技能競賽題庫
- 基于SpringBoot的校園流浪動物救助平臺
- 2025年麥當勞值班技能考試題庫
- 2026年中考英語復習:初中英語課標詞匯 80天語境背誦清單
- “蘇超”現(xiàn)象:文化破圈、城市崛起與青年力量的融合交響-2026年高考語文作文熱點話題素材積累與實戰(zhàn)訓練
- 制作教學課件的完整步驟
- 貨運企業(yè)安全管理規(guī)范
- 生活污水管網(wǎng)改造提升工程建議書(模板)
- 危險廢物突發(fā)事故應急演練方案
- 老年衰弱護理課件
- 供應商準入管理制度及流程
- 一級建造師法律教學課件
- excel培訓課件制作
- 2025至2030中國酶載體樹脂行業(yè)發(fā)展模式及前景規(guī)劃研究報告
評論
0/150
提交評論