1、瀑布模型是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，
代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
2、迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
什么是迭代式开发？
每次只设计和实现这个产品的一部分,
逐步逐步完成的方法叫迭代开发,
每次设计和实现一个阶段叫做一个迭代.
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、
固定长度（如3周）的小项目，被称为一系列的迭代。
每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，
并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
再通过客户的反馈来细化需求，并开始新一轮的迭代。
迭代式开发的优点：
1、降低风险
2、得到早期用户反馈
3、持续的测试和集成
4、使用变更
5、提高复用性
螺旋开发，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷软件开发又称敏捷开发， 是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
- 人和交互 重于过程和工具。
- 可以工作的软件 重于求全而完备的文档。
- 客户协作重于合同谈判。
- 随时应对变化重于循规蹈矩。
其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。
人员彼此信任 人少但是精干 可以面对面的沟通
项目的敏捷开发：
敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果；
关注业务优先级； 检查与调整。
最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，
因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
大规模的敏捷软件开发尚处于积极研究的领域。
四者对比区别：
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.
按照测试模式来分类：
瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索测试等。
传统的瀑布模型： 
优点：
强调需求、设计的作用；前一阶段完成后，只需关注后续阶段；
为项目提供了按阶段划分的检查点，里程碑清晰；文档规范
缺点：
难以适用需求的频繁变化；项目周期后段才能看到成果；
强制的里程碑、完成时间点；文档工作量大。
V模型： 
W模型： 
X模型： 
H模型： 
敏捷测试：
Agile Testing–遵循敏捷宣言的一种测试实践。
敏捷宣言：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比较中，后者并非全无价值，但我们更看重前者。
特点：
强调从客户角度进行测试；重点关注迭代测试新功能，不再强调测试阶段；尽早测试，不间断测试，具备条件即测试；强调持续反馈；预防缺陷重于发现缺陷。
敏捷测试 vs 传统测试: 
基于脚本的测试-SBT：
Script-based Testing
Scripted Testing(ST)
Exploratory Testing(ET)
探索式测试(ET):完全抛开测试脚本的测试。它是一种测试风格、思维而不是一种测试技。
探索式测试的优点：
1.更能激发测试人员的创造性和工作乐趣
2.增加了发现新的或较深入Bug的可能性
3.在较短时间内找到更多Bug以及对SUT做一个快速的评估
4.有利于更加有效的实施自动化
5.更加适用于敏捷项目
6.减少了在简单、繁复上用例的无谓编写时间
探索式测试的缺点：
1.测试管理上有局限性，较难协调和控制
2.对于Bug的重复利用和重复上作用有限
3.对测试人员的测试技能和业务知识深度依赖较大
4.只有在SUT已完全可用的前提下才更有作用
5.ET的生产率很难定义
6.ET本身较难进行自动化
局部探索式测试：输入、状态、代码路径、用户数据、执行环境。
全局探索式测试：漫游测试法—–商业区、旅馆区、历史区、旅游区、娱乐区、破旧区。
执行探索式测试：
Know You Mession—>Learning Session—>Coverage Session—>Deep Session—>Close Session
基于风险的测试-RBT：
Risk-based Testing
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。
哪些是风险：质量风险、管理风险、风险级别=风险可能性*风险严重度。
识别风险：
可能性：复杂性、时间压力、高变更率、技能水平、地理分散度。
严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任。
风险要素分=Sum(单项权重*得分)
RBT的优点：
基于模型的测试-MBT：
Model-based testing is software testing in which test cases are derived in whole or in part from a model that describe some(usually fnctional) aspects of the system under test(SUT).
http://blogs.msdn.microsoft.com/sechina/2009/11/18/123
主要的MBT工具：
Spec Explore(Microsoft)
GraphWalker(OpenSource) http://graphwalker.github.io/
Tcases(OpenSource) http://github.com/Cornutum/tcases
Modeljunit(OpenSource) http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit