软件测试模型

几种比较常见的模型汇总：

 

 V模型

    V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。

    V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

　　但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

 

 W模型（也叫双V模型）

   W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

　　W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

　　但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除面临着困惑。

X模型

  X模型是由Marick提出的，他的目标是弥补V模型的一些缺陷，例如：交接、经常性的集成等问题。

    X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

     X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

      但V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。 而且由于X模型从没有被文档化，其内容一开始需要从V模型的相关内容中进行推断，因为它还没有完全从文字上成为V模型的全面扩展。

 

H模型

    V模型和W模型均存在一些不妥之处。如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内是可以交叉进行的，所以，相应的测试之间也不存在严格的次序关系。同时，各层次的测试（、集成测试、系统测试等）也存在反复触发、迭代的关系。

　　为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

瀑布模型（Waterfall Model）

1970年温斯顿•罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的。

瀑布模型核心思想

　　瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采

用结构化的分析与设计方法将逻辑实现与物理实现分开。将划分为制定计划、需求分析、软件设计、程序编写、和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

瀑布模型的优缺点

1、瀑布模型有以下优点

　　1）为项目提供了按阶段划分的检查点。

　　2）当前一阶段完成后，您只需要去关注后续阶段。

　　3）可在中应用瀑布模型。

　　增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

2、瀑布模型有以下缺点

　　1）在项目各个阶段之间极少有反馈。

　　2）只有在项目生命周期的后期才能看到结果。

　　3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

螺旋模型

1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:：

软件过程

螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。

　　螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。

四种象限

　　螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

　　

四种象限

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

　　（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

　　（3）实施工程：实施软件开发和验证；

　　（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

　　螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

优缺点

优点

　　1）设计上的灵活性,可以在项目的各个阶段进行变更。

　　2）以小的分段来构建大型系统,使成本计算变得简单容易。

　　3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

　　4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

　　5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点

　　很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

　　螺旋模型的项目适用：

　　对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！