目录

1 软件开发模型

1.1 瀑布模型

1.2 快速原型模型

1.3 增量模型

1.4 螺旋模型

1.5 敏捷模型

1.5.1 Scrum（开发管理框架）

1.5.2 Kanban（看板）

---

1 软件开发模型

        软件开发模型规定了软件开发应遵循的步骤，是软件开发的“导航图” 。它能够清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和要完成的任务。开发人员在选择开发模型时，要根据软件的特点、开发人员的参与方式选择稳定、可靠的开发模型。

1.1 瀑布模型

        瀑布模型和软件生命周期一致，是其他模型的基础框架。各阶段按固定顺序执行，前一阶段完成后才能进入下一阶段，每个阶段需完成完整文档，作为下一阶段的依据。线性结构，每个阶段只执行一次。

优点:

• 方便管理，流程清晰、结构固定
• 各阶段文档完整，便于后期维护与交接
• 阶段明确，便于质量把控与进度检查

缺点:

• 灵活性差，无法适应需求变更
• 用户仅在最终阶段看到产品，问题发现晚
• 前面各阶段遗留的风险到测试阶段才被发现，导致项目大面积返工，付出代价大
• 周期长，需完成所有阶段才能交付，上线速度慢，可能导致需求/功能过时

【适用场景】需求固定，规模小的项目

1.2 快速原型模型

        快速开发出可运行、可交互的原型，不追求完整功能，用户直接试用原型，提出修改意见，根据反馈反复修改原型，逐步完善。

优点:

• 能快速构建软件原型
• 降低需求风险，提前暴露需求问题，减少后期返工

缺点:

• 质量难保证，可能忽略设计、测试，后期难维护
• 不适用于大型项目

【适用场景】需求不明确、易变化的项目

1.3 增量模型

        将完整的软件拆分成不同的组件，然后对每个组件进行开发测试，分批开发、分批交付，不同增量模块可并行设计与开发。

优点:

• 很好地适应用户需求变更
• 交付灵活
• 降低成本与风险，这一个组件不符合需求，只需要更改这一个组件

缺点:

• 架构要求高，需良好整体架构
• 集成复杂

【适用场景】需求不明确的大型项目

1.4 螺旋模型

        结合了瀑布模型和快速原型模型，引入了风险分析。

优点:

• 增加风险分析，强调严格的全过程风险管理
• 用户参与每个阶段的开发，保证产品贴合需求
• 强调各开发阶段的质量

缺点:

• 项目中可能存在的风险与风险管理人员的技能水平有直接关系
• 成本较高，人员、资金、时间投入大

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

1.5 敏捷模型

        需求被拆分为许多个可以增量开发的子项目，采用迭代开发，每个增量部分都在迭代中开发。旨在帮助项目快速适应变更要求，主要目的是促进项目的快速完成。
敏捷模型有一个非常重要的《敏捷宣言》

• 个体和交互重于过程和工具
• 可用软件重于完备文档
• 用户协作重于合同谈判
• 响应变化重于遵循计划

        由此可看出，敏捷模型更注重人与人之间的交流和沟通，也可以总结出敏捷模型的四个特点:轻文档、轻流程、重目标、重产出。

优点:

• 灵活性强，能快速响应需求变更，不断适应新的趋势
• 用户参与度高，可及时获取反馈，产品更贴合需求

缺点:

• 若文档缺失，会导致后期维护、交接困难
• 对团队成员能力、协作要求高
• 不适用于大型复杂项目

【适用场景】小型项目

1.5.1 Scrum（开发管理框架）

        敏捷模型主要有两种开发方式:Scrum（开发管理框架）和Kanban（看板）
在Scrum中，主要有三个角色和五个重要会议

三个角色:

• 产品经理（product owner）:负责整理用户故事，定义其商业价值，对其排序，定需求的优先级，制定发布计划，对产品负责。
• 项目经理（scrum master）:负责召开各种会议，协调项目，为研发团队服务。
• 研发团队（team）:由开发、测试、设计等成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

五个重要会议:

• 需求梳理会议
• 迭代计划会议
• 每日站会
• 评审会议
• 回顾会议

        Scrum 将产品的开发分解为若干个小sprint（迭代），周期一般为1∽4周，参与的团队成员一般是5∽9人，每次迭代都要交付成果。

1.5.2 Kanban（看板）

        将工作细分成任务，将工作流程显示在“看板卡”上，每个人都能及时了解自己的工作任务和工作进度。

以上就是软件开发中最常用的测试模型，作为软件测试人员，理解开发模型不仅能更好地配合开发团队、制定测试计划，也是面试中的高频考点。后续我会继续分享测试流程、用例设计、工具使用等干货，欢迎关注、点赞、收藏、转发一起学习进步～