• 软件測试系列之软件測试过程模型(四)


                                                     

    回想往昔:

          在软件开发的不断实践过程中。人们积累经验教训,预估未来发展,总结出了非常多的开发模型,比較典型的开发模型有,边做边改模型,瀑布模型,高速原型模型、螺旋模型,增量模型。演化模型,喷泉模型,智能模型,混合模型还有RAD模型以及近期比較流行的。基于网络的面向对象的模型——RUP(RationalUnifiedProcess,统一软件开发过程。

    可是遗憾的是。这些模型中。没有给予測试足够的重视和诠释。所以,才会有后来的软件測试过程模型的诞生。在这些測试模型中,兼顾了软件开发过程,对开发和測试做了非常好的融合。

     

    一、简单了解软件測试过程模型

     

            软件測试和软件开发一样。都遵循软件project原理,遵循管理学原理。

    測试专家通过实践总结出了非常多非常好的測试模型。这些模型将測试活动进行了抽象,明白了測试与开发之间的关系。是測试管理的重要參考根据。今天我主要向大家介绍五种測试模型。分别为:V模型。W模型,H模型,X模型和前置測试模型。接下来。让我们一一分析:

     

    二、逐一认识

     

             每一类分别介绍。历史来源,详细原理,有图有真相。也能够说一下它们的不同之处

     

    V模型

     

                                            

     

    原理:V模型是软件开发瀑布模型的变种。主要反映測试活动与分析和设计的关系,从左到右,描写叙述了主要的开发过程和測试行为。

    V模型的策略既包含低层測试又包含了高层測试,低层測试是为了源码的正确性,高层測试是为了使整个系统满足用户的需求。

    如图所看到的,图中的箭头表示时间方向,左边下降的是开发过程各阶段,与此相相应的是右边上升的部分。即个測试过程的各个阶段。

    它在測试中的地位,就和瀑布模型在开发中的地位一样,是一种最基础的模型,其它模型都是从这个模型演化来的。

     

    价值体现:它很明白地标明了測试过程中存在的不同级别。强调了在整个软件项目开发中须要经历的若干个測试级别。并与每个开发级别相应。

     

    局限性:把測试作为编码之后的最后一个活动。需求分析等前期产生的错误直到后期的验收測试才干发现。忽略了測试的对象不应该只包含程序。没有明白指出对需求、设计的測试。言简意赅的说:没有明白说明早期的測试。不能体现“尽早地和不断地进行软件測试”的原则。

     

     W模型

       

     

    原理:V模型中添加软件各开发阶段应同步进行的測试,别演化为一种W模型,由于实际上开发是“V”,測试也是与此相并行的“V”。W模型能够说是V模型自然而然的发展。

    它强调,測试伴随着整个软件开发周期,并且測试的对象不不过层序。需求,功能和设计相同要測试。

     

    价值体现:我们能够觉得。W模型。測试与开发是同步进行的,从而有利于今早的发现问题。强调了測试计划等工作的先行和对系统需求和系统设计的測试。

     

    局限性:仍把开发活动看成是从需求開始到编码结束的串行活动。仅仅有上一阶段完毕后,才干够開始下一阶段的活动。不能支持迭代,自发性以及变更调整。

     

    H模型

                                                   

     

    原理:H模型将測试活动从开发流程全然独立出来,使測试流程形成一个全然独立的流程,将測试准备活动与測试运行活动清晰地体现出来。

    图中的流程只演示了再整个生产周期中某个层次上的一次測试“微循环”。图中的其它流程能够是随意开发流程。也就是说,只要測试条件成熟了,測试准备活动完毕了,測试运行活动就能够进行了。

     

    价值体现:软件測试是一个独立的流程。贯穿于产品的整个生命周期。与其它流程并发的进行。

    软件測试原则“尽早准备,尽早运行”;强调測试是独立的,仅仅要測试准备完毕。就能够运行測试。

     

    局限性:本模型太过于模型化。重点在于理解当中的意义指导实际工作,而模型本身并无太多的可运行的指导意义。

     

    X模型

                           

     

    原理:X模型左边描写叙述的是针对单独程序片段所进行的相互分离的编码和測试,此后。将进行频繁的交接,通过集成终于合成为可运行的程序。这一点在图的右上方得以体现。并且这额可运行程序还须要进行測试。已通过集成測试的成品能够进行封版并提交给用户,也能够作为更大规模和范围内集成的一部分。

    同一时候,X模型还定位了探索性測试,如图右下方所看到的。这是不进行事先计划的特殊类型的測试。比如“我就这么測一下,结果会怎么样”。

     

    价值体现:探索性測试。可以帮助有经验的測试人员在測试计划之外发现很多其它的软件错误。

     

    局限性:探索性測试可能对測试造成人力、物力和財力的浪费。对測试员的熟练程度要求比較高。

     

    前置測试模型

                     

     

    原理:前置測试模型将开发和測试的声明周期整合在一起,表示了项目声明周期从開始到结束之间的关键行为。

    它对每个交付内容进行測试(图中的椭圆框表示了其它一些要測试的对象),在设计阶段进行測试计划和測试设计,让验收測试和技术測试保持相互独立。总之。它是一个将測试和开发紧密结合的模型,该模型提供了轻松的方式。能够使你的项目加快素的。。

     

    价值体现:前置測试能给须要使用測试技术的开发者、測试人员、项目经理和用户等带来非常多不同于传统方法的内在的价值。与曾经的方法中非常少划分优先级所不同的是,前置測试用较低的成本来及早发现错误,并且充分强调了測试对确保系统的高质量的重要意义。

    它不仅能节省时间,并且能够降低那些令开发者十分厌恶的反复工作。

     

    三、总结

     

             在这些模型中,V模型强调了在整个软件项目开发中须要经历的若干个測试级别,可是它没有明白指出应该对软件的需求、设计进行測试,在这一点上。W模型得到了补充。

    可是W模型和V模型一样没有专门针对測试的流程说明。随着软件測试的不断发展。第三方測试已经独立出来这个时候,H模型就得到了相应的体现,表现为測试独立。X模型和前置測试模型又在此基础上添加了很多不确定的因素处理情况,这就相应了实际情况中,项目常常变更的情况发生。

            总而言之,在实际的项目中,我们要合理应用这些模型的长处,比方在W模型下,合理运用H模型的思想进行独立的測试。或者在前置測试模型中,參考X模型的一个程序片段也须要相关的集成測试的理论等。将測试和开发紧密结合,寻找最适合的測试方案。


  • 相关阅读:
    【java多线程】队列系统之说说队列Queue
    【传输协议】什么是CA证书
    5.1 javassist基本使用
    第四章 dubbo内核之aop源码解析
    第三章 dubbo内核之ioc源码解析
    2.2 dubbo-spi源码解析
    2.1 jdk-spi的实现原理
    第一章 第一个dubbo项目
    第零章 dubbo源码解析目录
    macOS Sierra10.12.5 显示允许任何来源
  • 原文地址:https://www.cnblogs.com/liguangsunls/p/6721836.html
Copyright © 2020-2023  润新知