第3章

軟件測試用例的設計2006-9-19第3章軟件測試用例的設計※黑盒測試※

白盒測試※

面向對象的測試用例設計3.3白盒測試什么是白盒測試呢？白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。這一方法是把測試對象看作一個透明的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。應用程序1：路徑測試

基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路（圈）復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。控制流圖控制流圖主要由節點和邊構成。如何建立控制流圖？1）確定程序的程序流程圖2）程序流程圖轉化為控制流圖轉換的原則如下：控制流圖中的每一個節點可以表示程序流程圖中矩形框所表示的處理；菱形表示的兩個甚至多個出口判斷；多條流線相交的匯合點。例：1ifaorb2x3else4y環形（圈）復雜度定義：環形復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用于計算程序的基本的獨立路徑數目，為確保所有語句至少執行一次的測試數量的上界。獨立路徑：路徑中包含一條在定義之前未曾用到的邊。環形復雜度的計算方法方法一：流圖中區域的數量對應于環形的復雜性；方法二：給定流圖G的圈復雜度V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量；方法三：給定流圖G的圈復雜度V(G)，定義為V(G)=P+1，P是流圖G中判定結點的數量。路徑測試方法應用舉例例：VoidSort(int

iRecordNum,intiType)1

{2

intx=0;3

inty=0;4

while(iRecordNum--

>0)5

{6

if(0==iType)7

x=y+2;8

else9

if(1==iType)10

x=y+10;11

else12

x=y+20;13

}14}第一步，畫出程序的控制流圖。第二步，計算環形復雜度，并確定獨立路徑。

V(G)=E-N+2=10-8+2=4。

路徑1:4-14；路徑2：4-6-7-13-4-14；路徑3：4-6-8-10-13-4-14；路徑4：4-6-8-12-13-4-14。第三步，導出測試用例第四步，執行測試。intmain(){inta,b,c;boolIsTraingle;cin>>a>>b>>c;cout<<a<<endl;cout<<b<<endl;cout<<c<<endl;if((a<b+c)&&(b<a+c)&&(c<a+b))

IsTraingle=true;elseIsTraingle=false;if(IsTraingle)if((a==b)&&(b==c))

cout<<"Equilateral"<<endl;elseif((a!=b)&&(a!=c)&&(b!=c))

cout<<"Scalene"<<endl;elsecout<<"Isosceles"<<endl;elsecout<<"NotaTriangle"<<endl;}三角形程序控制流圖結點3到7是一個序列，結點7到9是一個if-then-else結構，結點10到16是一個嵌套的if-then-else結構。結點3和17是程序源結點和匯結點，對應于單入口、單出口準則。該程序沒有循環，因此控制流圖是一個有向非循環圖。作業：請根據本程序控制流圖完成環形復雜度的計算、列出獨立路徑、測試用例的設計并執行測試2:數據流測試數據流測試的意義？路徑測試可以測試程序中所有的條件和語句塊，但是，這也不能檢測出程序中所有的錯誤。基于數據流的測試主要關注程序中數據的定義和使用，可以用于對基于控制流測試的補充。1定義/使用測試首先要明確一個假設，數據流的假設還是和路徑的假設一致，程序P的程序圖（有向圖）是一個單入口，單出口，并且不允許有從某個結點到其自身的邊。

a、DEF(v,n)，定義結點。

intx；x=y+z;b、USE(v,n)，使用結點

System.out.println(x)。c、P-use，當一個變量被用在分支語句的條件表達式中（如if和while語句），則稱為變量的P-use（謂詞使用）。

if(x>0){……..};d、C-use，如果一個變量被用在賦值語句的表達式、輸出語句中，被當作參數傳遞給調用函數，或被用在下標表達式中，則稱為變量的C-use。其中，C表示“計算”（計算使用）。y=x+1；function(x);e、定義使用路徑（DU-path）開始節點是DEF(v,n)，結束結點是USE(v,n)的路徑。f、定義清除路徑（DC-path）,當開始結點和結束結點中間沒有其他的定義結點的時候為清除路徑。voidf(intx,inty,intm){ w=x; if(m>0) w++; else w=w+2; if(y<=10) x=5*y; else x=3*y+5; z=w+x;}

全定義-使用路徑覆蓋準則：測試路徑需要覆蓋所有定義點到所有使用點的路徑，用dc-path擴展成測試路徑測試路徑1：1→2→3→4→7→8→11測試路徑2：1→2→3→6→7→10→11測試路徑3：1→2→3→6→7→8→11測試路徑4：1→2→3→4→7→10→11變量x的測試用例：3.4邏輯覆蓋邏輯覆蓋是通過對程序邏輯結構的遍歷實現對程序的覆蓋，它是一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。根據覆蓋目標的不同和覆蓋源程序語句的詳盡程度，邏輯覆蓋可分為語句覆蓋、判定（分支）覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。下一頁語句覆蓋語句覆蓋是選擇足夠多的測試數據，使得程序中的每個可執行語句至少執行一次。A>1&&B=0A=2||x>1x=x/Ax=x++abcdeFTFTA=2，B=0，x=4，路徑：ade25語句覆蓋準則的優缺點：【優點】

：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。【缺點】

：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件是無法測試的。如在多分支的邏輯運算中無法全面的考慮。語句覆蓋是最弱的邏輯覆蓋。返回判定（分支）覆蓋判定覆蓋是設計足夠多的測試用例，使得程序中的每一個判斷至少獲得一次“真”和一次“假”，即使得程序流程圖中的每一個真假分支至少被執行一次。A>1&&B=0A=2||x>1x=x/Ax=x++abcdeFTFT27分支覆蓋優缺點：【優點】：分支（判定）覆蓋具有比語句覆蓋更強的測試能力。同樣分支（判定）覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。【缺點】：往往大部分的分支（判定）語句是由多個邏輯條件組合而成，若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。判定覆蓋仍是弱的邏輯覆蓋。返回條件覆蓋條件覆蓋要求設計足夠多的測試用例，使得程序中每個判定表達式中的每個條件至少獲得一次“真”和一次“假”。29條件覆蓋優缺點：【優點】：增加了對條件判定情況的測試，增加了測試路徑。【缺點】：條件覆蓋不一定包含分支（判定）覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。返回判定/條件覆蓋得判斷中每個條件的所有可能至少出現一次，并且每個判斷本身的判定結果也至少出現一次。

對于上例，兩個判斷中各包含兩個條件，4個條件在兩個判斷中可能有8種組合：判定/條件覆蓋的優缺點【優點】：能同時滿足判定、條件兩種覆蓋標準。【缺點】

：判定/條件覆蓋準則的缺點是未考慮條件的組合情況。一些條件往往掩蓋了另一些條件。對于條件表達式(A＞1)&&(B=0)來說，只要(A＞1)的測試為真，才需測試(B=0)的值來確定此表達式的值，但是若(A＞1)的測試值為假時，不需再測(B=0)的值就可確定此表達式的值為假，因而B=0沒有被檢查。

邏輯表達式中的錯誤不一定能夠檢查出來。返回條件組合覆蓋條件組合覆蓋要求設計足夠多的測試用例，使得每個判定中條件的各種可能組合都至少出現一次。（1）A＞1，B=0屬第一個判斷的取真分支；（2）A＞1，B≠0屬第一個判斷的取假分支；（3）A<=1，B=0屬第一個判斷的取假分支；（4）A<=1，B≠0屬第一個判斷的取假分支；（5）A＝2，x＞1屬第二個判斷的取真分支；（6）A＝2，x<=1屬第二個判斷的取真分支；（7）A≠2，x＞1屬第二個判斷的取真分支；（8）A≠2，x<=1屬第二個判斷的取假分支。返回幾種覆蓋準則之間的區別及關系復合謂詞覆蓋準則分支--謂詞覆蓋準則分支覆蓋準則原子謂詞覆蓋準則語句覆蓋準則3.5白盒測試策略在軟件開發過程的不同階段，都可能需要進行白盒測試，根據實際的開發情況，可有選擇的使用下面的白盒測試策略。1：桌前檢查桌前檢查是在程序員實現特定功能后，進行單元測試之前，對源代碼進行的初步檢查。該項工作的參與人員為開發人員，重點檢查編碼、語句的使用等是否符合編碼規范，并根據《編碼規范》調整自己的代碼以符合編碼規范的要求。2：單元測試單元測試也稱作模塊測試，在傳統結構化程序中，以一個函數、過程為一個單元；在面向對象編程過程中，一般將類作為單元進行測試。該項工作的參與人員為專門的白盒測試人員。可采用白盒測試和黑盒測試相結合的方法。3：代碼評審代碼評審是在編碼初期或編寫過程中采用一種有同行參與的評審活動。該項工作需要所有開發小組共同參與，通過大家共同閱讀代碼或由程序編寫者講解代碼，其他同行邊聽邊分析問題的方法。共同查看程序，可以找出問題，使大家的代碼風格一致或遵守編碼規范。4：同行評審在同行評審中，由軟件產品創建者的同行們檢查該工作產品，識別產品的缺陷，改進產品的不足。主要用于檢驗工作產品是否正確的滿足了以往的工作產品中建立的規范，如需求或設計文檔；識別工作產品相對于標準的偏差，包括可能影響軟件可維護性的問題；向創建者提出改進建議；促進參與者之間的技術交流和學習等。根據CMM標準，該項工作的參與人員為程序員、設計師、單元測試工程師、維護者、需求分析師、編碼標準專家。至少需要開發人員，測試人員和設計師。5：代碼走查代碼走查由測試小組組織或者專門的代碼走查小組進行代碼走查，這時需要開發人員提交有關的資料文檔和源代碼給走查人員，并進行必要的講解。代碼走查往往根據《代碼檢查單》來進行，代碼檢查單常常是根據《編碼規范》總結出來的一些條目，目的是檢查代碼是否按照《編碼規范》來編寫的。當然，代碼走查的最終目的還是為了發現代碼中潛在的錯誤和缺陷。該項工作的參與者為測試人員。代碼走查速度一般建議為：匯編代碼與C代碼150行/小時，C++/Java200-300行/小時。6：靜態分析靜態分析通常需要輔助工具支持，通過提取代碼信息，進行統計，根據統計結果對源代碼進行質量評估。代碼規則檢查也是靜態分析的一個方面。該項工作的參與人員為測試小組。桌面檢查、代碼走查、代碼審查同時屬于代碼檢查的方式。代碼檢查是發現錯誤缺陷最有效的手段之一，通常能發現30%-70%的邏輯設計和編碼缺陷。可以發現的問題如：聲明或引用錯誤、函數/方法參數錯誤、語句不可達錯誤、數組越界錯