常见的开发模型和测试模型
软件的生命周期
软件开发阶段的生命周期
需求分析->计划->设计->编码->测试->运维
软件测试阶段的生命周期
需求分期->测试计划->测试设计与开发->执行测试->测试评估
开发模型
瀑布模型
可以看到,这个模型和我们上面的软件开发生命周期很相似
采用的是线性的结构,所以错误发现的越晚,项目的成本开销就增加的越多
缺点:可运行的产品很迟才能被看到,测试又比较置后,所以往往会失去及早修正错误的机会
优点:非常适用于需求比较固定的小项目开发
螺旋模型
乍一看很吓人,但是我们只要慢慢研究是可以理解的
从需求分析开始,沿着线一直往后走,其实就是瀑布模型,只是在相应的部分添加了风险分析和原型,
这里我把他拉直,读者可以和瀑布模型进行对比,从而更好地记忆螺旋模型
优点:多次进行风险评估,从而可以更好的接收变化
缺点:团队是需要花费资金去招聘风险分析师的,所以增大了开发成本
适用于:软件规模较大,并且变化可能性较大的项目
增量模型
将项目进行模块化,使每一个模块都可以独立开发和独立上线,供用户使用
优点:可以较快的将项目交付给用户使用
适用于:需求明确,各个功能直接可以明确划分模块
迭代模型
迭代功能就是将功能不断完善,比如我们现在要开发一款聊天软件,第一次迭代,我们就想把聊天室的基础功能实现,然后发布.完成之后,再进行第二次迭代,比如推出朋友圈功能之类的,然后发布,继续迭代
优点:可以最快速的交付产品,并且可以不断完善
适用类型:需求不是特别明确,后期可以根据需求迭代
敏捷模型
在说敏捷模型之前,我们先来读一下敏捷模型宣言:
总结一下:就是说团队的沟通大于开发工具和开发流程,最终的目标就是得到可交付的软件
特点:轻流程 轻文档 重目标 重产出
敏捷模型有三个重要的角色和五个重要的会议
角色:产品经理,项目经理,研发团队
会议:需求发布会议,迭代计划会议,每日会议,演示会议,回顾会议
具体流程如上
产品经理先整理用户需求,然后开需求发布会议,确定本次迭代的需求,然后开迭代计划会议,把需求拆分成一个个的任务,确定工时,最后明确负责人.然后每天项目经理开展每日例会,主要处理三个问题:1.昨天做了什么?2.今天打算做什么?3.在开发过程中,遇到了什么问题.在每日例会结束后开演示会议,对产品进行演示,最后开总结回顾会议
测试模型
V模型
V模型是将测试后置的一种模型,测试的标准是前面对用的阶段,比如软件单元测试是根据软件详细设计来完成的
W模型
W模型是V模型的升级版,在软件开发初期,测试工作就已经介入了,有利于更早的发现和解决问题,但是如果前面的需求发生变化,W模型并不能很好的进行变化,是一种重流程的模型,不太支持敏捷模型