开发模型和测试模型

1. 开发模型

1.1 瀑布模型

瀑布模型是其他模型的基础框架
start—>需求分析---->计划----->设计----->编码----->测试----->End(其实就是软件开发的生命周期)
特点:线性的开发流程
缺陷:测试被后置。①风险往往到测试阶段才显露,失去了早纠正的机会;②测试不充分,把缺陷遗留给了用户;③不能够应对需求的变化
最大缺陷:可以运行的产品很迟才可以被看到
使用场景:需求固定的小项目,不拥抱变化

1.2 螺旋模型

螺旋模型就是在铺膜模型的基础上每个阶段引入风险分析。
start----->需求分析—(风险分析)–>计划—(风险分析)–>设计—(风险分析)–>编码—(风险分析)–>测试----->end
在这里插入图片描述

使用场景:规模庞大、复杂度高、风险大的项目
风险分析能力和产品遗留的风险是成反比的。
缺点:时间较长、人力、资金

1.3 增量模型和迭代模型

场景:用户有一个需求,功能包括A,B,C
①上述模型:完整开发好A,B,C,然后上线
②增量模型:开发完A就直接上线给用户去使用,继续开发B,开发完B就又上线去给用户用,开发完C就再上线去给用户用。
③迭代模型:先开发一个基础版本(包含A,B,C3个功能),但是ABC功能比较简陋,接下来再基础版本上对ABC的功能进行迭代优化。
例:一个人物画
增量模型:先画眼睛,画好之后再画嘴巴,逐块去建造
迭代模型:先把轮廓画出来,再细化

1.4 敏捷模型

敏捷模型的特点:轻流程、轻文档、重目标、重产出
3个角色和5个会议
3个角色:①产品经理:收集用户需求,编写需求文档,对产品负责的人;②项目经理:催作业的一个人,负责召开各种会议,协调项目,为研发团队服务;③研发团队:开发人员、测试人员,UI设计人员等。
5个会议:①发布会议②迭代会议③每日例会④演示会议⑤回顾会议
发布会议:产品经理从需求池重选取几个需求,开展发布计划会议;
迭代会议对需求进行拆解,对每个任务都有明确的负责人,并完成工时初估计;
每日例会:站会,快速过几个问题,团队成员回答昨天做了什么,今天计划做什么
演示会议:产出新的用户需求,展示本次迭代取得的成果
回顾会议:总结与改进

2. 测试模型

2.1 V模型

在这里插入图片描述
用户需求----->需求分析与系统设计------>概要设计(设计整体框架、架构)------>详细设计(模块和模块之间的详细设计)----->编码----->单元测试------>集成测试------>系统测试------>验收测试
特点:①明确标注了测试的类型②明确标注了测试阶段和开发阶段之间的对应关系
缺点:测试被后置了,①风险推迟到后期,测试才发现,失去了早修正的机会②编码完成之后,需要留足够的时间给测试,否则测试不充分会把软件缺陷报了给用户。

2.2 W模型(双V模型)

在这里插入图片描述
特点:测试从需求开始阶段就介入了,每个开发活动完成后就同步进行测试活动
缺点:①上一阶段完成下一阶段才能开始;②开发模型和测试模型也保持着一种前后的线性关系,只有开发活动完成了才能进行测试活动,不支持敏捷模式

2.3 H模型

在这里插入图片描述
特点:H模型中测试是一个独立的流程,只要满足了测试就绪条件,就可以开始测试。这种灵活的组织方式,使得H偶像完全具备了前2个模型的优点,即可以与所有的开发活动紧密结合,又足够灵活满足敏捷和迭代开发模型。
缺点:灵活,但是难以驾驭,如果管理者没有足够的经验就实施H模型,可能会事倍功半。建议一般的软件开发过程采用W模型,实施敏捷和迭代开发的可以考虑采用H模型。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CodeKnightShuai

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值