# 敏捷方法論&模型：軟件開發指南&測試 > 原文： [https://www.guru99.com/agile-scrum-extreme-testing.html](https://www.guru99.com/agile-scrum-extreme-testing.html) ## 什么是敏捷方法論？ AGILE 方法論是在項目的整個軟件開發生命周期中促進開發和測試的**連續迭代**的實踐。 與瀑布模型不同，開發和測試活動是同時進行的  敏捷軟件開發強調四個核心價值。 1. 個人和團隊在流程和工具上的互動 2. 通過全面的文檔工作軟件 3. 客戶合作而非合同談判 4. 響應計劃變更 在本軟件工程教程中，您將學習 * [什么是敏捷方法論？](#1) * [敏捷與瀑布法](#2) * [Scrum](#3) * [產品待辦事項列表](#4) * [Scrum 實踐](#5) * [Scrum 方法論的流程：](#6) * [極限編程（XP）](#7) * [eXtreme 編程的階段：](#8) * [晶體方法](#9) * [動態軟件開發方法（DSDM）](#10) * [功能驅動開發（FDD）](#11) * [精益軟件開發](#12) * [看板](#13) * [敏捷指標](#14) ## 敏捷與瀑布法 敏捷模型和瀑布模型是軟件開發過程中的兩種不同方法。 盡管它們的方法不同，但這兩種方法有時還是有用的，具體取決于項目的要求和類型。 <colgroup><col style="width: 300px;"><col style="width: 301px;"></colgroup> | **敏捷模型** | **瀑布模型** | | * 敏捷方法提出了軟件設計的增量和迭代方法 | * 軟件的開發從起點到終點依次進行。 | | * **敏捷過程** 分為設計人員在 上使用的各個模型。 | * 設計過程未分解為單個模型 | | * 客戶有早期和頻繁的機會來查看產品并為項目做出決策和更改 | * 客戶只能在項目結束時看到產品 | | 與瀑布模型 相比， * 敏捷模型被認為是非結構化的 | * 瀑布模型更安全，因為它們是如此面向計劃的 | | * 小型項目可以很快實施。 對于大型項目，很難估計開發時間。 | * 可以估算并完成各種項目。 | | * 錯誤可以在項目中間修復。 | * 僅在最后測試整個產品。 如果發現需求錯誤或必須進行任何更改，則該項目必須從頭開始 | | * 開發過程是迭代的，并且項目在短（2-4）周的迭代中執行。 計劃非常少。 | * 開發過程是分階段的，并且該階段比迭代大得多。 每個階段都以下一階段的詳細說明結束。 | | * 文檔的優先級不及軟件開發 | * 文檔是頭等大事，甚至可以用于培訓人員并與另一個團隊一起升級軟件 | | * 每個迭代都有其自己的測試階段。 它允許在每次發布新功能或邏輯時實施回歸測試。 | * 僅在開發階段之后，才執行測試階段，因為單獨的部分未完全發揮功能。 | | * 在迭代結束時的敏捷測試中，產品的可交付功能交付給客戶。 發貨后立即可以使用新功能。 與客戶保持良好聯系時，此功能很有用。 | * 在長期的實施階段之后，立即交付了所有開發的功能。 | | * 測試人員和開發人員一起工作 | * 測試人員與開發人員 分開工作 | | * 在每次沖刺結束時，都會執行用戶接受操作 | * 用戶接受是在項目結束時執行的 **。** | | * 它需要與開發人員緊密溝通，并共同分析需求和計劃 | * 開發人員沒有參與需求和計劃過程。 通常，測試和編碼 之間的時間延遲 | ### 敏捷方法論  敏捷測試中存在多種**方法**，以下列出了這些方法： ## Scrum SCRUM 是一種敏捷開發方法，專門集中于如何在基于團隊的開發環境中管理任務。 基本上，Scrum 源自橄欖球比賽期間發生的活動。 Scrum 相信能夠增強開發團隊的能力，并提倡在小型團隊中工作（例如 7 至 9 名成員）。 它由三個角色組成，其職責解釋如下：  * Scrum Master * 大師負責組建團隊，進行沖刺會議并消除前進的障礙 * 產品所有者 * 產品負責人創建產品待辦事項列表，確定待辦事項的優先級，并負責在每次迭代時交付功能 * Scrum 小組 * 團隊管理自己的工作并組織工作以完成沖刺或周期 ## 產品待辦事項列表 這是一個跟蹤需求的倉庫，其中包含每個版本要完成的需求（用戶故事）的詳細信息。 它應該由產品負責人維護并確定優先級，并應分發給 Scrum 團隊。 團隊還可以請求添加，修改或刪除新需求 ## Scrum 實踐 具體做法如下：  ## Scrum 方法論的流程： Scrum 測試的流程如下： * 一個 scrum 的每次迭代都稱為 Sprint * 產品待辦事項列表是輸入所有詳細信息以獲取最終產品的列表 * 在每個 Sprint 期間，都會選擇產品積壓的頂級用戶案例并將其轉換為 Sprint 積壓 * 小組致力于定義的 sprint 待辦事項 * 小組檢查日常工作 * 在沖刺結束時，團隊交付了產品功能 ## 極限編程（XP） 當客戶的需求或需求不斷變化或不確定系統的功能時，極限編程技術將非常有用。 它提倡在較短的開發周期中頻繁地“發布”產品，這從本質上提高了系統的生產率，并引入了一個檢查點，可以輕松地實現任何客戶要求。 XP 開發的軟件使客戶始終處于目標位置。  根據故事收集業務需求。 所有這些故事都存儲在一個稱為停車場的地方。 在這種方法中，發布是基于較短的周期（稱為迭代），周期為 14 天。 每個迭代都包括編碼，單元測試和系統測試等階段，在每個階段中，應用程序都將構建一些次要或主要功能。 ## eXtreme 編程的階段： Agile XP 方法共有 6 個階段，其解釋如下： ### *規劃* * 識別利益相關者和發起人 * 基礎結構要求 * [安全性](/ethical-hacking-tutorials.html)相關信息并收集 * 服務水平協議及其條件 ### *分析* * 捕獲停車場中的故事 * 優先考慮停車場中的故事 * 整理故事以進行估算 * 定義迭代 SPAN（時間） * 開發和質量檢查團隊的資源規劃 ### *設計* * 細分任務 * 每個任務的測試場景準備 * 回歸自動化框架 ### *執行* * 編碼 * 單元測試 * 執行手動測試場景 * 缺陷報告生成 * 手動到自動化回歸測試用例的轉換 * 中期迭代審核 * 迭代結束審查 ### *包裝* * 小版本 * 回歸測試 * 演示和評論 * 根據需要開發新故事 * 基于迭代結束審閱注釋的流程改進 ### *關閉* * 試運行 * 培訓 * 生產啟動 * SLA 保證保證 * 審查 SOA 策略 * 生產支持 每天有兩個故事板可用來跟蹤工作，下面列出了這些故事板以供參考。 * Story Cardboard * This is a traditional way of collecting all the stories in a board in the form of stick notes to track daily XP activities. As this manual activity involves more effort and time, it is better to switch to an online form. * 在線情節提要 * 在線工具 Storyboard 可用于存儲故事。 **幾個團隊可以將其**用于不同的目的。 ## 晶體方法 水晶方法論基于三個概念 1. **憲章**：此階段涉及的各種活動正在創建開發團隊，進行初步可行性分析，制定初步計劃并微調開發方法 2. **周期性投放**：主要開發階段包括兩個或多個投放周期，在此期間， 1. 團隊更新并完善發布計劃 2. 通過一個或多個程序測試集成迭代來實現需求的子集 3. 集成產品交付給真實用戶 4. 審查項目計劃和采用的開發方法 3. **總結**：在此階段中執行的活動是部署到用戶環境中，進行部署后審查和反思。 ## 動態軟件開發方法（DSDM） DSDM 是一種用于軟件開發的快速應用程序開發（RAD）方法，并提供了一個敏捷的項目交付框架。 DSDM 的重要方面是要求用戶積極參與，并且團隊有權制定決策。 產品的頻繁交付成為 DSDM 的關注重點。 DSDM 中使用的技術是 1. 時間拳擊 2. MoSCoW 規則 3. 原型制作 DSDM 項目包含 7 個階段 1. 前期項目 2. 可行性研究 3. 商業研究 4. 功能模型迭代 5. 設計和構建迭代 6. 實作 7. 項目后 ## 功能驅動開發（FDD） 此方法集中于“設計&建筑物”功能。 與其他敏捷方法不同，FDD 描述了非常具體且短暫的工作階段，每個階段必須分別完成。 它包括域演練，設計檢查，升級，代碼檢查和設計。 FDD 開發產品，始終遵循目標 1. 領域對象建模 2. 按功能開發 3. 組件/類所有權 4. 功能團隊 5. 視察 6. 配置管理 7. 常規構建 8. 可見進度和結果 ## 精益軟件開發 精益軟件開發方法基于“準時生產”原則。 它旨在提高軟件開發速度和降低成本。 精益開發可以歸納為七個步驟。 1. 消除浪費 2. 加強學習 3. 推遲承諾（盡早決定） 4. 提早交貨 5. 賦予團隊權力 6. 建筑誠信 7. 優化整體 ## 看板 看板最初是從日語單詞中出現的，意思是一張卡片，其中包含在完成產品的每個階段都需要在產品上完成的所有信息。 該框架或方法在軟件測試方法中尤其是在敏捷測試中已被廣泛采用。 ### Scrum 與看板 <colgroup><col style="width: 263px;"><col style="width: 276px;"></colgroup> | **Scrum** | **看板** | | * 在 Scrum 技術中，必須分解測試，以便可以在一次沖刺中完成測試。 | * 沒有規定特殊的物品尺寸 | | * 規定了優先產品積壓 | * 優先級是可選的 | | * Scrum 團隊致力于迭代的特定工作量 | * 承諾是可選的 | | 規定了 * 燃盡圖 | * 沒有規定特殊的物品尺寸 | | * 在每個沖刺之間，重置一個 Scrum 板 | * 看板板是永久性的。 它限制了工作流程狀態 中的項目數 | | * 無法向正在進行的迭代添加項目 | * 只要有可用容量，便可以添加項目。 | | * WIP 間接限制 | * 在制品直接限制 | | * 指定了時間框的迭代 | * 時間盒式迭代可選 | ## 敏捷指標： 可以收集的有效使用敏捷的指標是： * 阻力因子 * 數小時內的努力對沖刺目標沒有幫助 * 可以通過減少共享資源的數量，減少非貢獻工作量來提高拖動因子。 * 新的估算值可以通過阻力系數的百分比增加-新的估算值=（舊估算值+阻力系數） * 速度 * 積壓的（用戶故事）數量轉換為 sprint 的可交付功能 * 未添加任何單元測試 * 完成每日構建所需的時間間隔 * 在一次迭代或之前的迭代中檢測到的錯誤 * 生產缺陷泄漏