---
source: ../../core/testing-standards.md
source_version: 2.2.0
translation_version: 2.2.0
last_synced: 2026-01-20
status: current
---

# 測試標準

> **語言**: [English](../../../../core/testing-standards.md) | 繁體中文

**版本**: 2.2.0
**最後更新**: 2026-01-20
**適用範圍**: 所有軟體專案

---

## 目的

本標準定義測試慣例與最佳實踐，透過多層級的系統化測試確保軟體品質。

**參考標準**：
- [ISTQB CTFL v4.0](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
- [ISO/IEC/IEEE 29119](https://www.iso.org/standard/81291.html)
- [SWEBOK v4.0](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society

---

## 術語表

本文件中使用的測試術語縮寫快速參考：

| 縮寫 | 全名 | 說明 |
|------|------|------|
| **UT** | Unit Testing（單元測試）| 隔離測試個別函式/方法 |
| **IT** | Integration Testing（整合測試）| 測試元件之間的互動 |
| **ST** | System Testing（系統測試）| 測試完整整合的系統 |
| **AT** | Acceptance Testing（驗收測試）| 根據業務驗收標準測試 |
| **E2E** | End-to-End Testing（端對端測試）| 測試完整的使用者工作流程 |
| **UAT** | User Acceptance Testing（使用者驗收測試）| 由最終使用者執行的驗收測試 |
| **SIT** | System Integration Testing（系統整合測試）| 測試多個系統的整合 |
| **TDD** | Test-Driven Development（測試驅動開發）| 開發方法論：先測試，後編碼 |
| **BDD** | Behavior-Driven Development（行為驅動開發）| 使用自然語言場景的開發方法論 |
| **ATDD** | Acceptance Test-Driven Development（驗收測試驅動開發）| 由驗收標準驅動的開發方法論 |

> **注意**：本文件中的「IT」一律指「Integration Testing（整合測試）」，而非「Information Technology（資訊科技）」。

---

## 目錄

1. [測試基礎](#測試基礎) ⭐ 新增
2. [測試框架選擇](#測試框架選擇)
3. [測試金字塔](#測試金字塔預設業界標準)
4. [測試層級](#單元測試-ut)（UT、IT、ST、E2E）
5. [靜態測試](#靜態測試)
6. [測試設計技術](#測試設計技術)
7. [經驗導向測試](#經驗導向測試)
8. [風險導向測試](#風險導向測試)
9. [專項測試](#專項測試)
10. [測試相關度量](#測試相關度量) ⭐ 新增
11. [缺陷管理](#缺陷管理)
12. [測試流程管理](#測試流程管理)
13. [測試替身](#測試替身)
14. [測試資料管理](#測試資料管理)
15. [測試環境隔離](#測試環境隔離)
16. [CI/CD 整合](#cicd-整合)
17. [最佳實踐](#最佳實踐)
18. [測試文件結構](#測試文件結構) ⭐ 新增

---

## 測試基礎

了解軟體測試的理論基礎對於有效的測試設計和執行至關重要。

**參考來源**：SWEBOK v4.0 第 5 章

### 錯誤 vs 失效

```
┌─────────────────────────────────────────────────────────────┐
│              錯誤、缺陷與失效                                │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Error（錯誤/人為失誤）                                      │
│       │                                                      │
│       ▼ 開發過程中引入                                       │
│  ┌─────────┐                                                 │
│  │  Fault  │ （缺陷/Bug，程式碼中的問題）                   │
│  └─────────┘                                                 │
│       │                                                      │
│       ▼ 執行時                                               │
│  ┌─────────┐                                                 │
│  │ Failure │ （失效，可觀察到的錯誤行為）                   │
│  └─────────┘                                                 │
│                                                              │
│  重點：                                                       │
│  • 缺陷可能存在但不一定導致失效                             │
│  • 失效需要缺陷被執行才會發生                               │
│  • 多個缺陷可能導致相同的失效                               │
│  • 測試發現失效；除錯找出缺陷                               │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### 測試預言問題（Oracle Problem）

**測試預言（Oracle）** 是任何用於判斷程式行為是否正確的機制。測試預言問題探討如何知道預期結果的挑戰。

```
┌─────────────────────────────────────────────────────────────┐
│                    預言類型                                  │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  人工預言                                                    │
│  └── 由領域專家手動驗證                                     │
│                                                              │
│  規格導向預言                                                │
│  └── 與正式需求規格比對                                     │
│                                                              │
│  參考實作                                                    │
│  └── 與已知正確的實作比對                                   │
│                                                              │
│  變形預言（Metamorphic Oracle）                              │
│  └── 驗證輸出之間的關係                                     │
│      （例如：sort(sort(x)) == sort(x)）                     │
│                                                              │
│  統計預言                                                    │
│  └── 驗證是否符合預期分布                                   │
│                                                              │
│  隱式預言                                                    │
│  └── 無當機、無例外、無逾時                                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### 測試的理論限制

> 「程式測試可以用來顯示錯誤的存在，但永遠無法證明錯誤不存在。」— Edsger W. Dijkstra

```
┌─────────────────────────────────────────────────────────────┐
│              測試限制                                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  窮盡測試不可能                                              │
│  ├── 無限的輸入領域                                         │
│  ├── 狀態空間爆炸                                           │
│  └── 時序和並行變化                                         │
│                                                              │
│  不可行路徑                                                  │
│  ├── 某些程式碼路徑無法被任何輸入執行                       │
│  ├── 死碼可能在控制流程圖中看起來可達                       │
│  └── 100% 路徑覆蓋可能在數學上不可能                        │
│                                                              │
│  停機問題                                                    │
│  └── 無法透過演算法判斷所有測試是否會終止                   │
│                                                              │
│  啟示：                                                       │
│  • 測試是抽樣，不是證明                                     │
│  • 風險導向的優先排序至關重要                               │
│  • 在關鍵處結合測試與形式方法                               │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### 可測試性

可測試性衡量軟體能被有效測試的容易程度。

| 因素 | 描述 | 如何改善 |
|------|------|----------|
| **可控制性** | 設定系統狀態進行測試的能力 | 提供測試掛鉤、依賴注入 |
| **可觀察性** | 觀察測試結果的能力 | 增加日誌、暴露內部狀態 |
| **可隔離性** | 獨立測試元件的能力 | 模組化設計、清晰介面 |
| **可理解性** | 預期行為的清晰度 | 良好文件、清晰規格 |
| **穩定性** | 低變更率 | 測試階段前凍結功能 |
| **簡單性** | 低複雜度 | 降低循環複雜度 |

### 測試充分性準則

測試充分性準則回答：「我們測試得夠了嗎？」

```
┌─────────────────────────────────────────────────────────────┐
│              測試充分性準則                                  │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  覆蓋率準則                                                  │
│  ├── 敘述覆蓋率：執行的敘述百分比                           │
│  ├── 分支覆蓋率：走過的分支百分比                           │
│  ├── 條件覆蓋率：評估的條件百分比                           │
│  └── MC/DC：修改條件/決策覆蓋                               │
│                                                              │
│  缺陷準則                                                    │
│  ├── 變異分數：殺死的變異體百分比                           │
│  └── 缺陷植入：找到的植入缺陷百分比                         │
│                                                              │
│  需求準則                                                    │
│  └── 需求覆蓋率：測試的需求百分比                           │
│                                                              │
│  風險準則                                                    │
│  └── 風險覆蓋率：測試的高風險項目百分比                     │
│                                                              │
│  停止規則：                                                   │
│  • 達到目標覆蓋率                                           │
│  • 缺陷發現率降至閾值以下                                   │
│  • 預算/時間用盡（需記錄風險）                              │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

---

## 測試框架選擇

根據專案需求選擇測試框架。本標準支援兩種方法：

### 選項 A：ISTQB 標準框架

最適合企業專案、認證需求和正式 QA 流程。

**參考來源**: [ISTQB Glossary v4.0](https://glossary.istqb.org)

| 層級 | 縮寫 | 目的 |
|------|------|------|
| 單元測試 | UT | 驗證個別程式碼單元 |
| 整合測試 | IT/SIT | 驗證元件互動 |
| 系統測試 | ST | 驗證系統符合需求 |
| 驗收測試 | AT/UAT | 驗證系統符合業務需求 |

**何時選擇 ISTQB**：
- 有正式 QA 流程的企業專案
- 需要認證或合規的專案
- 擁有專門 QA 團隊的組織
- 需要嚴格稽核紀錄的專案

### 選項 B：業界測試金字塔

最適合敏捷開發、CI/CD 優化和快速迭代。

**參考來源**: [Martin Fowler's Testing Pyramid](https://martinfowler.com/bliki/TestPyramid.html), [Google Testing Blog](https://testing.googleblog.com)

| 層級 | 縮寫 | 比例 | 目的 |
|------|------|------|------|
| 單元測試 | UT | 70% | 隔離元件測試 |
| 整合測試 | IT/SIT* | 20% | 元件互動測試 |
| E2E 測試 | E2E | 10% | 使用者工作流程測試 |

*整合測試縮寫說明：
- **IT** (Integration Testing)：敏捷/DevOps 社群常用
- **SIT** (System Integration Testing)：企業/ISTQB 環境常用
- 兩個術語指的是同一個測試層級

**何時選擇業界金字塔**：
- 敏捷/Scrum 開發團隊
- CI/CD 導向環境
- 快速迭代的中小型專案
- DevOps 實踐

---

## 測試金字塔（預設：業界標準）

```
              ┌─────────┐
              │   E2E   │  ← 10%（較少、較慢、成本高）
              │  端對端  │
             ─┴─────────┴─
            ┌─────────────┐
            │   IT/SIT    │  ← 20%（整合測試）
            │    整合測試  │
           ─┴─────────────┴─
          ┌─────────────────┐
          │       UT        │  ← 70%（單元測試 - 基礎）
          │     單元測試     │
          └─────────────────┘
```

### 建議比例（業界金字塔）

| 層級 | 縮寫 | 百分比 | 執行時間 |
|------|------|--------|----------|
| 單元測試 | UT | 70% | 總計 < 10 分鐘 |
| 整合測試 | IT/SIT | 20% | 總計 < 30 分鐘 |
| E2E 測試 | E2E | 10% | 總計 < 2 小時 |

### ISTQB 4 層結構（替代方案）

| 層級 | 縮寫 | 執行者 | 重點 |
|------|------|--------|------|
| 單元測試 | UT | 開發人員 | 程式碼正確性 |
| 整合測試 | IT/SIT | 開發人員/QA | 介面契約 |
| 系統測試 | ST | QA 團隊 | 需求驗證 |
| 驗收測試 | AT/UAT | 終端使用者 | 業務驗證 |

---

## 單元測試 (UT)

### 定義

測試個別函式、方法或類別，與外部相依性隔離。

### 特性

- **獨立**: 不存取資料庫、網路或檔案系統
- **快速**: 每個測試 < 100ms
- **確定性**: 相同輸入永遠產生相同輸出

### 範圍

```
┌─────────────────────────────────────────┐
│              測試單元範圍               │
├─────────────────────────────────────────┤
│  ✅ 單一函式/方法                       │
│  ✅ 單一類別                           │
│  ✅ 純業務邏輯                         │
│  ✅ 資料轉換                           │
│  ✅ 驗證規則                           │
├─────────────────────────────────────────┤
│  ❌ 資料庫查詢                         │
│  ❌ 外部 API 呼叫                      │
│  ❌ 檔案 I/O 操作                      │
│  ❌ 多類別互動                         │
└─────────────────────────────────────────┘
```

### 命名慣例

**檔案命名**:
```
[ClassName]Tests.[ext]
[ClassName].test.[ext]
[ClassName].spec.[ext]

範例:
  UserService.test.ts
  UserServiceTests.cs
  user_service_test.py
  user_service_test.go
```

**方法命名**:
```
[MethodName]_[Scenario]_[ExpectedResult]
should_[ExpectedBehavior]_when_[Condition]
test_[method]_[scenario]_[expected]

範例:
  CalculateTotal_WithDiscount_ReturnsDiscountedPrice()
  should_return_null_when_user_not_found()
  test_validate_email_invalid_format_returns_false()
```

**命名風格選擇指南**:

| 風格 | 最適合 | 範例 |
|------|--------|------|
| `[Method]_[Scenario]_[Result]` | 針對特定方法的單元測試；C#、Java 慣例 | `CalculateTotal_NegativePrice_ThrowsException()` |
| `should_[behavior]_when_[condition]` | BDD 風格測試；行為導向測試；JavaScript/TypeScript | `should_reject_login_when_account_locked()` |
| `test_[method]_[scenario]_[expected]` | Python 慣例；pytest 命名 | `test_validate_email_invalid_format_returns_false()` |

**建議**：每個專案選擇一種風格並在專案的測試慣例中記錄。程式碼庫內的一致性比選擇哪種風格更重要。

### 覆蓋率指引

| 指標 | 最低要求 | 建議 |
|------|----------|------|
| 行覆蓋率 | 70% | 85% |
| 分支覆蓋率 | 60% | 80% |
| 函式覆蓋率 | 80% | 90% |

### 範例

```csharp
// C# 範例
[TestClass]
public class UserValidatorTests
{
    private UserValidator _validator;

    [TestInitialize]
    public void Setup()
    {
        _validator = new UserValidator();
    }

    [TestMethod]
    public void ValidateEmail_ValidFormat_ReturnsTrue()
    {
        // Arrange - 準備
        var email = "user@example.com";

        // Act - 執行
        var result = _validator.ValidateEmail(email);

        // Assert - 斷言
        Assert.IsTrue(result);
    }

    [TestMethod]
    public void ValidateEmail_InvalidFormat_ReturnsFalse()
    {
        // Arrange
        var email = "invalid-email";

        // Act
        var result = _validator.ValidateEmail(email);

        // Assert
        Assert.IsFalse(result);
    }
}
```

```typescript
// TypeScript 範例
describe('UserValidator', () => {
    let validator: UserValidator;

    beforeEach(() => {
        validator = new UserValidator();
    });

    describe('validateEmail', () => {
        it('有效的 email 格式應回傳 true', () => {
            const result = validator.validateEmail('user@example.com');
            expect(result).toBe(true);
        });

        it('無效的 email 格式應回傳 false', () => {
            const result = validator.validateEmail('invalid-email');
            expect(result).toBe(false);
        });
    });
});
```

---

## 整合測試 (IT)

### 定義

測試多個元件、模組或外部系統之間的互動。

### 何時必須有整合測試

| 情境 | 原因 |
|------|------|
| 查詢條件 | Mock 無法驗證過濾表達式 |
| 實體關聯 | 驗證外鍵正確性 |
| 複合主鍵 | 記憶體資料庫行為可能與真實資料庫不同 |
| 欄位映射 | DTO 與 Entity 轉換 |
| 分頁 | 資料排序與計數 |
| 交易 | 回滾行為 |

**判斷規則**:
如果你的單元測試對查詢/過濾參數使用萬用匹配器（`any()`、`It.IsAny<>`、`Arg.Any<>`），該功能必須有整合測試。

### 特性

- **元件整合**: 測試模組邊界
- **真實相依性**: 使用實際資料庫、API（通常容器化）
- **較慢**: 每個測試通常 1-10 秒

### 範圍

```
┌─────────────────────────────────────────┐
│         整合測試範圍                     │
├─────────────────────────────────────────┤
│  ✅ 資料庫 CRUD 操作                    │
│  ✅ Repository + Database               │
│  ✅ Service + Repository                │
│  ✅ API 端點 + Service 層               │
│  ✅ 訊息佇列生產者/消費者               │
│  ✅ 快取讀寫操作                        │
├─────────────────────────────────────────┤
│  ❌ 完整使用者工作流程                  │
│  ❌ 跨服務通訊                          │
│  ❌ UI 互動                             │
└─────────────────────────────────────────┘
```

### 命名慣例

**檔案命名**:
```
[ComponentName]IntegrationTests.[ext]
[ComponentName].integration.test.[ext]
[ComponentName].itest.[ext]

範例:
  UserRepositoryIntegrationTests.cs
  user-service.integration.test.ts
  user_repository_itest.py
```

**方法命名**:
```
[Operation]_[Context]_[ExpectedOutcome]

範例:
  CreateUser_WithValidData_PersistsToDatabase()
  GetUserById_ExistingUser_ReturnsUserFromDatabase()
  SendMessage_ToQueue_ConsumerReceivesMessage()
```

### 測試夾具

```csharp
// C# 整合測試範例，使用測試資料庫
[TestClass]
public class UserRepositoryIntegrationTests
{
    private TestDbContext _dbContext;
    private UserRepository _repository;

    [TestInitialize]
    public async Task Setup()
    {
        // 使用測試資料庫（如 SQLite in-memory 或 Testcontainers）
        _dbContext = TestDbContextFactory.Create();
        _repository = new UserRepository(_dbContext);
        await _dbContext.Database.EnsureCreatedAsync();
    }

    [TestCleanup]
    public async Task Cleanup()
    {
        await _dbContext.DisposeAsync();
    }

    [TestMethod]
    public async Task CreateUser_WithValidData_PersistsToDatabase()
    {
        // Arrange - 準備
        var user = new User { Name = "Test User", Email = "test@example.com" };

        // Act - 執行
        await _repository.CreateAsync(user);
        var savedUser = await _repository.GetByIdAsync(user.Id);

        // Assert - 斷言
        Assert.IsNotNull(savedUser);
        Assert.AreEqual("Test User", savedUser.Name);
    }
}
```

---

## 系統測試 (ST)

### 定義

測試完整整合的系統，驗證是否符合指定需求。

### 特性

- **完整系統**: 所有元件部署並整合
- **基於需求**: 依據功能規格測試
- **類生產環境**: 使用類似生產的環境

### 範圍

```
┌─────────────────────────────────────────┐
│           系統測試範圍                   │
├─────────────────────────────────────────┤
│  ✅ 完整 API 工作流程                   │
│  ✅ 跨服務交易                          │
│  ✅ 資料流貫穿整個系統                  │
│  ✅ 安全需求                            │
│  ✅ 負載下的效能                        │
│  ✅ 錯誤處理與恢復                      │
│  ✅ 設定驗證                            │
├─────────────────────────────────────────┤
│  ❌ UI 視覺測試                         │
│  ❌ 使用者流程模擬                      │
│  ❌ A/B 測試情境                        │
└─────────────────────────────────────────┘
```

### 系統測試類型

| 類型 | 說明 |
|------|------|
| 功能測試 | 驗證功能符合規格 |
| 效能測試 | 負載、壓力、可擴展性測試 |
| 安全測試 | 滲透測試、漏洞掃描 |
| 可靠性測試 | 故障轉移、恢復、穩定性 |
| 相容性測試 | 跨平台、瀏覽器相容性 |

### 命名慣例

**檔案命名**:
```
[Feature]SystemTests.[ext]
[Feature].system.test.[ext]
[Feature]_st.[ext]

範例:
  OrderProcessingSystemTests.cs
  authentication.system.test.ts
  payment_processing_st.py
```

### 範例

```csharp
// 系統測試範例：完整資源處理流程
// 注意：將 {Resource}, {Item}, {Action} 替換為您的領域概念
[TestClass]
public class ResourceProcessingSystemTests
{
    private HttpClient _client;
    private TestEnvironment _env;

    [TestInitialize]
    public async Task Setup()
    {
        _env = await TestEnvironment.CreateAsync();
        _client = _env.CreateAuthenticatedClient();
    }

    [TestMethod]
    public async Task ProcessResource_CompleteFlow_CompletedSuccessfully()
    {
        // Arrange: 建立測試資料
        var item = await _env.CreateTestItem(value: 100);
        var user = await _env.CreateTestUser();

        // Act: 執行完整處理流程
        // Step 1: 建立請求
        var requestResponse = await _client.PostAsync("/api/requests",
            new { itemId = item.Id, quantity = 2 });
        Assert.AreEqual(HttpStatusCode.OK, requestResponse.StatusCode);

        // Step 2: 提交處理
        var processResponse = await _client.PostAsync("/api/processes",
            new { requestId = requestResponse.RequestId, userId = user.Id });
        var process = await processResponse.Content.ReadAsAsync<Process>();
        Assert.AreEqual(HttpStatusCode.Created, processResponse.StatusCode);

        // Step 3: 確認完成
        var confirmResponse = await _client.PostAsync($"/api/processes/{process.Id}/confirm",
            new { confirmationType = "standard", amount = 200 });
        Assert.AreEqual(HttpStatusCode.OK, confirmResponse.StatusCode);

        // Assert: 驗證最終狀態
        var finalProcess = await _client.GetAsync($"/api/processes/{process.Id}");
        var result = await finalProcess.Content.ReadAsAsync<Process>();

        Assert.AreEqual(ProcessStatus.Completed, result.Status);
        Assert.AreEqual(200, result.TotalAmount);
        Assert.IsNotNull(result.Confirmation);
    }
}
```

---

## 端對端測試 (E2E)

### 定義

從使用者介面測試完整的使用者工作流程，貫穿所有系統層。

### 特性

- **使用者視角**: 模擬真實使用者互動
- **全棧**: UI → API → 資料庫 → 外部服務
- **最慢**: 每個測試通常 30 秒到數分鐘

### 範圍

```
┌─────────────────────────────────────────┐
│            E2E 測試範圍                 │
├─────────────────────────────────────────┤
│  ✅ 關鍵使用者流程                      │
│  ✅ 登入/驗證流程                       │
│  ✅ 核心業務交易                        │
│  ✅ 跨瀏覽器功能                        │
│  ✅ 部署煙霧測試                        │
├─────────────────────────────────────────┤
│  ❌ 所有可能的使用者路徑                │
│  ❌ 邊界情況（使用 UT/IT）              │
│  ❌ 效能基準測試                        │
└─────────────────────────────────────────┘
```

### 命名慣例

**檔案命名**:
```
[UserJourney].e2e.[ext]
[Feature].e2e.spec.[ext]
e2e/[feature]/[scenario].[ext]

範例:
  user-registration.e2e.ts
  checkout-flow.e2e.spec.ts
  e2e/authentication/login.spec.ts
```

### 範例

```typescript
// Playwright E2E 測試範例
import { test, expect } from '@playwright/test';

test.describe('使用者註冊流程', () => {
    test('應成功完成註冊並登入', async ({ page }) => {
        // Step 1: 導航到註冊頁面
        await page.goto('/register');

        // Step 2: 填寫註冊表單
        await page.fill('[data-testid="email"]', 'newuser@example.com');
        await page.fill('[data-testid="password"]', 'SecurePass123!');
        await page.fill('[data-testid="confirm-password"]', 'SecurePass123!');
        await page.click('[data-testid="register-button"]');

        // Step 3: 驗證註冊成功
        await expect(page.locator('[data-testid="success-message"]'))
            .toContainText('Registration successful');

        // Step 4: 使用新帳號登入
        await page.goto('/login');
        await page.fill('[data-testid="email"]', 'newuser@example.com');
        await page.fill('[data-testid="password"]', 'SecurePass123!');
        await page.click('[data-testid="login-button"]');

        // Step 5: 驗證登入成功並導向儀表板
        await expect(page).toHaveURL('/dashboard');
        await expect(page.locator('[data-testid="welcome-message"]'))
            .toContainText('Welcome, newuser@example.com');
    });
});
```

---

## 靜態測試

靜態測試在不執行軟體的情況下檢查工作產出物（程式碼、文件、需求）。它透過在 SDLC 早期發現缺陷來補充動態測試。

**參考來源**：ISTQB CTFL v4.0 第 3 章、ISO/IEC/IEEE 29119-4

### 靜態測試類型

```
┌─────────────────────────────────────────────────────────────┐
│                    靜態測試類型                               │
├─────────────────────────────────────────────────────────────┤
│  審查（人工）                                                 │
│  ├── 非正式審查：臨時性、無正式流程                          │
│  ├── 走查：作者主導、教育目的                                │
│  ├── 技術審查：同儕主導、發現缺陷                            │
│  └── 檢驗：正式、度量驅動、最嚴謹                            │
├─────────────────────────────────────────────────────────────┤
│  靜態分析（工具輔助）                                         │
│  ├── 程式碼分析：Linters、複雜度分析器                       │
│  ├── 安全分析：SAST 工具（SonarQube、Checkmarx）            │
│  ├── 架構分析：相依性檢查                                    │
│  └── 資料流分析：變數使用模式                                │
└─────────────────────────────────────────────────────────────┘
```

### 審查流程（ISTQB）

| 階段 | 活動 |
|------|------|
| 計畫 | 定義範圍、進入條件、角色 |
| 啟動審查 | 分發工作產出物 |
| 個人審查 | 每位審查者獨立檢查 |
| 問題溝通 | 在會議中討論發現 |
| 修復與報告 | 作者修復、收集指標 |

### 各語言靜態分析工具

| 語言 | Linting | 安全性 | 複雜度 |
|------|---------|--------|--------|
| JavaScript/TypeScript | ESLint, Biome | npm audit, Snyk | ESLint 複雜度規則 |
| Python | Pylint, Ruff, Flake8 | Bandit, Safety | Radon |
| Java | Checkstyle, PMD | SpotBugs, OWASP DC | JaCoCo |
| C# | StyleCop, Roslyn | Security Code Scan | NDepend |
| Go | golangci-lint | gosec | gocyclo |

### 程式碼審查檢查清單

```
┌─────────────────────────────────────────────────────────────┐
│              程式碼審查重點領域                               │
├─────────────────────────────────────────────────────────────┤
│  功能性                                                      │
│  ├── 程式碼是否執行預期功能？                               │
│  ├── 是否處理邊界情況？                                     │
│  └── 錯誤處理是否適當？                                     │
├─────────────────────────────────────────────────────────────┤
│  可維護性                                                    │
│  ├── 程式碼是否可讀且組織良好？                             │
│  ├── 命名是否有意義？                                       │
│  └── 複雜度是否可管理？                                     │
├─────────────────────────────────────────────────────────────┤
│  安全性                                                      │
│  ├── 輸入驗證是否存在？                                     │
│  ├── 沒有寫死的機密資訊？                                   │
│  └── SQL 注入 / XSS 預防措施？                              │
├─────────────────────────────────────────────────────────────┤
│  效能                                                        │
│  ├── 沒有明顯的低效率？                                     │
│  ├── 資源清理（連線、檔案）？                               │
│  └── 適當的資料結構？                                       │
└─────────────────────────────────────────────────────────────┘
```

---

## 測試設計技術

測試設計技術是用於導出和選擇測試案例的方法。ISTQB 和 ISO/IEC/IEEE 29119 將其分為三個主要類別。

**參考來源**：ISTQB CTFL v4.0 第 4 章、ISO/IEC/IEEE 29119-4

### 技術分類

```
┌─────────────────────────────────────────────────────────────┐
│              測試設計技術分類                                 │
├─────────────────────────────────────────────────────────────┤
│  規格導向（黑箱）                                            │
│  └── 從需求/規格導出測試                                    │
├─────────────────────────────────────────────────────────────┤
│  結構導向（白箱）                                            │
│  └── 從內部程式碼結構導出測試                               │
├─────────────────────────────────────────────────────────────┤
│  經驗導向                                                    │
│  └── 從測試人員的知識和直覺導出測試                         │
└─────────────────────────────────────────────────────────────┘
```

### 規格導向技術（黑箱）

#### 1. 等價類別劃分（EP）

將輸入資料劃分為系統應該以相同方式處理的分區。

```
輸入：年齡（有效範圍：18-65）

┌─────────────┬─────────────┬─────────────┐
│    無效     │     有效     │    無效     │
│    < 18     │   18 - 65   │    > 65     │
├─────────────┼─────────────┼─────────────┤
│   分區 1    │   分區 2     │   分區 3    │
│  測試: 10   │  測試: 30   │  測試: 70   │
└─────────────┴─────────────┴─────────────┘

覆蓋率：每個分區至少 1 個測試案例
```

#### 2. 邊界值分析（BVA）

在等價類別分區的邊界進行測試，因為缺陷最可能在此發生。

```
輸入：數量（有效範圍：1-100）

       0      1      2    ...    99    100    101
       │      │      │           │      │      │
       ▼      ▼      ▼           ▼      ▼      ▼
    無效   有效   有效        有效   有效   無效
   (邊界) (邊界)             (邊界) (邊界)

測試值：0, 1, 2, 99, 100, 101
```

#### 3. 決策表測試

用於捕捉具有多個條件的複雜業務規則。

```
折扣規則：
- 高級會員：20% 折扣
- 訂單 > $100：10% 折扣
- 兩個條件都符合：25% 折扣（不累加）

┌─────────────────┬──────┬──────┬──────┬──────┐
│ 條件            │ TC1  │ TC2  │ TC3  │ TC4  │
├─────────────────┼──────┼──────┼──────┼──────┤
│ 高級會員        │  N   │  Y   │  N   │  Y   │
│ 訂單 > $100     │  N   │  N   │  Y   │  Y   │
├─────────────────┼──────┼──────┼──────┼──────┤
│ 動作            │      │      │      │      │
├─────────────────┼──────┼──────┼──────┼──────┤
│ 折扣 %          │  0%  │ 20%  │ 10%  │ 25%  │
└─────────────────┴──────┴──────┴──────┴──────┘
```

#### 4. 狀態轉換測試

基於系統狀態和轉換測試行為變化。

```
訂單狀態機：

  ┌─────────┐    place()    ┌───────────┐   pay()    ┌────────┐
  │  草稿   │──────────────▶│   待處理   │───────────▶│  已付款 │
  └─────────┘               └───────────┘            └────────┘
       │                          │                       │
       │ cancel()                 │ cancel()              │ ship()
       ▼                          ▼                       ▼
  ┌───────────┐             ┌───────────┐           ┌──────────┐
  │  已取消   │             │  已取消   │           │  已出貨  │
  └───────────┘             └───────────┘           └──────────┘
```

### 結構導向技術（白箱）

#### 1. 語句覆蓋

確保每個語句至少執行一次。

#### 2. 分支覆蓋

確保每個分支（決策結果）都被執行。

#### 3. 條件覆蓋

確保決策中的每個條件都被評估為 true 和 false。

#### 4. MC/DC（修改條件/決策覆蓋）

每個條件獨立影響決策結果。安全關鍵系統必需。

### 額外規格導向技術

#### 6. 成對測試（Pairwise Testing / 組合測試）

測試所有可能的輸入參數值配對，在維持良好覆蓋率的同時減少測試案例數量。

**參考來源**：SWEBOK v4.0 - 輸入領域技術

```
範例：具有 3 個參數的登入表單，每個參數有 3 個值

參數：
- 瀏覽器：Chrome, Firefox, Safari
- 作業系統：Windows, macOS, Linux
- 語言：英文, 西班牙文, 法文

完整組合：3 × 3 × 3 = 27 個測試案例
成對覆蓋：9 個測試案例（涵蓋所有配對）
```

**工具**：PICT（Microsoft）、AllPairs、Jenny

#### 7. 資料流測試（Data Flow Testing）

透過追蹤變數的定義和使用來測試程式中的資料流動。

**參考來源**：SWEBOK v4.0 - 程式碼導向技術

```
┌─────────────────────────────────────────────────────────────┐
│              資料流術語                                      │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Definition（定義）：變數被賦值                             │
│  Use（使用）：變數的值被存取                                │
│  - c-use：計算使用（在計算中）                              │
│  - p-use：述詞使用（在條件中）                              │
│                                                              │
│  def-use 配對：從定義到使用的路徑                           │
│  def-clear 路徑：定義和使用之間沒有重新定義                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

**覆蓋準則**：

| 準則 | 要求 | 強度 |
|------|------|------|
| All-Defs | 每個定義至少到達一個使用 | 弱 |
| All-Uses | 每個 def-use 配對都被執行 | 中 |
| All-DU-Paths | 從定義到使用的所有 def-clear 路徑 | 強 |

### 技術選擇指南

| 技術 | 最適合 | 測試層級 |
|------|--------|----------|
| 等價類別劃分 | 輸入驗證、範圍 | UT, IT |
| 邊界值分析 | 數值限制、日期 | UT, IT |
| 決策表 | 複雜業務規則 | UT, IT, ST |
| 狀態轉換 | 工作流程、狀態變更 | IT, ST |
| 用例測試 | 使用者場景 | ST, E2E |
| 成對測試 | 多參數組合 | IT, ST |
| 資料流測試 | 變數生命週期驗證 | UT |
| 語句覆蓋 | 基本程式碼覆蓋 | UT |
| 分支覆蓋 | 決策邏輯 | UT |
| MC/DC | 安全關鍵系統 | UT |

---

## 經驗導向測試

經驗導向測試利用測試人員的知識、技能和直覺來設計和執行測試。它補充系統化技術。

**參考來源**：ISTQB CTFL v4.0 第 4.4 節

### 經驗導向測試類型

#### 1. 探索性測試

同時進行測試設計、執行和學習。測試人員在沒有預定義腳本的情況下探索系統。

```
┌─────────────────────────────────────────────────────────────┐
│              探索性測試會議                                   │
├─────────────────────────────────────────────────────────────┤
│  章程："探索結帳流程，重點關注付款失敗場景"                    │
├─────────────────────────────────────────────────────────────┤
│  時間箱：60 分鐘                                              │
├─────────────────────────────────────────────────────────────┤
│  備註：                                                       │
│  - 測試過期信用卡 → 得到通用錯誤                              │
│  - 測試餘額不足 → 同樣的通用錯誤                              │
│  - 發現：不同失敗沒有特定錯誤訊息                             │
│  - Bug：用相同卡片重試不會清除之前的錯誤                       │
├─────────────────────────────────────────────────────────────┤
│  發現的 Bug：2 個                                             │
│  需進一步測試的區域：錯誤訊息的具體性                          │
└─────────────────────────────────────────────────────────────┘
```

#### 2. 錯誤猜測

根據類似系統的經驗或常見錯誤來預測缺陷。

```
常見錯誤類別：

┌─────────────────────────────────────────────────────────────┐
│  輸入錯誤                                                    │
│  ├── 空/null 輸入                                           │
│  ├── 超長字串                                               │
│  ├── 特殊字元（', ", <, >, & 等）                          │
│  ├── Unicode/emoji 字元                                     │
│  └── 期望正數時輸入負數                                     │
├─────────────────────────────────────────────────────────────┤
│  邊界錯誤                                                    │
│  ├── 差一錯誤                                               │
│  ├── 整數溢位/下溢                                          │
│  ├── 日期邊界（閏年、月底）                                 │
│  └── 陣列索引越界                                           │
├─────────────────────────────────────────────────────────────┤
│  狀態錯誤                                                    │
│  ├── 對已刪除記錄的操作                                     │
│  ├── 並發修改                                               │
│  ├── 操作期間會話超時                                       │
│  └── 提交後按瀏覽器返回鍵                                   │
└─────────────────────────────────────────────────────────────┘
```

#### 3. 檢查表測試

使用基於經驗和標準的預定義檢查表。

### 何時使用經驗導向測試

| 場景 | 建議技術 |
|------|----------|
| 新功能探索 | 探索性測試 |
| 沒有文件的遺留系統 | 探索性測試 |
| 已知問題區域 | 錯誤猜測 |
| 回歸測試 | 檢查表測試 |
| 時間壓力 / 快速驗證 | 錯誤猜測 |
| 合規驗證 | 檢查表測試 |

---

## 風險導向測試

風險導向測試根據潛在失敗的可能性和影響來優先安排測試工作。

**參考來源**：ISTQB CTFL v4.0 第 5.2 節

### 風險評估

#### 風險公式

```
風險等級 = 可能性 × 影響

┌─────────────────────────────────────────────────────────────┐
│                    風險矩陣                                   │
├─────────────┬───────────────────────────────────────────────┤
│             │         影響                                   │
│ 可能性      │   低 (1)      中 (2)       高 (3)             │
├─────────────┼───────────────────────────────────────────────┤
│ 高 (3)      │   中 (3)      高 (6)       嚴重 (9)           │
│ 中 (2)      │   低 (2)      中 (4)       高 (6)             │
│ 低 (1)      │   低 (1)      低 (2)       中 (3)             │
└─────────────┴───────────────────────────────────────────────┘
```

#### 風險因素

**可能性因素**（技術風險）：
- 功能複雜度
- 新的/不熟悉的技術
- 程式碼品質指標
- 開發人員經驗
- 變更頻率
- 整合複雜度

**影響因素**（業務風險）：
- 營收影響
- 受影響的使用者數量
- 法規合規
- 品牌聲譽
- 資料安全/隱私
- 營運關鍵性

### 風險導向測試優先排序

```
範例：電子商務應用程式

┌──────────────────────┬─────────┬─────────┬───────┬──────────┐
│ 功能                  │ 可能性  │  影響   │ 風險  │ 優先順序 │
├──────────────────────┼─────────┼─────────┼───────┼──────────┤
│ 付款處理             │    2    │    3    │   6   │    1     │
│ 使用者認證           │    2    │    3    │   6   │    2     │
│ 購物車               │    2    │    2    │   4   │    3     │
│ 商品搜尋             │    1    │    2    │   2   │    4     │
│ 商品評論             │    1    │    1    │   1   │    5     │
│ 願望清單             │    1    │    1    │   1   │    6     │
└──────────────────────┴─────────┴─────────┴───────┴──────────┘

測試工作分配：
- 嚴重（風險 6+）：50% 測試工作，最徹底的覆蓋
- 中等（風險 3-5）：30% 測試工作，標準覆蓋
- 低（風險 1-2）：20% 測試工作，基本覆蓋
```

---

## 專項測試

現代軟體開發需要超越傳統類別的專項測試類型。

### 契約測試

驗證服務根據約定的契約正確通訊。對微服務架構至關重要。

```
┌─────────────────────────────────────────────────────────────┐
│              消費者驅動契約測試                               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  消費者                          提供者                       │
│  (前端)                          (API)                       │
│      │                              │                        │
│      │  1. 定義期望                 │                        │
│      │─────────────────────────────▶│                        │
│      │                              │                        │
│      │  2. 產生契約                 │                        │
│      │  (Pact 檔案)                 │                        │
│      │                              │                        │
│      │  3. 分享契約                 │                        │
│      │─────────────────────────────▶│                        │
│      │                              │                        │
│      │                   4. 提供者驗證契約                    │
│      │                              │                        │
└─────────────────────────────────────────────────────────────┘
```

**工具**：Pact、Spring Cloud Contract、Postman

### 變異測試

通過在程式碼中引入小變化（變異體）來評估測試套件品質，並檢查測試是否能檢測到它們。

```
┌─────────────────────────────────────────────────────────────┐
│                   變異測試                                    │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  原始程式碼：         變異體（改變運算子）：                   │
│  if (a > b)          if (a >= b)    ← 邊界變異               │
│  if (a > b)          if (a < b)     ← 否定變異               │
│  return a + b;       return a - b;  ← 算術變異               │
│  return true;        return false;  ← 回傳值變異             │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  變異分數 = (殺死的變異體 / 總變異體) × 100                   │
│                                                              │
│  - 殺死：測試失敗 → 好，測試檢測到變化                       │
│  - 存活：測試通過 → 差，測試漏掉缺陷                         │
│                                                              │
│  目標：關鍵程式碼 > 80% 變異分數                              │
└─────────────────────────────────────────────────────────────┘
```

**工具**：Stryker (JS/TS)、PITest (Java)、mutmut (Python)

### 混沌工程

通過在生產或預備環境中注入失敗來主動測試系統韌性。

```
┌─────────────────────────────────────────────────────────────┐
│              混沌工程原則                                     │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  1. 定義「穩態」（正常行為指標）                              │
│  2. 假設在混沌期間穩態繼續維持                               │
│  3. 引入真實世界事件：                                       │
│     - 伺服器故障                                             │
│     - 網路延遲/分區                                          │
│     - 資源耗盡                                               │
│     - 時鐘偏移                                               │
│  4. 嘗試證偽假設                                             │
│  5. 最小化影響範圍（從小處開始）                              │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

**工具**：Chaos Monkey、Gremlin、Litmus、Chaos Toolkit

### 額外專項測試類型（SWEBOK）

以下測試類型定義於 SWEBOK v4.0 作為測試目標：

#### 安裝測試（Installation Testing）

驗證軟體在目標環境中正確安裝。

| 階段 | 檢查項目 |
|------|----------|
| 安裝前 | 先決條件、磁碟空間、權限 |
| 安裝過程 | 全新安裝、升級、自訂選項、靜默安裝 |
| 安裝後 | 應用程式啟動、配置檔案、解除安裝 |

#### Alpha 和 Beta 測試

| 階段 | 參與者 | 環境 | 目的 |
|------|--------|------|------|
| **Alpha** | 內部使用者、開發人員 | 開發現場 | 早期驗證、重大問題 |
| **Beta** | 外部使用者、客戶 | 客戶現場 | 真實世界驗證、回饋 |
| **開放 Beta** | 一般大眾 | 各種環境 | 廣泛曝光、壓力測試 |

#### 復原測試（Recovery Testing）

測試系統從失效中復原的能力。

| 場景 | 測試項目 |
|------|----------|
| 硬體故障 | 交易期間斷電、磁碟故障、網路中斷 |
| 軟體故障 | 應用程式當機復原、資料庫連線遺失 |
| 資料復原 | 備份還原、交易回滾、時間點復原 |

**關鍵指標**：
- RTO（復原時間目標）：最大可接受停機時間
- RPO（復原點目標）：最大可接受資料遺失

#### 配置測試（Configuration Testing）

在不同配置下測試系統。測試每個支援的配置組合。

#### 背對背測試（Back-to-Back Testing）

使用相同輸入比較多個實作的輸出。

使用情境：
- 比較新版本與舊版本
- 比較最佳化程式碼與參考實作
- 跨平台一致性驗證
- 驗證重構程式碼行為

#### 易用性測試（Usability Testing）

評估使用者學習和使用系統的容易程度。

| 方法類別 | 方法 |
|----------|------|
| 觀察法 | 有聲思考、眼球追蹤、錄影 |
| 任務法 | 任務完成率、任務時間、錯誤率 |
| 問卷法 | SUS（系統易用性量表）、NPS |

### 專項測試總結

| 類型 | 目的 | 何時使用 |
|------|------|----------|
| 契約測試 | API 相容性 | 微服務 |
| 變異測試 | 測試品質評估 | 關鍵程式碼路徑 |
| 混沌工程 | 韌性驗證 | 生產系統 |
| 屬性導向測試 | 邊界案例發現 | 演算法、解析器 |
| 視覺回歸測試 | UI 一致性 | 前端變更 |
| 無障礙測試 | 包容性設計 | 所有面向使用者的應用 |
| 安裝測試 | 部署驗證 | 發布候選版本 |
| Alpha/Beta 測試 | 早期使用者驗證 | 預發布階段 |
| 復原測試 | 失效復原 | 業務關鍵系統 |
| 配置測試 | 多配置支援 | 跨平台應用 |
| 背對背測試 | 版本比較 | 遷移、重構 |
| 易用性測試 | 使用者體驗 | 面向使用者的應用 |

---

## 測試相關度量

用於評估被測軟體和測試品質的量化度量。

**參考來源**：SWEBOK v4.0 第 5.4 節

### 程式評估度量

#### 缺陷密度

```
缺陷密度 = 總缺陷數 / 大小

其中大小可以是：
- KLOC（千行程式碼）
- 功能點
- 故事點

業界基準：
┌─────────────────────┬────────────────────────────┐
│ 品質等級            │ 每 KLOC 缺陷數            │
├─────────────────────┼────────────────────────────┤
│ 一般                │ 1 - 25                     │
│ 良好                │ 0.5 - 1                    │
│ 優秀                │ < 0.5                      │
│ 安全關鍵            │ < 0.1                      │
└─────────────────────┴────────────────────────────┘
```

#### 可靠度成長模型

追蹤缺陷發現率隨時間的變化，以預測剩餘缺陷。

隨著測試進行：
- 缺陷發現率下降
- 曲線接近漸近線（總缺陷數）
- 可估計剩餘缺陷

常見模型：Goel-Okumoto（指數型）、Musa（對數型）

### 測試評估度量

#### 缺陷植入（Fault Seeding）

插入已知缺陷以衡量測試效能。

```
缺陷偵測效能 = 找到的植入缺陷 / 總植入缺陷

若測試找到 80% 的植入缺陷，可估計：
- 對真實缺陷有類似的偵測率
- 剩餘缺陷 ≈ 找到的缺陷 / 偵測率
```

#### 覆蓋率度量摘要

| 度量 | 公式 | 目標 |
|------|------|------|
| 語句覆蓋率 | 執行的語句 / 總語句 | ≥ 70% |
| 分支覆蓋率 | 執行的分支 / 總分支 | ≥ 60% |
| 條件覆蓋率 | 評估 T 和 F 的條件 / 總條件 | ≥ 80% |
| MC/DC | 獨立影響決策的條件 | 100%（安全關鍵）|
| 需求覆蓋率 | 測試的需求 / 總需求 | 100% |
| 變異分數 | 殺死的變異體 / 總變異體 | ≥ 80% |

### 測試流程度量

```
┌─────────────────────────────────────────────────────────────┐
│              關鍵測試度量                                    │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  效率度量                                                    │
│  ├── 測試案例生產力 = 建立的測試 / 投入                     │
│  ├── 缺陷偵測率 = 找到的缺陷 / 測試時數                     │
│  └── 自動化率 = 自動化測試 / 總測試                         │
│                                                              │
│  效能度量                                                    │
│  ├── 缺陷洩漏 = 生產環境缺陷 / 總缺陷                       │
│  ├── 測試效能 = 找到的缺陷 / 存在的缺陷                     │
│  └── 階段封閉 = 階段中找到的缺陷 / 注入的缺陷               │
│                                                              │
│  進度度量                                                    │
│  ├── 測試執行率 = 執行的測試 / 計劃的測試                   │
│  ├── 通過率 = 通過的測試 / 執行的測試                       │
│  └── 阻塞率 = 被阻塞的測試 / 總測試                         │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

---

## 缺陷管理

系統化地追蹤和管理整個測試生命週期中的缺陷。

**參考來源**：ISTQB CTFL v4.0 第 5.5 節、ISO/IEC/IEEE 29119-3

### 缺陷生命週期

```
┌─────────────────────────────────────────────────────────────┐
│                    缺陷生命週期                               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌────────┐    ┌────────┐    ┌──────────┐                  │
│   │  新建   │───▶│  開啟   │───▶│  處理中  │                  │
│   └────────┘    └────────┘    └──────────┘                  │
│                      │              │                        │
│                      │              ▼                        │
│                      │        ┌──────────┐                  │
│                      │        │  已修復   │                  │
│                      │        └──────────┘                  │
│                      │              │                        │
│                      │              ▼                        │
│                      │        ┌──────────┐    ┌──────────┐  │
│                      │        │  已驗證   │───▶│  已關閉   │  │
│                      │        └──────────┘    └──────────┘  │
│                      │              │                        │
│                      │              ▼                        │
│                      │        ┌──────────┐                  │
│                      └───────▶│  重新開啟 │                  │
│                               └──────────┘                  │
│                                                              │
│   替代路徑：                                                  │
│   - 新建 → 已拒絕（非 bug、重複）                             │
│   - 開啟 → 延後（延後到以後的版本）                           │
│   - 開啟 → 不修復（接受風險）                                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### 嚴重性 vs 優先順序

| 嚴重性 | 描述 | 範例 |
|--------|------|------|
| 嚴重 | 系統崩潰、資料遺失、安全漏洞 | 應用無法啟動、資料損壞 |
| 高 | 主要功能損壞、無替代方案 | 無法完成結帳 |
| 中 | 功能受損但有替代方案 | 匯出失敗、手動複製可行 |
| 低 | 小問題、外觀問題 | 錯字、對齊問題 |

| 優先順序 | 描述 | 回應時間 |
|----------|------|----------|
| P1 | 立即修復 | 當天 |
| P2 | 發布前修復 | Sprint 內 |
| P3 | 可能時修復 | 下個 Sprint |
| P4 | 有空時修復 | 待辦清單 |

### 缺陷指標

```
┌─────────────────────────────────────────────────────────────┐
│                    關鍵缺陷指標                               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  缺陷密度 = 總缺陷數 / 規模（KLOC 或 FP）                     │
│  - 行業平均：1-25 缺陷/KLOC                                   │
│                                                              │
│  缺陷檢測效率（DDE）=                                         │
│    發布前發現的缺陷 / 總缺陷 × 100                            │
│  - 目標：> 90%                                               │
│                                                              │
│  缺陷移除效率（DRE）=                                         │
│    移除的缺陷 / 注入的缺陷 × 100                              │
│  - 目標：> 95%                                               │
│                                                              │
│  平均檢測時間（MTTD）= 從注入到檢測的平均時間                  │
│  平均解決時間（MTTR）= 從報告到修復的平均時間                  │
│                                                              │
│  缺陷洩漏率 = 生產缺陷 / 總缺陷                               │
│  - 目標：< 5%                                                │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

---

## 測試流程管理

規劃、監控和控制測試活動的結構化方法。

**參考來源**：ISTQB CTFL v4.0 第 5 章、ISO/IEC/IEEE 29119-2

### 測試計畫

#### 測試計畫組成（ISO/IEC/IEEE 29119-3）

```
┌─────────────────────────────────────────────────────────────┐
│                   測試計畫結構                               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  1. 測試計畫識別                                             │
│     - 專案名稱、版本、日期                                   │
│                                                              │
│  2. 簡介                                                     │
│     - 目的、範圍、目標                                       │
│                                                              │
│  3. 測試項目                                                 │
│     - 要測試的功能                                           │
│     - 不測試的功能                                           │
│                                                              │
│  4. 測試方法                                                 │
│     - 測試層級和類型                                         │
│     - 測試技術                                               │
│     - 進入/退出條件                                          │
│                                                              │
│  5. 測試環境                                                 │
│     - 硬體、軟體、工具                                       │
│     - 測試資料需求                                           │
│                                                              │
│  6. 測試排程                                                 │
│     - 里程碑、相依性                                         │
│                                                              │
│  7. 角色與職責                                               │
│     - 團隊結構、RACI 矩陣                                    │
│                                                              │
│  8. 風險與應變措施                                            │
│     - 風險評估、緩解                                         │
│                                                              │
│  9. 核准                                                     │
│     - 簽核要求                                               │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

#### 進入和退出條件

| 條件類型 | 範例 |
|----------|------|
| **進入條件**（開始測試）| 需求已核准、程式碼完成、環境就緒、測試資料可用 |
| **退出條件**（停止測試）| 所有 P1/P2 測試通過、覆蓋率達標、無嚴重缺陷開啟 |

### 測試監控與控制

#### 關鍵進度指標

```
┌─────────────────────────────────────────────────────────────┐
│              測試進度指標                                     │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  執行指標：                                                   │
│  - 計畫測試數：500                                           │
│  - 已執行測試：350（70%）                                    │
│  - 測試通過：320（已執行的 91%）                             │
│  - 測試失敗：30（已執行的 9%）                               │
│  - 測試阻塞：15                                              │
│                                                              │
│  缺陷指標：                                                   │
│  - 發現的總缺陷：45                                          │
│  - 開啟的缺陷：12（3 個嚴重、5 個高、4 個中）                │
│  - 已修復的缺陷：28                                          │
│  - 已驗證的缺陷：20                                          │
│                                                              │
│  覆蓋率指標：                                                 │
│  - 需求覆蓋率：85%                                           │
│  - 程式碼覆蓋率：78%                                         │
│  - 風險覆蓋率：90%                                           │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

---

## 測試替身

### 類型

| 類型 | 用途 | 使用範例 |
|------|------|----------|
| **Stub** (樁) | 回傳預定值 | 固定的 API 回應 |
| **Mock** (模擬物件) | 驗證互動 | 驗證方法被呼叫 |
| **Fake** (假物件) | 簡化的實作 | 記憶體資料庫 |
| **Spy** (間諜) | 記錄呼叫，委派給真實物件 | 部分模擬 |
| **Dummy** (虛設物件) | 佔位符，從不使用 | 填充必要參數 |

### 使用指引

```
┌─────────────────────────────────────────────────────────┐
│                  何時使用哪種替身                         │
├─────────────────────────────────────────────────────────┤
│  單元測試 (UT)                                          │
│  ├── 對所有外部相依使用 Mocks/Stubs                     │
│  └── 使用 Mocks 驗證互動                                │
├─────────────────────────────────────────────────────────┤
│  整合測試 (IT)                                          │
│  ├── 對資料庫使用 Fakes（記憶體、容器）                 │
│  ├── 對外部 API 使用 Stubs                              │
│  └── 最小化 mocking - 測試真實整合                      │
├─────────────────────────────────────────────────────────┤
│  系統測試 (ST)                                          │
│  ├── 盡可能使用真實元件                                 │
│  ├── 僅對外部第三方服務使用 Fakes                       │
│  └── 系統邊界內不使用 mocking                           │
├─────────────────────────────────────────────────────────┤
│  E2E 測試                                               │
│  ├── 使用真實的一切                                     │
│  └── 僅對外部支付/郵件服務使用 Stub                     │
└─────────────────────────────────────────────────────────┘
```

---

## Mock 限制

### 查詢條件驗證

**問題**:
當 Mock 接受查詢條件的 Repository 方法時（如 lambda 表達式、過濾函式），
使用萬用匹配器如 `any()` 會忽略實際的查詢邏輯，讓錯誤的查詢通過單元測試。

**範例**:

```python
# Python 範例
# ❌ 這個測試無法驗證查詢正確性
mock_repo.find.return_value = users
# 查詢可能寫錯，測試仍會通過

# ✓ 新增整合測試驗證實際查詢
```

```csharp
// C# 範例
// ❌ Moq 忽略實際的表達式
_repo.Setup(r => r.FindAsync(It.IsAny<Expression<Func<User, bool>>>()))
     .ReturnsAsync(users);

// ✓ 用整合測試驗證，或使用 It.Is<> 來驗證
```

**經驗法則**:
如果你的單元測試 Mock 了一個接受查詢/過濾/條件參數的方法，
你必須有對應的整合測試來驗證查詢邏輯。

---

## 測試資料管理

### 原則

1. **隔離**: 每個測試管理自己的資料
2. **清理**: 測試結束後自行清理
3. **確定性**: 測試不依賴共享狀態
4. **可讀性**: 測試資料清楚顯示意圖

### 模式

```csharp
// Builder 模式建立測試資料
public class UserBuilder
{
    private string _name = "Default User";
    private string _email = "default@example.com";
    private bool _isActive = true;

    public UserBuilder WithName(string name)
    {
        _name = name;
        return this;
    }

    public UserBuilder WithEmail(string email)
    {
        _email = email;
        return this;
    }

    public UserBuilder Inactive()
    {
        _isActive = false;
        return this;
    }

    public User Build() => new User
    {
        Name = _name,
        Email = _email,
        IsActive = _isActive
    };
}

// 在測試中使用
var activeUser = new UserBuilder()
    .WithName("Active User")
    .Build();

var inactiveUser = new UserBuilder()
    .WithName("Inactive User")
    .Inactive()
    .Build();
```

### 區分識別欄位

當實體同時有代理鍵（自動產生的 ID）和業務識別碼（如員工編號、部門代碼）時，
測試資料必須使用不同的值。

**問題**:
如果測試資料在兩個欄位使用相同的值，欄位映射錯誤將無法被發現。

```python
# Python 範例
# ❌ 錯誤：id 與 business_code 相同
dept = Department(id=1, business_code=1)

# ✓ 正確：不同的值能抓到映射錯誤
dept = Department(id=1, business_code=1001)
```

```csharp
// C# 範例
// ❌ 錯誤：Id 與 DeptId 相同 - 映射錯誤不會被發現
var dept = new Department { Id = 1, DeptId = 1 };

// ✓ 正確：不同的值能抓到欄位映射錯誤
var dept = new Department { Id = 1, DeptId = 1001 };
```

**驗證**:
```csharp
// C#
testData.Dept.Id.Should().NotBe(testData.Dept.DeptId,
    "Test precondition: Id must differ from business identifier");
```

### 複合主鍵

對於使用複合主鍵的實體，確保每筆記錄有唯一的主鍵組合。

```csharp
// C# 範例
// ❌ 主鍵衝突 - 相同的 (Id, SendTime) 組合
var batch1 = new BatchRecord { Id = 0, SendTime = now };
var batch2 = new BatchRecord { Id = 0, SendTime = now };  // 衝突！

// ✓ 唯一組合
var batch1 = new BatchRecord { Id = 0, SendTime = now.AddSeconds(1) };
var batch2 = new BatchRecord { Id = 0, SendTime = now.AddSeconds(2) };
```

**提示**：建立自動產生唯一複合主鍵的輔助函式。

```csharp
// C# 輔助函式範例
private static int _timeOffset = 0;
public static BatchRecord CreateWithUniqueKey(DateTime baseTime)
{
    return new BatchRecord
    {
        SendTime = baseTime.AddSeconds(Interlocked.Increment(ref _timeOffset))
    };
}
```

---

## 測試環境隔離

### 目的

確保在開發機器與 CI/CD 管線之間獲得一致、可重現的測試結果。

### 為什麼重要

- **可重現性**: 相同測試在任何地方產生相同結果
- **隔離性**: 專案相依性不與系統或其他專案衝突
- **CI/CD 一致性**: 本地環境與 CI 環境相符

### 語言專屬虛擬環境

| 語言 | 工具 | Lock 檔案 |
|------|------|-----------|
| Python | venv, virtualenv, conda, poetry | requirements.txt, poetry.lock |
| Node.js | nvm, fnm + npm/yarn/pnpm | package-lock.json, yarn.lock |
| Ruby | rbenv, rvm, bundler | Gemfile.lock |
| Java | SDKMAN, jenv, Maven/Gradle | pom.xml, build.gradle.lock |
| .NET | dotnet SDK | packages.lock.json |
| Go | go mod | go.sum |
| Rust | rustup, cargo | Cargo.lock |

#### 最佳實踐

1. **開發和測試時始終使用虛擬環境**
2. **將 lock 檔提交到版本控制**
3. **在 CI/CD 管線中鎖定版本**
4. **在 README 或 .tool-versions 記錄所需的執行環境版本**

#### 範例：Python 使用 venv

```bash
# 建立虛擬環境
python -m venv .venv

# 啟用
source .venv/bin/activate  # Linux/macOS
.venv\Scripts\activate     # Windows

# 安裝相依套件
pip install -r requirements.txt

# 執行測試
pytest tests/
```

#### 範例：Node.js 使用 nvm

```bash
# 使用專案的 Node 版本
nvm use

# 安裝相依套件
npm ci

# 執行測試
npm test
```

### 容器化測試

使用容器為整合測試和系統測試提供一致的外部相依性（資料庫、訊息佇列等）。

#### 何時使用

| 測試層級 | 容器使用 |
|----------|----------|
| UT (單元測試) | ❌ 不需要 - 使用 mocks |
| IT (整合測試) | ✅ Testcontainers 用於資料庫、快取 |
| ST (系統測試) | ✅ Docker Compose 用於完整環境 |
| E2E (端對端) | ✅ 完整容器化堆疊 |

#### Testcontainers

Testcontainers 提供輕量級、可拋棄式的測試容器。

```csharp
// C# 範例使用 Testcontainers
public class DatabaseIntegrationTests : IAsyncLifetime
{
    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder()
        .WithImage("postgres:15")
        .Build();

    public async Task InitializeAsync()
    {
        await _postgres.StartAsync();
    }

    public async Task DisposeAsync()
    {
        await _postgres.DisposeAsync();
    }

    [Fact]
    public async Task Should_Connect_To_Database()
    {
        var connectionString = _postgres.GetConnectionString();
        // 使用 connectionString 進行測試
    }
}
```

```python
# Python 範例使用 Testcontainers
import pytest
from testcontainers.postgres import PostgresContainer

@pytest.fixture(scope="module")
def postgres_container():
    with PostgresContainer("postgres:15") as postgres:
        yield postgres

def test_database_connection(postgres_container):
    connection_url = postgres_container.get_connection_url()
    # 使用 connection_url 進行測試
```

#### Docker Compose 用於系統測試

```yaml
# docker-compose.test.yml
version: '3.8'
services:
  app:
    build: .
    depends_on:
      - db
      - redis
      - rabbitmq
    environment:
      - DATABASE_URL=postgres://test:test@db:5432/testdb
      - REDIS_URL=redis://redis:6379
      - RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672

  db:
    image: postgres:15
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test
      POSTGRES_DB: testdb

  redis:
    image: redis:7-alpine

  rabbitmq:
    image: rabbitmq:3-management
```

```bash
# 使用 Docker Compose 執行系統測試
docker-compose -f docker-compose.test.yml up -d
npm run test:system
docker-compose -f docker-compose.test.yml down -v
```

### 環境一致性檢查清單

```
┌─────────────────────────────────────────────────────────────┐
│              環境一致性檢查清單                               │
├─────────────────────────────────────────────────────────────┤
│  ✅ 本地與 CI 使用相同的執行環境版本（Node, Python 等）      │
│  ✅ 容器與生產使用相同的資料庫版本                           │
│  ✅ Lock 檔案已提交並在 CI 中使用（npm ci, pip -r）          │
│  ✅ 環境變數有文件並保持一致                                 │
│  ✅ 容器映像使用特定版本標籤                                 │
│  ✅ 使用 .tool-versions 或類似工具管理執行環境版本           │
├─────────────────────────────────────────────────────────────┤
│  ❌ 在生產/CI 中使用 "latest" 標籤                           │
│  ❌ 開發與 CI 使用不同的資料庫版本                           │
│  ❌ 儲存庫中缺少 lock 檔案                                   │
│  ❌ 硬編碼路徑或機器特定設定                                 │
└─────────────────────────────────────────────────────────────┘
```

---

## CI/CD 整合

### 測試執行策略

```yaml
# CI 管線範例
stages:
  - unit-test        # 每次提交執行
  - integration-test # 每次提交執行
  - system-test      # PR 合併到 main 時執行
  - e2e-test         # 發布候選版本時執行

unit-test:
  stage: unit-test
  script:
    - npm run test:unit
  timeout: 10m
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

integration-test:
  stage: integration-test
  services:
    - postgres:14
    - redis:7
  script:
    - npm run test:integration
  timeout: 30m
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

system-test:
  stage: system-test
  environment: staging
  script:
    - npm run test:system
  timeout: 2h
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

e2e-test:
  stage: e2e-test
  environment: staging
  script:
    - npm run test:e2e
  timeout: 4h
  rules:
    - if: $CI_COMMIT_TAG
```

### 測試報告

每個測試層級所需的指標：

| 指標 | UT | IT | ST | E2E |
|------|----|----|----|----|
| 通過/失敗計數 | ✅ | ✅ | ✅ | ✅ |
| 執行時間 | ✅ | ✅ | ✅ | ✅ |
| 覆蓋率 % | ✅ | ✅ | ⚠️ | ❌ |
| 不穩定測試率 | ✅ | ✅ | ✅ | ✅ |
| 截圖/影片 | ❌ | ❌ | ⚠️ | ✅ |

---

## 最佳實踐

### AAA 模式

```csharp
[TestMethod]
public void MethodName_Scenario_ExpectedBehavior()
{
    // Arrange - 準備測試資料與環境
    var input = CreateTestInput();
    var sut = new SystemUnderTest();

    // Act - 執行被測試的行為
    var result = sut.Execute(input);

    // Assert - 驗證結果
    Assert.AreEqual(expected, result);
}
```

### FIRST 原則

| 原則 | 說明 |
|------|------|
| **F**ast (快速) | 測試執行迅速 |
| **I**ndependent (獨立) | 測試不互相影響 |
| **R**epeatable (可重複) | 每次結果相同 |
| **S**elf-validating (自我驗證) | 明確的通過/失敗 |
| **T**imely (及時) | 與生產程式碼一起撰寫 |

### 應避免的反模式

```
❌ 測試相依
   測試必須按特定順序執行

❌ 不穩定測試
   測試有時通過有時失敗

❌ 測試實作細節
   重構時測試會壞掉

❌ 過度模擬
   Mock 太多導致沒測到真正的東西

❌ 缺少斷言
   測試沒有驗證任何有意義的東西

❌ 魔術數字/字串
   測試程式碼中有未解釋的值

❌ 相同測試識別碼
   代理鍵和業務鍵使用相同的值
```

---

## 測試文件結構

透過在測試目錄中維護標準化的文件結構，提升測試可發現性。

### tests/README.md 必要區塊

每個 `tests/` 目錄應包含 README.md，並具備以下區塊以提高可發現性。

#### 1. 測試總覽表格

列出所有測試類型、數量、技術棧和執行環境。

```markdown
| 測試類型 | 數量 | 框架 | 環境 |
|----------|------|------|------|
| 單元測試 | 150 | Jest | Node.js |
| 整合測試 | 45 | Jest | Node.js + TestContainers |
| E2E 測試 | 12 | Playwright | 瀏覽器 |
```

#### 2. 當前狀態區塊

顯示最新測試執行結果，包含清楚的通過/失敗指標。

```markdown
## 當前狀態

| 指標 | 數值 | 目標 | 狀態 |
|------|------|------|------|
| 通過率 | 98.5% | ≥ 95% | ✅ |
| 行覆蓋率 | 82% | ≥ 80% | ✅ |
| 分支覆蓋率 | 75% | ≥ 70% | ✅ |

**最後執行**: 2026-01-20 14:30 UTC
**報告**: [test-report-20260120-143000.md](results/test-report-20260120-143000.md)
```

#### 3. 報告連結區塊

包含測試報告、差距分析和覆蓋率摘要的連結。

```markdown
## 報告

| 報告類型 | 位置 | 說明 |
|----------|------|------|
| 測試結果 | `results/` | 帶時間戳的測試執行報告 |
| 覆蓋率 | `coverage/` | 程式碼覆蓋率報告（HTML、JSON） |
| 差距分析 | `docs/gap-analysis.md` | 缺失的測試覆蓋率分析 |
```

### 測試報告命名規範

| 項目 | 規範 | 範例 |
|------|------|------|
| 報告檔名 | `test-report-YYYYMMDD-HHMMSS.md` | `test-report-20260120-143000.md` |
| 報告目錄 | `tests/results/` | `tests/results/test-report-*.md` |
| 覆蓋率目錄 | `tests/coverage/` | `tests/coverage/lcov-report/` |
| 差距分析 | `tests/docs/gap-analysis.md` | - |

### 目錄結構範例

```
tests/
├── README.md                    # 測試總覽與狀態
├── results/                     # 測試執行報告
│   ├── test-report-20260120-143000.md
│   └── test-report-20260119-090000.md
├── coverage/                    # 覆蓋率報告
│   ├── lcov-report/
│   └── coverage-summary.json
├── docs/                        # 測試文件
│   └── gap-analysis.md
├── unit/                        # 單元測試
├── integration/                 # 整合測試
└── e2e/                         # 端對端測試
```

### 效益

| 效益 | 說明 |
|------|------|
| **可發現性** | 開發者可快速找到測試狀態，無需全面搜尋 |
| **透明度** | 當前品質指標一目了然 |
| **可追溯性** | 歷史報告支援趨勢分析 |
| **新人入門** | 新團隊成員可立即理解測試結構 |

---

## 快速參考卡

```
┌─────────────────────────────────────────────────────────────┐
│                    參考標準                                  │
├─────────────────────────────────────────────────────────────┤
│  • ISTQB CTFL v4.0 - 測試認證                               │
│  • ISO/IEC/IEEE 29119 - 測試標準                            │
│  • SWEBOK v4.0 - 軟體工程知識體系                           │
├─────────────────────────────────────────────────────────────┤
│                 測試基礎（SWEBOK）                           │
├─────────────────────────────────────────────────────────────┤
│  Error → Fault → Failure（因果鏈）                          │
│  Oracle Problem：如何知道預期結果？                          │
│  限制：測試證明缺陷存在，無法證明不存在                      │
│  可測試性：可控制性 + 可觀察性 + 可隔離性                   │
├─────────────────────────────────────────────────────────────┤
│                    測試框架選項                              │
├─────────────────────────────────────────────────────────────┤
│  ISTQB: UT → IT/SIT → ST → AT/UAT（企業/合規）            │
│  業界金字塔: UT (70%) → IT (20%) → E2E (10%)（敏捷/DevOps）│
├─────────────────────────────────────────────────────────────┤
│                    測試層級摘要                              │
├──────────┬──────────────────────────────────────────────────┤
│   UT     │ 單一單元、隔離、模擬相依、< 100ms               │
├──────────┼──────────────────────────────────────────────────┤
│  IT/SIT  │ 元件整合、真實資料庫、1-10 秒                   │
├──────────┼──────────────────────────────────────────────────┤
│   ST     │ 完整系統、基於需求（僅 ISTQB）                  │
├──────────┼──────────────────────────────────────────────────┤
│  E2E     │ 使用者流程、UI 到 DB、僅關鍵路徑                │
├──────────┼──────────────────────────────────────────────────┤
│  AT/UAT  │ 業務驗證、終端使用者（僅 ISTQB）                │
├──────────┴──────────────────────────────────────────────────┤
│                 測試類型（ISTQB）                            │
├─────────────────────────────────────────────────────────────┤
│  功能性：驗證系統行為（黑箱）                               │
│  非功能性：效能、安全性、可用性                             │
│  結構性：程式碼覆蓋、白箱技術                               │
│  變更相關：確認測試與回歸測試                               │
├─────────────────────────────────────────────────────────────┤
│                測試設計技術                                  │
├─────────────────────────────────────────────────────────────┤
│  黑箱：EP、BVA、決策表、狀態轉換                            │
│        成對測試、用例測試                                    │
│  白箱：語句、分支、條件、MC/DC                              │
│        資料流（All-Defs、All-Uses）                          │
│  經驗：探索性、錯誤猜測、檢查表                             │
├─────────────────────────────────────────────────────────────┤
│                    覆蓋率目標                                │
├─────────────────────────────────────────────────────────────┤
│  行: 最低 70% / 建議 85%                                    │
│  分支: 最低 60% / 建議 80%                                  │
│  函式: 最低 80% / 建議 90%                                  │
│  變異分數：關鍵程式碼 ≥ 80%                                 │
├─────────────────────────────────────────────────────────────┤
│                專項測試類型                                  │
├─────────────────────────────────────────────────────────────┤
│  契約：微服務 API 相容性                                    │
│  變異：透過程式碼變異評估測試品質                           │
│  混沌：透過故障注入驗證韌性                                 │
│  屬性導向：基於屬性的隨機輸入                               │
│  視覺回歸：UI 截圖比較                                      │
│  無障礙：WCAG 合規驗證                                      │
│  安裝：部署驗證                                              │
│  復原：失效復原（RTO/RPO）                                  │
│  配置：多配置測試                                            │
│  易用性：使用者體驗（SUS、NPS）                             │
├─────────────────────────────────────────────────────────────┤
│                 測試相關度量                                  │
├─────────────────────────────────────────────────────────────┤
│  缺陷密度 = 缺陷數 / KLOC（目標：< 1）                      │
│  缺陷洩漏 = 生產環境缺陷 / 總缺陷（< 5%）                   │
│  缺陷植入：插入已知缺陷衡量偵測率                           │
│  可靠度成長：追蹤缺陷率隨時間變化                           │
└─────────────────────────────────────────────────────────────┘
```

---

## 相關標準

- [測試驅動開發](../test-driven-development.md) - TDD/BDD/ATDD 方法論
- [測試完整性維度](../test-completeness-dimensions.md) - 7 維度測試覆蓋
- [規格驅動開發](../spec-driven-development.md) - SDD 工作流程整合
- [AI 協作防幻覺標準](../anti-hallucination.md)
- [程式碼簽入檢查點標準](../checkin-standards.md)
- [程式碼審查清單](../code-review-checklist.md)
- [Commit 訊息規範](../commit-message-guide.md)

---

## 版本歷史

| 版本 | 日期 | 變更 |
|------|------|------|
| 2.2.0 | 2026-01-20 | 新增測試文件結構章節：tests/README.md 必要區塊、測試報告命名規範、目錄結構範例。 |
| 2.1.0 | 2026-01-05 | 新增 SWEBOK v4.0 參考。新章節：測試基礎（錯誤 vs 失效、Oracle Problem、理論限制、可測試性、測試充分性）、測試相關度量（缺陷密度、可靠度成長、缺陷植入）。擴充：測試設計技術（成對測試、資料流測試）、專項測試（安裝、Alpha/Beta、復原、配置、背對背、易用性）。更新快速參考卡。 |
| 2.0.0 | 2026-01-05 | 重大更新，對齊 ISTQB CTFL v4.0 與 ISO/IEC/IEEE 29119。新增：靜態測試（審查、靜態分析）、測試設計技術（EP、BVA、決策表、狀態轉換、用例、語句/分支/條件/MC/DC 覆蓋）、經驗導向測試（探索性、錯誤猜測、檢查表）、風險導向測試（風險評估、優先排序）、專項測試（契約、變異、混沌、屬性導向、視覺回歸、無障礙）、缺陷管理（生命週期、指標、根因分析）、測試流程管理（計畫、監控、完成） |
| 1.3.0 | 2025-12-29 | 新增：測試框架選擇（ISTQB vs 業界金字塔）、IT/SIT 縮寫說明、來源引用 |
| 1.2.0 | 2025-12-19 | 新增：Mock 限制章節、整合測試必要性、區分識別欄位、複合主鍵測試資料模式 |
| 1.1.1 | 2025-12-11 | 改進：系統測試範例改用通用領域概念取代特定業務術語 |
| 1.1.0 | 2025-12-05 | 新增測試環境隔離章節（venv、容器） |
| 1.0.0 | 2025-12-05 | 初始測試標準，涵蓋 UT/IT/ST/E2E |

---

## 授權

本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。

---

**維護者**: 開發團隊
