測試是敏捷開發過程重要的環節，自始自終測試貫穿于每個迭代。Scott W. Ambler 認為就整個產品的敏捷開發生命周期可以分為 4 個階段，即初始階段，項目的建設階段，產品發布階段和產品的維護階段，在關鍵的項目建設階段中，測試被分成兩個部分，Confirmatory 測試和 Investigative 測試。 1 下面，我們來講講迭代的測試的這兩個方面。
圖 3. 敏捷測試生命周期
Confirmative 測試就是對 build 的有效性和關鍵的功能是否正確進行驗證，測試人員依據測試用例和測試腳本的完整測試是工作的重心。原文中的 Confirmative 測試包含了開發人員的單元測試（必不可少的重要開發活動）和被稱之為 Agile Acceptance Testing 的測試部分，這段時間的測試任務用來保障迭代的必須輸出的質量�；镜墓δ�、非功能的任務，但凡是在迭代開始時制定的計劃中承諾的高優先級需求，哪怕是很繁瑣的細節工作都要被充分的測試和驗證。
Investigative 測試是對 Confirmative 測試的補充和是更廣泛的測試活動，測試團隊在完成 Confirmative 測試后的時間用來做這部分測試，它包含功能測試，文檔測試和系統測試以及和其他產品、環境之間產生的必然的 Integration 測試，還有個非常有趣的測試活動叫做 Exploratory 測試，筆者認為這部分測試是測試人員創造性的采用多種不同途徑去嘗試測試產品。就好比“猴子敲鍵盤”一樣，測試員使用各種手段來考驗 build 和產品的穩定和正確性等。
圖 4. 敏捷測試的 Incremental Testing
我們在敏捷項目開發的過程中使用了定制的測試流程，我們同樣有相同的兩部分測試，即 Confirmative 和 Investigative 兩部分。不同的是，我們原則的將這兩部分測試都放在當前迭代的計劃內完成。原因是，敏捷測試團隊針對當前迭代的任務計劃本應服務于當前的產品，過去的迭代產物，或者因為需求變更不再適用，又或者因為未解決的質量缺陷使得實際測試效果不佳。而同時，因為 Product Owner 和 STAKEHOLDER 的期望是團隊能夠高效的完成當前迭代的任務，完成更高優先級的工作，每個迭代的考核亦非常清晰。為了完成服從當前的高優先級任務，計劃，也為了 STAKEHOLDER 更好的關注和幫助當前問題的及時解決，測試人員對以往 Build 的測試應應合理的計入先前迭代的任務而不是當前迭代計劃。倘若真要測試以往的產品而不是最新的，敏捷測試的管理也將變得有些困難，同時測試團隊所關注的問題也只能是過時的，只能成為團隊的低優先級的問題。這不是與團隊整體的目標背離嗎？因此，我們建議測試團隊使用我們改進后的敏捷增量測試模型，即在當前迭代僅僅完成當前迭代的計劃，而所有測試都需要圍繞最新的產品 Build 進行。
圖 5. 定制的 Incremental Testing
在我們新的增量測試模型中 Confirmative 測試包含對需求的靜態測試，開發人員做的單元測試，以及 Build 驗證測試，功能測試（僅限于對當前迭代功能）和重要的其他類型測試。通過了 Confirmative 測試的產品 Build 就可以作為在迭代結束時發布了。而為了產品擁有更好的質量，也為了完成對那些較低優先級的質量驗證的需求得以確保成功的實現，我們需要針對性的做系統測試，壓力，并發，安全甚至全球化的測試，這部分我們把它叫做 Investigative 測試。還需要強調的是，為了保障產品的最終穩定，為了產品不會出現在代碼重構后的質量回歸現象，我們將回歸測試（Regression Test）放在這個階段，用以涵蓋對以往關鍵功能的再度驗證。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
