# 什么是敏捷測試？ 流程，策略，測試計劃，生命周期示例 > 原文： [https://www.guru99.com/agile-testing-a-beginner-s-guide.html](https://www.guru99.com/agile-testing-a-beginner-s-guide.html) ## 什么是敏捷測試？ **敏捷測試**是遵循敏捷軟件開發規則和原則的測試實踐。 與瀑布方法不同，敏捷測試可以在項目開始時就開始進行，而開發和測試之間會不斷進行集成。 敏捷測試不是順序的（從某種意義上說，它僅在編碼階段之后才執行），而是連續的。 在本文中，我們將討論 * [敏捷性測試計劃。](#1) * [敏捷測試策略。](#2) * [敏捷測試象限。](#3) * [敏捷軟件開發的質量保證挑戰。](#4) * [敏捷過程中的自動化風險。](#5) ### 敏捷性測試計劃 與瀑布模型不同，在敏捷模型中，針對每個發行版編寫并更新測試計劃。 敏捷測試計劃包括在該迭代中完成的測試類型，例如測試數據需求，基礎架構，測試環境和測試結果。 敏捷的典型測試計劃包括 1. 測試范圍 2. 正在測試的新功能 3. 基于功能復雜性的測試級別或類型 4. 負載和性能測試 5. 基礎設施注意事項 6. 緩解或風險計劃 7. 資源配置 8. 可交付成果和里程碑 ### 敏捷測試策略 敏捷測試生命周期涵蓋四個階段  **（a）** **迭代 0** 在第一階段或迭代 0 中，您執行初始設置任務。 它包括確定要測試的人員，安裝測試工具，安排資源（可用性測試實驗室）等。在迭代 0 中設置了以下步驟來實現 a）為項目建立業務案例 b）確定邊界條件和項目范圍 c）概述將推動設計權衡的關鍵要求和用例 d）概述一個或多個候選架構 e）識別風險 f）成本估算并準備初步項目 **（b）** **構造迭代** 測試的第二階段是構造迭代，大部分測試在此階段進行。 該階段被視為一組迭代以建立解決方案的增量。 為了做到這一點，在每次迭代中，**團隊都將[XP]，XP，Scrum，敏捷建模和敏捷數據等各種實踐結合在一起**。 在構造迭代中，敏捷團隊遵循優先級的需求實踐：在每次迭代中，他們都會提取工作項堆棧中剩余的最重要的需求并加以實施。 施工迭代分為確認測試和調查測試兩種。 **確認性測試集中在**上，以驗證系統是否滿足團隊迄今所描述的利益相關者的意圖，并由團隊執行。 當調查性測試檢測到確認小組已跳過或忽略的問題時。 在調查測試中，測試人員以缺陷案例的形式確定潛在的問題。 調查測試處理常見問題，例如集成測試，負載/壓力測試和安全測試。 再次，對于確認性測試，有兩個方面**開發人員測試**和**敏捷接受測試** **。 兩者**都是自動化的，可以在整個生命周期中進行連續回歸測試。 確認性測試是與規范測試敏捷等效的方法。 敏捷驗收測試是作為開發團隊的傳統功能測試和傳統驗收測試的結合，利益相關者正在共同努力。 開發人員測試是傳統單元測試和傳統服務集成測試的混合。 開發人員測試將驗證應用程序代碼和數據庫架構。 **（c）** **發行結束游戲或過渡階段** “發布，結束游戲”的目標是成功地將系統部署到生產中。 在此階段的活動包括對最終用戶，支持人員和操作人員的培訓。 此外，它還包括產品發布的市場營銷，備份&還原，系統定稿和用戶文檔。 最后的測試階段包括完整的系統測試和驗收測試。 為了完成最后的測試階段而沒有任何障礙，您應該在產品迭代過程中對產品進行更嚴格的測試。 在最終游戲中，測試人員將研究其缺陷故事。 **（d）** **產量** 在發布階段之后，產品將進入生產階段。 ### 敏捷測試象限  敏捷測試象限將整個過程分為四個象限，并有助于了解如何執行敏捷測試。 a）**敏捷象限 I** –內部代碼質量是此象限的主要重點，它由技術驅動并為支持團隊而實施的測試用例組成，其中包括 1.單元測試 2.組件測試 b）**敏捷象限 II** –它**包含**測試用例，這些測試用例是**業務驅動的，并已實施**以支持團隊。 本象限關注需求。 在此階段執行的測試類型是 1.測試可能的場景和工作流的示例 2.測試用戶體驗，例如原型 3.配對測試 c）**敏捷象限 III** –該象限向第一和第二象限提供反饋。 測試用例可以用作執行自動化測試的基礎。 在此象限中，進行了許多輪迭代審核，從而建立了對產品的信心。 在該象限中完成的測試類型是 1.可用性測試 2.探索性測試 3.與客戶配對測試 4.協同測試 5.用戶驗收測試 d）**敏捷象限 IV** – **該象限將**集中于非功能性要求，例如性能，安全性，穩定性等。借助該象限，可以使應用程序交付 非功能性質量和期望值。 1.非功能測試，例如壓力和性能測試 2.關于**身份驗證**和黑客的安全測試 3.基礎架構測試 4.數據遷移測試 5.可伸縮性測試 6.負載測試 ### 敏捷軟件開發的質量保證挑戰 a）錯誤的可能性更大，因為文檔的優先級降低，最終給質量檢查團隊帶來更大的壓力 b）快速引入了新功能，這減少了測試團隊用于確定最新功能是否符合要求并真正解決了商務問題的可用時間 c）測試人員通常需要扮演半開發人員的角色 d）測試執行周期被高度壓縮 e）很少時間準備測試計劃 f）對于回歸測試，他們將有最少的時間 g）他們的角色從成為質量關守的角色轉變為成為質量合作伙伴的角色 h）需求變更和更新是敏捷方法所固有的，成為質量檢查的最大挑戰 ### 敏捷過程中的自動化風險 * 自動化的 UI 提供了很高的置信度，但是它們執行速度慢，易維護且構建成本高。 除非測試人員知道如何進行測試，否則自動化可能不會顯著提高測試效率 * 不可靠的測試是自動化測試中的主要問題。 修復失敗的測試并解決與脆性測試相關的問題應是當務之急，以避免誤報 * 如果自動測試是手動啟動的，而不是通過 CI（連續集成）啟動的，則可能會導致它們無法正常運行，因此可能導致測試失敗 * 自動化測試不能替代探索性的手動測試。 為了獲得預期的產品質量，需要混合測試類型和級別 * 許多可商購的自動化工具提供了簡單的功能，例如自動化手動測試用例的捕獲和重放。 這種工具鼓勵通過 UI 進行測試，并導致固有的脆弱性和難以維護的測試。 另外，將測試用例存儲在版本控制系統之外會產生不必要的復雜性 * 為了節省時間，很多時候自動化測試計劃的計劃不當或計劃外，都會導致測試失敗 * 通常在測試自動化過程中會錯過測試設置和拆卸程序，而執行手動測試時，測試設置和拆卸程序聽起來是無縫的 * 諸如每天創建或執行的多個測試用例之類的生產率指標可能會產生極大的誤導，并可能導致對運行無用測試的大量投資 * 敏捷自動化團隊的成員必須是有效的顧問：平易近人，合作且足智多謀，否則該系統將很快失效 * 自動化可能會提出并提供測試解決方案，這些解決方案相對于所提供的價值而言需要過多的持續維護 * 自動化測試可能缺乏構思和交付有效解決方案的專業知識 * 自動化測試可能是如此成功，以至于用盡了重要的問題來解決，因此變成了不重要的問題。 ### 結論 敏捷測試包括在軟件開發生命周期中盡早進行測試。 它一經推出，就需要高度的客戶參與和測試代碼。 該代碼應足夠穩定以進行系統測試。 可以進行廣泛的回歸測試以確保錯誤已得到修復和測試。 主要是，團隊之間的溝通使敏捷測試成功！！！