• 软件测试模型综述


     引言

      当前主流的软件生命周期模型有瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发以及Rational统一过程等,但是在这些模型中,软件测试的价值并未得以足够的体现,也没有给软件测试以足够的重视,利用这些模型无法更好的指导测试工作。本文对软件测试模型做了循序渐进的剖析,可以让测试相关工作者能够对软件测试模型能够有个较为深入的认识。
      二、模型解读
      1.V模型
      在软件测试方面,V模型是最广为人知的模型,他是软件开发瀑布模型的变种,V模型是在快速应用开发(RapApplicationDevelopment,RAD)模型基础上演变而来,由于整个开发过程构成一个V字型而得名,详情见图1。尽管很多富有实际经验的测试人员还是不太熟悉V模型,或者其它的模型。V模型已存在了很长时间,和瀑布开发模型有着一些共同的特性,由此也和瀑布模型一样地受到了批评和质疑。V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
      
    图1.V模型
      从上图可以看出:
      强调软件开发的协作和速度,反映测试活动和分析设计关系,将软件实现和验证有机结合起来;
      明确界定了测试过程存在不同的级别;
      明确了不同的测试阶段和研发过程中的各个阶段的对应关系;
      仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析;
      系统设计的验证,一直到后期的验收测试才被发现;
      没有明确的说明早起的测试,不能体现“尽早地、不断地进行软件测试”的原则。
      2.W模型
      V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试,演化为W模型(如下图)。在模型中不难看出,开发是“V”,测试是与此并行的“V”,详情见图2。基于“尽早地和不断地进行软件测试”的原则,在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认(V&V)》的原则。
      W模型由Evolutif公司提出,相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。
      W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支持迭代、自发性以及变更调整。
      W模型,也就是双V模型,并不是在V模型上又搞出一个来,而是开发阶段与测试设计阶段同步进行,比如在进行需求分析,软件功能规格说明书评审,软件功能规格说明书基线化后,系统测试计划,方案,用例也设计完毕,接着是概要设计与集成测试设计,详细设计与单元测试设计,直到编码完成后,进行代码审查,继续执行单元测试、集成测试、系统测试。
      
    图2.W模型
      从上图可以看出:
      W模型强调测试伴随着整个软件开发周期,测试与开发并行进行,有利于尽早发现问题;
      测试的对象不单单是程序,还有需求和设计等;
      W模型有利于即时了解项目的测试风险,及早制定应对方案,加快项目进度;
      软件开发和测试保持着线性的前后关系,无法支持迭代、自发性以及需求变更调整等。
    3.H模型
      在H模型中,软件测试的过程活动完全独立,形成一个独立的流程,贯穿于整个软件的声明周期,与其他流程并发进行,某个测试点准备就绪后就可以从测试准备阶段进行到测试执行阶段,软件测试活动可以根据被测产品的不同而分层进行,详情如图3。
      图3.H模型
      从上图可以看出:
      软件测试不仅仅指测试的执行,还包括很多其他的活动;
      软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行;
      软件测试要尽早准备,尽早执行;
      软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的;
      把软件的开发视为需求、设计、编码等一系列串行活动,但实际上,这些活动可以交叉的进行,严格的划分只是一种理想状态。
      4.X模型
      X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序,详情见图4。
      
    图4.X模型
      从上图可以看出:
      X模型并不要求在进行作为创建可执行程序(图中右上方)的一个组成部分的集成测试之前,对每一个程序片段都进行单元测试(图中左侧的行为);
      X模型没能提供是否要跳过单元测试的判断准则;
      X模型填补了V模型和X模型的缺陷,并可为测试人员和开发人员带来明显的帮助;
      X模型还定位了探索性测试(右下方)。这是不进行事先计划的特殊类型的测试,诸如“我这么测一下结果会怎么样?”,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
      X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见,X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。
    作者简介:
    王超,花名于龙,2007年计算机软件与理论专业硕士毕业,先后在微软全球技术支持中心、SAP中国研究院、淘宝网从事自动化测试用例开发、自动化框架研发、测试平台建设、信息系统研发、测试工具研发团队管理等工作,目前负责支付宝产品质量部测试工具研发团队。
    版权声明:本文出自支付宝产品质量部 王超(花名于龙),51Testing软件测试网原创出品,未经明确的书面许可,任何人或单位不得对本文进行复制、转载或镜像,否则将追究法律责任。
  • 相关阅读:
    Tomcat启动过程[更详细]
    数据库连接池原理
    Druid
    Spring的注解积累
    React基础知识
    mac里git项目删除.DS_Store文件
    GET请求参数为中文时乱码分析
    npm中package.json详解
    前后端分离工具之ftl-server
    利用performance属性查看网页性能
  • 原文地址:https://www.cnblogs.com/lingling99/p/3580110.html
Copyright © 2020-2023  润新知