敏捷开发及敏捷测试(很详细的说明).docVIP

敏捷开发与敏捷测试 来源: cnblogs敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。 　　我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。 　　敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。 改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。” 　　敏捷开发提出了以下遵循的原则： 　　· 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 　　· 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 　　· 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 　　· 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 　　· 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 　　· 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 　　· 工作的软件是首要的进度度量标准。 　　· 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 　　· 不断地关注优秀的技能和好的设计会增强敏捷能力。 　　· 简单是最根本的。 　　· 最好的构架、需求和设计出于自组织团队。 　　· 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 　　敏捷测试流程总结： 　　在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。 　　根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程： 　　1. 验证需求和设计 　　需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（2）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性. 　　在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。 　　产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来 　　2. 测试计划，测试用例 　　2.1 编写计划、测试用例 　　在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。 　　好处： 　　客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。 　　问题： 　　在user story的时间估算