[軟件測試][黑盒測試][三][學習筆記]（軟件測試黑盒測試實例）

1.黑盒測試的概念

黑盒測試又稱為數據驅動的測試或輸入/輸出驅動的測試。使用這種測試方法時，將程序視為一個黑盒子。測試目標與程序內部機制和結構完全無關，而是將重點集中放在發現程序不按其規范正確運行的環境條件。測試數據完全來源于軟件規范。

2.設計測試用例

2.1.測試用例的定義

設計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設計的預期結果。

如果程序在這種情況下不能正常運行，而且這種問題會重復發生，就代表軟件測試員已經測出了軟件有缺陷，這時候就必須把這個問題標識出來，并通知開發人員。開發人員接到通知后，將這個問題修改完成于下一個測試版本內。

軟件測試員取得新的測試版本后，必須利用同一個用例來測試這個問題，確保該問題已經修改完成。

2.2.測試用例模板和包含的內容

模板通常使用Excel表格完成。測試用例應該包含以下內容：

標識符（測試編號規則TestCase_項目名稱_模塊名稱_功能名稱_0001）：由測試設計過程說明和測試程序說明引用的唯一標識符。

測試項（測試用例的測試目的，一般用一句話表明目的，例如：用瀏覽器打開百度首頁）：描述被測試的詳細特征、代碼模塊等，應該比測試設計說明中所列的特征更加具體。還要指出引用的產品說明書或者測試用例所依據的其他設計文檔。

輸入說明：該說明列舉執行測試用例的所有輸入內容或者條件。

輸出說明：描述進行測試用例預期的結果。

環境要求：是指執行測試用例必要的硬件、軟件、測試工具、人員等。

特殊要求：描述執行測試必須的特殊要求。

用例之間的依賴性：如果一個測試用例依賴于其他用例，或者受其他用例的影響，就應該在此注明。

測試步驟：用最樸實的語言，寫出來軟件的操作步驟，要盡量詳細，例如：在用戶名文本框輸入信息。

測試數據：單獨整合測試數據，必須和測試步驟中的數據保持一致。

預期結果：準確，對象的準確性，內容的準確性，原則上每一個操作，都要有一個結果，在重要的步驟之后，設定預期結果，例如：頁面跳轉到XXX，程序彈出對話框提示，一般和測試目的密切相關，測試目的決定了測試步驟和預期結果。

測試結果：要求在測試執行完成后添加，沒有執行保持為空。測試結果只有成功或失敗。

測試人：測試的執行人，可以和設計者相同，也可以不同。

備注：為了測試用例正常執行而做的特殊準備，例如：網絡不好會有提示。

2.3.設計測試用例的作用

有效性：測試用例是測試人員測試過程中的重要參考依據。

可復用性：良好的測試用例具有重復使用的功能，使得測試過程事半功倍，提高測試效率。

易組織性：即使是小的項目，也可能有幾千甚至更多的測試用例，測試用例可能在數月甚至幾年的測試過程中被創建和使用

可評估性：從測試的項目管理角度來說，測試用例的通過率是檢驗代碼質量的保證。

可管理性：測試用例也可以作為檢驗測試人員進度、工作量以及跟蹤/管理測試人員的工作效率的標準。

2.4.測試用例編寫注意事項

不要設計"窮舉測試用例"

在詳細測試用例與有效測試時間中找到平衡點

好的測試用例應該多關注"反向測試問題"

測試用例庫應該不斷更新和維護

測試用例可以復用，但要注意數據有效性與環境變化

多學習經驗豐富的測試工程師所設計的測試用例

針對不同的需求類型和測試對象，靈活采用不同的測試用例設計方法

3.等價劃分

對程序的窮舉輸入測試是無法實現的，因此，當測試某個程序時，我們被限制在從所有可能的輸入中努力找出某個小的子集。這個子集必須是正確的，并且是可能發現最多錯誤的子集。

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

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

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

第一個特征意味著，每個測試用例都必須體現盡可能多的不同的輸入情況，以最大程度減少測試所需的全部用例的數量。

第二個特征意味著應該盡量將程序輸入范圍進行劃分，將其劃分為有限數量的等價類，這樣就可以合理假設測試每個等價類的代表性數據等同于測試該類的其他任何數據。也就是說，如果等價類的某個測試用例發現了某個錯誤，該等價類的其他用例也應該能發現同樣的錯誤。相反，如果測試用例沒有發現錯誤，那么其他測試用例也不會發現錯誤。

這兩種思想形成了稱為等價劃分的黑盒測試方法。第二種思想可以用來設計一個輸入條件集合以供測試，而第一個思想可以隨后用來設計涵蓋這些狀態的一個最小測試用例集。使用等價劃分法設計測試用例主要有兩個步驟：（1）確定等價類；（2）生成測試用例。

3.1.確定等價類

確定等價類是選取每一個輸入條件（通常是規格說明中的一個句子或短語）并將其劃分為兩個或更多的組。可以用以下表格劃分：

有效等價類代表對程序的有效輸入，無效等價類代表的則是其他任何可能的輸入條件（不正確的輸入值）。在給定了輸入或外部條件之后，確定等價類大體上是一個啟發式的過程。有以下一些原則：

如果輸入條件規定一個取值范圍（數量可以是1到999），那么就應確定一個有效等價類（1≤數量≤999），以及兩個無效等價類（數量＜1，數量＞999）。

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

如果輸入條件規定了一個輸入值的集合，而且有理由認為程序會對每個值做不同處理（交通工具類型必須是公車、卡車、出租車、火車、摩托車），那么就應為每個輸入值確定一個有效等價類和一個無效等價類（拖車）。

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

3.2.生成測試用例

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

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

編寫新的用例，覆蓋一個且僅一個尚未被覆蓋的無效等價類，直到所有的無效等價類都被測試用例所覆蓋。

為什么用單個測試用例覆蓋無效等價類，因為某些特定的輸入錯誤檢查可能會屏蔽或取代其他輸入錯誤檢查。比如，如果規格說明規定了"輸入書籍類型（硬皮、軟皮或活頁）及數量（1-999）"，代表兩個錯誤輸入（書籍類型錯誤，數量錯誤）的測試用例"XYZ 0"，很可能不會執行對數量的檢查，因為程序也會提示"XYZ是未知的書籍類型"，就不檢查輸入的其余部分了。

4.邊界值分析

經驗證明，考慮了邊界條件的測試用例與其他沒有考慮邊界條件的測試用例相比，具有更高的測試回報率。所謂邊界條件，是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態。邊界值分析方法與等價劃分方法存在兩方面的不同：

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

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

4.1.一些通用指南：

如果輸入條件規定了一個輸入值范圍，那么應針對范圍的邊界設計測試用例，針對剛剛越界的情況設計無效輸入測試用例。比如，如果輸入值的有效范圍是-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條摘要。

如果程序的輸入或輸出是一個有序序列（比如順序的文件、線性列表或表格），則應特別注意該序列的第一個和最后一個元素。

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

以分析數值是否能構成三角形為例說明邊界值分析的必要性。作為代表三角形的輸入值，必須是大于0的整數，而且其中任意兩個值和應大于第三個。如果定義了等價劃分，可能會確定一個滿足此條件的等價類，以及另一個兩個輸入之和不大于第三個的等價類。因此，3-4-5和1-2-4都是可能的用例。我們漏了一個可能的錯誤，如果程序中表達式寫成了A+B>=C，而不是A+B>C，那么程序就會錯誤告訴我們1-2-3表示的是一個有效的不規則三角形。因此，邊界值分析方法和等價劃分之間的重要區別是：邊界值分析考察正處于等價劃分邊界或在邊界附近的狀態。

5.因果圖

邊界值分析和等價劃分的一個弱點是未對輸入條件的組合進行分析。因果圖有助于用一個系統的方法選擇出高效的測試用例集。它還有一個額外的好處，就是可以指出規格說明的不完整性和不明確之處。

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

5.1.生成測試用例采用的過程：

將規格說明分解為可執行的片段。這是必須的步驟，因為因果圖不善于處理較大的規格說明。（因為原因和結果很多時，關系連線會很多導致可讀性差，可以用于小功能的分析）

確定規格說明中的因果關系。所謂"因"，是指一個明確的輸入條件或輸入條件的等價類。所謂"果"，是指一個輸出條件或系統轉換（輸入對程序或系統狀態的延續影響）。通過閱讀規格說明，同時標識出描述"因"和"果"的文字或句子，就可以將"因""果"確定。一旦確定因果都被賦予一個唯一的編號。

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

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

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

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

5.2.基本的因果圖符號

例子：第一列中的字符必須是"A"或"B"，第二列中的字符必須是一個數字。在這種情況下，對文件進行更新。如果第一個字符不正確，產生提示X12。如果第二個字符不是數字，產生提示X13。

畫出因果圖如下：

“因”：1，第一列字符是A；2，第一列字符是B；3，第二列字符是一個數字。

“果”：70，對文件做了更新；71，產生提示信息X12；72，產生提示信息X13。

盡管因果圖表示了規格說明，但圖中包含一個不可能的原因組合，即原因1和原因2不可能同時設置為1。在大多數程序中，由于語法或環境的原因，某些原因的組合是不可能存在的（一個字符不能同時為A和B）。所以我們要引入約束符建立約束關系。

約束E（Exclusive）表示其必須總為真，而a和b最多只有一個為1（不能同時為1）。

約束I（Include）表示其為真時，a，b，c中至少有一個應為1（a，b，c不能同時為0）。

約束O（Only）表示a，b中有且僅有一個必須為1。

約束R（Request）表示如果a為1，b也必須為1（a為1，b為0的情況不存在）

約束M（Mask）表示，結果a為0，b也強制為0。

回到上面的例子，原因1和原因2實際上是不可能同時成立的，而兩者同時不成立是可能的。因此它們之間用約束E連接。

6.判定表法

6.1.什么是判定表

判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。有以下幾個內容組成：

條件樁（Condition Stub）：列出了問題的所有條件。通常認為列出的條件的次序無關緊要。

動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。

條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能的情況下的真假值。

動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。

判定表的應用場合：主要適用于多條件的內容組合與結果分析。

判定表的組成：由條件項、條件樁、動作項、動作樁組成。

判定表的使用條件：所有的條件樁在表中的位置和順序相互不影響；所有的動作樁順序不會因為條件順序的變化產生不同

6.2.建立判定表的步驟

確定規則的個數

識別出操作條件（原因）和對應的動作（結果）

分析條件的條件項（組合數量）：如果有n個條件，每個條件有成立和不成立兩種情況，那么最后一共有2^n個數量

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

填入條件項

填入動作項，指定初始判定表

簡化，合并相似規則或相同動作

6.3.判定表使用的實例

需求：訂購單的檢查

如果金額超過500元，又未過期，則發出批準單和提貨單

如果金額超過500元，但由過期了，則不發批準單

如果金額低于500元，則不論是否過期都發出批準單和提貨單，在過期的情況下還需要發出通知單

分析條件和動作

寫入條件樁、動作樁、條件項、動作項

對判定表進行簡化和優化（對其中不合理的內容進行取舍）

不管金額高低，只要未過期，就會發批準單和通知單。

將判定表中的每一列（條件項和對應的動作項）作為測試用例的數據和操作以及對應的預期結果

6.4.適合使用判定表設計測試用例的條件

規格說明以判定表的形式給出，或很容易轉換成判定表

條件的排列順序不影響執行哪些操作

規則的排列順序不影響執行哪些操作

當某一個規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則

如果某一規則要執行多個操作，這些操作的執行順序無關緊要

6.5.測試用例的設計方法：沒有哪一種方式是單獨使用的

所有的軟件，都是因為某種操作才會導致一定的結果，考慮使用因果圖

所有的軟件都有文本框，考慮使用等價類、邊界值

7.正交實驗法

7.1.原理介紹

日本統計學家提出，使用的工具（正交表），統計和分析實驗數據，從大量實驗中找到合適的實驗數據組合。（原本用于工業生產的數據組合與實驗室的數據挑選）。大量實驗組合中，挑選出一部分具有代表性的點，進行試驗，分析數據。

基本思想：在一項實驗中，把影響實驗結果的量稱為實驗因素（因子），簡稱因素。在實驗過程中，每一個因素可以處于不同的狀態或狀況，把因素所處的狀態或狀況，稱為因素的水平，簡稱水平。每列中不同數字出現的次數相等。這一特點表明每個因素的每個水平與其他因素的每個水平參與實驗的概率是完全相同的，能有效地比較實驗結果并找出最優的實驗條件。在任意2列其橫向組成的數字對中，每種數字對出現的次數相等。這個特點保證了實驗點均衡地分散在因素與水平的完全組合之中。

一般的正交表記為

L

n

(

m

k

)

L_n(m^k)

Ln (mk)

m是水平數，k是因素數，n是需要進行實驗的行數

行數：正交表中的行的個數，即試驗的次數，也是通過正交實驗法設計的測試用例的個數

因素數：正交表中列的個數，即要測試的功能點。

水平數：任何單個因素能夠取得的值的最大個數，即要測試功能點的輸入值

正交表種類（各列水平數均相同的正交表，混合水平正交表）

正交表特征（整齊可比，均衡分散）

例如：字體的顯示效果，字體、字號、顏色稱為因素。字體選擇時，可以選擇宋體、楷體、微軟雅黑稱為水平。字號選擇時，稱為水平。顏色選擇時，稱為水平。

數學原理

線性代數

統計學和概率論

數理統計

7.2.實現步驟

確定因素：這里因素是指軟件運行結果有影響的軟件

確定因素的取值范圍或集合

因素的取值范圍是指軟件輸入的取值范圍或集合以及可用的硬件資源

例如：文本框、按鈕等需求中提及或者沒有提及的因素

確定每個因素的水平

根據因素的取值范圍或集合，采用等價類、邊界值分析以及其他軟件測試技術，在每個因素的取值范圍或集合內挑選出有效等價類、無效等價類、正好等于、剛剛大于或剛剛小于邊界值等有代表性的測試值

例如：需求中說明和未說明的概要分析

選擇正交表

根據確定的因素和水平，選擇適合的正交表

如果沒有合適的正交表可用或需要的測試用例太多，要對因素和水平調整

只有特定的因素和水平的組合才有對應的正交表，所以在現實中用到的時候，找最貼近的正交表（正交表的因素和水平一般大于實際的因素和水平）

7.4.相關軟件

正交實驗助手

8.功能圖法

8.1.原理介紹

功能圖又叫狀態遷徙圖

來源：在遇到有事務流或由于某種條件成立導致狀態改變的軟件時，如何進行測試用例的設計就比較麻煩

目標：設計足夠多的測試用例達到對系統狀態的覆蓋、狀態-條件組合的覆蓋以及狀態遷移路徑的覆蓋

8.2.實現步驟

列出所有可能的輸入事件，以input-N的方式命名（N為1，2，3，4等）

把軟件的打開的初始狀態，定義為"空閑"狀態

在"空閑"狀態上加所有可能的輸入（只加一次）

為上一步產生的所有新狀態，分別加所有可能的輸入（只加一次）

循環執行上一步

直到再沒有新狀態產生，列出所有的狀態，生成狀態表

組合任意可能的狀態組合，寫出相應的測試用例

8.3.QQ登錄界面為例

識別出可以進行的操作

input1：輸入賬號

input2：輸入密碼

input3：點擊登錄

input4：點擊關閉按鈕

定義QQ登錄界面為空閑狀態

給空閑狀態加操作（第一輪分析后產生新的狀態）

產生了新的狀態，針對新的狀態進行分析

得到了新的狀態，繼續進行分析

將狀態變化過程進行列表化，準備測試用例

A列：從QQ登錄界面，直接點擊關閉按鈕，QQ退出

B列：從QQ登錄界面，先輸入QQ號（狀態變為QQ已輸入），在輸入密碼（狀態變為QQ號，密碼輸入），點擊登錄，狀態就變為QQ主界面

9.場景法

9.1.場景法基本原理

場景法圖示如下：

現在軟件幾乎都是用事件觸發來控制流程的。測試時，可以生動地描述出事件觸發時的情景，有利于設計測試用例，同時使用測試用例更容易理解和執行。

基本流：軟件功能按照正確的事件流實現的一條正確流程。通常一個業務僅存在一個基本流，且基本流僅有一個起點和一個終點。

備選流：除了基本流之外的各支流，包含多種不同的情況

注意：場景中必須有基本流；場景中必須有內容從用例的開始，到用例的結束

場景列表

場景1：基本流

場景2：基本流 備選流1

場景3：基本流 備選流1 備選流2

場景4：基本流 備選流3

場景5：基本流 備選流4

9.2.場景法設計用例的步驟

根據說明，描述出程序的基本流及各項備選流

根據基本流和各項備選流生成不同的場景

對每一個場景生成相應的測試用例

對生成的所有測試用例重新復審，去掉多余的測試用例

測試用例確定后，對每一個測試用例確定測試數據值

場景法適用于解決業務流程清晰的系統或功能

9.3.場景法設計實例

銀行卡在ATM機取錢

基本流：插卡-輸入密碼-出錢-取卡

備選流：卡片不是銀行卡；卡片不是銀聯卡；密碼輸錯一次；密碼輸錯兩次，第三次輸入正確；密碼輸入錯誤三次，凍結賬號或吞卡；選擇存款服務；選擇查詢服務；選擇轉賬服務；選擇修改密碼服務；選擇取款金額；選擇其他金額；賬戶金額；ATM機沒錢；賬戶取款金額達到取款機當日取款上限；賬戶取款金額達到賬戶當日取款上限；取款機掉線了；取款機停電了

設計測試用例（假定ATM只能識別銀聯卡）：

插卡（Master卡）

換卡（銀聯卡），進行插卡

輸入密碼（第一次輸入錯誤）

再次輸入密碼（第二次輸入錯誤）

第三次輸入密碼（輸入正確）

選擇服務-取款

選擇取出金額-500

等待出鈔

取卡

10.其他用例設計方法

測試大綱法

一種著眼于需求的方法

為列出各種測試條件，將需求轉換為大綱的形式（思維導圖/樹形結構）

無需用例設計，一般從根節點開始，到葉節點為止

一般用于快速的測試和過程記錄，用例一般進行后補

探索性測試法

基于測試人員經驗與直覺的測試方法

是對測試用例設計的有效補充

探索性測試也必須生成測試用例

猴子測試（隨意性測試）

一種沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試

缺點：測試往往不太真實；不能達到一定的覆蓋率；許多測試都是冗余的；需要使用同樣的隨機數才能重建測試

11.用例設計方法綜合選擇

首先進行等價類劃分

在任何情況下都必須使用邊界值分析法

如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法和判定表法

對于參數配置類的軟件，要用正交實驗法選擇較少的組合方式達到最佳效果

狀態遷徙圖也是很好的測試用例設計方法，可以通過不同時期條件的有效性設計不同的測試數據

對于業務流清晰的系統，可以利用場景法貫穿整個測試案例過程

可以用錯誤推測法追加一些測試用例

對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例

自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。