常见的开发模型和测试模型

1. 软件的生命周期

软件开发阶段的生命周期

需求分析->计划->设计->编码->测试->运维

软件测试阶段的生命周期

需求分期->测试计划->测试设计与开发->执行测试->测试评估

2. 开发模型

1. 瀑布模型

可以看到,这个模型和我们上面的软件开发生命周期很相似

采用的是线性的结构,所以错误发现的越晚,项目的成本开销就增加的越多

缺点:可运行的产品很迟才能被看到,测试又比较置后,所以往往会失去及早修正错误的机会

优点:非常适用于需求比较固定的小项目开发

2. 螺旋模型

乍一看很吓人,但是我们只要慢慢研究是可以理解的

从需求分析开始,沿着线一直往后走,其实就是瀑布模型,只是在相应的部分添加了风险分析和原型,

这里我把他拉直,读者可以和瀑布模型进行对比,从而更好地记忆螺旋模型

优点:多次进行风险评估,从而可以更好的接收变化

缺点:团队是需要花费资金去招聘风险分析师的,所以增大了开发成本

适用于:软件规模较大,并且变化可能性较大的项目

3. 增量模型

将项目进行模块化,使每一个模块都可以独立开发和独立上线,供用户使用

优点:可以较快的将项目交付给用户使用

适用于:需求明确,各个功能直接可以明确划分模块

4. 迭代模型

迭代功能就是将功能不断完善,比如我们现在要开发一款聊天软件,第一次迭代,我们就想把聊天室的基础功能实现,然后发布.完成之后,再进行第二次迭代,比如推出朋友圈功能之类的,然后发布,继续迭代

优点:可以最快速的交付产品,并且可以不断完善

适用类型:需求不是特别明确,后期可以根据需求迭代

5. 敏捷模型

在说敏捷模型之前,我们先来读一下敏捷模型宣言:

总结一下:就是说团队的沟通大于开发工具和开发流程,最终的目标就是得到可交付的软件

特点:轻流程 轻文档 重目标 重产出

敏捷模型有三个重要的角色和五个重要的会议

角色:产品经理,项目经理,研发团队

会议:需求发布会议,迭代计划会议,每日会议,演示会议,回顾会议

具体流程如上

产品经理先整理用户需求,然后开需求发布会议,确定本次迭代的需求,然后开迭代计划会议,把需求拆分成一个个的任务,确定工时,最后明确负责人.然后每天项目经理开展每日例会,主要处理三个问题:1.昨天做了什么?2.今天打算做什么?3.在开发过程中,遇到了什么问题.在每日例会结束后开演示会议,对产品进行演示,最后开总结回顾会议

3. 测试模型

1. V模型

V模型是将测试后置的一种模型,测试的标准是前面对用的阶段,比如软件单元测试是根据软件详细设计来完成的

2. W模型

W模型是V模型的升级版,在软件开发初期,测试工作就已经介入了,有利于更早的发现和解决问题,但是如果前面的需求发生变化,W模型并不能很好的进行变化,是一种重流程的模型,不太支持敏捷模型