[筆記] 黑箱測試入門：標準流程(SOP)與七大方法

當測試人員看不到內部情況的時候，同常會採用黑箱測試（Black-Box Testing） 確保品質。透過使用者的視角，不窺探內部程式碼，僅根據軟體規格來驗證其功能是否符合預期。

我查閱了多本書籍與網路資料，透過AI 做成標準作業流程（SOP），再深入解析流程中提到的七種核心測試技術，未來除了給自己參考之外，也想作為LLM的prompt。

第一章：專業黑箱測試的標準作業流程 (SOP)

步驟一：測試前的準備工作 (前置檢查清單)

在撰寫任何測試案例之前，請先確保以下項目都已準備就緒：

步驟二：系統化的核心執行流程

準備工作完成後，即可依照以下流程執行測試：

1. 界定測試範圍與目標：依據已核准的規格文件，確認本次測試的具體功能範疇、目標屬性（例如：功能性、可靠性），並確認測試目標（例如：最大化發現錯誤、驗證需求符合度）。
2. 分析需求與設計測試案例：系統性地設計一組非冗餘且高錯誤偵測率的測試案例。
   • 主要方法：等價類劃分 (Equivalence Partitioning)、邊界值分析 (Boundary Value Analysis)。
   • 輔助方法：因果圖法 (Cause-Effect Graphing)、決策表 (Decision Tables)、狀態轉換測試 (State Transition Testing)、錯誤猜測 (Error Guessing)、所有配對測試 (All-Pair Testing)。
3. 準備並驗證測試環境：根據測試案例的前置條件，載入所需資料、設定系統參數，並確保測試環境處於可預期的初始狀態。
4. 執行測試案例：依照測試程序，透過使用者介面 (UI) 或應用程式介面 (API) 輸入已設計的測試資料。
5. 記錄實際輸出與系統行為：詳盡、準確地記錄每次測試執行的實際輸出結果、系統回應及任何異常現象。
6. 比對與分析結果：將記錄的「實際結果」與測試案例中預先定義的「預期輸出」進行嚴格比對。
7. 識別並記錄不一致性：若實際結果與預期結果存在任何偏差，則判定為一次 「成功的測試」（發現潛在缺陷），並立即啟動缺陷提報流程。

步驟三：產出與缺陷提報標準

測試的價值在於其產出。一個完整的測試週期應包含以下文件，並遵循標準化的缺陷提報格式。

• 必需文件

  1. 測試案例庫 (Test Case Repository)：儲存所有設計的測試案例，包含輸入與預期輸出，作為回歸測試與未來複用的基礎。
  2. 測試執行紀錄 (Test Execution Log)：詳實記錄每個測試案例的執行歷史，包含執行者、日期、版本、實際結果及通過/失敗狀態。
  3. 測試摘要報告 (Test Summary Report)：彙總測試活動的整體結果，評估軟體品質，並提供是否進入下一階段的建議。
  4. 異常/缺陷報告 (Anomaly/Defect Report)：針對所有已識別的不一致性，建立獨立的追蹤報告。

• 缺陷提報標準 一份標準的缺陷報告必須包含以下五個核心要素，以利快速定位與修復問題：

  1. 缺陷標題：清晰、簡潔地描述問題的現象。
  2. 重現步驟 (Steps to Reproduce)：提供一個能穩定重現該缺陷的詳細步驟列表。
  3. 預期結果 (Expected Result)：根據規格，描述在此步驟下軟體應有的正確行為。
  4. 實際結果 (Actual Result)：描述軟體實際發生的錯誤行為或輸出。
  5. 環境資訊 (Environment Information)：提供測試時的軟體版本、作業系統、硬體規格及其他相關配置。

第二章：黑箱測試核心技術深度解析

在上面的執行流程中，我們提到了多種測試設計方法。現在，讓我們深入了解這些強大的技術是什麼，以及如何應用它們。

1. 等價類劃分 (Equivalence Partitioning)

什麼是等價類劃分？

一種將所有可能的輸入資料劃分為若干個「等價類」的技術。其核心假設是，同一等價類中的任何一個輸入資料，對於揭露程式錯誤而言，其效果是相同的。測試時，只需從每個等價類中選取一個代表性的資料即可，從而大幅減少測試案例的數量。

等價類可分為 「有效等價類」（符合規格的輸入）和 「無效等價類」（不符合規格的輸入）。

程式案例

假設一個函式用於驗證使用者年齡，合法年齡範圍為 18 至 60 歲。

1
2
3
4
5
6

def is_age_valid(age: int) -> bool:
    """檢查年齡是否在 18 到 60 歲之間"""
    if 18 <= age <= 60:
        return True
    else:
        return False

測試案例設計：

• 有效等價類: 18 <= age <= 60
  • 測試案例：輸入 35，預期結果：True。
• 無效等價類 1: age < 18
  • 測試案例：輸入 10，預期結果：False。
• 無效等價類 2: age > 60
  • 測試案例：輸入 70，預期結果：False。

適用情境

• 當輸入域非常大或包含無限可能時（例如：任意整數、字串）。
• 適用於處理具有明確輸入範圍或分類的功能。
• 作為減少冗餘測試案例、提高測試效率的基礎方法。

不適用情境

• 單獨使用時，容易忽略邊界條件的錯誤。它需要與 「邊界值分析」 結合使用。
• 對於輸入之間存在複雜邏輯組合的情況，效果有限。

2. 邊界值分析 (Boundary Value Analysis)

什麼是邊界值分析？

一種基於經驗的測試技術，即大量的程式錯誤發生在輸入值的 「邊界」 上，而非範圍的中央。此方法專注於測試輸入域的邊緣、剛好在邊緣內和剛好在邊緣外的點。

程式案例

延續上述的年齡驗證函式，其邊界為 18 和 60。

1
2
3
4
5
6

def is_age_valid(age: int) -> bool:
    """檢查年齡是否在 18 到 60 歲之間"""
    if 18 <= age <= 60:
        return True
    else:
        return False

測試案例設計：

• 最小值邊界:
  • 測試案例 1：輸入 17 (略低於最小值)，預期結果：False。
  • 測試案例 2：輸入 18 (等於最小值)，預期結果：True。
  • 測試案例 3：輸入 19 (略高於最小值)，預期結果：True。
• 最大值邊界:
  • 測試案例 4：輸入 59 (略低於最大值)，預期結果：True。
  • 測試案例 5：輸入 60 (等於最大值)，預期結果：True。
  • 測試案例 6：輸入 61 (略高於最大值)，預期結果：False。

適用情境

• 任何具有明確數值範圍、順序或長度限制的輸入。
• 非常適合用於發現 「差一錯誤」(Off-by-one errors)。
• 作為等價類劃分的補充，是投資報酬率極高的測試方法。

不適用情境

• 對於沒有明確邊界的輸入（例如：枚舉值、布林值），此方法不適用。
• 無法有效處理多個輸入參數之間的組合性缺陷。

3. 決策表 (Decision Tables)

什麼是決策表？

一種將複雜的業務規則和邏輯組合以表格形式呈現的系統化方法。決策表包含「條件」（Conditions）和「動作」（Actions），表的每一欄代表一個業務規則，即一組條件的組合會觸發哪些對應的動作。

程式案例

假設一個電商網站的折扣規則如下：

1. 若是 VIP 會員，則打 9 折。
2. 若訂單金額滿 1000 元，也打 9 折。
3. 若同時是 VIP 且訂單滿 1000 元，則打 8 折。
4. 其他情況不打折。

決策表：

每個規則（R1-R4）都可直接轉換為一個測試案例。

適用情境

• 當系統功能包含大量複雜、有交集的業務規則時。
• 需要確保所有邏輯組合都被完整覆蓋的場景。
• 輸入條件與最終執行的動作之間有明確的因果關係。

不適用情境

• 對於業務邏輯簡單、沒有太多條件組合的功能，使用決策表會過於繁瑣。
• 當系統行為與「順序」或「狀態」相關時，狀態轉換測試 更為合適。

4. 狀態轉換測試 (State Transition Testing)

什麼是狀態轉換測試？

一種用於測試 「有限狀態機」 的技術。它關注系統如何根據不同的事件（或輸入）從一個狀態轉變到另一個狀態，以及在轉換過程中會觸發哪些動作。測試的目標是覆蓋所有有效的狀態和轉換。

程式案例

一個簡單的 ATM 提款機有以下狀態：待機、已插卡、已輸入密碼、交易完成。

狀態轉換圖 (簡化):

• 待機 –(插入提款卡)–> 已插卡
• 已插卡 –(輸入正確密碼)–> 已輸入密碼
• 已插卡 –(輸入錯誤密碼)–> 待機 (退卡)
• 已輸入密碼 –(執行提款)–> 交易完成
• 交易完成 –(退出)–> 待機 (退卡)

測試案例設計：

• 測試案例 1 (成功流程): 插入提款卡 -> 輸入正確密碼 -> 執行提款 -> 退出。驗證每一步的狀態是否正確。
• 測試案例 2 (密碼錯誤): 插入提款卡 -> 輸入錯誤密碼。驗證是否退卡並回到 待機 狀態。

適用情境

• 適用於任何 「有記憶」 的系統，其當前行為取決於過去的事件和狀態。
• 例如：使用者登入狀態、訂單處理流程、工作流程引擎、通訊協定等。

不適用情境

• 對於 「無狀態」 的系統，即每次的輸出僅取決於當前的輸入，而與歷史無關。例如一個簡單的計算機。

5. 因果圖法 (Cause-Effect Graphing)

什麼是因果圖法？

一種更形式化的技術，用於分析和視覺化輸入條件（因）與輸出結果（果）之間的複雜邏輯關係。它使用圖形符號（如 AND, OR, NOT）來表示規格文件中的語義，最終目的通常是為了導出決策表，以生成測試案例。

程式案例

與決策表的案例相似，但更強調圖形化的分析過程。例如，規格描述：「當使用者點擊’儲存’按鈕時，如果’檔案未變更’或’使用者無權限'，則系統應’顯示錯誤訊息'。」

• 因 (Causes): C1=點擊儲存, C2=檔案未變更, C3=使用者無權限
• 果 (Effect): E1=顯示錯誤訊息

邏輯圖: C1 AND (C2 OR C3) -> E1

此圖可以幫助分析師系統性地找出觸發 E1 的所有組合，並轉換為決策表來設計測試案例。

適用情境

• 當需求規格是用自然語言描述，且其中包含大量邏輯詞（如 if, and, or, not）時。
• 作為從複雜文字需求到結構化決策表的橋樑。

不適用情境

• 對於簡單的邏輯，直接使用決策表或等價類劃分更有效率。
• 繪製和分析因果圖本身可能非常耗時，對於敏捷開發的快速迭代可能不適合。

6. 錯誤猜測 (Error Guessing)

什麼是錯誤猜測？

一種非系統化的、依賴測試人員 直覺、經驗和專業知識 的測試技術。測試人員會「猜測」開發者可能犯的錯誤或系統的薄弱環節，並為此設計專門的測試案例。

程式案例

針對一個檔案上傳功能：

1
2
3

def upload_file(file_path: str):
    # ... 處理檔案上傳的邏輯 ...
    pass

測試案例設計 (猜測):

• 輸入一個不存在的 file_path。
• 上傳一個 0 KB 的空檔案。
• 上傳一個超出系統限制大小的檔案（例如 2GB）。
• 上傳一個檔名包含特殊字元（如 *, ?, /）的檔案。
• 在檔案上傳過程中，中斷網路連線。
• 輸入 null 或空字串作為 file_path。

適用情境

• 作為對其他系統化測試方法的補充，用於發現 「意料之外」 的錯誤。
• 在時間有限的情況下，由經驗豐富的測試人員執行，可以快速找到高風險區域的缺陷。

不適用情境

• 不能作為唯一的測試方法，因为它沒有明確的覆蓋率指標，無法保證測試的完整性。
• 測試效果高度依賴測試人員的個人能力，難以複製和標準化。

7. 所有配對測試 (All-Pair Testing / Pairwise Testing)

什麼是所有配對測試？

一種組合測試技術，旨在用最少的測試案例來覆蓋所有輸入參數的 「兩兩組合」。其理論基礎是，系統中的大多數錯誤是由單一參數或最多兩個參數之間的交互作用引起的。

程式案例

假設一個文件編輯器有以下文字格式選項：

• 字體 (Font): Arial, Times, Verdana (3個選項)
• 大小 (Size): 10, 12, 14 (3個選項)
• 顏色 (Color): 紅, 藍, 黑 (3個選項)
• 對齊 (Alignment): 左, 中, 右 (3個選項)

如果要測試所有可能的格式組合，總共需要 3 * 3 * 3 * 3 = 81 組測試案例，這在實務上幾乎不可行。

若改用「所有配對測試」，目標則是用最少的案例覆蓋所有選項的「兩兩組合」（例如，[Arial, 10]、[12, 紅]、[黑, 右對齊] 都必須至少出現一次）。使用配對測試工具可以生成如下的精簡測試集：

在這個例子中，測試案例的數量從 81 個驟減到 9 個。我們無需執行全部 81 次測試，只需這 9 次就能覆蓋所有參數兩兩之間的組合，在保證足夠測試覆蓋率的同時，極大地提升了測試效率。

適用情境

• 當被測系統有多個獨立的輸入參數或配置選項，而進行全組合測試不切實際時。
• 非常適合用於測試軟體的配置組合、API 參數組合等。

不適用情境

• 當已知或高度懷疑錯誤是由三個或更多參數的特定交互作用引起時。
• 如果參數數量很少，全組合測試是可行的，且能提供更強的信心。