软件测试有哪些模型

　　软件测试有哪些模型?在软件质量体系中，为了更好地指导软件开发的全部过程、活动和任务，人们提出了软件开发模型。典型的开发模型有：边做边改模型(Build-and-Fix Model)、瀑布模型(Waterfall Model)、快速原型模型(Rapid Prototype Model)、增量模型(Incremental Model)、螺旋模型(Spiral Model)、演化模型(Incremental Model)、喷泉模型(Fountain Model)、智能模型(四代技术(4GL))、混合模型(Hybrid Model)。但是所有的开发模型都没有把软件测试列进去，这样就无法对软件测试过程进行很好的指导，而随着软件测试的发展，软件测试成为软件质量保证的重要手段之一，软件测试也慢慢地受到公司的重视，于是人们就希望软件测试也像软件开发一样，由一个模型来指导整个软件测试过程。当前最常见的软件测试模型有瀑布模型、V 模型、W 模型、H 模型和X 模型，下面详细介绍。

　　一、瀑布模型

　　1970 年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”，直到20 世纪80 年代早期，它一直是唯一被广泛采用的软件开发模型，瀑布模型是由瀑布开发模型演变而来的。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六项基本活动，其过程是将上一项活动接收的工作对象作为输入，当该项活动完成后会输出该项活动的工作成果，并将该项成果作为下一项活动的输入。该模型规定这六项基本活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。从本质上讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。如果在其中某个阶段有信息未被覆盖或有问题，那么就得返回到上一个阶段，并对这些阶段进行适当的修改才能进入下一个阶段，这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动”到下一个阶段，这也是瀑布模型名

　　称的由来，瀑布模型如图2-3 所示。

　　瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。　　

　　图2-3 瀑布模型

　　瀑布模型的优点如下：

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

2. 　　当前一阶段完成后，只需要关注后续阶段;

　　可在迭代模型中应用瀑布模型，如图2-4 所示。　　

　　图2-4 迭代中的瀑布模型

　　增量迭代应用于瀑布模型，迭代1 解决最大的问题，每次迭代产生一个可运行的版本，同时增

　　加更多的功能，但每次迭代必须经过严格的质量和集成测试。

　　瀑布模型有以下缺点：

• 　　项目中各个阶段之间极少有反馈;

• 　　只有在项目生命周期的后期才能看到结果;

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

　　二、 V 模型

　　V 模型最早是由Paul Rook 在20 世纪80 年代后期提出的，V 模型在英国国家计算中心文献中发布，目的是改进软件开发的效率和效果。它是软件测试最具代表性的测试模型之一。在传统的开发模型中，如瀑布模型，通常把软件测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时软件测试工作会占整个项目周期一半的时间，但是仍然被认为软件测试只是一个收尾工作，而不是主要的工程。故对以前的测试模型进行了一定程度的改进，V 模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开发过程(从分析到设计)的关系，如图2-5 所示。　　

　　图2-5 V 模型

　　V 模型从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别以及测试阶段和开发过程各阶段的对应关系。图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程各阶段。

　　V 模型指出，单元和集成测试是验证程序设计，单元测试主要由白盒测试工程对代码进行测试，但目前国内真正做白盒测试的企业不多。这主要有两大原因：第一，白盒测试投入的成本很高，并且产出不明显，很多企业不希望投入更多的资源去做这项工作;第二，白盒测试对测试工程师的要求较高，在目前系统测试还没有完全成熟的情况下很难真正地开展白盒测试。而集成测试是介于白盒测试与系统测试之间的一种测试，也叫灰盒测试，由于它与白盒测试和系统测试之间没有明显的界限，所以在实际的测试过程中，即使开展集成测试也是由系统测试工程师来完成。

　　系统测试主要验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标，由测试人员和用户进行软件的确认测试和验收测试，以及对需求说明书进行测试，以确定软件的实现是否满足用户需求或合同要求。

　　V 模型存在一定的局限性，它把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。如果不做白盒测试，那么其实都是在系统完成集成后才开始系统测试的，这样需求分析阶段隐藏的问题一直到后期的验收测试才被发现，因此修改缺陷的成本就高了很多。

　　V 模型详细的描述了每个测试阶段所对应验证的对象，单元测试验收的对象是详细测试说明书、集成测试验证的对象是概要设计说明书，系统测试验证的对象是需求说明书。在测试过程中，我们经常说测试的目的就是验证产品是否满足客户的需求，那么如何确保我们的产品是满足客户需求的呢?换一个角度来理解，其实结果是靠过程来保证的，也就是说，如果我们可以确保开发每个阶段的工作是正确的，那么就说明开发出来的产品肯定是满足客户需求的，因为开发每个阶段的工作都是以需求说明书为依据的，所以V 模型有一个优点是其详细地介绍了测试每个阶段所测试验证的依据。

　　由于V 模型是软件开发中瀑布模型的变种，所以它存在和瀑布模型相似的一些问题。由于测试阶段处于软件实现后，这意味着在代码完成后必须有足够的时间预留给测试活动;否则将导致测试不充分，开发前期未发现的错误会传递并扩散到后面的阶段，而在后面发现这些错误时，可能已经很难再修正，从而导致项目的失败。

　　V 模型最大的缺陷就是只把程序作为被测试对象，而需求、说明书等其他规格说明书都未被列为测试对象。

　　总之V 模型具有以下特征：

• 　　(1)测试阶段划分得很清楚。

• 　　(2)每个开发阶段都有相应的测试对其进行验证。

• 　　(3)测试与开发是串行进行的而不是并行，也就是测试需要等开发完成后再开始。

• 　　(4)测试对象只有程序，而不包括需求等其他的说明书。

• 　　(5)V 模型是瀑布模型的变种，瀑布模型存在的问题V 模型也存在。

　　三、W 模型

　　由于V 模型存在一些明显的缺陷，人们就在实际测试过程中对V 模型进行了改进，将V 模型演变为W 模型。W 模型由Evolutif 公司提出，由两个V 字型模型组成，相对于V 模型，W 模型增加了软件各开发阶段中应同步进行的验证和确认活动，如图2-6 所示。

　　W 模型也称之为双V 模型，一个V 是开发的生命同期，另一个V 是测试的生命周期，W 模型与V 模型有一个很大的不同，就是W 模型是一个并行的模型，V 模型是一个串行的模型，W 模型开始是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分更清楚，而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。　　

　　图2-6 W 模型

　　W 模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

　　W 模型有利于尽早全面地发现问题。从需求分析开始测试工程师就参与到项目的测试中，当需求分析完成后，测试工程师就需要参与到需求的验证和确认活动中，并需要提供可测试性需求分析说明书，这样可以尽早地发现需求阶段的缺陷。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。但W 模型也存在局限性，需求、设计、编码等活动被视为是串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一阶段工作，这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W 模型并不能解除测试管理面临的困惑。

　　总之W 模型具有以下特征：

• 　　(1)测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试;

• 　　(2)测试与开发是并行的，从需求测试就应该开始介入;

• 　　(3)提出尽早测试的概念，这样可以降低缺陷修复成本;

• 　　(4)测试对象不仅仅是程序，还包括需求或其他的相关文档。

　　四、 H 模型

　　H 模型将测试活动分离出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图2-7 所示。

　　图2-7 H 模型

　　H 模型提倡者认为测试是一个独立的过程中，所以在H 模型中并没有看到关于开发的过程，而是测试的一个流程，当然这个测试的流程并不像V 模型和W 模型那样有明确的测试区分。

　　H 模型演示了在整个生命周期中某个层次上一次软件测试的“微循环”。当测试条件准备完成，进入测试就绪状态后，所在测试H 模型中有一个测试就绪点，也就是测试有一个准入条件。通常情况下判断测试是否达到准入条件，应该检查以下几部分内容是否已经完成：

　　该开发流程对应的测试策略是否完成：

• 　　测试方案是否完成;

• 　　测试用例是否完成;

• 　　测试环境是否搭建好;

　　相关输入件、输出件是否明确。也就是说，通常我们要检查上面一些内容是否完成，再确定我们是否需要进入下一个阶段的测试。当测试条件成熟，并且测试准备工作已经完成，进入了测试就绪点，测试执行活动才可以进行。

　　H 模型中还有一个“其他流程”的测试，这个观点强调了测试其他不一定要是常见的应用程序也可以其他的内容，这可以理解为整个产品包中所有的对象，包括开发阶段的一些设计流程，这样将测试的范围直接扩展到整个产品包，而非W 模型中提到的代码、需求或其他相关说明书。与V 模型和W 模型不同的是，H 模型的核心是将软件测试过程独立出来，并贯穿产品的整个生命周期，与开发流程并行进行，不需要等到程序全部开发完成才开始执行测试，这充分体现了软件测试要尽早准备、尽早执行的原则。不同的测试活动可以按照某个次序先后进行，当一次测试工作后产品质量无法达到要求时，可以反复进行多次测试。

　　总之H 模型具有以下特征：

　　(1)测试是一个独立的过程;

　　(2)测试达到准入条件，才可以执行;

　　(3)测试对象是整个产品包，而不仅仅是程度、需求或相关说明书。

　　五、2.3.5 X 模型

　　X 模型的基本思想是由Marick 提出的，但是Marick 不建议建立一个替代模型。Robin F Goldsmith引用了Marick 的一些想法，并经过重新组织，形成了“X 模型”。当然这并不是为了和V 模型相对应而选择这样的名字，是由于X 通常代表未知，而Marick 也认为他的观点并不足以支撑一个模型的完整描述，但具备一个模型所需要的主要内容，其中包括了探索性测试(Exploratory Testing)见解，如图2-8 所示。　　

　　图2-8 X 模型

　　Marick 对V 模型提出质疑，他认为V 模型必须按照一定顺序严格执行开发步骤，而这样很可能无法反映实际的实践过程。而众所周知很多项目在立项时需求并不完整，但V 模型还是从需求处理开始，要求对各开发阶段中已经得到的内容进行测试，但它没有规定需要取得多少内容，如果没有任何的需求资料，开发人员知道他们要做什么吗?或者需求不完善，开发工程师做出来的功能就不完善，必须不断地修改。他主张在X 模型中需要足够的需求，并且需求至少进行一次发布。

　　Marick 也质疑单元测试和集成测试的区别，目前在国内真正做单元测试的企业不多，很多企业都是跳过单元测试直接进行集成测试，甚至集成测试也被跳过，直接进行系统测试。而X 模型则没有强制要求在进行集成测试之前，必须对每一个程序片段进行单元测试，但是X 模型并没有提供是否跳过单元测试的判断准则。

　　Marick 认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X 模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。

　　X 模型左边是单元测试和单元模型之间的集成测试，右边是功能的集成测试，通过不断的集成最后成为一个系统，如果整个系统测试没有问题就可以封版发布。这个模型有一个很大的优点是它呈现了一种动态测试的过程中，也就是测试是一个不断迭代的过程中，这更符合企业实际情况，其他模型更像一个静态的测试过程。

　　X 模型提倡公司可以根据自身的实际情况确定是否要进行单元测试和集成测试，并不是所有的研发公司都会先做单元测试和集成测试，更多的是直接做系统测试。在X 模型中还显示了测试步骤，包括测试设计、工具配置、执行测试三个步骤，虽然这个测试步骤并不很完善，但是毕竟将一些主要的内容表现出来了。

　　X 模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。

　　综上，X 模型具有以下特征：

　　(1)公司可以根据自身的情况确定是否要做单元测试，还是直接做系统测试;

　　(2)测试应该是一个不断迭代的过程，直到封版发布;

　　(3)提倡探索性测试。

　　本章主要讲解了关于“软件测试有哪些模型”的内容，大家喜欢的话记得每天来这里和小编一起学习涨薪技能。识别下方二维码，免费领取学习课件、视频哦。(笔芯)　

　　附：川石信息全国校区最新开班时间，课程资料获取13691729932(微信同号)。