以上的思考讓測試人員對系統的隱含假設更加清晰：
首先，系統應該能夠在高峰時候處理 200 條搜索請求和 1000 個鼠標點擊事件。
其次，用戶可以在已經查找到的內容中繼續查找
最后，系統提供一個商戶類別清單;如果用戶選擇商戶類別而忘記具體名字，系統提供模糊查詢。
在敏捷開發中，這些假設可以作為用戶故事記錄下來，從而指導未來系統的開發和測試。
3.2.2 設計概要的驗收測試用例
定義完一系列用戶故事后，測試人員就可以著手設計概要的驗收測試用例。正如我們在前文論述，不同于單元測試，驗收測試檢查系統是否滿足客戶的預期，也就是用戶故事是否能夠實現。于是，測試人員可以根據每條用戶故事來擴展，尋找其中的“動作”，然后為每條“動作”制定正例和反例。
項目實例：
| 動作 | 數據 | 期待的結果 |
|---|---|---|
| 搜索 | 一組能成功搜索到的（類別，位置）數據 | 在該類別和位置條件下的一組商戶信息 |
| 搜索 | 一組不能成功搜索到的（類別，位置）數據 | 空列表 |
3.3 迭代 Sprint 階段
當一個 Sprint 周期正式開始時，項目經理將制定該周期的具體開發和測試任務。在定期的 Sprint 計劃會議(Planning Meeting)上，每位團隊成員都要提供自己在未來一個 Sprint 周期中的休假和培訓計劃。另外，每個團隊可以根據各自團隊成員的能力和工作經驗，適當設定一個工作負載值(Load Factor)。比如，我們團隊的工作負載值為 75%，也就是說每個人平均每天工作 6 小時(以 8 小時計算)。接著，大家就可以開始分配任務。
當開發團隊開始編碼和單元測試時，測試人員的工作重點包括：估算驗收測試的時間、估算測試框架的搭建、詳細設計驗收測試和編寫驗收測試代碼。第兩個主要活動一般在項目初期的 Sprint 周期中完成。其他的三個主要活動將在接下來的多個 Sprint 周期中視情況迭代進行。下面我們將具體介紹每個主要活動。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
