常见的开发模式模式

前言

主要是了解常见的开发模式,从而理解测试贯穿在整个软件研发过程中的定位。

一、常见的开发模式

引用林子老师梳理的开发模式,主要包括以下几种:

测试流程通常跟软件开发流程紧密相关,需要基于开发流程来定义。基于企业不同的开发模式,测试流程常见的有以下几种情况:

  • 传统瀑布开发模式下的独立测试阶段,发生在开发完成之后;
  • 基于V模型开发模式下的测试,同样是发生在开发完成之后的阶段;
  • 基于W模型开发模式下的测试,更早进入到开发阶段,测试与开发并行,但是顺序性的,过程不可逆;
  • 基于敏捷开发模式的测试,左移到需求阶段,在软件开发全生命周期进行持续的测试,并且右移到生产环境,给软件开发提供全流程的质量反馈,做到缺陷预防,降低成本,提高软件交付质量。

大概展开几种开发模式说明一下测试在其中的位置。

1、传统瀑布开发模式

应该是起源最早的一种开发模式,但并无完全意味着落后。这种开发模式将项目从头到尾划分为不同的阶段(需求,设计,实施,验证,上线,维护),显而易见的好处是流程和依赖关系清晰,缺点也同样明显,几乎没有反馈和修改的机会,很可能等到发现无法轻易修正的偏离时已经晚了。

在这样的开发模式下,测试一般都是在开发自测并提交代码后才会介入,也就意味着等到产品开发完成以后,才开始了解需求、实现并进行测试测试和验收。

2、基于V模型开发模式

区别于传统的瀑布开发模式,对于设计、开发、测试提出了更加精细的要求,将整个软件研发流程拆解为了不同阶段进行实现,包括:需求 -> 系统 -> 组件(子系统) -> 细节实现,呈现出一个金字塔的形状。

对应到测试活动,每一个开发活动都会对应一个测试活动,可以看做是一种有效的测试分层,不同层次的测试覆盖了不同层次的实现。但是依然没有能够解决反馈周期长的问题,等到系统测试或验收测试时发现问题,很有可能已经晚了。

3、基于W模型开发模式

可以理解为是V模型的Plus加强版,将开发和测试的工作各增加了一倍,测试要从需求分析阶段开始接入,开发也要一直负责到整个产品交付完成。这就要求,开发人员不仅具备对软件产品单点的理解,还需要对整个产品有所认知。同理,测试人员不能仅关注整系统级别的构架和功能实现,还需要下沉到单个功能点的具体实现。

发展到这里,仅仅考虑单个产品1个版本的交付流程,W模型已经做的几乎尽善尽美。同时也对研发人员提出了极高的要求,开发和测试同时在需求阶段介入,以便于尽早识别风险和偏离条目。

那么还是回到上面那个问题,有没有更好的问题反馈机制?现在我们尽可能地减少了问题,但假如还是发生了问题,那么应该怎么办。

在这里插入图片描述

附:H模型(严格意义上来说,仅是1种单纯的测试模式,非开发模式)

其实这个模式没啥好谈的,看到了就顺便学习下。总的来说就是,这是一个把测试活动独立出来的模型,重点讲述穿插在研发流程中的测试活动如何执行。具体的如何执行也很简单,第一步分析出测试就绪点,即什么时候可以开始测试。第二步,准备测试,比如测试设计、环境准备。第三步,执行测试验收。

个人感觉这就是个空架子(也可能没看到原文未理解精髓),什么时候进行测试这一点完全没有明确,脱离整个开发流程谈测试,就是纸上谈兵,没有实现何谈验证?哪怕是瀑布模式,也会告诉你需要等到开发完成后测试开始介入。

 

 4、敏捷开发流程

这个就不用介绍了,大家都应玩的很多,讲究的就是快速迭代,积极反馈,将原本冗长的研发流程分割成了多个小的阶段进行交付,可以看做是多个W模式的横向堆叠,组成了整个版本的交付。

 未完待续

 

 

  • 1
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值