測試策略

測試策略（Test strategy）是簡述軟體開發過程中測試進行的方式。測試策略的目的是以品質保證的角度，從組織層面的高階目標出發，合理地推導出實現這些目標的實際測試活動。測試策略的產生和文件化需以系統化的方式進行，確保所有目標都已包括在內，而且可被所有利益相關人所理解。測試策略還可以讓品質保證裡的各利益相關人，在用語、測試和整合層級、角色和職責、可追蹤性、資源規劃等議題上同步。

測試策略會說明測試階段如何減少利益相關者的產品風險，要進行哪些測試，以及通用的進入與結束條件標準。在開發設計的每一個階段，都需要依據高階的測試策略來規劃具體的測試活動（即測試計劃），以驗證新的功能。測試計劃會依開發階段的設計文件為基礎產生，主要會用系統設計文件，偶爾會用概念設計的文件。設計文件會說明在此軟件版本週期所開啟的軟體功能。

 與測試計劃的區別 

在軟體工程與品質保證（QA）領域中，測試策略（Test Strategy）與測試計劃（Test Plan）雖常被提及，但兩者在層級與目的上有顯著差異。

層級與範圍：測試策略通常是組織層級或產品線層級的靜態文件，定義了測試的通用方法、標準、工具選擇與風險評估，目標是確保組織內測試的一致性。而測試計劃則是針對特定專案或發布版本（Release）的動態文件，依據測試策略的指導，詳細規劃具體的時程、資源分配、人員職責與測試範圍。
變更頻率：測試策略一旦制定，除非技術堆疊或組織政策有重大改變，否則較少修訂。相反地，測試計劃會隨著專案進度、需求變更或資源波動而頻繁更新。
包含關係：在大型專案中，測試策略往往作為獨立的高階指導文件存在；而在小型專案或敏捷開發（Agile）模式中，測試策略的內容常被縮減並包含在「主測試計劃（Master Test Plan）」的一個章節中。

簡言之，測試策略回答的是「如何測（How）」的問題，而測試計劃回答的是「何時測（When）、誰來測（Who）以及測什麼（What）」的問題。

+ 測試策略與測試計劃之比較 特性  測試策略  測試計劃 主要層級  組織級 / 產品線級  專案級 / 發布級 核心問題  如何測？ (方法論)  何時測？誰來測？ (執行面) 屬性  靜態 (長期指導)  動態 (隨專案調整) 主要內容  工具、環境規範、風險標準  時程、資源、範圍、驗收標準

 測試層級 

測試策略需要定義軟體開發生命週期中必須執行的測試層級，並規範各層級的關注點與責任歸屬。常見的層級包含：

單元測試：策略通常規範此層級由開發人員執行，並可能設定代碼覆蓋率（Code Coverage）的最低標準。
整合測試：策略需定義整合的範圍（如模組間或系統間），並指定介面測試的工具標準。
系統測試：驗證完整系統是否符合需求，通常是測試策略中規範最嚴格的階段。
驗收測試（UAT）：策略需定義由誰（如最終用戶或產品經理）來執行驗收，以決定產品是否可上線。

 角色與職責 

為了避免專案執行時的權責不清，測試策略會明確定義組織內各角色的核心職責，而非針對特定專案進行人員指派。這通常包括釐清測試經理（負責制定策略與資源審核）、自動化工程師（負責維護測試框架與腳本）、手動測試人員（負責執行探索性測試）以及開發人員（負責單元測試與缺陷修復）之間的分工邊界。

 環境需求 

測試策略需規範測試活動所需的基礎設施架構與數據管理原則。這包括定義必要的環境層級（如開發環境、QA 環境、預發布環境 Staging 的區隔），以及測試數據管理的規範（例如是否使用脫敏的生產數據、數據重置機制等）。此外，策略中也常包含產品的相容性矩陣（Compatibility Matrix），明確定義必須支援的作業系統、瀏覽器版本或裝置清單。

 測試工具 

為了確保跨專案的一致性並促進資源共享，策略文件通常會定義標準化的工具堆疊（Tool Stack）。這涵蓋了用於儲存用例與報告的測試管理工具（如 JIRA, TestRail）、用於執行 UI 與 API 測試的自動化框架（如 Selenium, JUnit），以及針對與弱點掃描的專用工具。標準化的工具選型有助於降低維護成本並簡化人員培訓。

 風險管理 

測試策略應建立風險管理的框架，指導團隊如何進行。這通常涉及定義風險評估的標準矩陣（以發生可能性與衝擊程度為維度），並制定相應的緩解策略。例如，對於被評估為高風險的功能模組，策略可能規定必須達到更高的測試覆蓋率，或強制執行更嚴格的代碼審查程序。

 測試執行標準 

測試策略需建立一套標準化的執行準則，以確保不同專案在面對品質問題時有一致的判斷依據。

首先，策略應針對測試案例與缺陷（Bug）設定標準化的優先級定義，明確界定何種嚴重程度的缺陷屬於「發布阻礙（Showstopper）」。一旦出現此類嚴重缺陷，產品將被禁止上線，這能有效消除開發團隊與測試團隊對於「是否可發布」產生標準不一的爭議。

此外，策略亦需制定明確的迴歸測試方針，規範在軟體迭代過程中，如何平衡測試的廣度與深度（例如界定何時僅需針對受影響模組進行局部迴歸，何時需執行全量迴歸），並指導核心業務流程的自動化策略，以確保新功能的開發不會破壞既有系統的運作。

 文檔與報告規範 

為了確保測試過程的透明度與可追溯性，測試策略通常會強制規範文檔產出與溝通機制。

在規劃層面，策略強調建立需求可追蹤性（Traceability），意即每一個業務需求都必須能對應到具體的測試案例，並透過（RTM）來防止功能漏測。

在溝通層面，策略需定義報告與度量指標，規範測試報告的頻率以及報告中必須包含的關鍵績效指標（Metrics），如測試執行進度（S-Curve）、缺陷密度與修復率等，協助管理層客觀判斷產品品質。最後，針對測試資產維護，策略應規範產出物的存儲與版本控制原則，確保所有測試執行的結果、日誌與證據都被妥善保存，以滿足組織的稽核需求或未來的回溯分析。
 相關條目 
 软件测试
 测试用例
測試計劃

 參考資料 
 Ammann, Paul and Offutt, Jeff. Introduction to software testing, New York: Cambridge University Press, 2008

 Dasso, Aristides. Verification, validation and testing in software engineering, Hershey, PA: Idea Group Pub., 2007

Category:软件测试