一、 软件开发模型
1 为什么学习软件开发模型
了解开发能够更好的有针对性的做好测试。
2 什么是软件开发模型
软件开发生命周期模型是软件产品从最初构思到退役的过程。
3 常见的开发模型
大爆炸模型
边写边改模型
瀑布模型
螺旋模型
敏捷开发模型
3.1 大爆炸模型
3.1.1 直接冲过河去的模型
一大堆东西（人力和资金）放在一起，巨大的能量释放，要么产生了优秀的产品，要么是一堆废品。
3.1.2 特点
大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都几乎没有，所有精力都花在开发软件和编写代码上；
一般，大爆炸模式几乎没有测试，即使有也要挤在产品发布前，通常都会避免在此模式下进行测试。
3.2 边写边改模型
3.2.1 摸着石头过河的模型
项目小组在未刻意采用其他开发模式时默认的开发模式。
它在大爆炸模式基础上更进了一步，至少考虑到了产品需求。
开发小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程，直到觉得足够才发布产品。
此种模式是测试期间最有可能碰到的模型。
3.2.2 特点
此种模式没有计划和文档编制，项目能够迅速展现成果，所以比较适合用完就扔的项目；
与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重；
软件测试会陷入无休止的循环往复，因为每天都可能在测试新版本。
3.3 瀑布模型
3.3.1 制定周密计划的模型
1970 年，温斯顿•罗伊斯（WinstonRoyce）提出，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。
采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，写好文档，项目小组组织审查，并决定是否进入下一步。如项目未准备好进入下一步，就停滞下来直到准备好。
3.3.2 特点
从测试的角度看来，瀑布模式比截至到目前为止的其他模式更有优势。
瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。
测试对象非常明确，即程序。
在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活
动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。
3.4 螺旋模型
3.4.1 计划赶得上变化的模型
1988 年，Barry Boehm（巴利•玻姆）提出。
开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品。
特别适合于大型复杂系统。
3.4.2 特点
螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员地测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。
3.5 敏捷开发模型
3.5.1 起源
另外一些名称：如快速原型、极限编程或进化开发等。
2001 年初，在犹他州的 Snowbird，由于看到很多软件开发团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有轻量化、快速工作、响应变化能力的价值观和原则，他们称自己为“敏捷联盟”。
3.5.2 敏捷宣言
敏捷联盟在随后几个月，他们创建了一份价值观声明，也就是敏捷联盟宣言。
这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。
通过过程和工具理解个人和交流的作用
通过全面的文档理解运行的软件
通过合同和谈判得到客户的协作
在计划的执行中做出对变更的响应
敏捷开发的核心思想是：以人为本，适应变化。
3.5.3 特点
敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。
敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是敏捷。但这些模式都有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
