[敏捷测试之迭代开始.pptVIP

* 第十七章 迭代开始 Owen Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 为什么要开始迭代 迭代模型是RUP（Rational Unified Process，统一软件开发过程)推荐的周期模型。 迭代是循环，往复反馈的一个过程。 理解：我们大家可以这样想：我们开发一个产品，如果不太复杂，会采用瀑布模型，这样几个月过去了，直到最后一天发布时，大家可以见到一个完整的产品。这种模型周期相对短些，成本相对低些。但这样的方式有明显的缺点，假如我们对用户的需求判断的不是很准确时，你工作了几个月甚至是几年，当你把产品拿给客户看时，客户往往会大吃一惊，这就是我要的东西吗？ 如果采用迭代模型：假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。 缺陷：那就是周期长、成本很高。 优势：在应付大项目、高风险项目时——就比如是航天飞机的控制系统时，迭代的成本比项目失败的风险成本低得多（降低项目风险低，成功率高，特别是大型项目），用这种方式明显有优势。 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 迭代的开始 1，迭代计划 了解细节 考虑所有观点 书写任务卡片 确定工作量 2，可测试的故事 3，与客户协作 4，高层次测试和事例 与客户一起审查 与开发人员一起审查 测试用例作为文档 敏捷测试人员在迭代开始时的活动？ Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 17.1.1 了解细节 理想情况下，产品负责人或者客户团队的其它成员参加迭代计划会议，回答大家的问题，并且提供示例来描述每个故事的需求。如果业务方面的人都无法参加，那么团队中工作与客户紧密相关的成员们可以充当客户的代理，比如分析师。 他们会在迭代会议上解释故事的细节，并从客户的角度做决策，或者简单的记录大家的问题以便依次快速回答。 17.1 迭代计划 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 我们在本书中始终强调，最好通过举例子的方式来帮助团队理解每个故事，并把这些示例写成测试用例来驱动开发。按照故事的优先级为他们排序。 故事应该事先经过评估，以保证每个故事能在几天之内完成。如果我们每隔几天就能拿到可测试的小故事，我们肯定不会把它们压到迭代末期才去完成。 敏捷测试人员以及其他团队成员们都应该警惕“范围扩展”的趋势。如果发现一个故事好像越做越复杂了，无需犹豫，赶紧两处红牌警告。Uesr story中的Lisa的团队总是特意找出那些华而不实的或者“最好有”的组件，因为他们并非故事的核心功能。这类功能可以最后再做，如果该故事的实际开发时间比计划时间长，他们也可以暂时不做。 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 17.1.2 考虑所有的观点 作为测试人员，需要从整体的角度考虑每个故事对系统其它部分可能的潜在影响。就像 在产品发布计划会议中那样，站在不同角色立场考虑问题——用户，利益相关者，程序员，技术文档编写者以及每个参与开发功能的人员。 User story：