一、簡介

任何工程產品都可以使用白盒測試和黑盒測試兩種方法之一進行測試。

1.1 黑盒測試

黑盒測試：已知產品的功能設計規格和使用者手冊，可以進行測試證明每個功能是否實現、每個實現了的功能是否符合要求，以及產品的效能是否滿足使用者的要求。
  軟體的黑盒測試意味著測試要在軟體的介面處進行，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書和使用者手冊，檢查程式的功能是否符合它的功能說明，以及效能是否滿足使用者的要求。因此黑盒測試又叫功能測試或資料驅動測試。
黑盒測試主要是為了發現以下幾類錯誤：

1. 是否有不正確或遺漏的功能？
2. 在介面上，輸入是否能正確的接受？能否輸出正確的結果？
3. 是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？
4. 效能上是否能夠滿足要求？
5. 是否有初始化或終止性錯誤？ 

1.2 白盒測試

白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否已經過檢查。
  軟體的白盒測試是對軟體的過程性細節做細緻的檢查，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試，通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。
白盒測試需要對程式模組進行如下檢查：

1. 保證一個模組中的所有獨立路徑至少被使用一次。
2. 對所有邏輯值均測試true和false。
3. 在迴圈的邊界和執行的界限內執行迴圈體。
4. 檢查內部資料結構以確定其有效性。

2.測試技術

2.1 白盒測試技術

白盒測試物件基本上是源程式，是以程式的內部邏輯為基礎的一種測試方法。
白盒測試方法又可分為靜態測試和動態測試。
  靜態測試是一種不通過執行程式而進行測試的技術，其關鍵功能是檢查軟體的表示和描述是否一致，沒有衝突或者沒有歧義。它瞄準的是糾正軟體系統在描述、表示和規格上的錯誤，是任何進一步測試的前提。
  動態測試需要軟體的執行，當軟體系統在模擬的或真實的環境中執行之前、之中和之後。對軟體系統行為的分析是動態測試的主要特點，它顯示了一個系統在檢查狀態下是正確還是不正確。

2.1.1 靜態測試

  最常見的靜態測試是找出原始碼的語法錯誤，這類測試可由編譯器來完成，因為編譯器可以逐行分析檢驗程式的語法，找出錯誤並報告。除此之外，測試人員須採用人工方法來檢驗程式，有些地方存在非語法方面的錯誤，只能通過人工檢測的方法來判斷。
  人工檢測的方法主要有程式碼檢查法、靜態結構分析法等。
<1>程式碼檢查法

程式碼檢查法主要是通過桌面檢查，程式碼審查和走查方式，對以下內容進行檢查。

1. 檢查程式碼和設計的一致性；
2. 程式碼的可讀性以及對軟體設計標準的遵循情況；
3. 程式碼邏輯表達的正確性；
4. 程式碼結構的合理性；
5. 程式中不安全、不明確和模糊的部分；
6. 程式設計風格方面的問題等。

桌面檢查：桌面檢查是一種傳統的檢查方法，由程式設計師檢查自己編寫的程式。程式設計師在程式通過編譯之後對原始碼進行分析、檢驗，並補充相關的文件，目的是發現程式中的錯誤。

程式碼審查：程式碼審查是由一組人通過閱讀、討論和爭議對程式進行靜態分析的過程，以小組會的方式進行。
程式碼走查：程式碼走查就是針對程式碼，在假想的輸入情況下，逐行的瀏覽程式碼，走查程式碼中發現潛在的缺陷並記錄結果的過程。
<2>靜態結構分析法
  在靜態結構分析中，測試人員通常通過使用測試工具分析程式原始碼的系統結構、資料結構、資料介面、內部控制邏輯等內部結構，生成函式呼叫關係圖、模組控制流圖、內部檔案呼叫關係圖等各種圖形、圖表，清晰地標識整個軟體的組成結構。

  通過分析這些圖表，包括控制流分析、資料據流分析、介面分析、表示式分析等，使其便於閱讀與理解，然後可以通過分析這些圖表，檢查軟體有沒有存在缺陷或錯誤。
靜態結構分析法通常採用以下一些方法進行源程式的靜態分析：

• 通過生成各種圖表，來幫助對源程式的靜態分析。
• 靜態錯誤分析

常用的各種引用表主要有(5個)：
① 標號交叉引用表：列出在各模組中出現的全部標號，並標出標號屬性。
② 變數交叉引用表：變數定義與引用表。
③ 子程式（巨集、函式）引用表：列出各個子程式、巨集和函式屬性，引數表。
④ 等價表：列出在等價語句或等值語句中出現的全域性變數和標號。
⑤ 常數表：列出全部數字常數和字元常數，並指出它們在哪些語句中首先被定義。

常用的各種關係圖、控制流圖主要有：
① 函式呼叫關係圖：列出所有函式，用連線表示呼叫關係，通過應用程式各函式之間的呼叫關係展示系統的結構。
② 模組控制流圖：由許多結點和連線結點的邊組成的圖形，其中每個結點代表一條或多條語句，邊表示控制流向，可以直觀地反映出一個函式的內部結構。
靜態錯誤分析主要用於確定在源程式中是否有某類錯誤或“危險”結構。
① 型別和單位分析（發現數據型別錯誤和單位的不一致。）
② 引用分析（變數在賦值前被引用，在賦值後未被引用，都是引用異常，需要檢查程式的每一條路徑，採用深度優先遍歷方法。）
③ 表示式分析（表示式中的錯誤，如不正確的使用括號，陣列下標越界，除數為0，對負數開平方等。）
④ 介面分析（模組間介面的一致性和模組與外部資料庫之間的介面的一致性。）

2.1.2 程式插樁技術

  程式插樁方法是藉助往被測程式中插入操作，來實現測試目的的方法，即向源程式中新增一些語句，實現對程式語句的執行、變數的變化等情況進行檢查。

  想要了解一個程式在某次執行中所有可執行語句被覆蓋的情況，或是每個語句的實際執行次數，最好的辦法是利用插樁技術。

下面是一個插樁例項：

上圖計算整數X和整數Y的最大公約數的程式流程圖，其中虛線的部分就是插樁的地方。

設計插樁程式時需要考慮的問題（4個）：

1. 探測哪些資訊；
2. 在程式的什麼部位設定探測點；
   1. 程式塊的第一個可執行語句之前
   2. for，do while等迴圈語句處
   3. if，else if等條件語句各分支處
   4. 輸入輸出語句之後
   5. 函式、過程、子程式呼叫語句之後
   6. return語句之後
   7. goto語句之後
3. 需要設定多少個探測點；（一般情況下，在沒有分支的程式段中只需一個計數語句，但如果程式中出現了多種控制結構，則要設計最少的計數語句完成相應的測試要求。）
4. 程式中特定部位插入某些用以判斷變數特性的語句。（這些判斷變數特性的語句稱為斷言語句，通過斷言語句的執行，使得程式的執行特性得到證實。）

2.1.3 邏輯覆蓋

  邏輯覆蓋是以程式內部的邏輯結構為基礎的測試技術，是通過對程式邏輯結構的遍歷實現程式的覆蓋，這一方法要求測試人員對程式的邏輯結構有清楚的瞭解。
  從覆蓋源程式語句的詳細程度分析，邏輯覆蓋標準有語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋。
示例程式一：

function js(float A,float B,float X){
	if(A>1&&B=0) X=X/A;
	if(A=2||X>1) X=X+1;
}

其流程圖為：

例項程式二：

void DoWork(int x,int y,int z){
	int k=0,j=0;
	if((x>3)&&(z<10)){//語句塊1
		k=x*y-1;
		j=sqrt(k);
	}
	if((x==4)||(y>5)){//語句塊2
		j=x*y+10;
	}
	j=j%3;		  //語句塊3
}

其流程圖為：

<1>語句覆蓋

語句覆蓋使程式中每個語句至少都能被執行一次。
例如:

在程式1中，為使程式中每個語句至少執行一次，只需設計一個能通過路徑a-c-e的資料就可以了，例如選擇輸入資料為：A=2，B=0，X=3就可達到“語句覆蓋”標準。
在程式2中，如測試用例輸入為：x=4、y=5、z=5 程式執行的路徑是：a-b-d。

<2>判定覆蓋

比語句覆蓋稍強的覆蓋標準是判定覆蓋。按判定覆蓋準則進行測試是指，設計若干測試用例，執行被測程式，使得程式中每個判斷的取真分支和取假分支至少經歷一次，即判斷的真假值均曾被滿足。判定覆蓋又稱為分支覆蓋。

<3>條件覆蓋

在設計程式中，一個判定語句是由多個條件組合而成的複合判定。
條件覆蓋的含義是：構造一組測試用例，使得每一判定語句中每個邏輯條件的可能值至少滿足一次。

<4>判定/條件覆蓋

判定/條件覆蓋的含義是：設計足夠的測試用例，使得判定中每個條件的所有可能（真/假）至少出現一次，並且每個判定本身的判定結果（真/假）也至少出現一次。

<5>多條件覆蓋

多條件覆蓋也稱為條件組合覆蓋，它的含義是：設計足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋的。

2.1.4 基本路徑測試法

前面的例子是個比較簡單的程式段，只有兩條路徑。但在實際問題中，即使一個不太複雜的程式，其路徑的組合都是一個龐大的數字。

基本路徑測試法是在程式控制流圖的基礎上，通過分析控制構造的環路複雜性，匯出基本可執行路徑集合，從而設計測試用例的方法。

設計出的測試用例要保證在測試中程式的每一條可執行語句至少執行一次。
基本路徑測試法的步驟：

1. 畫出程式控制流圖
2. 計算程式環路複雜性
3. 確定獨立路徑集合
4. 準備測試用例 

<1>程式控制流圖

  控制流圖是描述程式控制流的一種圖示方式。其中基本的控制結構對應的圖形符號如下圖所示。圖中的圖形符號中，圓圈稱為控制流圖的一個結點，它表示一個或多個無分支的語句或源程式語句。 

  程式流程圖中的一個順序處理框序列和一個菱形判定框，可以對映成流圖中的一個節點。在流圖中一條邊必須終止於一個節點，即使這個節點並不代表任何語句（實際上相當於一個空語句）。

  邊和節點圍成的面積稱為區域，但計算區域數時應該包括圖外部未被包圍的哪個區域。

下圖是一個簡單的流程圖轉換為控制流圖的示例：

注意：控制流圖的判定節點是左假右真。

<2>環路複雜性

  進行程式的基本路徑測試時，程式的環路複雜性給出了程式基本路徑集合中的獨立路徑條數，這是確保程式中每個可執行語句至少執行一次所必須的測試用例數目的上界。
  基本路徑集不是惟一的，對於給定的控制流圖，可以得到不同的基本路徑集。
通常環路複雜性V(G)可用以下3種方法求得：

1. 將環路複雜性定義為控制流圖中的區域數。
2. 設E為控制流圖的邊數，N為圖的結點數，則定義環路的複雜性為V(G)=E−N+2。（最為簡單）
3. 若設P為控制流圖中的判定結點數，則有V(G)=P+1。（最不易出錯）

上圖中邊數為13，節點數為11。

第一種方法：4

第二種方法計算：13-11+2=4

第三種方法計算：3+1=4

2.1.5 其它白盒測試方法

<1>域測試

域指程式的輸入空間。
域錯誤：若程式的控制流有錯誤，對應某一特定的輸入可能執行的是一條錯誤路徑，這種錯誤稱為路徑錯誤，也叫做域錯誤。
域測試主要是針對域錯誤進行的程式測試，是一種基於程式結構的測試方法。

缺點：
A．為進行域測試對程式提出的限制過多：
程式中不出現陣列；
程式中不含有子函式或子例程；
程式中沒有輸入和輸出錯誤；
程式的分支謂語是簡單謂語，即不含有布林運算子and和or；
程式分支謂語是線性的；
程式輸入域是連續的而不是離散的；
相鄰的兩個域上計算是不相同的；
B． 當程式存在很多路徑時，存在的測試點也很多。

<2>符號測試

符號測試的基本思想是允許程式的輸入不僅僅是具體的數值資料，而且包括符號值，這一方法也因此而得名。其測試步驟如下(5個)。
（1）利用符號執行直譯器對被測程式進行符號執行；
（2）若是遇到程式不能繼續執行的情況，要求使用者干預，或是遍歷各執行樹的各分支路徑；
（3）化簡得到的路徑條件式
（4）用解線性不等式的方法求解路徑條件式，以求得滿足各個限制謂語的測試資料；
（5）對程式進行測試，若上述不等式無解，則相應的路徑不可執行。
遇到的測試問題：
（1）分支問題
分支條件是符號，無法確定分支的走向；
（2）二義性問題
由於符號不能代表確切的值，經常會產生二義性問題；
（3）大程式問題
程式很複雜時，最終結果的表示式非常長，如果得不到簡化，則測試時會佔用大量的時間和空間，或者問題解決不了。

<3>Z路徑覆蓋

指簡化迴圈意義下的路徑覆蓋。無論迴圈的形式和實際執行迴圈體的次數是多少，只考慮迴圈一次或零次兩種情況。
程式中的所有路徑可以用路徑樹來表示，當得到某一程式的路徑樹後，從其根結點開始，一次遍歷，再回到根結點，把所經歷的葉節點排列起來，就得到一個路徑。如果設法遍歷了所有的葉節點，那就得到了所有路徑，然後生成每個路徑的測試用例，就做到了Z路徑覆蓋測試。

<4>程式變異

程式變異方法是一種錯誤驅動測試。所謂錯誤驅動測試方法，是指該方法是針對某類特定程式錯誤的。
錯誤驅動測試主要有兩種，即程式強變異和程式弱變異。
　（1） 測試輸入資料必須對突變和原始資料引起不同的程式狀態。
　 （2）輸出結果應該得到驗證。

2.1.6 白盒測試應用策略

（1）在測試中，應儘量先使用工具進行靜態結構分析。
（2）測試中可採取先靜態後動態的組合方式：先進行靜態結構分析、程式碼檢查，再進行覆蓋率測試。
（3）利用靜態分析的結果作為導引，通過程式碼檢查和動態測試的方式對靜態發現結果進行進一步的確認，使測試工作更為有效。
（4）覆蓋率測試是白盒測試的重點，一般可使用基本路徑測試法達到語句覆蓋標準；對於軟體的重點模組，應使用多種覆蓋率標準衡量程式碼的覆蓋率。
（5）在不同的測試階段，測試的側重點不同：

• 在單元測試階段，以程式碼檢查、邏輯覆蓋為主；
• 在整合測試階段，需要增加靜態結構分析等；
• 在系統測試階段，應根據黑盒測試的結果，採取相應的白盒測試。

2.2 黑盒測試技術

  黑盒測試也稱資料驅動測試，在測試時，把程式看作一個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試。
  在黑盒測試過程中，只是通過輸入資料、進行操作、觀察輸出結果，來檢查軟體系統是否按照需求規格說明書的規定正常使用，軟體是否能適當地接收輸入資料而產生正確的輸出資訊，並保持外部資訊的完整性。
黑盒測試方法：功能測試和非功能測試

2.2.1 功能測試（共8種）

<1>等價類劃分法

  所謂等價類是指某個輸入域的子集，使用這一方法時，是把所有可能的輸入資料，即程式的輸入域劃分成若干部分（子集），然後從每一個子集中選取少數具有代表性的資料作為測試用例。
等價類劃分有以下兩種不同的情況:

1. 有效等價類：是指對於程式規格說明來說，是合理的、有意義的輸入資料構成的集合。利用它，可以檢驗程式是否實現了規格說明預先規定的功能和效能。
2. 無效等價類 ：是指對於程式規格說明來說，是不合理的、無意義的輸入資料構成的集合。利用它，可以檢查程式中功能和效能的實現是否有不符合規格說明要求的地方。

劃分等價類的方法如下：

1.  按區間劃分 (1<x<100)
2.  按數值劃分 (x=1,2,3)
3.  按數值集合劃分 (x {大於2小於20的整數} )
4.  按限制條件劃分 (x是一個布林型變數)
5.  按限制規則劃分 (英語過四級，各門課程都及格才能拿獎學金)
6.  按處理方式劃分 (確保每一個等價類中的資料只有一種處理方式，否則要再細分為更小的等價類)

在確立了等價類之後，建立等價類表，列出所有劃分出的等價類，如表3-1所示。

再從劃分出的等價類中按以下原則選擇測試用例:

1. 為每個等價類規定一個惟一編號；
2. 設計一個新的測試用例，使其儘可能多地覆蓋尚未覆蓋的有效等價類；重複這一步驟，直到所有的有效等價類都被覆蓋為止。
3. 設計一個新的測試用例，使其僅覆蓋一個無效等價類，重複這一步驟，直到所有的無效等價類都被覆蓋為止。

例題：

該函式包含3個變數：month、day和year，函式的輸出為輸入日期後一天的日期。例如，輸入為2006年3月7日，則函式的輸出為2006年3月8日。要求輸入變數month、day和year均為整數值，並且滿足條件：1≤month≤12，1≤day≤31，1920≤year≤2050。
程式的輸入結構如下圖：

正確的輸入與輸出為：

前提條件是：輸入變數month、day和year均為整數值，並且滿足條件：1920≤year≤2050 ，1≤month≤12，1≤day≤31。

解題步驟：

等價類表：

預期的輸出結果：

R1: day=day+1
R2: day=1 month=month+1
R3: day=1 month=1 year=year+1

R4: day越界
R5: month越界
R6: year越界
測試用例：

<2>邊界值分析法

  邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。
  在測試過程中，邊界值分析法是通過選擇等價類邊界的測試用例進行測試，邊界值分析法與等價類劃分法的區別是邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。另外，邊界值分析不僅考慮輸入條件邊界，還要考慮輸出域邊界產生的測試情況。

  使用邊界值分析方法設計測試用例，首先應確定邊界情況。
  通常輸入等價類與輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等於，剛剛大於，或剛剛小於邊界的值作為測試資料，而不是選取等價類中的典型值或任意值作為測試資料。
選擇測試用例的原則如下（6個）。

1. 如果輸入條件規定了值的範圍，則應該取剛達到這個範圍的邊界值，以及剛剛超過這個範圍邊界的值作為測試輸入資料。
2. 如果輸入條件規定了值的個數，則用最大個數、最小個數、比最大個數多1個、比最小個數少1個的數作為測試資料。
3. 根據規格說明的每一個輸出條件，使用前面兩條規則 。
4. 如果程式的規格說明給出的輸入域或輸出域是有序集合（如有序表、順序檔案等），則應選取集合的第一個和最後一個元素作為測試用例。
5. 如果程式用了一個內部資料結構，應該選取這個內部資料結構的邊界值作為測試用例。
6. 分析規格說明，找出其它可能邊界條件。

<3>錯誤推測法

  基於經驗和直覺推測程式中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法，這就是錯誤推測法。
  錯誤推測法的基本想法是：列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。

<4>因果圖法

因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程式輸入條件的各種組合情況。
在因果圖的基本符號中，圖中的左結點ci表示輸入狀態（或稱原因），右結點ei表示輸出狀態（或稱結果）。ci 與 ei 取值0或1，0表示某狀態不出現，1則表示某狀態出現。

• 恆等：若 c1 是1，則 e1 也為1，否則 e1 為0。
• 非：若 c1 是1，則 e1 為0，否則e1為1。
• 或：若 c1 或 c2 或 c3 是1，則 e1 為1，否則 e1 為0。
• 與：若 c1 和 c2 都是1，則 e1 為1，否則 e1 為0。

因果圖中用來表示4種因果關係的基本符號：

  在實際問題中輸入狀態相互之間、輸出狀態相互之間可能存在某些依賴關係，稱為“約束”。對於輸入條件的約束有E、I、O、R四種約束，對於輸出條件的約束只有M約束。

因果圖中的約束（共5種）

• E約束(互斥)：a和b中最多有一個可能為1，即a和b不能同時為1。
• I 約束(包含)：a、b中至少有一個必須為1，即 a、b不能同時為0。
• O約束(唯一)：a和b必須有一個且僅有一個為1。
• R約束(要求)：a是1時，b必須是1，即a為1時，b不能為0。
• M約束(強制)：若結果a為1，則結果b強制為0。

因果圖中用來表示約束關係的約束符號：

因果圖法最終生成的是決策表。利用因果圖生成測試用例的基本步驟如下：
（1）分析軟體規格說明中哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個識別符號。
（2）分析軟體規格說明中的語義，找出原因與結果之間、原因與原因之間對應的關係， 根據這些關係畫出因果圖。
（3）由於語法或環境的限制，有些原因與原因之間、原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。
（4）把因果圖轉換為決策表。
（5）根據決策表中的每一列設計測試用例。

優點：
（1）考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關係。
（2）能夠幫助測試人員按照一定的步驟，高效率的開發測試用例。
（3）因果圖法是將自然語言規格說明轉化成形式語言規格說明的一種嚴格的方法，可以指出規格說明存在的不完整性和二義性。

缺點：
（1）輸入條件與輸出結果的因果關係，有時難以從軟體需求規格說明書得到。
（2）即使得到了這些因果關係，也會因為因果關係複雜導致因果圖非常龐大，測試用例數目及其龐大。

例題：

  程式的規格說明要求：輸入的第一個字元必須是#或*，第二個字元必須是一個數字，此情況下進行檔案的修改；如果第一個字元不是#或*，則給出資訊N，如果第二個字元不是數字，則給出資訊M。
解題步驟：
（1）分析程式的規格說明，列出原因和結果。
（2）找出原因與結果之間的因果關係、原因與原因之間的約束關係，畫出因果圖。
（3）將因果圖轉換成決策表。
（4）根據（3）中的決策表，設計測試用例的輸入資料和預期輸出。

<5>場景法

  現在的軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟體設計方面的思想也可以引入到軟體測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。

<6>判定表驅動法

判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具。
由於它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確，能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，在一些資料處理問題當中，若某些操作的實施依賴於多個邏輯條件的組合，即針對不同邏輯條件的組合值，分別執行不同的操作，判定表很適合處理這類問題。

判定表通常由四個部分組成：

1. 條件樁：列出了問題的所有條件，通常認為列出的條件的次序無關緊要。
2. 動作樁：列出了問題規定可能採取的操作，這些操作的排列順序沒有約束。
3. 條件項：列出針對它條件的取值，在所有可能情況下的真假值。
4. 具體項：列出在條件項的各種取值情況下應該採取的動作。

生成條件表的規則如下：
① 規則：任何一個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然,判定表中列出多少組條件取值,也就有多少條規則，即條件項和動作項有多少列。
② 化簡：就是把有兩條或多條具有相同的動作，並且其條件項之間存在著極為相似的關係的規則合併。
判定表的建立步驟:
① 確定規則的個數，假如有n個條件，每個條件有兩個取值（0，1），故有2n 種規則；
② 列出所有的條件項和動作項；
③ 填入條件取值；
④ 填入具體動作，得到初始判定表。
⑤ 簡化，合併相似規則（相同動作）。

優點：
它能把複雜的問題按各種可能的情況一一列舉出來，簡明而易於理解，也可避免遺漏。
缺點：
不能表達重複執行的動作，如迴圈。
適合使用判定表設計測試用例的條件：
① 規格說明以判定表形式給出，或很容易轉換成判定表。
② 條件的排列順序不會也不影響執行那些操作。
③ 規則的排列順序不會也不影響執行那些操作。
④ 每當某一規則的條件已經滿足，並確定要執行的操作後，不必檢驗別的規則。
⑤ 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。
例題：

一個軟體的規格說明指出：
（1）當條件1和條件2滿足，並且條件3和條件4不滿足，或者當條件1、條件3和條件4滿足時，要執行操作1；
（2）在任一個條件都不滿足時，要執行操作2；
（3）在條件1不滿足，而條件4被滿足時，要執行操作3；
（4）在不滿足以上條件時，執行默許操作。

<7>正交試驗法

正交實驗設計方法:是依據Galois理論，從大量的（實驗）資料（測試例）中挑選適量的，有代表性的點（例），從而合理地安排實驗（測試）的一種科學實驗設計方法。
類似的方法有：聚類分析方法，因子方法方法等。

正交試驗法常使用下面2個術語：
（1）因子：影響實驗指標的條件稱為因子。
（2）因子的狀態：影響實現因子的條件。
利用正交實驗設計測試用例的步驟（3步）
① 提取功能說明,構造因子--狀態表
根據被測軟體的規格說明書找出影響其功能實現的操作物件和外部因素，把他們當作因子，而把各個因子的取值當作狀態。
② 加權篩選,生成因素分析表
對因子與狀態的選擇可按其重要程度分別加權。可根據各個因子及狀態的作用大小、出現頻率的大小以及測試的需要，確定權值的大小。
③ 利用正交表構造測試資料集
正交表的推到過程根據Galois理論，在一些數理統計的書籍裡可以查閱到相應的正交表。在正交表中，每一列表示一個因子，每行表示一個專案，當因子數確定下來後，相應的正交表就可以確定了。

<8>功能圖法

功能圖法是用功能圖形象地表示程式的功能說明，並機械地生成功能圖的測試用例，功能圖方法是一種黑盒白盒混合用例設計方法。
程式功能說明包括動態說明和靜態說明。
動態說明：描述輸入資料的次序或轉移次序。
靜態說明：描述輸入條件和輸出條件之間的對應關係。

功能圖模型由狀態遷移圖（動態說明）和邏輯功能模型（靜態說明）構成。

狀態遷移圖：用於表示輸入資料序列以及相應的輸出資料；由輸入資料和當前狀態決定輸出資料和後續狀態。  

 邏輯功能模型：用於表示在狀態中輸入條件和輸出條件的對應關係。由輸入資料決定輸出資料。此模型只適用於描述靜態說明。

生成測試用例的方法是：
狀態遷移圖：從狀態遷移圖中選取測試用例，用節點代替狀態，用弧線代替遷移，狀態圖就可轉化成一個程式的控制流程圖的形式，並且在狀態的遷移中，也定義三種結構：順序，選擇和重複。
邏輯功能模型：在每個狀態中，由滿足輸入資料和對應的輸出資料組成。
生成的測試用例由兩部分組成：
（1）狀態遷移的測試用例（測試路徑）
（2） 邏輯模型的測試用例（區域性測試用例）。
功能圖生成測試用例步驟如下(4點)：

 ① 生成區域性測試用例：在每個狀態中，從因果圖生成區域性測試用例；

 ② 測試路徑生成：利用上面的規則生成從初始狀態到最後狀態的測試路徑；

③ 測試用例合成：合成測試路徑與功能圖中每個狀態的區域性測試用例。結果是初始狀態到最後狀態的一個狀態序列，以及每個狀態中輸入資料與對應輸出資料的組合；

 ④ 採用條件構造樹測試用例的合成演算法。

2.2.2 非功能測試（9個）

<1>強度測試

強度測試是驗證軟體的效能在各種極端的周邊環境和系統條件下是否能正常工作，也就是驗證軟體的效能在各種極端的周邊環境和系統條件下的承受能力。
這裡所謂“強度”包括了兩項：一項是超載執行測試，另一項是容量測試。
超（滿）載執行測試：是對軟體在單位時間內所能承受的荷載的極限進行驗證。（文件下載網站）
容量測試：是對軟體系統處理大量資料的能力進行檢驗。（文字編輯軟體 檔案輸送軟體）

<2>效能測試

效能測試通常是驗證軟體的效能在正常環境和系統條件下重複使用時是否還能滿足效能指標，軟體的效能測試是系統測試中難度較大的測試。
軟體系統的效能測試包括：系統反應時間、使用者反應時間、軟體介面反應時間、中央處理器的利用率、檢查系統記憶容量在執行程式時有沒有流失現象（或稱記憶體洩露）等。

<3>安全測試

軟體安全測試是為了檢驗軟體對資料的保密及對資料完整性的測試。可以說，任何的軟體都只是在一定程度上安全而沒有絕對安全的軟體。
一般情況下，軟體的安全檢驗是由專門人員完成的，測試工程師只能從功能檢測的角度去配合。
測試人員在發現問題後，應將問題送交專門人員，由他們判斷到底是軟體設計結構的問題，還是程式設計的問題，或者是使用者方面的設定問題。

<4>安裝與卸裝測試

安裝測試：在安裝過程中，注意測試軟體給使用者的提示是否清楚明瞭、安裝的操作是否容易、安裝過程是否太冗長、各系統設定是否正確、安裝完成後軟體是否能正常運作、安裝過程有沒有干擾計算機中其他的程式等。
卸裝測試：卸裝測試要考慮卸裝過程中，系統的提示是否清楚明瞭、操作是否簡單、卸裝是否徹底、系統設定是否回覆到安裝前狀態等。

<5>配置測試

配置測試主要注意三個方面：
（1）軟體安裝與卸裝過程中系統配置的變化；
（2）是軟體完成安裝後，人為改變配置，軟體 是否有相應的變化；
（3）是硬體的不同組合是否與軟體相容。

<6>相容性測試

相容性測試是針對測試中軟體與其他軟體之間，以及被測試的軟體與不同硬體之間的相容性進行的測試。
它包括該軟體本身不同版本之間、該軟體與其他不同版本軟體之間、不同版本硬體之間的相容性測試。

如果軟體的使用者手冊上標示該軟體與另外幾種軟體、硬體相容，那麼就一定要做相容性測試，應包括以下這些：
（1） 作業系統相容
並非所有的軟體都具有平臺無關性。
（2）硬體相容
軟體在不同硬體環境下執行結果是否一樣。

（3）軟體相容
與支援軟體或同機執行的其它常用軟體之間會不會有衝突，造成一方出現不正常現象。
（4）資料庫相容
軟體對不同資料庫平臺的支援能力，在需要轉換到其它平臺的情況下，軟體是否可以直接掛接，或者提供相關的轉換工具，還是必須重新開發或需較大改動。
（5）資料相容
不同形式資料之間及新舊資料之間的相容。

<7>故障修復測試

故障修復測試是為了保證軟體無論在遇到特殊事故或任何出錯的情況下，一旦故障排除，即能迅速恢復到事故或出錯前的狀況，繼續正常執行。
測試人員可用各種方法使軟體出錯，觀察軟體的反應，然後排錯，看看軟體是否會恢復到原來的狀態並正常工作。這一測試技術廣泛應用於檔案傳輸軟體、資料庫的相關軟體的測試中。
（檔案傳輸軟體，傳輸過程中網路中斷）

<8>使用效能測試

使用效能測試從使用者的角度去審視及改進軟體，從而保證了軟體的使用效能。
使用效能測試一般是由使用者實現的，通常情況下，由於使用者接觸該軟體的時間不長，因而需要在測試人員或技術人員的協助下進行。
很多時候，該類測試是通過Alpha及Beta 測試來實現的。

<9>幫助選單及使用者說明測試

軟體的幫助菜單系統及使用者說明書是最容易被測試部門忽略的。大家都集中精力測試軟體的各部分功能，但不要忘記，幫助菜單系統及使用者說明書也會有許多錯誤出現，對這部分的測試應該一併列入測試工作中。
測試幫助選單及使用者說明書，很重要的是對其使用效能進行測試，也就是從使用者的角度來檢驗使用的方便程度及其可靠性、準確性。

2.2.3 黑盒測試策略

在實際測試中，往往是綜合使用各種方法才能有效提高地提高測試效率和測試覆蓋率，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效地提高測試水平。
以下是功能測試部分的各種黑盒測試方法的綜合選擇的策略（共8條）。
① 首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效的方法。
② 在任何情況下都必須使用邊界值分析方法。經驗表明，用這種方法設計出的測試用例發現程式錯誤的能力最強。
③ 可以用錯誤推測法追加一些測試用例，這需要依靠測試工程師的智慧和經驗。
④ 對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。
⑤ 如果程式的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法和判定表驅動法。
⑥ 對於引數配置類的軟體，要用正交試驗法選擇較少的組合方式達到最佳效果。
⑦ 功能圖法也是很好的測試用例設計方法，我們可以通過不同時期條件的有效性設計不同的測試資料。
⑧ 對於業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。