开发模型与测试模型

文章介绍了软件开发的生命周期,包括需求分析、计划、设计、编码、测试和维护。测试不仅限于开发后期,而是贯穿整个过程。文章提到了瀑布模型、螺旋模型、增量模型、迭代模型和敏捷模型,特别强调了敏捷模型的灵活性和重视交互与快速反馈的特点。敏捷开发中的Scrum模型也被提及,包括其三个角色(产品经理、项目经理、研发团队)和五个重要会议。
摘要由CSDN通过智能技术生成

1.开发模型和测试模型概述

1.开发模型(可以理解为开发流程或软件的生命周期):从产品开始设想到不再维护使用。

2.产品/软件的生命周期:需求分析(可行性)ㅡ 计划(时间)ㅡ 设计(工作)ㅡ 编码 ㅡ 测试 ㅡ 运行维护。

①需求分析:市场分析(有没有需求量,是否存在大量的需求用户)、投入和收益占比、技术上实现的可行性。

②计划:开始时间、结束时间、耗时多久。

③设计:将一个大的需求拆分成一个个具体可实施的任务,并进行技术设计(设计哪些接口、采用哪些框架、采用哪些技术等)。

④编码:开发人员参考需求文档和技术文档等来进行代码的开发。
⑤测试:这里是指执行测试,测试人员参考测试用例来设计。
⑥运行维护:修复性维护(对项目中没有发现的问题要进行及时修复)、完善性维护(对功能进行完善)、预防性维护(居安思危:为了避免产品在线上运行期间出现意想不到的问题,需要进行一些预防性的手段)。

从产品的角度分析,测试是在开发之后;但是从测试的角度分析,测试是贯穿于产品的整个生命周期的。

举一个例子(建房子):

需求分析:首先要明确,为什么要建房子,是用于居民居住还是商用?假如要建造商用房,在哪里建造?商品房建造投入和收益的占比是否过大?建造多少层?建造100层的话技术上是否可行。

计划:什么时候开始建造?什么时候竣工?什么时候可以招商?

设计:先出设计图,谁来负责打地基,谁来负责建筑框架,谁来负责砌砖,水电和墙面谁来粉刷。

编码:脚踏实地的一步一步按照需求和计划来建造房子。

测试:等到房子要交付的日期了,需要进行房屋的验收测试。房子是否漏水,是否存在偷工减料,是否是按照规定来建造的。

运行维护:测试没有问题就交房了,用户入住了之后接下来可能会遇到一些异常的情况。比如房子漏水、墙皮脱落等情况,需要用户自己来进行维护。

3.软件测试贯穿于软件的整个生命周期,那么是如何贯穿的呢?

软件测试的生命周期:需求分析——测试计划——测试设计与开发——测试执行——测试评估

① 需求分析:用户角度思考问题(软件需求是否合理)、技术角度思考问题(技术上是否可行,是否还有优化的空间)、测试的角度思考问题(是否存在业务逻辑冲突/冗余)
② 测试计划:开始时间、结束时间以及耗时多久。
③ 测试设计与开发:写测试文档,明确标注使用到的测试方法、测试工具、测试形式等。参考需求文档、技术文档(开发人员写的)等编写测试用例。
④ 测试执行:充分利用测试用例和其他工具对项目尽可能做到全方面的覆盖测试。
⑤ 测试评估:评估产品是否存在质量问题,以及进行功能演示。

4.【面试题】如果线上出现问题,测试人员该怎么办?
项目测试完成之后需要进行项目上线。产品在线上运行期间,我们测试人员也要及时关注产品线上运行情况,是否出现了产品质量问题,如果出现了问题:

① 尝试复现(是普遍存在还是个别问题): 复现成功后通知项目组内所有成员进行问题的定位。
② 尝试定位问题出现的原因,帮助开发人员尽快的定位问题并解决问题。
③ 反思问题(为什么出现,如何解决,后续如何避免):如果问题比较严重or比较典型,则需要写一个文档。

2.开发模型

一、瀑布模型

瀑布模型

                        (上图这里的“测试”指的是所有的测试活动)

特点:
① 线性结构,每个阶段只执行一次
② 是其他模型的基础框架

缺点:
1)测试后置
① 前面各阶段遗留的风险(计划风险、需求风险等等)推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会。
② 必须留有足够的时间给测试活动,否则会导致测试不充分,将缺陷暴露给用户(产品质量差)
2)周期太长:产品很迟才能被用户看到和使用;可能会导致需求/功能过时(由于测试后置可能导致的返工)。

使用场景:
需求固定的小项目

二、螺旋模型

螺旋模型

① 螺旋模型拉直之后就相当于瀑布模型,螺旋模型中增加了风险分析和原型。
② 螺旋模型需要招聘专业的风险分析人才。

特点:
螺旋模型中增加了风险分析和原型。

缺点:
1)项目中可能存在的风险性与风险管理人员的技能水平有直接的关系。
2)需要人员、资金、时间的增加和投入,可能会导致项目的成本过高。

使用场景:
规模庞大、复杂度高、风险大的项目尤其适合。

三、增量模型和迭代模型

1.增量模型(逐块建造)

2.增量模型中把大的需求划分成一个个可以独立开发上线的功能。

3.增量模型在开发上线各功能时是可以并行开发的。

4.迭代模型(反复求精):迭代模型在开发上线软件的各功能时,先开发个功能的基础版本,然后再在基础版本上不断进行功能的完善。

增量模型和迭代模型不同点(假设要开发A、B、C、D、E五个功能):

        增量模型是先开发A、B、C三个功能进行上线,然后再开发D、E功能。

        迭代模型是先开发A、B、C、D、E五个功能的基础版本进行上线,然后再在基础版本上完善其功能。

        增量模型像绘画人物相貌时,先画脑袋、然后画脖子、直到画完。

        迭代模型像绘画人物相貌时,先把人物全身画完,然后再上色。

 四、敏捷模型【重点】

1.敏捷模型不强调流程,而是更多地思考如何去激发开发人员的工作热情。
2.敏捷模型的考核标准是:可交付的软件。
3.简单理解《敏捷宣言》

① 个体与交互重于过程和工具: 要注重人与人之间的交流沟通
② 可用的软件重于完备的文档: 不太关注在过程中产生的各种文档,更注重最后有没有产出一个可用的软件。【敏捷模型的考核标准是:可交付的软件】
③ 客户协作重于合同谈判:用户需求五花八门,可能会在不同时间有不同需求,所以要注重与客户的沟通协调,注意及时修改更新。
④ 响应变化重于遵循计划:及时响应变化
⑤ 在每对比对中,后者并非全无价值,但我们更看重前者。

其实也就是说:
敏捷模型的特点:轻流程、轻文档、重目标、重产出。

4.敏捷开发有很多种方式,其中scrum是比较流行的一种
5.scrum模型
1)重点掌握【三个角色五个重要会议】
2)三个角色:产品经理、项目经理、研发团队。


① 产品经理product owner:负责整理用户故事(user story),定义其商业价值,对其进行排序,制定发布计划,对产品负责
② 项目经理scrum master: 负责召开各种会议,协调项目,为研发团队服务。
③ 研发团队team:由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。
 

User Story 是用户需求的简化表达,用一两句话表达完整的想法

3)五个重要会议:
发布计划会议、迭代计划会议、每日例会、演示会议、回顾会议。

 4)特点:
敏捷模型拥抱变化

3、测试模型

一、V模型

1.V模型

2.特点:
① 测试过程中存在不同类型的测试
② 测试阶段的参考标准以前面对应的阶段为准

3.缺点:
测试后置
① 前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会。
② 必须留有足够的时间给测试活动,否则会导致测试不充分,将缺陷暴露给用户(产品质量差)
 

 二、W模型(双V模型)

1.W模型

2.特点
① W模型重流程(前一个完成之后一个才能开始),不能很好地迎接变化。
② W模型不适合敏捷模型。
③ 测试阶段从需求开始就介入。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值