软件开发模型

目录

软件开发模型（也是软件开发生命周期模型）：

常见开发模型：

常见测试模型：

 测试模型的使用：

软件开发模型（也是软件开发生命周期模型）：

        是软件产品从最初构思到退役的过程。

常见开发模型：

1. 大爆炸模型（直接冲过河去的模型）：一大堆东西（人力和资金）放在一起，巨大的能力释放，要么产生了优秀的产品，要么是一堆废品。

   特点

   1.大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都是几乎没有，所有精力都花在开发软件和编写代码上；

   2.一般，大爆炸模式几乎没有测试，即使有也要挤在产品发布前，通常都会避免在此模式下进行测试。

2. 边写边改模型：摸着石头过河的模型。

   概念	特点
   项目小组在未刻意采用其他开发模式时默认的开发模式；	此种模式没有计划和文档编制，项目能够迅速展现成果，所以比较适合用完就扔的项目；
   它在大爆炸模式基础上更进了一步，至少考虑到了产品需求；	与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重；
   开发小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程，直到觉得足够才发布产品；	软件测试会陷入无休止的循环往复，因为每天都可能在测试新版本。
   此种模式是测试期间最有可能碰到的模型

3. 瀑布模型：制定周密计划的模型。

   概念	特点
   采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，写好文档，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好。	从测试的角度看来，瀑布模式比截止到目前位置的其他模式更有优势；
   	优势1.瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度；
   	优势2：测试对象非常明确，即程序。
   	缺点：在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。

4. 螺旋模型：计划赶得上变化的模型。

   概念	特点
   开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈（边写边改），然后进入下一阶段，重复上述过程，直至得到最终产品。	螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式；
   特别适合于大型复杂系统	软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚，并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员的测试一直都在进行，所以最后一步只是一个验证表明所有部分都没有问题。

5. 敏捷软件开发：其他名称如快速原型、极限编程或进化开发等，核心思想是以人为本，适应变化。

   概念	特点
   个体与交互重于过程和工具：通过过程和工具理解个人和交流的作用；	敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
   可用的软件重于完备的文档：通过全面的文档理解运行的软件；	敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。
   客户协作重于合同谈判：通过合同和谈判得到客户的协作；	敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是敏捷，但这些模式都有三个共同特点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
   响应变化重于遵循计划：在计划的执行中做出对变更的响应

   常见测试模型：

• V模型（对应瀑布模型）：“V”的左端表示传统的瀑布开发模型，“V”的右端表明相应的测试阶段。

• W模型（与螺旋模型相似）：既强调了测试方案设计，也强调了测试执行。伴随公司内测诞生。

• H模型：测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。彻底将测试独立，伴随第三方测试。

特点：

1. 将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰的体现出来。测试贯穿产品整个生命周期，与其他流程并发的进行；
2. 软件测试不仅仅指测试的执行，还包括其他很多的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）；
3. 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
4. 软件测试要尽早准备，尽早执行；
5. 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

• 极限测试（敏捷测试） ：对应敏捷开发模型。

1. 为了满足极限测试的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试；
2. 测试在极限测试中的地位非常重要，所以需要首先创建单元（模块）测试和验收测试，然后才能创建代码库。这种形式的测试称为极限测试；
3. 极限测试模型需要客户参与，高度依赖模块的单元和验收测试：对任何一个递增的代码变更，开发人员都必须进行单元测试，以确保代码库满足其规格说明的要求；单元测试后，用户进行验收测试；

基于极限测试（敏捷测试）的项目步骤：

1. 程序员与客户会晤，决定产品需求并建立使用场景。客户不在场时，程序员进行会晤，将需求分解为独立的任务，并估计完成每项任务所需的时间。程序员向客户提交任务清单和时间估计，并要求客户产生一个功能优先级清单；
2. 每一对程序员依据应用程序的规格说明，对其编程任务生成单元测试用例；
3. 编程小组依据程序员具备的能力，将任务分配给结对的程序员。两位程序员协同工作，在同一台机器开发代码库，对代码进行实时检查。所有代码归程序员所有。遵循一直的系统隐喻，所有的代码看上去都一致。每一对程序员完成其任务，编写出代码库。每一对程序员在所有单元测试通过之前，不断修改和重测他们的代码。所有的结对程序员每天都整合、集成他们的代码库。编程小组发布应用程序的一个预览版本；
4. 客户进行验收测试，要么确认该应用程序，要么提交一份报告指出存在的bug或不足。程序员在验收测试成果的基础上发布一个产品版本。开发人员和编程小组可以随时接触客户，这样可以快速、迅速地解决问题；
5. 程序员根据最新的经验更新时间估计；
6. 不允许加班。如果每周都全力工作了25小时，就不需要加班。在重大发布前的一星期例外。

 敏捷测试要点总结：

1. 敏捷测试是协调测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏捷测试是连续测试；
2. 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然后进行编码，之后执行测试；
3. 敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再有客户进行验收测试。

 测试模型的使用：

1. 不同的软件生命周期模型需要使用不同的测试方法；
2. 应尽可能的去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也实际意义；
3. 各种模型可以适当结合。