測試基礎是每位測試工程師必須掌握的核心知識，包含測試金字塔、用例設計方法、覆蓋率分析等關鍵概念。

測試金字塔#

測試金字塔是一種測試策略模型，描述了不同類型測試的比例關係：

flowchart TB
    subgraph pyramid[" "]
        direction TB
        E2E["🔺 E2E 測試<br>數量最少 | 成本最高 | 速度最慢"]
        INT["🔷 整合測試<br>數量中等 | 成本中等 | 速度中等"]
        UNIT["🟩 單元測試<br>數量最多 | 成本最低 | 速度最快"]
    end

    E2E --- INT
    INT --- UNIT

三層測試的特點#

最佳實踐比例：單元測試 70%、整合測試 20%、E2E 測試 10%。這個比例確保了快速反饋的同時，也覆蓋了關鍵業務場景。

測試分類#

按測試階段分類#

flowchart LR
    A[單元測試<br>開發階段] --> B[整合測試<br>模組整合]
    B --> C[系統測試<br>完整系統]
    C --> D[驗收測試<br>交付確認]

按測試方法分類#

按測試類型分類#

功能性測試：

• 單元測試、整合測試、系統測試、回歸測試

非功能性測試：

• 效能測試、安全測試、兼容性測試、可靠性測試

非功能性需求往往是決定軟體品質的關鍵因素。一個完整的測試策略必須同時覆蓋功能性和非功能性需求。

測試用例設計方法#

什麼是「好的」測試用例？#

核心觀點：「好的」測試用例是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而與能否發現缺陷無關。

池塘捕魚的比喻：

如果把被測軟體看作池塘，軟體缺陷是池塘中的魚，建立測試用例集的過程就像是在編織漁網。好的測試用例集是一張能覆蓋整個池塘的大漁網，只要池塘裡有魚，這張網就一定能撈到。

好的測試用例的三個特徵#

1. 整體完備性：有效測試用例組成的集合，能完全覆蓋測試需求
2. 等價類劃分的準確性：每個等價類中任一輸入測試通過，其他輸入也測試通過
3. 等價類集合的完備性：所有可能的邊界值和條件都已正確識別

等價類劃分#

等價類劃分是將所有可能的輸入資料劃分成若干子集，每個子集中的任意輸入對於揭露缺陷具有同等效果。

示例：考試成績輸入#

假設成績取值範圍 0-100，及格分數線 60：

關鍵點：等價類劃分不僅要找出有效等價類，更要完整識別所有無效等價類。

邊界值分析#

邊界值分析是對等價類劃分的補充，因為大量錯誤發生在輸入輸出的邊界上。

選取邊界值的原則#

選取正好等於、剛剛大於、剛剛小於邊界的值作為測試資料。

示例：考試成績的邊界值#

邊界值集合：-1, 0, 1, 59, 60, 61, 99, 100, 101
             ↑   ↑  ↑   ↑   ↑   ↑   ↑   ↑    ↑
            最小  |  最小+1    |  及格+1    |  最大+1
           邊界-1 最小邊界  及格邊界   最大-1  最大邊界

錯誤推測法#

基於對被測軟體的理解、過往經驗及個人直覺，推測可能存在的缺陷。

常見的錯誤推測場景#

降低個人依賴：建立常見缺陷知識庫，在測試設計過程中作為 checklist 使用。

測試覆蓋率#

測試覆蓋率用來衡量測試的充分性和完整性。

覆蓋率類型#

程式碼覆蓋率指標#

// 示例程式碼
public String getGrade(int score) {
    if (score >= 60) {           // 判定點
        if (score >= 90) {       // 判定點
            return "優秀";
        }
        return "及格";
    }
    return "不及格";
}

覆蓋率的局限性：高程式碼覆蓋率不一定保證軟體品質。程式碼覆蓋率基於現有程式碼，無法發現「未考慮某些輸入」或「未處理某些情況」的缺陷。

覆蓋率的價值#

高覆蓋率 ≠ 高品質
低覆蓋率 = 一定有測試盲區

覆蓋率的真正價值：
1. 找出潛在的遺漏測試用例
2. 識別不可達的廢棄程式碼
3. 為補充測試用例提供依據

從需求到用例的映射#

flowchart LR
    A[業務需求<br>用戶目標] --> B[軟體功能需求<br>系統功能]
    B --> C[測試需求<br>測試點]
    C --> D[測試用例<br>具體測試]

用例設計的關鍵點#

1. 全面識別測試需求：從功能需求出發，無遺漏地識別測試需求
2. 綜合運用三種方法：等價類劃分 + 邊界值分析 + 錯誤推測

設計好用例的三個秘籍#

深入理解被測軟體的架構：不能把被測系統看作大黑盒，必須了解資料庫連線、讀寫分離、訊息中間件、快取系統等。

1. 深入理解架構：設計出「有的放矢」的測試用例集
2. 深入理解實現細節：避免只覆蓋「表面」
3. 引入覆蓋率指標：需求覆蓋率和程式碼覆蓋率衡量完備性

切記：不要以開發程式碼的實現為依據設計測試用例。開發程式碼的錯誤會導致測試用例也出錯，應該根據原始需求設計測試用例。