《軟件測試的藝術》第四章 測試用例的設計

• • 4.0 前言
  • 4.1 白盒測試
  • • 邏輯覆蓋測試
    • • 語句覆蓋
      • 判定覆蓋/分支覆蓋
      • 條件覆蓋
      • 判定/條件覆蓋
      • 多重條件覆蓋
  • 4.2 黑盒測試
  • • 4.2.1 等價劃分
    • • 4.2.1.1 確定等價類
      • 4.2.1.2 生成測試用例
    • 4.2.2 邊界值分析
    • 4.2.3 因果圖
  • 4.3 錯誤猜測
  • 4.4 測試策略
  • 4.5 小結

4.0 前言

本書第二章已經證明窮舉的黑盒和白盒測試通常是不可能的，但同時也建議：將這兩種測試的要素組合起來得到一種合理的測試策略。 我們可以通過使用特定的面向黑盒測試的測試用例設計方法，而后使用白盒測試方法對程序的邏輯結構進行檢查以補充這些測試用例，借此來設計出一個相當嚴格的測試。

4.1 白盒測試

白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構（源代碼）的程度。

邏輯覆蓋測試

下圖是一個普通的程序流程圖，其中有兩個判定語句和兩個復制語句，以及四條路徑L1：ace，L2：abd，L3：abe，L4：acd。

語句覆蓋

語句覆蓋每條語句至少執行一次。

我們可以創建一個測試用例（2，0，4）使得覆蓋圖中所有的語句（包括判定語句和賦值語句），也就是走L1路徑，它并沒有覆蓋所有的路徑，因此語句覆蓋的覆蓋程度最低。

判定覆蓋/分支覆蓋

判定覆蓋又稱分支覆蓋，它不僅每個語句執行一次，而且每個判斷都必須有“是”和“否”的結果、每個入口點（包括ON單元）都必須至少被調用一次。判定覆蓋通常可以滿足語句覆蓋，但是仍然有至少三種例外情況：

• 程序中不存在判斷
• 程序或子程序/方法有多重入口點。只有從程序的特定入口點進入時，某條特定的語句才能執行到。
• 在ON單元里的語句。遍歷每條分支路徑并不一定能確保所有的ON單元都能執行到。

在圖4-1中兩個涵蓋了路徑ace和abd，或涵蓋了路徑acd和abe的測試用例就可以滿足判定覆蓋的要求。如果我們選擇了后一種情況，兩個測試用例的輸入是A=3，B=0，X=3和A=2，B=1，X=1.

條件覆蓋

在條件覆蓋的情況下，要編寫足夠的測試用例以確保將一個判斷中的每個條件的所有可能的結果至少執行一次。因為這并不總能讓每條語句都執行到，因此作為對這條準則的補充就是對程序或子程序，包括ON單元的每一個入口點都至少調用一次。

上圖中的條件取值組合以及測試用例如下：

可以看出來即使條件組合覆蓋比較復雜，但是還沒有覆蓋所有的路徑，因此我們需要覆蓋強度更高的邏輯覆蓋。

判定/條件覆蓋

判定/條件覆蓋將一個判斷中的每一個條件的所有可能的結果至少執行一次，將每個判斷的所有可能的結果至少執行一次，將每個入口點都至少調用一次。

由于邏輯與和邏輯或表達式存在短路的情況，因此，條件覆蓋或者判定/條件覆蓋準則不一定會發現邏輯表達式中的錯誤，因為有的路徑可能根本不會被執行。

多重條件覆蓋

多重條件覆蓋將每個判定中的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。

總的來說，對于包含每個判斷只存在一種條件的程序，最簡單的測試準則就是設計出足夠數量的測試用例，實現：（1）將每個判斷的所有結果都至少執行一次；（2）將所有的程序入口都至少調用一次，以確保全部的語句都至少執行一次。而對于包含多重條件判斷的程序，最簡單的測試準則就是設計出足夠數量的測試用例，將每個判斷的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。

4.2 黑盒測試

基于程序規格說明書黑盒測試的目標是找出程序不符合規格說明書的地方。

4.2.1 等價劃分

一個好的測試用例描述為具有相當高的可能性發現某個錯誤來，因此，當測試某個程序時，我們就被限制在從所有可能的輸入中努力找出某個小的子集，這個子集必須是正確的，并且是可能發信最多錯誤的子集。

確定這個子集的一種方法，就是要意識到一個精心挑選的測試用例還應具備另外兩個特性：

嚴格控制測試用例的增加，減少為達到“合理測試”的某些既定目標而必須設計的其他測試用例的數量。這個特性意味著每個測試用例都必須體現盡可能多的不同的輸入情況，以使最大限度地減少測試所需的全部用例的數量。

它覆蓋了大部分其他可能的測試用例。也就是說，它會告訴我們，使用或不使用這個特定的輸入集合，哪些錯誤會發現，哪些會被遺漏掉。這個特性意味著應該盡量將程序輸入范圍進行劃分，將其劃分為有限數量的等價類，這樣就可以合理地假設測試每個等價類的代表性數據等同于測試該類的其他任何數據。

這兩種思想形成了稱為等價劃分的黑盒測試方法。第二種思想可以用來設計一個“令人感興趣的”輸入條件集合以供測試，而第一個思想可以隨后用來設計涵蓋這些狀態的一個最小測試用例集。

使用等價劃分方法設計測試用例主要有兩個步驟：（1）確定等價類；（2）生成測試用例。

4.2.1.1 確定等價類

確定等價類是選取每一個輸入條件（通常是規格說明中的一個句子或短語）并將其劃分為兩個或更多的組。我們確定了兩類等價類：有效等價類代表對程序的有效輸入，而無效等價類代表的則是其他任何可能的輸入條件（即不正確的輸入值）。

一些指導原則：

如果輸入條件規定了一個取值范圍（例如，“數量可以是從1到999”），那么就應確定出一個有效等價類（1<數量<999）以及兩個無效等價類（數量<1，數量>999）。

如果輸入條件規定了取值的個數（例如，“汽車可登記一至六名車主”），那么就應確定出一個有效等價類和兩個無效等價類（沒有車主，或車主多于六個）。

如果輸入條件規定了一個輸入值的集合，而且有理由認為程序會對每個值進行不同處理，那么就應為每個輸入值確定一個有效等價類和一個無效等價類。

如果存在輸入條件規定了“必須是”的情況，例如“標識符的第一個字符必須是字母”，那么就應該確定一個有效等價類（首字母是字母）和一個無效等價類（首字母不是字母）。

4.2.1.2 生成測試用例

為每個等價類設置一個不同的編號。

編寫新的測試用例，盡可能多地覆蓋那些尚未被覆蓋的有效等價類，直到所有的有效等價類都被測試用例所覆蓋（包含進去）。

編寫新的用例，覆蓋一個且僅一個尚未被涵蓋的無效等價類，直到所有的無效等價類都被測試用例所覆蓋。（用單個測試用例覆蓋無效等價類，是因為某些特定的輸入錯誤檢查可能會屏蔽或取代其他輸入錯誤檢查。）

4.2.2 邊界值分析

所謂邊界條件，是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態。

邊界值分析方法與等價劃分方法的不同：

與從等價類中挑選出任意一個元素作為代表不同，邊界值分析需要選擇一個或多個元素，以便等價類的每個邊界都經過一次測試。

與僅僅關注輸入條件（輸入空間）不同，還需要考慮從結果空間（輸出等價類）設計測試用例。

通用指南：

如果輸入條件規定了一個輸入值范圍，那么應針對范圍的邊界設計測試用例，針對剛剛越界的情況設計無效輸入測試用例。例如，如果輸入值的有效范圍是-1.0至+1.0，那么應針對-1.0,1.0，-1.001和1.001的情況設計測試用例。

如果輸入條件規定了輸入值的數量，那么應針對最小數量輸入值、最大數量輸入值，以及比最小數量少一個、比最大數量多一個的情況設計測試用例。例如，如果某個輸入文件可容納1~255條記錄，那么應根據0、1、255和256條記錄的情況設計測試用例。

對每個輸出條件應用指南1。例如，如果某個程序員按月計算FICA的扣除額，且最小金額是$0.00，最大金額是$1165.25，那么應該設計測試用例來測試扣除$0.00和$1165.25的情況。此外，還應觀察是否可能設計出導致扣除金額為負數或超過$1165.25的測試用例。注意，檢查結果空間的邊界很重要，因為輸入范圍的邊界并不總是能代表輸出范圍的邊界情況。

對每個輸出條件應用指南2。如果某個信息檢索系統根據輸入請求顯示關聯程度最高的信息摘要，而摘要的數量從未超過4條，則應編寫測試用例，是程序顯示0條、1條和4條摘要，還要設計測試用例，導致程序錯誤地顯示5條摘要。

如果程序的輸入或輸出是一個有序序列，則應特別注意該序列的第一個和最后一個元素。

此外，發揮聰明才智找出其他的邊界條件。

4.2.3 因果圖

邊界值分析和等價劃分的一個弱點是未對輸入條件的組合進行分析。對輸入組合進行測試并不是簡單的事情，因為即使對輸入條件進行了等價劃分，這些組合的數量也是個天文數字。如果在選擇輸入條件的子集時沒有采用一個系統的方法，很可能選擇出一個任意的輸入條件子集，這樣會使測試沒有什么成效。

因果圖有助于用一個系統的方法選擇出高效的測試用例集。它還有一個額外的好處，就是可以指出規格說明的不完整性和不明確之處。

因果圖是一種形式語言，用自然語言描述的規格說明可以轉換為因果圖。因果圖實際上是一種數字邏輯電路，但沒有使用標準的電子學符號，而是使用了稍微簡單點的符號。

生成測試用例的過程如下：

將規格說明分解為可執行的片段。

確定規格說明中的因果關系。所謂“因”，是指一個明確的輸入條件或輸入條件的等價類。所謂“果”，是指一個輸出條件或系統轉換（輸入對程序或系統狀態的延續影響）。例如，如果某個事物引起文件或數據庫記錄被修改，那么這種改變就是一個系統轉換，而系統反饋的確認信息就是一個輸出條件。因果關系一旦確定下來，每個“因”和“果”都被賦予一個惟一的編號。

分析規格說明的語義內容，并將其轉換為連接因果關系的布爾圖。這就是所謂的因果圖。

給圖加上注解符號，說明由于語法或環境的限制而不能聯系起來的“因”和“果”。

通過仔細地跟蹤圖中的狀態變化情況，將因果圖轉換成一個有限項的判定表。表中的每一列代表一個測試用例。

將判定表中的列轉換為測試用例。

建立有限項的判定表的過程：

選擇一個“果”（動作）作為當前狀態（1）。

對因果圖進行回溯，查找導致該“果”為1（根據約束條件）的所有“因”的組合。

在判定表中為每個“因”的組合生成一列。

對于每種“因”的組合，判斷其他“果”的狀態，并放置在一列中。

在執行第二步時要做以下考慮：

• 當回溯經過一個結果應為1的or結點時，不要同時將該or結點的一個以上的輸入設置為1。這就是所謂的“路徑敏感性”，其目的是避免由于原因之間的屏蔽而漏掉某些錯誤。

• 當回溯經過一個結果應為0的and結點時，顯然應列出導致結果為0的所有的輸入組合情況。然而，如果碰到的情況是一個輸入為0，其他的輸入中有一個或更多為1，那么就無需羅列出其他輸入可能為1的所有情況。（啥意思？——不必列出所有情況，列出一種使之為1的情況即可）
  

• 當回溯經過一個結果應為0的and結點時，僅有一種所有輸入皆為0的情況需要列舉出來（如果這個and結點位于因果圖的中部，其輸入來自于其他中間結點，那么所有輸入都為0的情況就會非常多）。

示例：


具體如何由因果圖法設計測試用例的實例見此，實例寫的很清楚明白

因果圖方法沒有充分考慮邊界條件，但這并不意味著我們需要為邊界條件重新生成更多的測試用例——我們可以在此過程中嘗試覆蓋邊界條件，即在由因果圖生成測試用例時，可以將邊界條件一并考慮進去。

現在已經有了商業軟件可以幫我們完成從因果圖到判定表的轉化。

4.3 錯誤猜測

錯誤猜測法在軟件測試活動種，人們可以依靠經驗和直覺推測系統種可能存在的各種錯誤，從而有針對性的編寫檢查這些錯誤的列子，這就是錯誤推測法。

基本思想：根據以往的測試經驗和對系統內部的知識的了解，列出系統中各種可能有的錯誤和容易發生的特殊情況，再根據他們來設計測試用例，隨著在產品測試的實踐對產品的了解的加深和測試經驗的豐富，使用錯誤推測法設計的測試用例往往非常有效，可以作為測試設計的一種補充手段，并且積累的經驗越豐富，方法使用效率越高。

4.4 測試策略

一組合理的策略如下：

如果規程說明中包含輸入條件組合的情況，應首先使用因果圖分析法。

在任何情況下都應使用邊界值分析方法。應記住，這是對輸入和輸出邊界進行的分析。邊界值分析可以產生一系列補充的測試條件，但是，也正如“因果圖分析”一節所述，多數甚至全部條件都可以被整合到因果圖分析中。

應為輸入和輸出確定有效和無效等價類，在必要情況下對上面確認的測試用例進行補充。

使用錯誤猜測技術增加更多的測試用例。

針對上述測試用例集檢查程序的邏輯結構。應使用判定覆蓋、條件覆蓋、判定/條件覆蓋或多重條件覆蓋準則（最后一個最為完整）。如果覆蓋準則未能被前四個步驟中確定的測試用例所滿足，并且滿足準則也并非不可能（由于程序的性質限制，某些條件的組合也許是不可能實現的），那么增加足夠數量的測試用例，以使覆蓋準則得到滿足。

4.5 小結

本章介紹了以下幾種測試用例設計方法：

邏輯覆蓋測試。該測試要求程序中的所有判斷都應至少覆蓋一次，同時每一條語句或者入口點都被執行一次。

等價類劃分。通過定義條件和錯誤類來幫助減少測試的工作量。這種劃分假設某分類的一個代表值能夠等價于該分類的所有值或條件。

邊界值分析。測試等價類中每一個分類取邊界值的情況，既要考慮輸入等價類，也要考慮輸出等價類。

因果圖。通過生成布爾圖來詮釋測試用例的可能結果，使用該法旨在幫助選擇那些有效地測試用例達到比較完整的測試用例設計效果。

錯誤猜測。依靠直覺和測試專家經驗來定位程序可能出錯的地方，并由此設計出更高效的測試用例。

總結

以上是生活随笔為你收集整理的《软件测试的艺术》第四章 测试用例的设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。