软件测试模型

《软件测试模型》由会员分享，可在线阅读，更多相关《软件测试模型（20页珍藏版）》请在金锄头文库上搜索。

1、由安博测试空间技术中心提供目录1、V模型22、W模型43、H模型54、X模型65、其他测试模型81、瀑布模型112、原型模型123、螺旋模型13背景知识：目前主流的软件生命周期模型或软件开发过程模型有:瀑布模型、原型模型、 螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程 (RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是在这些过程方 法中，软件测试的地位和价值并没有体现出来，也没有给软件测试以足够的重视, 利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系 列有计划、系统性的活动，显然软件测试也需要测试模型去指导实践。下面先对

2、主要的模型做一些简单的介绍，再补充软件生命周期做介绍。1、V模型V模型是最具有代表性的测试模型。V模型最早是由Paul Rook在20世纪 80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发 的效率和效果。在传统的开发模型中，比如瀑布模型，通常把测试过程作为在需求分析、概 要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整 个项目周期一半的时间，但是有人仍认为测试只是一个收尾工作，而不是主要的 工程。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关 系，从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存 在的不同级别，清

3、楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 如图5-1所示。需求分析验收测试1S要设计y详织设计、编码系统测试集廉测试单元测试图1 V模型图图IV模型图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此 相对应的是右边上升的部分，即测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了 确保源代码的正确性，高层测试是为了使整个系统满足用户的需求。V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程 序的执行是否满足软件设计的要求;系统测试应当验证系统设计，检测系统功能、 性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件

4、的确认测 试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户 需求或合同的要求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、 详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个 阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到 后期的验收测试才被发现。类比记忆：此模型与软件开发模式中的线性模型（典型的瀑布模型）有相似的不 足，在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足 够的时间预留给测试活动，否则将导致测试不充分，开发前期未发现的错误会传递并扩散到后面的阶段，而在后面发现这些错误时，可能已经

5、很难回头再修正, 从而导致项目的失败。2、W模型V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和丕断 地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试, 被演化为一种W模型，因为实际上开发是V，测试也是与此相并行的V。基于“尽 早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵 循IEEE stdl012-1998软件验证和确认(V&V)的原则。一个基于V&V原理的W模型示意图如图2所示。图2 W模型图相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、 功

6、能和设计同样要测试。这样，只要相应地开发活动完成，我们就可以开始执行 测试，可以说，则试与开发是同步进行的，从而有利于尽早地发现问题。以需求 为例，需求分析一完成，就可以对需求进行测试，而不是等到最后才进行针对需 求的验收测试。如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档 还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，还可 以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测 试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进 度。根据W模型的要

7、求，一旦有文档提供，就要及时确定测试条件，以及编写测 试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级 别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来 查找该阶段的设计缺陷。W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、 编码等一系列串行的活动。同样，软件开发和测试保持一种线性的前后关系，需 要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无 法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本 没有文档的做法（这已成为一种开发的文化），开发人员和测试人员都面临同样的 困惑。类比记忆：W模型

8、相当两个V模型的叠加，一个是开发的V，一个是测试的V， 由于在项目中开发和测试的是同步进行，相当于两个V是并列同步的进行的，测 试在一定程度是随着开发的进展而不断向前进行。3、H模型V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的 开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之 间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软 件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分 只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计 的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的

9、测 试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现 测试流程的完整性。为了解决以上问题，提出了 H模型。它将测试活动完全独立出来，形成一个完全 独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型如图3所 Z示O图3 H模型图H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。 图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其 他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条 件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。概括地说，H模型揭示了：1）软件测试不仅仅指测试的执行，

10、还包括很多其他的活动。2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进 行。3）软件测试要尽早准备，尽早执行。4）软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是 按照某个次序先后进行的，但也可能是反复的。在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与 其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段 进入测试执行阶段。4、X模型Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代 模型。这里我很冒昧地引用了一些Marick的想法，并重新经过组织，形成了X 模型。其实并不是为了和V模型相对应

11、而选择这样的名字，而是由于其它一些 原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完 整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性 测试(exploratory testing)这样的亮点。我还需要在使用文字方面也向Marick 道歉，因为认同Marick观点的无疑大多属于X 一代(X代)。另外，我勾画 了一张X形状的示意图，我相信该图能够很好地以另一种表达形式来体现 Marick的观点。图2-X模型示意图由于X模型从没有被文档化，其内容一开始需要从在V模型的相关内容中进行 推断，这在Marick的相关文章中已有体现。这里关于X模型的论述比较

12、简短, 因为它还没有完全从文字上成为V模型的全面扩展，而且我不想在这里重复在软件测试：不可忽略的阶段文章中所提到的很多测试技术的概念。Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的5、前置测试模型前置测试是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式, 可以使你的项目加快速度。前置测试模型体现了以下的要点：开发和测试相结合前置测试模型将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束 之间的关键行为。并且表示了这些行为在项目周期中的价值所在。如果其中有些行为没有得 到很好的

13、执行，那么项目成功的可能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。对每一个交付内容进行测试每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测 试的内容。在图中的被圈框表示了其它一些要测试的对象，包括可行性报告、业务需求说明， 以及系统设计文档等。这同V模型中开发和测试的对应关系是相一致的，并且在其基础上 有所扩展，变得更为明确。前置测试模型包括2项测试计划技术，这也是属于上述21项需求测试技术中的一部分。 其中的第一项技术是开发基于需求的测试用

14、例。这并不仅仅是为以后提交上来的程序的测试 做好初始化准备，也是为了验证需求是否是可测试的。这些测试可以交由用户来进行验收测 试，或者由开发部门做某些技术测试。很多测试团体都认为，需求的可测试性即使不是需求 首要的属性，也应是其最基本的属性之一。因此，在必要的时候可以为每一个需求编写测试 用例。不过，基于需求的测试最多也只是和需求本身一样重要。一项需求可能本身是错误的， 但它仍是可测试的。而且，你无法为一些被忽略的需求来编写测试用例。第2项技术是定义验收标准。在接受交付的系统之前,用户需要用验收标准来进行验证。 验收标准并不仅仅是定义需求，还应在前置测试之前进行定义，这将帮助揭示某些需求是否

15、正确，以及某些需求是否被忽略了。在设计阶段进行计划和测试设计设计阶段是做测试计划和测试设计的最好时机。在V模型中，验收测试最早被定义好，并在最后执行，以验证所交付的系统是否真正 符合用户业务的需求。与V模型不同的是，前置测试模型认识到验收测试中所包含的3种成份，其中的2种 都与业务需求定义相联系：即定义基于需求的测试，以及定义验收标准。但是，第三种则需 要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作 定义所组成，这些定义包括：如何判断验收标准已经达到，以及基于需求的测试已算成功 完成。技术测试主要是针对开发代码的测试，例如V模型中所定义的动态的单元测试，集成 测试和系统测试。另外，前置测试还提示我们应增加静态审查，以及独立的QA测试。QA测试通常跟随在系统测试之后，从技术部门的意见和用户的预期方面出发，进行最 后的检查同样的还有特别测试。我们取名特别测试，并把该名称作为很多测试的一个统称, 这些测试包括负载测试、安全性测试、可用性测试等等，这些测试不是由业务逻辑和应用 来驱动的。对技术测试最基本的要求是验证代码的编写和设计的要求是否相一致。一致的意思是系 统确实提供了要求提供的，并且系统并没有提供不要求提供的。技术测试在设计阶段进行计 划和设计，并在开发阶段由技术部门来执行。6、测试模型的使用前面我们介