universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/locales/zh-TW/core/testing-standards.md

@@ -1,1925 +1,226 @@
----
-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
-**適用範圍**: 所有軟體專案
+**版本**: 3.0.0
+**最後更新**: 2026-02-10
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
 
 ---
 
 ## 目的
 
-本標準定義測試慣例與最佳實踐，透過多層級的系統化測試確保軟體品質。
+本標準為 AI 代理和開發人員定義可執行的測試規則和慣例。關於理論基礎、教育內容和詳細範例，請參閱 **[測試理論知識庫](guides/testing-guide.md)**。
 
-**參考標準**：
+**參考標準**:
 - [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
-
----
-
-## 目錄
-
-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](https://www.computer.org/education/bodies-of-knowledge/software-engineering)
 
 ---
 
-## 測試基礎
-
-了解軟體測試的理論基礎對於有效的測試設計和執行至關重要。
-
-**參考來源**：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% | 使用者工作流程測試 |
+| **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) | 測試多個系統的整合 |
 
-*整合測試縮寫說明：
-- **IT** (Integration Testing)：敏捷/DevOps 社群常用
-- **SIT** (System Integration Testing)：企業/ISTQB 環境常用
-- 兩個術語指的是同一個測試層級
-
-**何時選擇業界金字塔**：
-- 敏捷/Scrum 開發團隊
-- CI/CD 導向環境
-- 快速迭代的中小型專案
-- DevOps 實踐
+> **注意**：本文件中的「IT」一律指「整合測試 (Integration Testing)」，而非「資訊科技 (Information Technology)」。
 
 ---
 
-## 測試金字塔（預設：業界標準）
+## 測試金字塔 (預設比例)
 
 ```
               ┌─────────┐
-              │   E2E   │  ← 10%（較少、較慢、成本高）
-              │  端對端  │
+              │   E2E   │  ← 10% (較少，較慢，成本較高)
              ─┴─────────┴─
             ┌─────────────┐
-            │   IT/SIT    │  ← 20%（整合測試）
-            │    整合測試  │
+            │    IT/SIT   │  ← 20% (整合測試)
            ─┴─────────────┴─
           ┌─────────────────┐
-          │       UT        │  ← 70%（單元測試 - 基礎）
-          │     單元測試     │
+          │       UT        │  ← 70% (單元測試 - 基礎)
           └─────────────────┘
 ```
 
-### 建議比例（業界金字塔）
-
-| 層級 | 縮寫 | 百分比 | 執行時間 |
-|------|------|--------|----------|
-| 單元測試 | UT | 70% | 總計 < 10 分鐘 |
-| 整合測試 | IT/SIT | 20% | 總計 < 30 分鐘 |
-| E2E 測試 | E2E | 10% | 總計 < 2 小時 |
-
-### ISTQB 4 層結構（替代方案）
-
-| 層級 | 縮寫 | 執行者 | 重點 |
-|------|------|--------|------|
-| 單元測試 | UT | 開發人員 | 程式碼正確性 |
-| 整合測試 | IT/SIT | 開發人員/QA | 介面契約 |
-| 系統測試 | ST | QA 團隊 | 需求驗證 |
-| 驗收測試 | AT/UAT | 終端使用者 | 業務驗證 |
+| 層級 | 比例 | 執行時間目標 |
+|------|------|--------------|
+| 單元測試 (UT) | 70% | 總計 < 10 分鐘 |
+| 整合測試 (IT) | 20% | 總計 < 30 分鐘 |
+| E2E 測試 | 10% | 總計 < 2 小時 |
 
 ---
 
-## 單元測試 (UT)
+## 測試層級需求
 
-### 定義
+### 單元測試 (UT)
 
-測試個別函式、方法或類別，與外部相依性隔離。
+**特性**: 隔離、快速 (< 100ms/個)、確定性
 
-### 特性
+#### 範圍
 
-- **獨立**: 不存取資料庫、網路或檔案系統
-- **快速**: 每個測試 < 100ms
-- **確定性**: 相同輸入永遠產生相同輸出
-
-### 範圍
-
-```
-┌─────────────────────────────────────────┐
-│              測試單元範圍               │
-├─────────────────────────────────────────┤
-│  ✅ 單一函式/方法                       │
-│  ✅ 單一類別                           │
-│  ✅ 純業務邏輯                         │
-│  ✅ 資料轉換                           │
-│  ✅ 驗證規則                           │
-├─────────────────────────────────────────┤
-│  ❌ 資料庫查詢                         │
-│  ❌ 外部 API 呼叫                      │
-│  ❌ 檔案 I/O 操作                      │
-│  ❌ 多類別互動                         │
-└─────────────────────────────────────────┘
-```
+| 包含 | 排除 |
+|------|------|
+| 單一函式/方法 | 資料庫查詢 |
+| 單一類別 | 外部 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
+[ClassName]Tests.[ext]      # C#
+[ClassName].test.[ext]      # TypeScript/JavaScript
+[class_name]_test.[ext]     # Python, 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()
-```
+**方法命名** (每個專案擇一):
 
-### 覆蓋率指引
-
-| 指標 | 最低要求 | 建議 |
-|------|----------|------|
-| 行覆蓋率 | 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);
-    }
-}
-```
+| 風格 | 最適合 | 範例 |
+|------|--------|------|
+| `[Method]_[Scenario]_[Result]` | C#, Java | `CalculateTotal_NegativePrice_ThrowsException()` |
+| `should_[behavior]_when_[condition]` | JavaScript/TypeScript | `should_reject_login_when_account_locked()` |
+| `test_[method]_[scenario]_[expected]` | Python (pytest) | `test_validate_email_invalid_format_returns_false()` |
 
-```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);
-        });
-    });
-});
-```
+#### 覆蓋率閾值
+
+| 指標 | 最低 | 推薦 |
+|------|------|------|
+| 行覆蓋率 (Line) | 70% | 85% |
+| 分支覆蓋率 (Branch) | 60% | 80% |
+| 函式覆蓋率 (Function) | 80% | 90% |
 
 ---
 
-## 整合測試 (IT)
+### 整合測試 (IT)
 
-### 定義
+**特性**: 元件整合、真實相依性 (通常容器化)、1-10 秒/個
 
-測試多個元件、模組或外部系統之間的互動。
+#### 何時必須有整合測試
 
-### 何時必須有整合測試
+**決策規則**: 如果你的單元測試對查詢/過濾參數使用萬用匹配器 (`any()`, `It.IsAny<>`, `Arg.Any<>`)，該功能必須有整合測試。
 
 | 情境 | 原因 |
 |------|------|
-| 查詢條件 | Mock 無法驗證過濾表達式 |
+| 查詢述詞 | Mock 無法驗證過濾表達式 |
 | 實體關聯 | 驗證外鍵正確性 |
-| 複合主鍵 | 記憶體資料庫行為可能與真實資料庫不同 |
-| 欄位映射 | DTO 與 Entity 轉換 |
-| 分頁 | 資料排序與計數 |
+| 複合主鍵 | 記憶體資料庫可能與真實 DB 不同 |
+| 欄位對應 | DTO ↔ Entity 轉換 |
+| 分頁 | 資料排序和計數 |
 | 交易 | 回滾行為 |
 
-**判斷規則**:
-如果你的單元測試對查詢/過濾參數使用萬用匹配器（`any()`、`It.IsAny<>`、`Arg.Any<>`），該功能必須有整合測試。
-
-### 特性
-
-- **元件整合**: 測試模組邊界
-- **真實相依性**: 使用實際資料庫、API（通常容器化）
-- **較慢**: 每個測試通常 1-10 秒
-
-### 範圍
+#### 範圍
 
-```
-┌─────────────────────────────────────────┐
-│         整合測試範圍                     │
-├─────────────────────────────────────────┤
-│  ✅ 資料庫 CRUD 操作                    │
-│  ✅ Repository + Database               │
-│  ✅ Service + Repository                │
-│  ✅ API 端點 + Service 層               │
-│  ✅ 訊息佇列生產者/消費者               │
-│  ✅ 快取讀寫操作                        │
-├─────────────────────────────────────────┤
-│  ❌ 完整使用者工作流程                  │
-│  ❌ 跨服務通訊                          │
-│  ❌ UI 互動                             │
-└─────────────────────────────────────────┘
-```
+| 包含 | 排除 |
+|------|------|
+| 資料庫 CRUD 操作 | 完整使用者工作流程 |
+| Repository + Database | 跨服務通訊 |
+| Service + Repository | UI 互動 |
+| API 端點 + Service 層 | |
 
-### 命名慣例
+#### 命名慣例
 
-**檔案命名**:
 ```
 [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)
+### 端對端測試 (E2E)
 
-### 定義
+**特性**: 使用者視角、全端 (UI → API → Database)、最慢 (30s+/個)
 
-測試完整整合的系統，驗證是否符合指定需求。
+#### 範圍
 
-### 特性
-
-- **完整系統**: 所有元件部署並整合
-- **基於需求**: 依據功能規格測試
-- **類生產環境**: 使用類似生產的環境
-
-### 範圍
-
-```
-┌─────────────────────────────────────────┐
-│           系統測試範圍                   │
-├─────────────────────────────────────────┤
-│  ✅ 完整 API 工作流程                   │
-│  ✅ 跨服務交易                          │
-│  ✅ 資料流貫穿整個系統                  │
-│  ✅ 安全需求                            │
-│  ✅ 負載下的效能                        │
-│  ✅ 錯誤處理與恢復                      │
-│  ✅ 設定驗證                            │
-├─────────────────────────────────────────┤
-│  ❌ UI 視覺測試                         │
-│  ❌ 使用者流程模擬                      │
-│  ❌ A/B 測試情境                        │
-└─────────────────────────────────────────┘
-```
-
-### 系統測試類型
-
-| 類型 | 說明 |
+| 包含 | 排除 |
 |------|------|
-| 功能測試 | 驗證功能符合規格 |
-| 效能測試 | 負載、壓力、可擴展性測試 |
-| 安全測試 | 滲透測試、漏洞掃描 |
-| 可靠性測試 | 故障轉移、恢復、穩定性 |
-| 相容性測試 | 跨平台、瀏覽器相容性 |
+| 關鍵使用者旅程 | 每個可能的使用者路徑 |
+| 登入/驗證流程 | 邊緣案例 (使用 UT/IT) |
+| 核心業務交易 | 效能基準測試 |
 
-### 命名慣例
+#### 命名慣例
 
-**檔案命名**:
-```
-[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 |
-
-### 專項測試總結
+## 測試替身 (Test Doubles)
 
 | 類型 | 目的 | 何時使用 |
 |------|------|----------|
-| 契約測試 | 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% |
+| **Stub** | 回傳預定義值 | 固定的 API 回應 |
+| **Mock** | 驗證互動 | 驗證方法被呼叫 |
+| **Fake** | 簡化的實作 | 記憶體資料庫 |
+| **Spy** | 記錄呼叫 | 部分 Mock |
+| **Dummy** | 佔位符 | 填補必要參數 |
 
-### 測試流程度量
+### 依測試層級使用
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│              關鍵測試度量                                    │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  效率度量                                                    │
-│  ├── 測試案例生產力 = 建立的測試 / 投入                     │
-│  ├── 缺陷偵測率 = 找到的缺陷 / 測試時數                     │
-│  └── 自動化率 = 自動化測試 / 總測試                         │
-│                                                              │
-│  效能度量                                                    │
-│  ├── 缺陷洩漏 = 生產環境缺陷 / 總缺陷                       │
-│  ├── 測試效能 = 找到的缺陷 / 存在的缺陷                     │
-│  └── 階段封閉 = 階段中找到的缺陷 / 注入的缺陷               │
-│                                                              │
-│  進度度量                                                    │
-│  ├── 測試執行率 = 執行的測試 / 計劃的測試                   │
-│  ├── 通過率 = 通過的測試 / 執行的測試                       │
-│  └── 阻塞率 = 被阻塞的測試 / 總測試                         │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## 缺陷管理
-
-系統化地追蹤和管理整個測試生命週期中的缺陷。
-
-**參考來源**：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                     │
-└─────────────────────────────────────────────────────────┘
-```
+| 層級 | 指引 |
+|------|------|
+| **UT** | 對所有外部依賴使用 Mocks/Stubs |
+| **IT** | 資料庫使用 Fakes，外部 API 使用 Stubs |
+| **E2E** | 全部使用真實元件；僅外部支付/郵件使用 Stub |
 
 ---
 
 ## Mock 限制
 
-### 查詢條件驗證
+**問題**: 萬用匹配器 (`any()`, `It.IsAny<>`) 會忽略實際查詢邏輯，允許錯誤的查詢通過。
 
-**問題**:
-當 Mock 接受查詢條件的 Repository 方法時（如 lambda 表達式、過濾函式），
-使用萬用匹配器如 `any()` 會忽略實際的查詢邏輯，讓錯誤的查詢通過單元測試。
-
-**範例**:
+**規則**: 如果 Mock 一個接受查詢/過濾/述詞參數的方法，你**必須**有對應的整合測試來驗證查詢邏輯。
 
 ```python
-# 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）和業務識別碼（如員工編號、部門代碼）時，
-測試資料必須使用不同的值。
+### 區分識別碼規則
 
-**問題**:
-如果測試資料在兩個欄位使用相同的值，欄位映射錯誤將無法被發現。
+當實體同時具有代理鍵 (自動產生 ID) 和業務識別碼時，測試資料**必須**為兩者使用不同的值。
 
 ```python
-# Python 範例
-# ❌ 錯誤：id 與 business_code 相同
+# ❌ 錯誤: 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 檔案                                   │
-│  ❌ 硬編碼路徑或機器特定設定                                 │
-└─────────────────────────────────────────────────────────────┘
-```
+| 層級 | 容器使用 |
+|------|----------|
+| UT | 不需要 - 使用 mocks |
+| IT | Testcontainers 用於資料庫、快取 |
+| ST | Docker Compose 用於完整環境 |
+| E2E | 完整容器化堆疊 |
 
 ---
 
@@ -1927,301 +228,23 @@ docker-compose -f docker-compose.test.yml down -v
 
 ### 測試執行策略
 
-```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%）                   │
-│  缺陷植入：插入已知缺陷衡量偵測率                           │
-│  可靠度成長：追蹤缺陷率隨時間變化                           │
-└─────────────────────────────────────────────────────────────┘
-```
+| 單元測試 | 每次提交 | 10 分鐘 |
+| 整合測試 | 每次提交 | 30 分鐘 |
+| 系統測試 | PR 合併至 main | 2 小時 |
+| E2E 測試 | 發布候選版 | 4 小時 |
 
 ---
 
 ## 相關標準
 
+- [測試理論知識庫](guides/testing-guide.md) - 教育內容、範例、技巧
 - [測試驅動開發](test-driven-development.md) - TDD/BDD/ATDD 方法論
-- [測試完整性維度](test-completeness-dimensions.md) - 7 維度測試覆蓋
+- [測試完整性維度](test-completeness-dimensions.md) - 8 維度測試覆蓋
 - [規格驅動開發](spec-driven-development.md) - SDD 工作流程整合
-- [AI 協作防幻覺標準](anti-hallucination.md)
-- [程式碼簽入檢查點標準](checkin-standards.md)
+- [程式碼簽入標準](checkin-standards.md)
 - [程式碼審查清單](code-review-checklist.md)
-- [Commit 訊息規範](commit-message-guide.md)
 
 ---
 
@@ -2229,21 +252,13 @@ tests/
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
-| 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 |
+| 3.0.0 | 2026-01-29 | **重大重構**：拆分為規則（本文件）和理論（testing-guide.md）。優化 AI 閱讀效率。 |
+| 2.2.0 | 2026-01-20 | 新增測試文件結構章節 |
+| 2.1.0 | 2026-01-05 | 新增 SWEBOK v4.0 參考 |
+| 2.0.0 | 2026-01-05 | 根據 ISTQB CTFL v4.0 和 ISO/IEC/IEEE 29119 進行重大更新 |
 
 ---
 
 ## 授權
 
 本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
-
----
-
-**維護者**: 開發團隊