敏捷測試 - 四象限

與傳統測試一樣，敏捷測試也需要涵蓋所有測試級別。

• 單元測試
• 整合測試
• 系統測試
• 使用者驗收測試

單元測試

• 與編碼一起完成，由開發人員完成
• 由編寫測試用例以確保 100% 設計覆蓋率的測試人員支援
• 需要審查單元測試用例和單元測試結果
• 未解決的主要缺陷（根據優先順序和嚴重性）不會被遺留
• 所有單元測試都已自動化

整合測試

• 隨著衝刺的進行，與持續整合一起完成
• 在所有衝刺完成後結束時完成
• 所有功能需求都經過測試
• 測試所有單元之間的介面
• 所有缺陷都已報告
• 儘可能自動化測試

系統測試

• 隨著開發的進行而完成
• 測試使用者故事、功能和特性
• 在生產環境中進行測試
• 執行質量測試（效能、可靠性等）
• 報告缺陷
• 儘可能自動化測試

使用者驗收測試

• 在每個衝刺結束時以及專案結束時完成

• 由客戶完成。團隊收集反饋

• 反饋將作為後續衝刺的輸入

• 衝刺中的使用者故事事先經過驗證以確保可測試，並且具有定義的驗收標準

測試型別

• 元件測試（單元測試）
• 功能測試（使用者故事測試）
• 非功能測試（效能、負載、壓力等）
• 驗收測試

測試可以是完全手動、完全自動化、手動和自動化的組合或由工具支援的手動測試。

支援程式設計和批判產品測試

測試可以用於 -

• 支援開發（支援程式設計） - 支援程式設計測試由程式設計師使用。

  • 決定他們需要編寫哪些程式碼來實現系統的特定行為

  • 編碼後需要執行哪些測試以確保新程式碼不會影響系統的其餘行為

• 僅驗證（批判產品） - 批判產品測試用於發現成品中的不足之處

面向業務和麵向技術的測試

要確定何時執行哪些測試，您需要確定測試是否為 -

• 面向業務，或
• 面向技術

面向業務的測試

如果測試使用業務領域的詞語來回答問題，則該測試是面向業務的測試。這些內容為業務專家所理解，並且會引起他們的興趣，以便能夠在即時場景中解釋系統的行為。

面向技術的測試

如果測試使用技術領域的詞語來回答問題，則該測試是面向技術的測試。程式設計師根據技術說明了解需要實現的內容。

可以使用 Brian Marick 定義的敏捷測試四象限來檢視這兩種測試型別的方面。

敏捷測試四象限

結合測試型別的這兩個方面，Brian Marick 得出了以下敏捷測試四象限 -

敏捷測試四象限提供了一個有用的分類法，以幫助團隊識別、計劃和執行所需的測試。

• 象限 Q1 - 單元級、面向技術，並支援開發人員。單元測試屬於此象限。這些測試可以是自動化測試。

• 象限 Q2 - 系統級、面向業務，並符合產品行為。功能測試屬於此象限。這些測試是手動或自動的。

• 象限 Q3 - 系統或使用者驗收級別、面向業務，並側重於即時場景。使用者驗收測試屬於此象限。這些測試是手動的。

• 象限 Q4 - 系統或運營驗收級別、面向技術，並側重於效能、負載、壓力、可維護性、可擴充套件性測試。除了自動化測試之外，還可以為此類測試使用特殊工具。

結合這些，反映測試什麼-何時的敏捷測試四象限可以視覺化為如下 -