敏捷測試 - 技術

---

---

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

測試依據

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

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

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

完成的定義

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

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

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

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

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

• 在每個測試級別
• 對於每個功能
• 對於每個迭代
• 用於釋出

測試資訊

測試人員需要掌握以下測試資訊：

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

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

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

功能和非功能測試設計

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

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

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

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

探索性測試

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

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

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

基於風險的測試

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

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

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

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

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

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

Fit測試

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

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