敏捷开发与敏捷测试

       敏捷开发：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的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。   分析： 
  由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。   举个例子： 
  开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。 
  开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。（也许更多）。需要处理一些公司突发性的事务等等。 
  所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2－3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。   测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。 2.2 测试用例的审核 
  为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix（Test Case跟踪矩阵），其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足（如某个重点Feature的Test Case不够）的地方能够及时给出意见。 
  另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。   在迭代后期测试要抽时间更新test case。   3. 实施运行测试