測試策略 (Testing Strategies) #
QA 的角色再定義 #
在專業的開發團隊中，QA (Quality Assurance) 的職責不僅僅是「找 Bug」，他們更像是團隊中的規格定義者與系統描述者。
1. 需求規約定義者 (Specifier) #
QA 協助定義系統在各種狀況下應有的表現，特別是開發者容易忽略的角落：
| 維度 | 定義 | 範例 | 預期目的 |
|---|---|---|---|
| 極端情況 (Corner Cases) | 發生機率低且複雜的組合情境 | 空值 (Null)、極大/極小值、不合法的資料類型 | 確保系統在極限狀態下不崩潰 |
| 邊界條件 (Boundary Conditions) | 範圍切換的臨界數值 | 陣列的 index 0、輸入長度的限制上限、剛好符合條件的門檻值 | 避免「差一錯誤 (Off-by-one)」 |
| 異常路徑 (Unhappy-path) | 偏離正常預期的錯誤流程 | 用戶輸入錯誤、資料庫連線超時、權限不足等失敗情境 | 驗證系統的回復力與錯誤處理 |
2. 特性描述者 (Characterizer) #
QA 透過探索式測試，觀察並描述系統在真實運行下的實際運作情況，確保系統行為符合業務預期。
自動化測試金字塔 (The Test Pyramid) #
作者依據負責人員、目的與覆蓋範圍，將測試策略分為五個層次。專業的測試策略應呈現金字塔狀：底層數量最多，越往上越精簡。
測試種類一覽表 #
| 測試種類 | 負責人員 | 目的與定義 | 關鍵指標與備註 |
|---|---|---|---|
| 單元測試 (Unit Tests) | 程式設計師 | 在最低層次上定義系統行為。確保個別函式或類別運作正常。 | • 覆蓋率應接近 100%。 • 這是 TDD 的產物。 |
| 元件測試 (Component Tests) | QA 與 業務人員 | 針對封裝後的系統元件進行測試，確保業務規則被正確執行。 | • 覆蓋率約達 50%。 • 重點在於驗收功能。 • 此階段主要測試正常路徑，測試異常路徑意義不大（應在單元測試完成）。 |
| 整合測試 (Integration Tests) | 系統架構師 首席設計師 | 聚焦於編排性 (Choreography)。測試各個元件組合在一起時是否協調運作。 | • 適合較大型系統。 • 通常在此階段進行性能測試。 |
| 系統測試 (System Tests) | QA / 系統整合方 | 對「整合完畢的系統」執行自動化測試。 | • 確保系統構造正確 (Correct Construction)。 • 注意：這不等於確保系統行為正確 (Correct Behavior)。 |
| 人工探索式 (Exploratory) | 人類 (QA/User) | 結合人類的直覺與創意，驗證預期行為並挖掘非預期行為。 | • 機器做不到的測試。 • 探索系統預期之外的缺陷。 |
策略細節解析 #
為什麼元件測試不測異常路徑？ #
在元件測試層級（通常對應到驗收測試），重點在於驗證「業務邏輯是否如預期運作」。至於輸入驗證、錯誤捕捉等底層的異常處理，應該在成本較低、回饋較快的單元測試層級就已經被攔截並驗證完畢。
整合測試 vs. 系統測試 #
這兩者常被混淆，區別在於關注點不同：
| 類別 | 關注核心 | 範例 | 目標 |
|---|---|---|---|
| 整合測試 (Integration) | 通訊與協作 | 資料庫連線是否成功、Microservices 接口格式是否對齊 | 組件間交互正確性 |
| 系統測試 (System) | 整體組裝 | 系統是否能正確啟動、各模組與環境變數是否部署於正確位置 | 軟體交付完整性 |
專業的測試策略不是「所有測試都混在一起」，而是各司其職。程式設計師顧好單元邏輯，架構師顧好元件連接，QA 顧好業務規則與系統全貌。
不要讓人類去做電腦能做的事（如回歸測試）。人類智慧應用於探索式測試，發現那些自動化腳本想像不到的邊緣問題。