需求

• 用户需求：没有经过合理的评估，通常就是一句话

• 软件需求：是开发人员和测试人员执行工作的依据

用户的需求不能直接作为开发和测试的依据。针对用户的需求，产品经理需要进行需求分析(技术可行性、市场可行性、成本投入和收益占比等)后才可转变为软件需求。

开发模型

规范的流程是在时代的演变下逐渐成型，并不是一开始就是规范的流程

软件生命周期

• 软件生命周期实际就是软件的开发模型（认识具体的开发模型之前先了解软件的生命周期）

需求的开始是软件生命的起点，中间会经历需求的计划、设计程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的重点

• 软件流程：需求分析、计划、设计、编码、测试、运行维护
• 开发:设计开发文档(用什么技术、用什么框架等等)
• 测试:明确需求，设计测试用例、测试计划(明确本次测试设计到的工具、设计到的测试类型…)
• 运行维护：软件上线之后，在线上环境使用下可能会出现一些意向不到的情况

修复性维护:对项目中未发现的问题进行修复。
完善性维护:对功能进行完善。
预防性维护:居安思危，为了避免产品在线上出现一些其他不可预料的问题，进行一些防护的手段。
正常使用没有问题，但是在极端的情况下会出现问题(性能问题)

软件的通用流程

阶段	具体内容	产出
需求分析	分析用户需求是否合理，分别从市场需求、技术等方面进行分析。	该阶段会输出需求等文档。
计划	对成立的需求执行需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能。	该阶段会输出计划等文档。
设计	将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计(如何进行架构设计，设计哪些接口、采用什么技术)	该阶段会输出技术等文档。
编码	开发人员参考需求文档、设计文档、交互图等等文件进行代码的编写。	代码文件等文档。
测试	测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试	测试用例、测试设计与计
运行维护	项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护、完善性维护和预防性维护。

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点/特点

1. 强调开发的阶段性
2. 线性结构，每个阶段只执行一次
3. 是其他模型的基础框架

缺点

1. 测试后置

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

2. 周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时

瀑布模型的适用场景:需求固定的小项目

螺旋模型

螺旋模型中各个阶段都引入的风险分析+原型
引入的目的是减少各阶段遗留的风险问题，避免把问题留到后面的阶段
优点

1. 强调严格的全过程风险管理
2. 强调各开发阶段的质量
3. 增加风险分析和原型

缺点

1. 项目中可能存在的风险性与风险管理人员的技能水平有直接关系
2. 需求人员、资金、时间的增加和投入，可能会导致项目的成本太高

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

增量模型、迭代模型

• 增量模型：将大需求拆分成小需求，每个小需求独立开发上线
  
• 迭代模型：基础板本->优化版本1->优化版本2->……
• 增量模型将一个大的需求修改成多个小功能，每个功能独立开发上线
• 迭代模型会上线一个基础版本，但是基础版本所有的功能都有只不过功能比较简陋，后期再继续迭代优化上线

增量是逐块建造的概念，迭代是反复求精的概念。

迭代模型和增量模型在现在已经不会单独去使用，而是配合着去使用

适用场景:大型项目，需求不明确

敏捷模型

克服在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。

• 敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成。
• 敏捷性是通过使过程适应项目，删除对特定项目可能不是必需的活动来实现的。此外，避免任何浪费时间和精力的事情。
• 在敏捷模型中，需求被分解成许多可以增量开发的小部分。
• 敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理，并且只能在几周内完成。
• 一次为客户计划、开发和部署一个迭代。没有制定长期计划。

《敏捷宣言》

1. 个体与交互重于过程和工具

强调高效的沟通

2. 可用的软件重于完备的文档

强调轻文档，文档不应该作为工作验收的标准

3. 客户协作重于合同谈判

主动及时了解当下的需求

4. 响应变化重于遵循计划

能够主动迎接变化

敏捷模型的四个特点:轻文档，轻流程，重自标，重产出

Scrum

• Scrum是敏捷模型中的一种，又称为迭代式增量软件开发模型。
• 在scrum模型中，主要有三个角色和五个重要会议。
• 三个角色不是指三个人，而是三类角色

三个角色:scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

1. product owner负责整理userstory(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。

产品经理收集需求，产出软件需求文档

2. scrum master负责召开各种会议，协调项目为研发团队服务。
3. 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

由很多角色组成:开发人员(前端、后端)、测试、交互、设计……

迭代开发：scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的userstorv是固定的。每次迭代会产生一定的交付。

Scrum的流程

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

敏捷中的测试
轻文档和快速迭代

• 敏捷模型中强调轻文档，所以测试人员不应使用传统的Excel编写测试用例的方法，更多的是0使用思维导图、探索性测试(强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划)、自动化测试等

轻文档：测试用例、测试计划文档、测试报告……

• 敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究bug出现的原因。

测试模型

V模型

V模型：目的是改进软件开发的效率和效果。是瀑布模型的变种。

优点:

1. 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率。
2. V模型指出:
   单元和集成测试应检测程序的执行是否满足软件设计的要求
   系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标
   验收测试确定软件的实现是否满足用户需要或合同的要求

缺点:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型。

W模型（双V模型）

开发V模型并不是单单指编码阶段，而是为产品开发流程而实施的各个阶段
特点:测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施，显著减少总体测试时间，加快项目进度。
缺点:

1. 需求、设计、编码等活动被视为串行的;
2. 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
3. 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。