軟體測試黑盒

這是個老生長談的話題了。多少人看不起的用例，多少人不會寫的用例，多少人覺得無聊的手工測試。記得之前一個朋友說，測試用例是一個測試人員非常重要的技能之一，十分贊同。

試想如果手工測試發現不了問題，那麼基於測試用例轉換的自動化測試，又怎麼能幫我們發現更多的問題呢？雖然自動化測試的定義更多的是幫助我們回歸併且驗證核心功能是否受到影響。

總而言之，測試用例是測試工作的核心，是測試活動開展的重要依賴，是基線測試覆蓋的重要支撐。今天主要跟大家分享黑盒測試用例設計方法。

黑盒測試的測試用例設計方法

· 等價類劃分方法

· 邊界值分析方法

· 錯誤推測方法· 因果圖方法· 判定表驅動分析方法· 正交實驗設計方法· 功能圖分析方法

等價類劃分：

等價類方法：是把程序的輸入域劃分成若干部分/等價類；然後從每個部分/等價類中選取少數或一個代表性數據作為測試用例，（ps：假設每一類的代表性數據在測試中的作用等價於這一類中的其他值）。

有效等價類 :對程序規格有效的、合理的輸入數據的集合；程序接收到有效等價類，可以正確計算、執行。

無效等價類：對程序規格無效的、不合理的輸入數據的集合；程序接收到無效等價類，應該給出錯誤提示，或者根本不允許輸入。

設計測試用例時，要同時考慮這兩種等價類。

劃分等價類的方法：下面給出六條確定等價類的原則。

1、如果輸入條件規定了取值範圍，或者是值得個數，則可以確立一個有效等價類和兩個無效等價類。

例如：序號值可以從1到999。

一個有效等價類：1<=序號值<=999

兩個無效等價類：序號值<1,序號值>999

2、如果輸入條件規定了輸入值的集合，或者是規定了「必須如何」的條件，可確立一個有效等價類和一個無效等價類。

例如：在C語言中對變數標識符規定為「以字母打頭的」。

所有字母打頭的構成有效等價類

不在此集合內的為無效等價類

3、如果輸入條件是布爾量，確立一個有效等價類和一個無效等價類

例如：0和1，是和非

4、如果規定了輸入數據是一組值，而且程序要對每個輸入值分別進行處理，這時可為每一個輸入值確立一個有效等價類，此外再針對這組值確立一個無效等價類，它應是所有不允許輸入值的集合。

例如：在規定教師分房方案中對教授、副教授、講師和助教分別計算分數，然後做處理。

四個有效等價類為：教授、副教授、講師、助教

一個無效等價類，即所有不符合以上四個的集合

5、如果規定了輸入數據必須遵守的規則，則可以確立一個有效等價類（符合的），和若干無效等價類（以不同角度違反規則）。

例如：在C語言中，規定「一個語句必須以分號『；』結束」。

一個有效等價類：以「；」結束

若干無效等價類：以「；，.」等符號結束

6、如果確定以劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分為更小的等價類。

每一個無效等價類至少要用一個測試用例，否則就有可能漏掉某一類錯誤，但允許若干個有效等價類合用同一個測試用例，以便進一步減少測試次數。

設計測試用例：按以下三個原則設計測試用例：

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

邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。

（1）邊界值分析方法的考慮：使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

（2）基於邊界值分析方法選擇測試用例的原則：

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

錯誤推測法：錯誤推測法發是根據經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設計測試用例的方法。

因果圖方法

適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。

因果圖方法最終生成的就是判定表。它適合於檢查程序輸入條件的各種組合情況。

利用因果圖生成測試用例的基本步驟：

（1）分析軟體規格說明描述中，那些是原因（即輸入條件或輸入條件的等價類），那些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。

（2）分析軟體規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關係。根據這些關係，畫出因果圖。

（3）由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不不可能出現。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。

（4）把因果圖轉換為判定表。

（5）把判定表的每一列拿出來作為依據，設計測試用例。

從因果圖生成的測試用例（局部，組合關係下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而線性地增加。

判定表（DECisionTable）是分析和表達多邏輯條件下執行不同操作的情況下的工具。在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了。由於它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。

判定表驅動分析方法

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

條件樁（ConDItion STub）：列出了問題得所有條件。通常認為列出得條件的次序無關緊要。動作樁（Action Stub）：列出了問題規定可能採取的操作。這些操作的排列順序沒有約束。條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。動作項（Action Entry）：列出在條件項的各種取值情況下應該採取的動作。

規則：任何一個條件組合的特定取值及其相應要執行的操作。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。

判定表的建立步驟：（根據軟體規格說明）

① 確定規則的個數。假如有n個條件。每個條件有兩個取值（0，1），故有種規則。

② 列出所有的條件樁和動作樁。

③ 填入條件項。

④ 填入動作項。等到初始判定表。⑤ 簡化、合併相似規則（相同動作）。適合使用判定表設計測試用例的條件：① 規格說明以判定表形式給出，或很容易轉換成判定表。② 條件的排列順序不會也不影響執行哪些操作。③ 規則的排列順序不會也不影響執行哪些操作。④ 每當某一規則的條件已經滿足，並確定要執行的操作後，不必檢驗別的規則。⑤ 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。

測試方法的選擇

· 在任何情況下都應該使用邊界值分析方法

· 必要時用等價類劃分法補充測試方法

· 必要時再用錯誤推測法補充測試方法

· 對照程序邏輯，檢查已經設計出的測試方案

一個好的測試用例描述為具有相當高的可能性發現某個錯誤來，此外，還應具備以下兩個特性：

1）嚴格控制測試用例的增加，減少為達到「合理測試」的某些既定目標而必須設計的其他測試用例的數量。

2）它覆蓋了大部分其他可能的測試用例。也就是說，它會告訴我們，使用或不使用這個特定的輸入集合，哪些錯誤會被發現，哪些會被遺漏掉。

關注51Testing軟體測試網，提升it技能，從不會到熟練只差一步。