软件的生命周期
**软件生命周期**是指**从软件产品的设想开始到软件不再使用而结束的时间**。 如果把软件看成是有生命的事 物，那么软件的生命周期可以分成**6个阶段**，即**需求分析**、**计划**、**设计**、**编码**、**测试**、**运行维护**
- 需求分析阶段： 分析需求的可行性，产品经理产出需求文档
- 计划： 项目什么时候开始开发，什么时候结束开发，由谁开发，测试的开始结束时间，测试人员都有谁...
设计：
1、开发人员：软件的架构 2、设计人员：设计师产出UI设计稿编码： 边写代码
- 测试： 编写代码提交BUG，验证BUG，发送测试报告
- 运行维护： 如果项目上线有BUG，此时测试人员协助开发人员定位问题，解决问题，最终将项目重新上线
开发模型
这里的模型指的不是大家认为的飞机模型或者汽车模型，指的是软件开发的流程
瀑布模型
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次，因此是线性顺序进行的软件开发模式。
- 需求分析人员有产品经理
- 计划人员有相关负责人
- 设计人员有开发、UI设计师
- 编码人员有开发
- 测试人员有测试人员
简易理解(更快速地认知对应知识)：
瀑布模型的优点是什么？
线性的 每个阶段做什么事情都是非常明确的瀑布模型缺点是什么
测试人员接入需求太晚了，导致发现项目问题的时机太晚了瀑布模型适用的项目是什么
适用于较小的项目
详细知识(更全面的知识体系)：
优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。 缺点： –依赖于早期进行的 唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产 品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是 集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶 段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷， 例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经 很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这 个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。 在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动， 否则将导致测试不充分，从而把缺陷直接遗留给用户。
螺旋模型（Spiral Model）
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代 表之一。 这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的 要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重 要性就不言而喻了。
简易理解(更快速地认知对应知识)：
优点：
每一个阶段都会进行风险分析，避免问题到达下一个阶段缺点：
公司需要一定的成本 一旦风险分析错误，就会带来一定的损失适用的项目：
大型项目
详细知识(更全面的知识体系)：
优点： –强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下去。
缺点： –引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高 的要求。这需要人员、资金和时间的投入。
scrum（敏捷开发）
注，阅读scrum前请先阅读文末的“敏捷”及“增量与迭代”的定义，因为scrum是敏捷开发中比较流行的一种方式，且用到了“增量与迭代”的相关知识
scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布 计划，对产品负责。
scrum master 负责召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。迭代开发
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
scrum的基本流程
scrum的基本流程如上图所示：
- 产品负责人负责整理user story，形成左侧的product backlog。
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出 就是制定出这一期迭代要完成的story列表，sprint backlog。
- 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每 个任务都有明确的负责人，并完成工时的初估计。
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什 么问题。
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达 到持续改进的效果。
测试模型
软件测试V模型
简易理解(更快速地认知对应知识)：
优点：
线性执行 将测试分为好多种类型缺点：
测试人员介入需求较晚，发现问题时机较晚
详细知识(更全面的知识体系)：
V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布 模型的变种
- 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系
- V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同 的要求
- 局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试
软件测试W模型
简易理解(更快速地认知对应知识)：
优点：
测试人员可以更早的介入需求缺点：
不能拥抱变化，不能适用于敏捷特点：
第一个V是开发模型，第二个V是测试模型
详细知识(更全面的知识体系)：
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分 别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
- W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
- W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需 求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度 和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
- 局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系， 上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复 杂多变的情况，W模型并不能解除测试管理面临着困惑。
增量和迭代
简易理解(更快速地认知对应知识)：
增量：ABCD
先开发A模块，再开发B模块，C模块，D模块迭代：
ABCD各自开发一部分(框架搭建起来) -> 再去开发接口 -> 方法
详细知识(更全面的知识体系)：
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增 量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品 的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件 版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。 增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我 们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以 采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
敏捷
敏捷是什么？
简单来说，敏捷是一种思想。 详细来说，敏捷（Agile）是一种软件开发和项目管理方法论，强调以灵活、迭代和协作的方式开发软件和管理项目。敏捷方法鼓励团队更好地适应需求的变化、更早地交付有价值的软件，以满足客户需求，并提高开发过程的效率和质量
敏捷宣言**：**
- 个体与交互重于过程和工具
- 可用的软件重于完备的文档
- 客户协作重于合同谈判
- 响应变化重于遵循计划
- 在每对比对中，后者并非全无价值，但我们更看重前者
由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在 于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的 领域。
敏捷开发有很多种方式，其中scrum是比较流行的一种。
🧸欢迎您于百忙之中阅读这篇博客，📜希望这篇博客给您带来了一些帮助，祝您生活愉快！
