需求

在软件开发中，我们一般把需求分为用户需求和软件需求。

用户需求就是甲方或者终端用户使用产品时必须要完成的任务，该需求一般比较简略，通常为一句话。

软件需求需要详细描述出软件的功能，同时也是测试人员进行测试工作的基本依据。
用户的需求不能直接作为开发和测试的依据，针对用户需求，产品经理需要进行需求分析然后才能转化为软件需求

软件的生命周期

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

开发模型

瀑布模型

瀑布模型是所有开发模型的基础框架，该模型来源于软件的生命周期

瀑布模型的缺点也很明显，由于测试的后置，因此前面各个阶段遗留的风险只能推迟到测试阶段才能被发现，可能会导致项目大面积的返工，失去及早修复的机会
由于测试后置，可能导致留给测试的时间不够充分，导致测试不充分，测试质量下降，可能会导致软件的质量问题直接暴露给用户，导致用户流失
由于软件的开发周期过长，可能不能及时上线，导致软件的需求或者功能的过时

---

优缺点总结：

瀑布模型适用于需求固定的小项目中。

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

螺旋模型适用于规模庞大、复杂度高、风险大的项目

螺旋模型在每一个阶段都加上了原型 和 风险分析。

大致流程：

优缺点总结:

增量模型 与 迭代模型

增量模型将大需求拆分成若干个小需求，每个小需求独立开发并上线

迭代模型是指 通过不断地更新版本来追求精益求精，例如微信版本的迭代。

一般在企业的开发中，增量和迭代我们会一起配合着使用

敏捷模型

敏捷模型宣言的四个特点：轻文档，轻流程，重目标，重产出

敏捷开发有很多种方式，其中 scrum 是比较流行的一种。

三个角色：product owner(产品经理)，scrum master(项目经理)，team (研发团队)
产品经理负责整理用户需求，定义商业价值，指定发布计划，对产品负责
项目经理负责召开各种会议，协调项目，为研发团队服务
研发团队的成员通过紧密的合作，负责每一次的迭代的目标，交付产品

五个会议：
发布计划会议：昌产品经理负责讲解 user story ，对其进行估算和排序，发布计划会议的产出就是指定这一期迭代要完成的 story 列表
迭代计划会议：项目团队对每一个story 进行任务分解，分解的标准就是完成该 story的所有任务，每个人物都有明确的负责人，并完成工时的初步估计
每日例会：由项目经理召开，团队成员回答昨天做了什么，今天要做什么，由什么问题需要解决
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责像大家展示本次迭代取得的成果，期间记录大家的反馈记录，由产品经理整理，形成新的story
回顾会议：项目团队对本次迭代进行总结，发现不足，指定改进计划，下一次迭代继续改进，以达到持续改进的效果。

测试模型

V 模型

编码前期，每一个阶段都对应编码后期的每一个阶段。

详细设计对应着单元测试，概要设计对应着集成测试，需求分析与系统对应着系统测试，用户需求对应着验收测试。

单元测试和解成测试检测程序的执行是否满足软件设计的要求
系统测试检测系统功能、性能的质量特性能否达到系统要求的指标
验收测试去欸的那个软件的实现是否满足用户需求或合同的要求

V 模型明确地标注了测试过程中存在的不同类型的测试，并且清晰地描述了这些测试阶段和开发阶段期间各阶段的对应关系，有效地提升了测试的质量和效率。

缺点：仅仅将测试作为编码之后的一个阶段，未在需求阶段就介入测试。

W (双V) 模型

W 模型增加了软件开发阶段对应的验证和确认活动，W 模型由两个 V 模型组成，分别表明测试与开发过程，可见测试与开发是并行的阶段

W模型的特点：测试的对象不仅仅是程序，还有需求、设计等等。

优点：
有利于尽早地全面的发现问题。
例如：在需求分析完成后，测试人员就应该参与对需求的验证和确认活动中，以尽早地找出缺陷所在。

缺点：
需求、设计、编码等活动依旧被视为串行。
测试与开发活动本质上也保持着一种线性的前后关系，等到上一个阶段完全结束后，下一个阶段才能进行。
W模型注重流程，无法支持敏捷开发模式，对于当前软件开发复杂多变的情况下，W模型并不能解除测试管理面临的困惑。