概念
測試的設計開發過程與正在構建的應用程式一樣複雜和艱巨。如果未能儘早開始，測試或者不夠完善，或者會導致需要在開發時間表上附加一個長時間的測試和錯誤修正時間表，這將有違疊代開發的初衷。此外，測試計畫和設計活動可以揭示應用程式定義中的故障和缺陷。這些問題越早得以解決，對整個時間表造成的影響就越小。評價過程中發現的問題可以在本次疊代解決，也可以留待下次疊代解決。通過核實已經實施的需求來評測疊代的完全程度，是評價的主要任務之一。疊代之間始終存在著某種“需求蠕變”，您需要意識到其存在並能夠對其加以管理。
執行測試的方式取決於多種因素：您的套用領域、預算、公司策略和風險承受能力以及職員。對於測試的投資多少取決於在具體環境中評價質量和承受風險的方式。
各種測試概念對照表
| 測試概念名稱 | 目標 | 範圍 | 所有人 | 是否該持續集成 | 工具 | 備註 |
| 單元測試 | 驗證原始碼單元能夠正確工作 | class | 開發人員 | 是 | JUnit | 應該產生100%的代碼覆蓋率報告 |
| 功能測試 | 面向代碼，通過組件內示例數據測試特徵 | class | 開發人員 | 是 | JUnit | 應該模擬依賴接口 |
| 集成測試 | 依賴一定的環境進行一些路徑覆蓋測試 | components | 開發人員 | 可選 | JWebUnit TestNG | 如果測試很快並且環境依賴可以很容易的自動安裝，可以包含在持續集成中 |
| 冒煙測試 | 確保關鍵功能運行 | application | 開發人員 | 否 | JWebUnit TestNG | 代碼提交給測試人員前運行，對於web-app模組等同於集成測試 |
| 回歸測試 | 尋找回歸的bugs，即只在新版本上出現的bugs。 | application | 測試人員 | 否 | Selenium | 重新運行之前版本運行過的測試 |
| 完備性測試 | 集中在修復的bugs和新特性上 | application | 測試人員 | 否 | Selenium | 為新特性增加新的測試用例 |
| 系統測試 | 針對功能需求規範（FRS）、系統需求規範（SRS）測試整個系統 | application platform | 測試人員 | 否 | Selenium | 可能包括更多測試，像可用性測試 |
| 平台測試 | 在不同的硬體和軟體平台上運行 | application platform | 測試人員 | 否 | Selenium | |
| 性能測試 | 通過採集套用數據消除瓶頸 | application platform | 開發人員 | 否 | JMon，ab， httperf，JMeter | |
| 負載測試 | 暴露非表面bugs，確保達到性能指標 | application platform | 團隊 | 否 | ab，siege httpref | 負載測試有時叫做大數據量測試，或者耐力測試 |
| 壓力測試 | 通過耗盡資源或者刪除資源來盡力破壞系統 | application platform | 測試人員 | 否 | ab，httpref | 也叫拒絕測試或者恢複測試 |
| 用戶驗證測試 | 需要的業務功能和正確的系統功能的一個最終驗證，在類實際環境中進行 | application platform | 客戶 | 否 | 客戶決定 | 也叫拒絕測試或者恢複測試 |
