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

3.3.4 編寫(xiě)驗收測試用例

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

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

3.4 Sprint 結束和下一個(gè) Sprint 開(kāi)始

在一個(gè) Sprint 周期結束時(shí)，團隊要舉行一個(gè)回顧會(huì )議（Retrospective Meeting）。團隊成員可以在會(huì )議上暢所欲言，指出在過(guò)去一個(gè) Sprint 周期中可行的，不可行的和有待改進(jìn)的地方。待改進(jìn)之處將在項目經(jīng)理監督下于未來(lái)的 Sprint 周期中實(shí)現。

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

如果下一個(gè) Sprint 周期是發(fā)布周期，那么測試人員需要準備執行回歸測試。下面我們來(lái)詳細了解每個(gè)測試活動(dòng)。

3.4.1 重構驗收測試

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

項目實(shí)例：

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

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