感谢各位大佬对我的支持,如果我的文章对你有用,欢迎点击以下链接
🐒🐒🐒 个人主页
🥸🥸🥸 C语言
🐿️🐿️🐿️ C语言例题
🐣🐣🐣 python
🐓🐓🐓 数据结构C语言
🐔🐔🐔 C++
🐿️🐿️🐿️ 文章链接目录
🏀🏀🏀 笔试练习题
🐯🐯🐯 Git
😎😎😎 软件测试

需求的概念

用户需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略，通常是一句话

用户需求有时会比较不合理,比如设计出一个五彩斑斓的黑色
有时需求非常简略,不容易理解到底是什么意思,比如开发一款用户软件,具体要开发一款什么样的用户软件没有细说,这种就很难理解意思

软件需求

软件需求是测试人员进⾏测试⼯作的基本依据
用户需求和软件需求有什么不同呢？看看下面的案例
用户需求:韩信拿五杀
软件需求:敌方五人全部复活->敌方五人站在我方防御塔下->韩信站在我方防御塔下->韩信对五人进行攻击
我们可以看到软件需求是更加详细合理的,是经过评估后发现可以实现的

在⼯作中我们实际见到的软件需求文档类似于下面的表述:
软件需求规格说明书一、用户需求：平台支持邮箱注册
软件需求：

开发模型

模型的概念

在我们日常生活中我们会见到模型飞机,模型坦克等等,在机械方向中我们可能会见到3D建模的模型,二维平面图等等
比如
而在软件方向的模型则是这样的

软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件⽣命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理

软件的生命周期

软件的生命周期其实就是软件的开发模型
这里提到了一个生命周期的概念,什么是生命周期呢?
我们所认识的生命周期就是人一生的整个过程,其实软件的生命周期也是如此，需求的开始是软件生命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的终点。
举个例子:假如现在想要建一个房子,那么建这个房子的生命周期是怎么样的

这个例子的需求是要求建一个房子,这个需求是用户需求,因为用户需求不一定能实现,所以需要对需求进行分析
需求分析觉得可行后就计划开始时间以及交付的时间
计划完后就开始设计一个规范的流程,从哪里开始做,要做哪些
当所有前期工作准备完成后就开始正式干了
成品出来后我们还需要对这个成品质量进行测试,如果不合格就需要修改,直到符合要求
最后商品上线出售后还需要维护,也就是售后

从上面可以得出软件的生命周期是需求分析->计划->设计->编码->测试->运行维护
将上面的例子转换成软件的生命周期后是这样的

这是软件的通用流程

常见开发模型

瀑布模型

这个模型和前面的基础流程是几乎一样的
下面是他的优缺点

我们具体分析一下这个优缺点
因为从这个流程可以看出编码和测试都是排在很靠后的,也就是说如果有一个很大的需求要做的话,前面的需求分析 计划 设计这三个部分就会花很长的时间,而后面的编码和测试需要等前三部分做完之后才开始进行,这样下来就需要花很长的时间才能做出来,一个产品不能够尽早做出了可能会出现下面这种情况,比如最近某款游戏比较火,现在要求马上做出一款类似的游戏上线,而用瀑布模型的话可能会花1年到2年的时间,这么长的时间等到上线的时候用户全被抢走了,也就是产品上线后没市场了
另外从瀑布分析的流程来看这个流程是一次性到位的,如果中间出现问题就需要出现再来
比如说在设计阶段的时候发现一个模块原本要求有2个后端去做,结果他们中的一个后端必须要去做另一个模块,导致人员不足,因为人员不足所有计划的时间就需要更改,而这个计划是根据需求去设计的,所有要从需求分析那部分修改
或者说在测试的阶段发现产品的需求不合理,因为开发是根据设计来做的,而设计又是根据计划去做的…这样又得重新来

但是如果需求非常小,比如编码部分可能只需要话1天的时间,测试也只花1天的时间,这种情况就可以用瀑布模型,因为周期短,风险很小

螺旋模型

这是他的优缺点

螺旋模型和瀑布模型的区别就是螺旋模型在各个阶段都引入了风险分析和原型
这里的原型就是每次都会进行一轮风险分析,分析合理后就会将之前的原型进行修改,每次都修改一点,直到变成最终可运行的原型
这样做的好处就是中途出问题了不需要重新开始,只需要用上一个原型就可以了

增量模型、迭代模型

增量模型就是将一个大需求拆分成小需求,让每个小需求独立开发上线,这样可以让产品尽早上线

迭代版本就是将一个大模型的框架的基础版本设计出来,后面通过更新的方式每次增加一点,对其进行完善

敏捷模型

敏捷模型其实就是增量模型和迭代模型的结合,为了更快的上线产品,会将产品的各个功能拆分出来,然后对这些功能独立开发,上线每个功能的一个基础版本

因为实际中客户的需求会经常变化,在之前的开发模型当中很难将新的需求合并在一起,而敏捷模型可以在比较快的适应变化快的需求
比如某款游戏开发到23版本后,需求突然变更了,但是这个版本不能说临时就改了,万一是一个大的需求就来不及修改,所以会将这个版本先上线,等到下一次版本更新时将这些需求一起上线

测试模型

V模型

V模型其实就是模型外观像V

优点：
明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间
各阶段的对应关系，有效提升测试的质量和效率。
V模型指出：
单元和集成测试应检测程序的执⾏是否满足软件设计的要求
系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标
验收测试确定软件的实现是否满足用户需要或合同的要求
缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型。

W模型

W模型就是V模型的优化

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系(一对一关系)
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
优点：
有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项⽬难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度
缺点：
需求、设计、编码等活动被视为串行的(上一个阶段出问题后就需要重新来)
测试和开发活动也保持着⼀种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段⼯作
重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑