敏捷測試 - 快速指南

---

---

敏捷測試 - 概述

敏捷是一種迭代式開發方法，開發和測試活動同時進行。測試不是一個單獨的階段；編碼和測試互動式地、增量式地進行，從而產生滿足客戶需求的優質最終產品。此外，持續整合可以儘早發現缺陷，從而節省時間、精力和成本。

敏捷宣言

敏捷宣言由一個軟體開發團隊於 2001 年釋出，強調了開發團隊的重要性、適應變化的需求以及客戶參與。

敏捷宣言是：

我們正在透過實踐和幫助他人實踐來發現更好的軟體開發方法。透過這項工作，我們已經瞭解到：

• 個體和互動高於流程和工具。
• 工作的軟體高於詳盡的文件。
• 客戶合作高於合同談判。
• 響應變化高於遵循計劃。

也就是說，雖然右邊的專案也有價值，我們更重視左邊的專案。

什麼是敏捷測試？

敏捷測試是一種遵循敏捷軟體開發原則的軟體測試實踐。

敏捷測試涉及專案團隊的所有成員，測試人員貢獻了特殊的專業知識。測試不是一個單獨的階段，而是與所有開發階段（如需求、設計和編碼以及測試用例生成）交織在一起。測試貫穿整個軟體開發生命週期。

此外，測試人員與跨職能團隊成員一起參與整個軟體開發生命週期，這使得測試人員能夠根據客戶需求構建軟體，並改進設計和程式碼。

敏捷測試涵蓋所有測試級別和所有型別的測試。

敏捷測試與瀑布測試

在瀑布式開發方法中，軟體開發生命週期活動按順序分階段進行。因此，測試是一個單獨的階段，只有在開發階段完成後才能啟動。

以下是敏捷測試和瀑布測試之間差異的要點：

敏捷測試原則

敏捷測試的原則包括：

• 測試推動專案前進 - 持續測試是確保持續進展的唯一途徑。敏捷測試提供持續反饋，最終產品滿足業務需求。

• 測試不是一個階段 - 敏捷團隊與開發團隊一起測試，以確保在給定迭代期間實現的功能實際上已完成。測試不會留到以後的階段。

• 每個人都測試 - 在敏捷測試中，整個團隊，包括分析師、開發人員和測試人員，都會測試應用程式。每次迭代後，甚至客戶也會執行使用者驗收測試。

• 縮短反饋迴圈 - 在敏捷測試中，業務團隊可以瞭解每個迭代的產品開發情況。他們參與每個迭代。持續反饋縮短了反饋響應時間，從而降低了修復成本。

• 保持程式碼整潔 - 缺陷在同一迭代中提出時就被修復。這確保了在任何開發里程碑上程式碼的整潔。

• 輕量級文件 - 敏捷測試人員使用輕量級文件，而不是詳盡的測試文件：

  • 使用可重複使用的檢查表來建議測試。

  • 關注測試的本質，而不是偶然的細節。

  • 使用輕量級文件樣式/工具。

  • 在探索性測試的章程中捕捉測試思路。

  • 利用文件實現多種用途。

• 利用一個測試工件進行手動和自動化測試 - 相同的測試指令碼工件可用於手動測試和作為自動化測試的輸入。這消除了手動測試文件以及等效的自動化測試指令碼的要求。

• “真正完成”，而不僅僅是“完成” - 在敏捷中，一個功能在開發和測試後才算完成，而不僅僅是開發完成。

• 測試最後 vs. 測試驅動 - 測試用例與需求一起編寫。因此，開發可以由測試驅動。這種方法稱為測試驅動開發 (TDD) 和驗收測試驅動開發 (ATDD)。這與瀑布測試中測試作為最後一個階段形成對比。

敏捷測試活動

專案級別的敏捷測試活動包括：

• 釋出計劃（測試計劃）

  • 對於每個迭代：

  • 迭代期間的敏捷測試活動

• 迴歸測試

• 釋出活動（與測試相關）

迭代期間的敏捷測試活動包括：

• 參與迭代計劃
• 從測試的角度估計任務
• 使用功能描述編寫測試用例
• 單元測試
• 整合測試
• 功能測試
• 缺陷修復
• 整合測試
• 驗收測試
• 測試進度狀態報告
• 缺陷跟蹤

敏捷測試 - 方法論

敏捷是一種迭代式開發方法，整個專案團隊參與所有活動。透過客戶和自組織團隊之間的協作，需求隨著迭代的進展而發展。由於編碼和測試在開發過程中互動式地和增量式地進行，因此最終產品將具有高質量並確保滿足客戶需求。

每次迭代都會產生一個整合的可工作產品增量，並交付進行使用者驗收測試。由此獲得的客戶反饋將作為下一次/後續迭代的輸入。

持續整合，持續質量

持續整合是敏捷開發成功的關鍵。頻繁整合，至少每天整合一次，以便在需要時隨時準備釋出。敏捷中的測試成為所有開發階段的重要組成部分，確保產品的持續質量。來自參與專案的所有人的持續反饋增加了產品的質量。

在敏捷中，溝通至關重要，客戶請求隨時接收。這使客戶滿意，因為所有輸入都被考慮在內，並且在整個開發過程中都有高質量的產品。

敏捷方法論

有幾種敏捷方法論支援敏捷開發。敏捷方法論包括：

Scrum

Scrum 是一種敏捷開發方法，強調以團隊為中心的方法。它提倡整個團隊參與所有專案開發活動。

XP

極限程式設計 (XP) 以客戶為中心，專注於不斷變化的需求。透過頻繁釋出和客戶反饋，最終產品將具有高質量，滿足在過程中變得更清晰的客戶需求。

Crystal

Crystal 基於制定章程、迴圈交付和收尾。

• 制定章程包括組建開發團隊、進行初步可行性分析、制定初步計劃和開發方法。

• 具有兩個或多個交付週期的迴圈交付側重於開發階段和最終整合產品的交付。

• 在收尾期間，將執行部署到使用者環境、部署後審查和反思。

FDD

功能驅動開發 (FDD) 涉及設計和構建功能。FDD 與其他敏捷開發方法論的區別在於，功能是分別在特定且短暫的階段開發的。

DSDM

動態軟體開發方法 (DSDM) 基於快速應用程式開發 (RAD)，並與敏捷框架對齊。DSDM 側重於頻繁交付產品，積極參與使用者，並授權團隊快速做出決策。

精益軟體開發

在精益軟體開發中，重點是消除浪費併為客戶創造價值。這導致了快速開發和有價值的產品。

浪費包括部分完成的工作、不相關的工作、客戶不使用的功能、缺陷等，這些都會導致交付延遲。

精益原則是：

• 消除浪費
• 敏捷學習
• 延後承諾
• 賦能團隊
• 快速交付
• 內建完整性
• 全域性視角

看板

看板關注於工作管理，強調準時制 (JIT) 交付，同時避免團隊成員超負荷工作。任務對所有參與者可見，團隊成員可以從佇列中提取工作。

看板基於：

• 看板（在整個開發過程中都可見且持久）
• 在製品 (WIP) 限制
• 交付週期

敏捷測試方法

無論專案是否採用敏捷方法，測試實踐都經過明確定義，以交付高質量產品。傳統的測試原則經常用於敏捷測試中。其中之一是儘早測試，它關注於：

• 編寫測試用例以表達系統的行為。

• 儘早預防、檢測和消除缺陷。

• 確保在正確的時間、正確的測試級別執行正確的測試型別。

在我們討論的所有敏捷方法中，敏捷測試本身就是一種方法。在所有方法中，測試用例都在編碼之前編寫。

在本教程中，我們將重點關注Scrum作為敏捷測試方法。

其他常用的敏捷測試方法包括：

• 測試驅動開發 (TDD) - 測試驅動開發 (TDD) 基於由測試引導的編碼。

• 驗收測試驅動開發 (ATDD) - 驗收測試驅動開發 (ATDD) 基於客戶、開發人員和測試人員之間的溝通，並由預定義的驗收標準和驗收測試用例驅動。

• 行為驅動開發 (BDD) - 在行為驅動開發 (BDD) 中，測試基於被開發軟體的預期行為。

敏捷測試生命週期

在 Scrum 中，測試活動包括：

• 根據系統預期行為（以測試用例的形式描述）貢獻使用者故事

• 基於測試工作量和缺陷的釋出計劃

• 基於使用者故事和缺陷的衝刺計劃

• 持續測試的衝刺執行

• 衝刺完成後進行迴歸測試

• 報告測試結果

• 自動化測試

測試是迭代的，並且基於衝刺，如下圖所示：

敏捷測試 - 團隊中的測試人員

敏捷開發以團隊為中心，開發人員和測試人員參與所有專案和開發活動。團隊合作最大限度地提高了敏捷專案測試的成功率。

敏捷團隊中的測試人員必須參與並貢獻所有專案活動，同時必須充分利用其測試專業知識。

敏捷測試人員應該具備傳統的測試技能。此外，敏捷測試人員還需要：

• 良好的溝通技巧。

• 能夠積極主動地與團隊成員和利益相關者一起解決問題。

• 能夠對產品進行批判性、面向質量、懷疑性的思考。

• 積極主動地從利益相關者那裡獲取資訊的能力。

• 與客戶和利益相關者有效合作，定義可測試的使用者故事和驗收標準的技能。

• 與開發人員一起編寫高質量程式碼，成為優秀團隊成員的能力。

• 能夠在衝刺時間內使用測試技能，在正確的時間和級別擁有正確的測試用例並有效地執行它們。

• 評估和報告測試結果、測試進度和產品質量的能力。

• 能夠快速響應變化，包括更改、新增或改進測試用例。

• 能夠進行自我組織工作。

• 對持續技能提升的熱情。

• 勝任自動化測試、測試驅動開發 (TDD)、驗收測試驅動開發 (ATDD)、行為驅動開發 (BDD) 和基於經驗的測試。

敏捷團隊中測試人員的角色

敏捷團隊中的測試人員參與所有專案和開發活動，以貢獻最佳的測試專業知識。

敏捷測試人員的活動包括：

• 確保正確使用測試工具。

• 配置、使用和管理測試環境和測試資料。

• 指導團隊成員在測試相關方面的技能。

• 確保在釋出和衝刺計劃期間安排適當的測試任務。

• 理解、實施和更新測試策略。

• 與開發人員、客戶和利益相關者合作，從可測試性、一致性和完整性方面闡明需求。

• 在正確的時間和正確的測試級別執行正確的測試。

• 報告缺陷並與團隊合作解決缺陷。

• 衡量和報告所有適用覆蓋率維度的測試覆蓋率。

• 參與衝刺回顧，主動提出和實施改進。

在敏捷生命週期中，測試人員在以下方面發揮著重要作用：

• 團隊合作
• 測試計劃
• 零衝刺
• 整合
• 敏捷測試實踐

團隊合作

在敏捷開發中，團隊合作是基礎，因此需要以下幾點：

• 協作方法 - 與跨職能團隊成員一起進行測試策略、測試計劃、測試規範、測試執行、測試評估和測試結果報告。結合其他團隊活動貢獻測試專業知識。

• 自我組織 - 在衝刺中進行良好的計劃和組織，透過整合其他團隊成員的專業知識來實現測試目標。

• 授權 - 在實現團隊目標方面做出適當的技術決策。

• 承諾 - 承諾理解和評估客戶和利益相關者所需的產品行為和特性。

• 透明 - 開放、溝通和負責。

• 信譽 - 確保測試策略及其實施和執行的信譽。使客戶和利益相關者瞭解測試策略。

• 樂於接受反饋 - 參與衝刺回顧，從成功和失敗中學習。尋求客戶反饋，並迅速採取適當行動以確保高質量的交付成果。

• 有韌性 - 對變化做出響應。

測試計劃

測試計劃應在釋出計劃期間開始，並在每個衝刺期間更新。測試計劃應涵蓋以下任務：

• 定義測試範圍、測試程度、測試和衝刺目標。

• 確定測試環境、測試工具、測試資料和配置。

• 分配功能和特性的測試。

• 安排測試任務並定義測試頻率。

• 確定測試方法、技術、工具和測試資料。

• 確定先決條件，例如前置任務、專業知識和培訓。

• 確定依賴關係，例如功能、程式碼、系統元件、供應商、技術、工具、活動、任務、團隊、測試型別、測試級別和約束。

• 考慮客戶/使用者重要性和依賴關係來設定優先順序。

• 確定測試所需的時間和工作量。

• 確定每個衝刺計劃中的任務。

零衝刺

零衝刺涉及第一個衝刺之前的準備活動。測試人員需要與團隊合作完成以下活動：

• 確定範圍
• 將使用者故事細分為衝刺
• 建立系統架構
• 計劃、獲取和安裝工具（包括測試工具）
• 為所有測試級別建立初始測試策略
• 定義測試指標
• 指定驗收標準，也稱為“完成”的定義
• 定義退出標準
• 建立Scrum看板
• 設定整個衝刺中測試的方向

整合

在敏捷方法中，高質量的工作產品應該在開發生命週期的任何時間點準備好釋出。這意味著持續整合是開發的一部分。敏捷測試人員需要透過持續測試來支援持續整合。

為此，測試人員需要：

• 瞭解整合策略。
• 識別功能和特性之間的所有依賴關係。

敏捷測試實踐

敏捷測試人員需要為敏捷專案中的測試採用敏捷實踐。

• 結對程式設計 - 兩名團隊成員在同一鍵盤上一起工作。當其中一人進行測試時，另一人進行審查/分析測試。這兩名團隊成員可以是：

  • 一名測試人員和一名開發人員

  • 一名測試人員和一名業務分析師

  • 兩名測試人員

• 增量測試設計 - 測試用例是從使用者故事構建的，從簡單的測試開始，然後轉向更復雜的測試。

• 思維導圖 - 思維導圖是一種以圖形方式組織資訊的圖表。思維導圖可以用作敏捷測試中的有效工具，可以使用它來組織有關必要測試會話、測試策略和測試資料的相關資訊。

敏捷測試 - 活動跟蹤

測試狀態可以透過以下方式進行溝通：

• 在每日站會期間
• 使用標準的測試管理工具
• 透過即時通訊工具

由測試透過狀態確定的測試狀態對於決定任務是否“完成”至關重要。“完成”意味著任務的所有測試都通過了。

測試進度

測試進度可以使用以下方式跟蹤：

• Scrum看板（敏捷任務看板）
• 燃盡圖
• 自動化測試結果

測試進度也直接影響開發進度。這是因為只有在達到驗收標準後，使用者故事才能被移至完成狀態。反過來，這由測試狀態決定，因為驗收標準是由測試狀態來判斷的。

如果測試進度有任何延誤或阻塞，整個團隊將一起討論並協作解決。

在敏捷專案中，變化經常發生。當發生許多變化時，我們可以預期測試狀態、測試進度和產品質量會不斷發展。敏捷測試人員需要將這些資訊提供給團隊，以便能夠在正確的時間做出適當的決策，以保持每個迭代的成功完成。

當發生變化時，它們可能會影響先前迭代中的現有功能。在這種情況下，必須更新手動和自動化測試，以有效地應對迴歸風險。還需要進行迴歸測試。

產品質量

產品質量指標包括：

• 測試透過/失敗
• 發現/修復的缺陷
• 測試覆蓋率
• 測試透過/失敗率
• 缺陷發現率
• 缺陷密度

自動化收集和報告產品質量指標有助於：

• 保持透明度。
• 在正確的時間收集所有相關和必需的指標。
• 無需溝通延遲即可立即報告。
• 允許測試人員專注於測試。
• 過濾指標的濫用。

為了確保整體產品質量，敏捷團隊需要獲得客戶反饋，以瞭解產品是否滿足客戶期望。這需要在每個迭代結束時進行，反饋將作為後續迭代的輸入。

關鍵成功因素

在敏捷專案中，如果敏捷測試成功，就可以交付高質量的產品。

敏捷測試的成功需要考慮以下幾點：

• 敏捷測試基於測試優先和持續測試方法。因此，基於測試後方法構建的傳統測試工具可能不適用。因此，在敏捷專案中選擇測試工具時，需要驗證其與敏捷測試的一致性。

• 透過在開發生命週期的早期自動化測試來減少總測試時間。

• 敏捷測試人員需要保持其速度以適應開發釋出計劃。因此，需要根據產品質量目標，動態地進行測試活動的適當計劃、跟蹤和重新計劃。

• 在專案中，手動測試佔測試的 80%。因此，需要經驗豐富的測試人員加入敏捷團隊。

• 這些經驗豐富的測試人員在整個開發生命週期中的參與使整個團隊專注於滿足客戶期望的優質產品。

  • 定義強調終端使用者預期產品行為的使用者故事。

  • 根據客戶期望，在使用者故事級別/任務級別確定驗收標準。

  • 測試活動的工時和時間估算。

  • 計劃測試活動。

  • 與開發團隊協同工作，確保在前期測試設計的基礎上產出符合需求的程式碼。

  • 測試先行並持續測試，確保在預期時間內達到完成狀態並滿足驗收標準。

  • 確保在衝刺（Sprint）中的所有級別進行測試。

  • 每個衝刺結束時進行迴歸測試。

  • 收集和分析對專案成功有用的產品指標。

  • 分析缺陷，確定哪些需要在本衝刺修復，哪些可以推遲到後續衝刺。

  • 關注從客戶角度來看什麼才是重要的。

Lisa Crispin 已經定義了敏捷測試成功的七個關鍵因素：

• **全團隊參與**——在這種方法中，開發人員培訓測試人員，測試人員培訓其他團隊成員。這有助於每個人理解專案中的每個任務，從而使協作和貢獻獲得最大收益。測試人員與客戶的協作也是一個重要因素，以便在開始時就正確設定他們的期望，並將驗收標準轉化為測試透過所需的標準。

• **敏捷測試思維**——測試人員積極主動地持續改進質量，並與團隊其他成員持續協作。

• **自動化迴歸測試**——設計可測試性，並透過測試驅動開發。從簡單開始，允許團隊選擇工具。準備好提供建議。

• **提供和獲取反饋**——由於這是敏捷的核心價值觀，整個團隊都應該開放反饋。由於測試人員是專業的反饋提供者，因此需要關注相關和必要的資訊。反過來，在獲得反饋後，應適應測試用例的更改和測試。

• **建立核心敏捷實踐的基礎**——關注與編碼並行的測試、持續整合、協作測試環境、增量工作、接受更改、保持協同。

• **與客戶協作**——引出示例、理解和檢查需求對映到產品行為，設定驗收標準，獲取反饋。

• **著眼大局**——使用真實世界的測試資料，透過面向業務的測試和示例驅動開發，並考慮對其他領域的影響。

敏捷測試 - 重要屬性

本章，我們將瞭解敏捷測試的一些重要屬性。

敏捷測試的益處

敏捷測試的益處包括：

• 透過快速、持續、完全測試的產品以及尋求客戶反饋來提高客戶滿意度。

• 客戶、開發人員和測試人員持續互動，從而縮短週期時間。

• 敏捷測試人員參與定義需求，貢獻他們的測試專業知識，重點關注可行性。

• 敏捷測試人員參與評估測試工作量和時間的估算。

• 反映驗收標準的早期測試設計。

• 整個團隊整合測試需求，避免缺點。

• 整個團隊持續關注產品質量。

• “完成”狀態的定義反映了測試透過，確保滿足需求。

• 持續反饋延遲或阻塞，以便能夠立即解決，並付出整個團隊的努力。

• 快速響應不斷變化的需求並儘快適應它們。

• 持續整合驅動的迴歸測試。

• 開發和測試之間沒有時間延遲。遵循測試先行、持續測試的方法。

• 在開發生命週期的早期實施自動化測試，從而減少總測試時間和工作量。

敏捷測試最佳實踐

遵循以下最佳實踐：

• 包含在所有級別具有各種測試型別專業知識的測試人員。

• 測試人員參與需求定義，與客戶協作確定產品的預期行為。

• 測試人員持續與開發人員和客戶共享反饋。

• 測試先行和持續測試方法與開發工作保持一致。

• 及時且持續地跟蹤測試狀態和測試進度，重點關注交付高質量產品。

• 在開發生命週期的早期進行自動化測試以縮短週期時間。

• 利用自動化測試作為一種有效的方法來執行迴歸測試。

敏捷測試中的挑戰

敏捷測試中存在以下挑戰：

• 業務和管理人員未能理解敏捷方法及其侷限性，可能導致期望無法實現。

• 敏捷遵循全團隊參與的方法，但並非每個人都瞭解測試實踐的基本知識。建議測試人員指導其他人，但在實際情況下，由於衝刺（迭代）的時間限制，這可能難以實現。

• 測試先行方法要求開發人員基於測試人員的反饋進行編碼，但在實際情況下，開發人員更習慣於基於來自客戶或業務的需求進行編碼。

• 高質量產品的責任在於整個敏捷團隊，但在初始階段，開發人員可能不會關注質量，因為他們更專注於實施。

• 持續整合需要回歸測試，即使需要自動化，這也需要相當大的工作量。

• 測試人員可以適應敏捷思維模式下的變化，但適應由此產生的測試更改和測試，在衝刺期間難以實現目標。

• 建議儘早進行自動化，以便減少手動測試的工作量和時間。但是，在實際情況下，確定可以自動化的測試並對其進行自動化需要時間和精力。

敏捷測試指南

執行敏捷測試時，請使用以下指南：

• 參與釋出計劃，以確定所需的測試活動並制定測試計劃的初始版本。

• 參與估算會議，以確定測試工作量和持續時間，以便在迭代中容納測試活動。

• 參與使用者故事定義，以確定驗收測試用例。

• 參與每次衝刺計劃會議，以瞭解範圍並更新測試計劃。

• 在衝刺期間持續與開發團隊協作，使測試和編碼能夠在衝刺內順利完成。

• 參與每日站會，並傳達任何測試延遲或阻塞，以便立即得到解決。

• 定期跟蹤和報告測試狀態、測試進度和產品質量。

• 準備好適應變化，並相應地修改測試用例和測試資料。

• 參與衝刺回顧，以瞭解和貢獻最佳實踐和經驗教訓。

• 協作獲取每個衝刺的客戶反饋。

敏捷測試 - 四象限

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

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

單元測試

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

整合測試

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

系統測試

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

使用者驗收測試

• 在每個衝刺結束時和專案結束時進行

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

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

• 衝刺中的使用者故事已預先驗證為可測試的，並具有已定義的驗收標準

測試型別

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

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

支援程式設計和評論產品測試

測試可以用於：

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

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

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

• **僅驗證（評論產品）**——評論產品測試用於發現成品中的不足之處

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

要決定何時執行哪些測試，您需要確定測試是：

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

面向業務的測試

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

面向技術的測試

如果測試能夠回答用技術領域詞彙構成的疑問，則該測試是面向技術的測試。程式設計師根據技術方面的說明來了解需要實現的內容。

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

敏捷測試象限

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

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

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

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

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

• **象限 Q4**——系統或運營驗收級別、面向技術，並關注效能、負載、壓力、可維護性、可擴充套件性測試。可以使用一些專用工具以及自動化測試來進行這些測試。

結合這些，可以將反映**什麼測試——何時測試**的敏捷測試象限視覺化如下：

敏捷測試 - Scrum

Scrum 提倡**全員參與的團隊方法**，即每個團隊成員都必須參與每個專案的活動。Scrum 團隊是自組織的，對專案交付成果負責。決策權交給團隊，從而能夠在適當的時間採取適當的行動，避免任何時間延誤。這種方法還鼓勵充分利用團隊人才，而不是將其限制在單一活動中。測試人員也參與所有專案和開發活動，貢獻他們在測試方面的專業知識。

整個團隊共同參與測試策略、測試計劃、測試規範、測試執行、測試評估和測試結果報告。

協作的使用者故事建立

測試人員參與使用者故事建立。測試人員貢獻他們對系統可能行為的想法。這有助於客戶和/或終端使用者瞭解真實環境中的系統，從而明確他們實際想要的結果。這導致更快地確定需求，並降低後期需求變更的可能性。

測試人員還會提出每個場景的驗收標準，並與客戶達成一致。

測試人員有助於建立可測試的使用者故事。

釋出計劃

整個專案都會進行釋出計劃。但是，Scrum 框架涉及在執行衝刺的過程中獲得更多資訊時的迭代決策。因此，專案開始時的釋出計劃會議不必生成整個專案的詳細釋出計劃。它可以隨著相關資訊的可用性而不斷更新。

並非每個衝刺結束都需要釋出。釋出可以在一組衝刺之後進行。釋出的主要標準是為客戶提供業務價值。團隊根據釋出計劃作為輸入來決定衝刺長度。

釋出計劃是釋出測試方法和測試計劃的基礎。測試人員評估測試工作量並計劃釋出測試。當釋出計劃發生變化時，測試人員必須處理這些變化，並考慮到釋出的更大範圍，獲得充分的測試基礎。測試人員還提供所有衝刺結束後所需的測試工作量。

衝刺計劃

衝刺計劃在每個衝刺開始時進行。衝刺待辦事項列表是從產品待辦事項列表中挑選出來，用於在特定衝刺中實施的使用者故事。

測試人員應該：

• 確定為衝刺選擇的使用者的可測試性
• 建立驗收測試
• 定義測試級別
• 確定測試自動化

測試人員使用衝刺中測試工作量和持續時間的估算值更新測試計劃。這確保了在限時衝刺期間為所需的測試提供時間，並保證了測試工作的責任性。

測試分析

衝刺開始時，當開發人員進行設計和實現的故事分析時，測試人員會對沖刺待辦事項列表中的故事進行測試分析。測試人員建立所需的測試用例——手動測試和自動化測試。

測試

Scrum 團隊的所有成員都應參與測試。

• 開發人員在為使用者故事開發程式碼時執行單元測試。單元測試在編寫程式碼之前，在每個衝刺中建立。單元測試用例源自低級別設計規範。

• 測試人員執行使用者故事的功能和非功能特性。

• 測試人員指導 Scrum 團隊中的其他成員，發揮他們在測試方面的專業知識，以便整個團隊對產品的質量承擔集體責任。

• 衝刺結束時，客戶和/或終端使用者進行使用者驗收測試並向 Scrum 團隊提供反饋。這將作為下一個衝刺的輸入。

• 收集和維護測試結果。

自動化測試

在 Scrum 團隊中，自動化測試非常重要。測試人員投入時間建立、執行、監控和維護自動化測試和結果。由於 Scrum 專案中隨時可能發生變化，測試人員需要適應對已更改功能的測試以及相關的迴歸測試。自動化測試有助於管理與更改相關的測試工作量。所有級別的自動化測試有助於實現持續整合。自動化測試比手動測試快得多，而且無需額外的工作量。

手動測試更側重於探索性測試、產品漏洞和缺陷預測。

測試活動的自動化

測試活動的自動化減少了重複工作的負擔，並降低了成本。自動化

• 測試資料生成
• 測試資料載入
• 將構建部署到測試環境
• 測試環境管理
• 資料輸出比較

迴歸測試

在一個衝刺中，測試人員測試該衝刺中新增/修改的程式碼。但是，測試人員還需要確保在早期衝刺中開發和測試的程式碼也能與新程式碼一起工作。因此，迴歸測試在 Scrum 中非常重要。自動化迴歸測試在持續整合中執行。

配置管理

Scrum 專案中使用使用自動化構建和測試框架的配置管理系統。這允許在將新程式碼檢入配置管理系統時重複執行靜態分析和單元測試。它還管理新程式碼與系統的持續整合。自動化迴歸測試在持續整合期間執行。

需要對手動測試用例、自動化測試、測試資料、測試計劃、測試策略和其他測試工件進行版本控制，並確保相關的訪問許可權。這可以透過在配置管理系統中維護測試工件來實現。

敏捷測試實踐

Scrum 團隊中的測試人員可以遵循以下敏捷實踐：

• **結對程式設計**——兩名團隊成員坐在一起協作工作。這兩個人可以是兩名測試人員，也可以是一名測試人員和一名開發人員。

• **增量測試設計**——隨著衝刺的進行和使用者故事的增加，測試用例也逐步開發。

敏捷指標

在軟體開發過程中，指標的收集和分析有助於改進流程，從而實現更高的生產力、高質量的交付成果和客戶滿意度。在基於 Scrum 的開發中，這是可能的，測試人員必須關注他們需要的指標。

建議了幾種 Scrum 開發指標。重要的指標包括：

• **成功衝刺比率**——**（成功衝刺次數 / 總衝刺次數）* 100**。成功衝刺是指團隊能夠完成其承諾的衝刺。

• **速度**——團隊的速度基於團隊在一個衝刺中獲得的故事點數。故事點是在估計期間計算的使用者故事的度量。

• **專注係數**——**（速度 / 團隊工作能力）/ 100**。專注係數是團隊工作量中導致完成故事的百分比。

• **估計準確性**——**（估計工作量 / 實際工作量）/ 100**。估計準確性是團隊準確估計工作量的能力。

• **衝刺燃盡圖**——剩餘工作量（以故事點或小時為單位）與理想情況下應剩餘的工作量（根據估計）。

  • 如果更多，則意味著團隊承擔的工作量超過了他們的能力。

  • 如果更少，則意味著團隊沒有準確地進行估計。

• **缺陷數量**——衝刺中的缺陷數量。缺陷數量是指軟體中相對於待辦事項的缺陷數量。

• **缺陷嚴重程度**——根據嚴重程度，缺陷可以分為輕微、主要和嚴重。測試人員可以定義分類。

衝刺回顧

在衝刺回顧中，所有團隊成員都將參與。他們分享：

• 進展順利的事情
• 指標
• 改進的空間
• 要應用的行動項

敏捷測試 - 方法

在敏捷測試中，常用的測試方法來自傳統實踐，並符合“儘早測試”的原則。測試用例是在編寫程式碼之前編寫的。重點是缺陷的預防、檢測和消除，在正確的時間和正確級別執行正確的測試型別。

在本節中，您將瞭解以下方法：

• 測試驅動開發 (TDD)
• 驗收測試驅動開發 (ATDD)
• 行為驅動開發 (BDD)

測試驅動開發

在測試驅動開發 (TDD) 方法中，程式碼的開發基於自動化測試用例引導的測試優先方法。首先編寫一個測試用例使其失敗，然後根據該測試用例開發程式碼以確保測試透過。重複該方法，透過程式碼開發進行重構。

可以透過以下步驟瞭解 TDD：

• **步驟 1**——編寫一個測試用例來反映需要編寫的程式碼的功能的預期行為。

• **步驟 2**——執行測試。由於程式碼尚未開發，測試將失敗。

• **步驟 3**——根據測試用例開發程式碼。

• **步驟 4**——再次執行測試。這次，測試必須透過，因為功能已編碼。重複步驟 (3) 和步驟 (4)，直到測試透過。

• **步驟 5**——重構程式碼。

• **步驟 6**——再次執行測試以確保其透過。

重複**步驟 1 - 步驟 6**，新增測試用例以新增功能。每次都會執行新增的測試和之前的測試，以確保程式碼按預期執行。為了使此過程加快，測試是自動化的。

測試可以在單元、整合或系統級別進行。需要確保測試人員和開發人員之間持續溝通。

驗收測試驅動開發

在驗收測試驅動開發 (ATDD) 方法中，程式碼的開發基於驗收測試用例引導的測試優先方法。重點是驗收標準以及測試人員在與客戶、終端使用者和相關利益相關者協作建立使用者故事期間編寫的驗收測試用例。

• **步驟 1**——與客戶和使用者協作，編寫使用者故事的驗收測試用例。

• **步驟 2**——定義相關的驗收標準。

• **步驟 3**——根據驗收測試和驗收標準開發程式碼。

• **步驟 4**——執行驗收測試以確保程式碼按預期執行。

• **步驟 5**——自動化驗收測試。重複**步驟 3 - 步驟 5**，直到迭代中的所有使用者故事都已實現。

• **步驟 6**——自動化迴歸測試。

• **步驟 7**——執行自動化迴歸測試以確保持續迴歸。

行為驅動開發 (BDD)

行為驅動開發 (BDD) 類似於測試驅動開發 (TDD)，重點是測試程式碼以確保系統的預期行為。

在 BDD 中，使用英語等語言，以便對使用者、測試人員和開發人員有意義。它確保：

• 使用者、測試人員和開發人員之間持續溝通。
• 開發和測試內容的透明度。

敏捷測試 - 技術

傳統測試的技術也可以應用於敏捷測試。此外，敏捷專案中還會使用敏捷特有的測試技術和術語。

測試依據

在敏捷專案中，產品待辦事項取代了需求規格說明文件。產品待辦事項的內容通常是使用者故事。非功能性需求也在使用者故事中得到處理。因此，敏捷專案中的測試依據是使用者故事。

為了確保高質量測試，還可以額外考慮以下內容作為測試依據：

• 相同專案或過去專案的先前迭代經驗。
• 系統現有的功能、架構、設計、程式碼和質量特性。
• 當前和過去專案的缺陷資料。
• 客戶反饋。
• 使用者文件。

完成定義 (DoD)

完成定義 (DoD) 是敏捷專案中用於確保衝刺待辦事項中活動完成的標準。DoD 在不同的 Scrum 團隊之間可能有所不同，但在同一個團隊內應保持一致。

DoD 是必要的活動清單，它確保了使用者故事中功能和特性的實現，以及作為使用者故事一部分的非功能性需求。在完成 DoD 清單中的所有專案後，使用者故事達到“完成”階段。DoD 在團隊中共享。

使用者故事的典型 DoD 可以包含：

• 詳細的可測試驗收標準
• 確保使用者故事與迭代中其他使用者故事一致的標準
• 與產品相關的特定標準
• 功能行為方面
• 非功能特性
• 介面
• 測試資料需求
• 測試覆蓋率
• 重構
• 審查和批准要求

除了使用者故事的 DoD 之外，DoD 還需要：

• 在每個測試級別
• 對於每個特性
• 對於每次迭代
• 對於釋出

測試資訊

測試人員需要具備以下測試資訊：

• 需要測試的使用者故事
• 相關的驗收標準
• 系統介面
• 系統預期工作的環境
• 工具可用性
• 測試覆蓋率
• DoD

在敏捷專案中，由於測試不是一個順序活動，並且測試人員應該以協作模式工作，因此測試人員有責任：

• 持續獲取必要的測試資訊。
• 識別影響測試的資訊差距。
• 與其他團隊成員協作解決差距。
• 確定達到測試級別的時間。
• 確保在相關時間執行適當的測試。

功能和非功能測試設計

在敏捷專案中，可以使用傳統的測試技術，但重點是儘早測試。測試用例需要在實現開始之前就到位。

對於功能測試設計，測試人員和開發人員可以使用傳統的黑盒測試設計技術，例如：

• 等價劃分
• 邊界值分析
• 決策表
• 狀態轉換
• 類樹

對於非功能測試設計，由於非功能性需求也是每個使用者故事的一部分，因此只能使用黑盒測試設計技術來設計相關的測試用例。

探索式測試

在敏捷專案中，時間往往是測試分析和測試設計的限制因素。在這種情況下，可以將探索式測試技術與傳統的測試技術結合起來。

探索式測試 (ET) 定義為同時進行學習、測試設計和測試執行。在探索式測試中，測試人員積極控制測試的設計，並在執行測試時使用獲得的資訊來設計新的和更好的測試。

探索式測試有助於適應敏捷專案中的變化。

基於風險的測試

基於風險的測試是基於失敗風險的測試，並使用測試設計技術來降低風險。

產品質量風險可以定義為產品質量的潛在問題。產品質量風險包括：

• 功能風險
• 非功能效能風險
• 非功能可用性風險

需要進行風險分析以評估每個風險的機率（可能性）和影響。然後，對風險進行優先順序排序：

• 高風險需要廣泛的測試
• 低風險只需要粗略測試

根據每個風險的風險級別和風險特徵，使用適當的測試技術設計測試。然後執行測試以降低風險。

Fit 測試

Fit 測試是自動化的驗收測試。可以使用 Fit 和 FitNesse 工具來自動化驗收測試。

FIT 使用 JUnit，但擴充套件了測試功能。HTML 表格用於顯示測試用例。Fixture 是 HTML 表格背後的 Java 類。Fixture 獲取 HTML 表格的內容並在被測專案上執行測試用例。

敏捷測試 - 工作產品

測試計劃在釋出計劃時準備，並在每次衝刺計劃時進行修訂。測試計劃作為測試過程的指南，以便獲得完整的測試覆蓋率。

測試計劃的典型內容包括：

• 測試策略
• 測試環境
• 測試覆蓋率
• 測試範圍
• 測試工作量和進度安排
• 測試工具

在敏捷專案中，所有團隊成員都對產品的質量負責。因此，每個人都參與測試計劃。

測試人員的責任是提供必要的指導，並利用其測試專業知識指導團隊其他成員。

使用者故事

原則上，使用者故事不是測試工作產品。但是，在敏捷專案中，測試人員參與使用者故事的建立。測試人員編寫為客戶帶來價值並涵蓋系統不同可能行為的使用者故事。

測試人員還確保所有使用者故事都是可測試的，並確保驗收標準。

手動和自動化測試

在第一次測試執行中，使用手動測試。它們包括：

• 單元測試
• 整合測試
• 功能測試
• 非功能測試
• 驗收測試

然後自動執行後續執行的測試。

在**測試驅動開發 (TDD)** 中，首先編寫單元測試使其失敗，然後開發和測試程式碼以確保測試透過。

在**驗收測試驅動開發 (ATDD)** 中，首先編寫驗收測試使其失敗，然後開發和測試程式碼以確保測試透過。

在其他開發方法中，測試人員與團隊其他成員協作以確保測試覆蓋率。

在所有型別的過程中，都會進行持續整合，其中包括持續整合測試。

團隊可以決定何時以及自動化哪些測試。即使自動化測試需要付出努力和時間，生成的自動化測試也會顯著減少敏捷專案迭代期間重複的測試工作量和時間。這反過來又促使團隊更多地關注其他所需活動，例如新的使用者故事、更改等。

在**Scrum** 中，迭代的時間是固定的。因此，如果某個使用者故事測試在特定衝刺中無法完成，測試人員可以在每日站會中報告該使用者故事無法在該衝刺中達到“完成”狀態，因此需要推遲到下一個衝刺。

測試結果

由於敏捷專案中的大部分測試都是自動化的，因此工具會生成必要的測試結果日誌。測試人員會檢查測試結果日誌。需要為每個衝刺/釋出維護測試結果。

還可以準備測試摘要，其中包含：

• 測試範圍（測試的內容和未測試的內容）
• 缺陷分析，如果可能的話，還要進行根本原因分析
• 缺陷修復後的迴歸測試狀態
• 問題及相應的解決方案
• 如有任何待處理問題
• 測試策略中需要進行的任何修改
• 測試指標

測試指標報告

在敏捷專案中，測試指標包括每個衝刺的以下內容：

• 測試工作量
• 測試估計準確性
• 測試覆蓋率
• 自動化測試覆蓋率
• 缺陷數量
• 缺陷率（每個使用者故事點的缺陷數量）
• 缺陷嚴重性
• 在同一衝刺中修復缺陷所需的時間（在當前衝刺中逃脫的錯誤修復成本是其 24 倍）
• 在同一衝刺中修復的缺陷數量
• 客戶在衝刺內完成驗收測試

衝刺回顧和總結報告

測試人員還參與衝刺回顧和總結報告。典型內容包括：

• 測試指標
• 測試結果日誌審查結果
• 從測試角度來看，哪些方面做得很好，哪些方面可以改進
• 最佳實踐
• 經驗教訓
• 問題
• 客戶反饋

敏捷測試 - Kanban

可以使用看板概念有效地管理敏捷測試活動。以下內容確保測試在迭代/衝刺內按時完成，從而專注於交付高質量的產品。

• 可測試且大小合適的使用者故事能夠在規定的時間限制內完成開發和測試。

• 在製品 (WIP) 限制允許一次專注於有限數量的使用者故事。

• 直觀顯示工作流程的看板，有助於跟蹤測試活動和瓶頸（如有）。

• 看板團隊協作理念允許在發現瓶頸時立即解決，無需等待。

• 提前準備測試用例，在開發過程中維護測試套件並獲取客戶反饋有助於在迭代/衝刺內消除缺陷。

• 完成定義 (DoD) 被認為是“真正完成”，這意味著只有在測試完成之後，故事才達到完成狀態。

產品開發中的測試活動

在產品開發中，可以使用功能看板來跟蹤釋出。特定釋出的功能被分配到功能看板，該看板直觀地跟蹤功能開發狀態。

釋出中的功能被分解成故事，並使用敏捷方法在釋出中進行開發。

以下敏捷測試活動確保每次釋出以及所有釋出結束時的質量交付：

• 測試人員參與使用者故事建立，從而確保：

  • 透過使用者故事和作為使用者故事一部分的非功能性需求來捕獲系統的所有可能行為。

  • 使用者故事是可測試的。

  • 使用者故事的大小允許在迭代內完成開發和測試（真正完成）。

• 視覺化任務看板：

  • 描述任務的狀態和進度

  • 在出現瓶頸時立即識別

  • 有助於衡量迴圈時間，然後可以對其進行最佳化

• 團隊協作有助於：

  • 整個團隊對高質量產品的責任

  • 在出現瓶頸時立即解決，節省等待時間

  • 所有活動中每項專業技能的貢獻

• 專注於持續整合測試的持續整合

• 自動化測試以節省測試工作量和時間

• 缺陷預防，提前編寫測試用例進行開發，並指導開發人員瞭解系統不同行為的預期：

  • WIP 限制，一次專注於有限數量的使用者故事

• 在開發過程中進行持續測試，以確保在迭代中修復缺陷：

  • 確保測試覆蓋率

  • 保持未解決缺陷數量較低

故事探索

故事探索是在敏捷團隊內部進行的溝通，用於在產品負責人提交故事以供開發驗收時探索對故事的理解。

產品負責人根據系統預期的功能提出故事。開發人員在標記故事為準備驗收之前，會對每個故事進行更多探索。測試人員也會從測試的角度參與溝通，使其儘可能易於測試。

故事的最終確定是基於產品負責人、開發人員和測試人員之間持續不斷的溝通。

估算

估算發生在釋出計劃和每次迭代計劃中。

在釋出計劃中，測試人員提供：

• 所需測試活動的資訊
• 相應的努力估算

在迭代計劃中，測試人員有助於確定在一個迭代中可以包含哪些和多少個故事。該決定取決於測試工作量和測試進度估算。故事估算也反映了測試估算。

在看板中，只有當故事被開發和測試並標記為無缺陷完成時，才能完成“完成完成”狀態。

因此，測試估算在故事估算中扮演著重要角色。

故事計劃

故事計劃在故事被估算並分配到當前迭代之後開始。

故事計劃包括以下測試任務：

• 準備測試資料
• 擴充套件驗收測試
• 執行手動測試
• 進行探索性測試
• 自動化持續整合測試

除了這些測試任務外，可能還需要其他任務，例如：

• 效能測試
• 迴歸測試
• 相關持續整合測試的更新

故事進展

故事進展揭示了開發人員和測試人員之間持續溝通所導致的額外測試需求。在開發人員需要更多實施說明的情況下，測試人員會進行探索性測試。

在故事進展期間進行持續測試，包括持續整合測試。整個團隊都參與測試活動。

故事驗收

當故事達到“完成完成”狀態時，故事驗收完成，即故事已開發和測試並標記為完成。

當與故事相關的所有測試透過或達到測試自動化水平時，則認為故事測試已完成。

敏捷測試 - 工具

在敏捷專案中，測試人員負責以下日常任務：

• 支援開發人員進行編碼，並對系統的預期行為進行澄清。

• 幫助開發人員建立有效且高效的單元測試。

• 開發自動化指令碼。

• 將自動化測試工具/指令碼與持續整合整合，進行迴歸測試。

為了有效快速地執行這些任務，大多數敏捷專案都使用支援程式碼和測試元件持續整合的持續整合 (CI) 系統。

敏捷專案中的測試人員和開發人員可以受益於各種工具來管理測試會話以及建立和提交缺陷報告。除了專門用於敏捷測試的工具外，敏捷團隊還可以受益於測試自動化和測試管理工具。

注意 - 記錄和回放、測試最後、重量級和測試自動化解決方案並非敏捷的，因為：

• 此類工具鼓勵的測試最後工作流程不適用于敏捷團隊。

• 使用此類工具建立的難以維護的指令碼會成為變更的障礙。

• 此類專用工具會產生對測試自動化專家的需求，從而形成資訊孤島。

廣泛使用的工具包括：

敏捷測試自動化工具

有效的敏捷測試自動化工具支援：

• 使用測試優先方法進行早期測試自動化。

• 使用真實的語言和領域特定語言編寫測試自動化程式碼。

• 關注系統的預期行為。

• 將測試的本質與實現細節分開，使其與技術無關。

• 促進協作。

自動化單元測試（使用Junit或NUnit）支援程式碼的測試優先方法。這些是白盒測試，確保設計合理且沒有缺陷。此類測試由開發人員在測試人員的支援下構建，可以獨立於所需的功能。這導致交付的產品可能無法滿足客戶需求，因此沒有業務價值。

透過自動化驗收測試來解決此問題，這些測試是在客戶、其他利益相關者、測試人員和開發人員的協作下編寫的。自動化驗收測試由客戶或產品負責人/業務分析師編寫，反映產品的預期行為。開發人員的參與確保根據需求生成程式碼。但是，如果測試僅關注驗收，則生成的程式碼可能仍然不可擴充套件。

因此，自動化單元測試和自動化驗收測試是互補的，敏捷開發都需要兩者。

支援自動化驗收測試的敏捷工具和框架包括：

• Fit
• Fitnesse
• Concordion
• Ruby
• Cucumber

Fit

Ward Cunningham開發的Fit工具可用於驗收測試自動化。Fit允許：

• 客戶或產品負責人使用Microsoft Word和Microsoft Excel提供產品行為示例

• 程式設計師可以輕鬆地將這些示例轉換為自動化測試。

Fit 1.1支援Java和.NET。

FitNesse

FitNesse是一個wiki，它是一種Web伺服器樣式，允許任何訪問者進行任何編輯，包括更改現有頁面和建立新頁面。簡單的標記語言使您可以輕鬆建立標題，使文字加粗、下劃線和斜體，建立專案符號列表以及執行其他簡單的格式設定。

在FitNesse中，驗收測試自動化如下：

• 將測試表示為輸入資料和預期輸出資料的表格。

• 使用FitNesse將測試表放在您可以編輯的頁面上。

  • 或者，將測試表放在Microsoft Excel中，複製到剪貼簿，然後使用Spreadsheet to FitNesse命令讓FitNesse正確格式化您的表格。

• 執行測試

• 您可以透過測試表中單元格的顏色編碼來獲得測試結果

  • 綠色單元格表示獲得了預期值

  • 紅色單元格表示獲得的值與預期值不同

  • 黃色單元格表示丟擲異常

Cucumber

Cucumber是一個基於行為驅動開發（BDD）框架的工具。主要功能包括：

• 用於編寫Web應用程式的驗收測試。

• 允許以易於閱讀和理解的格式（如純英語）自動化功能驗證。

• 在Ruby中實現，然後擴充套件到Java框架。兩者都支援Junit。

• 支援其他語言，如Perl、PHP、Python、.Net等。

• 可以與Selenium、Watir、Capybara等一起使用。