從一個實例詳解敏捷測試的最佳實踐(15)

3.3.4 編寫驗收測試用例

敏捷開發不提倡撰寫太多的文檔，提倡直接編寫測試用例。此外，測試人員和客戶應取得良好的溝通，將這些需求總結下來，轉化成驗收測試用例。如果資源充足，最好對驗收測試用例建立版本控制機制。

考慮到需求在每一輪 Sprint 周期中會不斷得變化，測試團隊要控制測試的自動化率，正確估計未來功能的增減。自動化率過高會導致后期大量測試代碼需要重構，反而增加很多工作量。

3.4 Sprint 結束和下一個 Sprint 開始

在一個 Sprint 周期結束時，團隊要舉行一個回顧會議（Retrospective Meeting）。團隊成員可以在會議上暢所欲言，指出在過去一個 Sprint 周期中可行的，不可行的和有待改進的地方。待改進之處將在項目經理監督下于未來的 Sprint 周期中實現。

由于敏捷開發倡導增量開發，當新的 Sprint 開始時，測試團隊需要根據新 Sprint 周期的開發進度及時重構驗收測試。如果新 Sprint 周期沒有具體的新功能開發，測試團隊可以將精力集中在執行驗收測試和尋找缺陷上。

如果下一個 Sprint 周期是發布周期，那么測試人員需要準備執行回歸測試。下面我們來詳細了解每個測試活動。

3.4.1 重構驗收測試

正如上文所提及，敏捷開發是以迭代方式進行的，功能在每次迭代中推陳出新。于是，驗收測試用例經常需要修改或者添加，相應的驗收測試代碼也需要刪減。這部分工作如果時間花銷很大，最好在估算的時候一并提出。

項目實例：

在下一個 Sprint 周期中，我們需要實現之前沒有實現的“模糊查找”功能。測試人員要在新的 Sprint 周期中更新原來的驗收測試用例，在測試“搜索”模塊中添加模糊查找測試。重新估算的測試任務參加下表：

原文轉自：https://www.ibm.com/developerworks/cn/rational/r-cn-agiletestexplain/