以上的思考让测试人员对系统的隐含假设更加清晰：
首先，系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。
其次，用户可以在已经查找到的内容中继续查找
最后，系统提供一个商户类别清单;如果用户选择商户类别而忘记具体名字，系统提供模糊查询。
在敏捷开发中，这些假设可以作为用户故事记录下来，从而指导未来系统的开发和测试。
3.2.2 设计概要的验收测试用例
定义完一系列用户故事后，测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。
项目实例：
| 动作 | 数据 | 期待的结果 |
|---|---|---|
| 搜索 | 一组能成功搜索到的（类别，位置）数据 | 在该类别和位置条件下的一组商户信息 |
| 搜索 | 一组不能成功搜索到的（类别，位置）数据 | 空列表 |
3.3 迭代 Sprint 阶段
当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议(Planning Meeting)上，每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外，每个团队可以根据各自团队成员的能力和工作经验，适当设定一个工作负载值(Load Factor)。比如，我们团队的工作负载值为 75%，也就是说每个人平均每天工作 6 小时(以 8 小时计算)。接着，大家就可以开始分配任务。
当开发团队开始编码和单元测试时，测试人员的工作重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。
文章来源于领测软件测试网 https://www.ltesting.net/
