什么是敏捷开发？

　　敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。迭代包括需求的开发和测试，典型的迭代周期是2周。目标随着从上一次的迭代中学到的东西、反馈以及商业机会而调整。

　　在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受测试通过才算完成。

　　敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。

　　在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。

　　为什么以前的开发模式不再适用？

　　以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因素的影响经常改变。

　　以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段会随之而过。

　　以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。

　　以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确性的判断。

　　测试的作用

　　有价值的东西有么提供产品，要么提供服务。那么测试提供什么产品或服务呢？有人认为测试提供调试通过的、经过测试的软件。这是错误的回答。测试不提供产品，测试提供信息，关于开发过程中的软件的状态的信息，以便基于这些信息做出决定。

　　敏捷测试的挑战之一：测试员是否不再需要了？

　　既然有开发人员做单元测试了，我们还需要测试员吗？有些项目团队采用了敏捷开发方式后把测试员都给解雇了，然后过了不久他们就后悔了。

　　测试可以是除QA或测试员外的人来做，例如业务分析员，有些项目团队让开发人员来做接受性测试。

　　但是有专门的测试员带来两个好处：

　　1、 专注于用户使用而不是软件的技术实现

　　2、 专注于发现软件的错误而不是证明完整性

　　敏捷测试的挑战之二：测试不完整的软件

　　频繁的迭代产生的测试版本很多时候是不完整的，测试员如何测试这些不完整的代码呢？

　　“故事”应该从业务价值方面来定义。一个“故事”应该在一个迭代周期内完成。好的“故事”是不容易定义出来的，但是差的故事对测试人员的影响比对开发人员的影响还要大。有时候测试人员需要帮助定义“故事”。

　　敏捷测试的挑战之三：可接受性测试是否过于简单了？

　　测试人员如果只是做可接受性测试，只是验证“故事”是否完整，岂不是太简单了？这样怎么能做好测试呢？

　　其实，每一个迭代都需要额外的测试，而不仅仅是局限于验证“故事”的完整性。

　　在迭代测试中还要按需进行下面类型的测试 ：

　　探索性测试：同时学习系统、计划和执行测试，寻找bug、遗漏的特性和改进的机会。

　　组合交互测试：专注于特性之间的交互。

　　场景测试：模拟真实世界的场景进行测试。

　　疲劳测试：长时间地执行软件

　　业务循环测试：基于月末、季度末等业务循环的边界来执行场景

　　压力测试：对系统施加强大的压力进行测试