软件测试模型

1、目录1、 V 模型 . 错误！未定义书签。2、 W 模型 . 错误！未定义书签。3、 H 模型 . 错误！未定义书签。4、 X 模型 . 错误！未定义书签。5、其他测试模型. 错误！未定义书签。1、瀑布模型 . 错误！未定义书签。2、原型模型 . 错误！未定义书签。3、螺旋模型 . 错误！未定义书签。1背景知识：目前主流的 软件生命周期模型或软件开发过程模型 有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发 (RAD)以及统一过程 (RUP)等，这些模型对于软件开发过程具有很好的指导作用， 但是在这些过程方法中， 软件测试的地位和价值并没有体现出来， 也没有给软件测试以足够的重视， 利用这些模型无法更好地指导测试实践。 软件测试是与软件开发紧密相关的一系列有计划、系统性的活动， 显然软件测试也需要测试模型去指导实践。 下面先对主要的模型做一些简单的介绍，再补充软件生命周期做介绍。1、V模型V 模型是最具有代表性 的测试模型。 V 模型最早是由 Paul Rook 在 20 世纪 80 年代后期提出的， V 模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果

2、。在传统的开发模型中，比如瀑布模型，通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段， 尽管有时测试会占用整个项目周期一半的时间， 但是有人仍认为测试只是一个收尾工作， 而不是主要的工程。V 模型是软件开发瀑布模型的变种， 它反映了测试活动与分析和设计的关系 ，从左到右，描述了基本的开发过程和测试行为， 明确地标明了测试工程中存在的不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 如图5-1 所示。2图1 V模型图图 1 V 模型图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。V 模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了确保源代码的正确性，高层测试是为了使整个系统满足用户的需求。V 模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求； 应当验证系统设计， 检测系统功能、 性能的质量特性是否达到系统设计的指标； 由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试， 以确定软件的实现是否满足用户需求或

3、合同的要求。V 模型存在一定的局限性， 它仅仅把测试过程作为在需求分析、 概要设计、详细设计及编码之后的一个阶段。 容易使人理解为测试是软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。类比记忆： 此模型与软件开发模式中的线性模型 （典型的瀑布模型） 有相似的不足，在瀑布模型中， 测试阶段处于软件实现后， 这意味着必须在代码完成后有足够的时间预留给测试活动， 否则将导致 测试不充分， 开发前期未发现的错误会传3递并扩散到后面的阶段，而在后面发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。2、W模型V 模型的局限性在于没有明确地说明早期的测试， 不能体现“尽早地和不断地进行软件测试”的原则 。在 V 模型中增加软件各开发阶段应同步进行的测试，被演化为一种 W模型，因为实际上开发是 V，测试也是与此相并行的 V。基于“尽早地和不断地进行软件测试”的原则， 在软件的需求和设计阶段的测试活动应遵循 IEEE std1012-1998 软件验证和确认 (V&V)的原则。一个基于 V&V原理的 W模型示意图如图 2 所示。图2

4、W模型图相对于 V 模型， W模型更科学。 W模型可以说是 V 模型自然而然的发展。W模型强调测试伴随着整个软件开发周期， 而且测试的对象不仅仅是程序， 需求、功能和设计同样要测试 。这样，只要相应地开发活动完成， 我们就可以开始执行测试，可以说， 测试与开发是同步进行的 ，从而有利于尽早地发现问题。以需求为例，需求分析一完成， 就可以对需求进行测试， 而不是等到最后才进行针对需求的验收测试。如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。 另外还有一个很大的益处是， 测试者可以在项目中4尽可能早地面对规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，还可以尽可能早地找出缺陷所在， 从而帮助改进项目内部的质量。 参与前期工作的测试者可以预先估计问题和难度， 这将可以显著地减少总体测试时间， 加快项目进度。根据 W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例， 这些工作对测试的各级别都有意义。当需求被提交后， 就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后， 就需要确定测试条件来查找该阶段的设计缺陷。W模

5、型也是有局限性的。 W模型和 V模型都把软件的开发视为需求、 设计、编码等一系列串行的活动。 同样，软件开发和测试保持一种 线性的前后关系 ，需要有严格的指令表示上一阶段完全结束， 才可以正式开始下一个阶段。 这样就无法支持迭代、 自发性以及变更调整 。对于当前很多文档需要事后补充， 或者根本没有文档的做法 ( 这已成为一种开发的文化 ) ，开发人员和测试人员都面临同样的困惑。类比记忆： W模型相当两个 V 模型的叠加 ，一个是开发的 V，一个是测试的 V，由于在项目中开发和测试的是同步进行， 相当于两个 V是并列同步的进行的， 测试在一定程度是随着开发的进展而不断向前进行。3、H模型V 模型和 W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、 设计和编码阶段， 但实践告诉我们， 严格的阶段划分只是一种理想状况。 试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以， 相应的测试之间也不存在严格的次序关系。 同

6、时，各层次之间的测试也存在 反复触发、迭代和增量关系 。其次， V 模型和 W模型都没有很好地体现测试流程的完整性。5为了解决以上问题， 提出了 H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型如图 3 所示。图3H模型图H 模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。图中的流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如， SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以( 或者说需要 ) 进行了。概括地说， H模型揭示了：1）软件测试 不仅仅指测试的执行，还包括很多其他的活动。2）软件测试是一个 独立的流程，贯穿产品整个生命周期，与其他流程 并发地进行。3）软件测试要 尽早准备，尽早执行 。4）软件测试是根据被测物的不同而分层次进行 的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。在 H 模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。4、X模型6Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代模型。这里我很冒昧地引用了一些Marick的想法，并重新经过组织，形成了“X模型 ”。其实并不是为了和V 模型相对应而选择这样的名字，而是由于其它一些原因： X 通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（ exploratory testing）这样的亮点。我还需要在使用文字方面也向Marick道歉，因为认同 Marick观点的无疑大多属于X 一代（ X 一代）。另外，我勾画了一张 X 形状的示意图，我相信该图能够很好地以另一种表达形式来体现Marick的观点。

《软件测试模型》由会员新**分享，可在线阅读，更多相关《软件测试模型》请在金锄头文库上搜索。