本章节思维导图：

1. 需求分析

什么是需求，在多数软件公司，软件分为两种，用户需求和软件需求

1.1 用户需求 

        用户需要的相应服务，没有经过相应的评估，就是一句话

1.2 软件需求

        是开发和测试人员进行工作的基本依据。

注意，用户需求并并不能作为开发和测试人员的工作依据。
只有在用户需求进行合理的评估之后（技术可行性，市场可行性，成本投入和市场占比等）后转变为 软件需求 后才可以

举个栗子

---

用户需求：使用邮箱进行注册

软件需求：

1. 基础功能需求

• 邮箱输入框

  • 格式校验（需符合标准邮箱格式，如 xxx@xxx.com）。

  • 实时提示格式错误（如缺少“@”或域名不完整）。

• 密码设置

  • 强度要求（如至少8位，含大小写字母+数字+特殊符号）。

  • 密码可见性切换（显示/隐藏）。

• 验证码校验

  • 发送邮箱验证码（6位数字/字母组合）。

  • 验证码有效期（如5分钟过期）。

  • 防刷机制（同一邮箱60秒内限发1次）。

• 用户协议勾选

  • 默认未勾选，需用户主动同意。

  • 可点击查看详细协议内容。

2. 安全需求

• 防重复注册

  • 同一邮箱仅允许注册一次（需提示“该邮箱已注册”）。

• 防机器注册

  • 图形验证码（如滑块、点选）或reCAPTCHA。

• 密码安全

  • 传输加密（HTTPS）。

  • 存储加密（BCrypt/SHA-256哈希）。

3. 用户体验需求

• 错误提示友好

  • 明确提示错误原因（如“邮箱格式错误”“验证码失效”）。

• 注册成功反馈

  • 跳转至登录页或直接登录。

  • 发送欢迎邮件（含账号激活链接，可选）。

• 邮箱修改与找回

  • 注册后允许绑定备用邮箱。

  • 提供“忘记密码”入口。

---

        这里就是将 用户需求 转化为 软件需求 的过程

---

2. 开发模型

        软件开发的生命周期: 需求分析 ---- 计划 ---- 设计 ---- 编码 ---- 测试 ---- 运行维护
运行维护又包括 修复性维护，完善性维护，预防性维护(比如)

常见的开发模型：

2.1 瀑布模型

特点：每个流程只执行依次，线性的开发流程

缺点：

        1) 测试后置

• 前面各阶段遗留的风险到了测试阶段才会被发现，导致项目多大面积返工，失去了及早修复的机会
• 必须给留给测试充分的时间，否则导致测试不充分，将缺点直接暴露给用户

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

虽然说瀑布模型具有一定的风险，但并不意味这不能使用，在某些需求简单，功能单一的小项目中这种简便的开发模型仍然是一种选择

并且瀑布模型是后续其它模型的基础，都是在它的基础上进行优化改进的，所以说普博模型还是有学习的必要

2.2 螺旋模型

特点：以原型为基础沿螺线旋转、每转一圈都经过计划/风险分析/实施/评估等过程且得到相应新版本、经过若干次螺旋上升得到最终版本。

螺旋模型的四个象限

每个螺旋循环都包括以下四个象限：

• 目标规划： 确定本轮迭代的目标、约束和备选方案。
• 风险评估： 识别技术、进度、成本等风险。
• 开发与测试 : 执行开发（编码、设计）和验证（测试、原型演示）。
• 客户评审 : 客户评估当前成果，提出修改意见。该象限决定是否进入下一阶段或者结束项目。

优点：

• 项目的每个接管都会进行这四个象限，可以减少各阶段遗留的风险问题，避免把问题滞留到后面的阶段
• 灵活适应需求变化。

缺点：

•  管理成本高，需频繁风险评估和客户参与。
• 不适合小型或低风险项目（过度复杂）。
• 迭代周期长，进度难预测。

和瀑布模型相比，引入了循环迭代，降低了各阶段产生的风险，但同时也增加了资源消耗。

该模型的适用场景：

        1. 高风险项目 : 如航空航天、医疗软件等，需严格管控技术或合规风险。

        2. 需求不明确 : 客户无法一次性提出完整需求，需逐步细化（如科研项目）。

        3. 长期复杂项目 : 开发周期长、技术难度高（如操作系统、大型游戏）。

2.3 增量模型、迭代模型

增量模型：

        与增量模型类似的还有一个迭代模型

         开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，迭代模型是类似小型的瀑布式项目。每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

大家常常会把这两个模型搞混，我用如下的图片来演示这两个模型的区别。

增量是逐块建造的概念，例如：画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……。
迭代是反复求精的概念，例如：同样是画人物画，我们可以先画整体轮廓，在勾勒出基本雏形，再细化、着色……。

2.4 敏捷模型

描述：敏捷模型是一种以人为核心、迭代增量式的软件开发方法，强调快速交付、灵活响应变化和持续客户协作。它通过小周期（Sprint/迭代）逐步交付可用的软件，而非一次性完成所有需求。

我们可以通过重要宣言来理解敏捷模型的特点：

• 个体和互动 高于 流程和工具 ：强调高效的交流

• 工作的软件 高于 详尽的文档 ： 强调轻文档，文档不应该作为工作验收的标准

• 客户合作 高于 合同谈判 ： 主动了解当下的需求

• 响应变化 高于 遵循计划 ： 能够主动迎接变化

敏捷模型的 12 原则，进行进一步的解释。感兴趣的可以看一下

我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

总结敏捷模型的四大特点：轻文档，轻流程，重目标，重产出

        2.4.1 Scrum 模型

        描述 ：Scrum 模型是敏捷模型中的一种，是当前最流行的敏捷开发框架，通过短周期迭代（Sprint）、角色分工和固定仪式，实现高效交付和持续改进。

        在 Scrum 模型中，主要有三个角色、五个重要会议

​​​​

三个角色：

角色	职责
产品负责人（PO）	- 定义需求优先级（管理产品待办列表 Product Backlog）。 - 代表客户利益，确保开发价值最大化。
Scrum Master	- 移除团队障碍，确保Scrum流程执行。 - 促进团队自组织，避免外部干扰。
开发团队	- 跨职能（设计、开发、测试等），5~9人。 - 自主分配任务，承诺迭代目标。

五个重要会议（流程）：

名称	目的与规则
发布计划会议（用户需求）	- 时长：2~4小时（每1周Sprint约1小时）。 - 输出：Sprint目标和Backlog。
迭代计划会议 （任务拆解 + 定时长）	- 固定时长（通常2~4周），期间目标与范围不变。 - 对每一个 sprint 进行拆解，每个任务都有对应的负责人，并初步估计工时
每日站会	- 15分钟限时，回答三问题： ① 昨天做了什么？ ② 今天计划做什么？ ③ 遇到什么障碍？
演示会议	- 演示本Sprint成果，收集客户/利益相关者反馈。形成新的 Sprint 成果
回顾会议	- 团队反思改进点（流程、协作等），制定下一Sprint优化计划

单单看上面的文字叙述可能有些抽象，下面我就用流程图的方式帮助大家理解 Scrum 模型的流程

会议流程图：

2.4.2 敏捷模型中的测试

轻文档与快速迭代

• 敏捷模型强调轻文档，测试人员应避免传统Excel编写测试用例的方式，转而使用：

  • 思维导图

  • 探索性测试（强调自由度，设计、执行同步进行，根据结果动态调整测试计划）

  • 自动化测试

• 敏捷注重协作，测试人员需主动：

  • 与开发人员沟通需求

  • 参与设计讨论

  • 共同分析Bug根源

3. 测试模型

3.1  v 模型

描述：V模型（V-Model）是软件开发中经典的测试与开发并行的模型，强调测试阶段与开发阶段的对应关系，因图形呈现为“V”字形而得名。它是瀑布模型的变种，但通过早期测试设计显著提升缺陷预防能力。

优点	缺点
✅ 缺陷早发现：测试设计前置，降低后期修复成本。	❌ 灵活性差：难以适应需求频繁变更（如敏捷项目）。
✅ 流程清晰：阶段明确，适合合规性强项目（如医疗、军工）。	❌ 客户参与晚：验收测试在最后阶段，反馈延迟。
✅ 高测试覆盖率：每个开发层级均有对应测试保障。	❌ 依赖文档：需完整的前期设计文档支撑

 3.2  w 模型

描述：W模型是V模型的扩展，通过双重“V”结构将开发和测试活动进一步并行化，强调全程测试与早期验证。其核心理念是“测试伴随开发”，而非仅在后期介入。

优点	缺点
✅ 更早发现缺陷 • 测试用例设计前置（需求阶段即设计验收测试） • 在开发前期暴露问题，降低修复成本	❌ 串行依赖 • 小流程间仍需严格串行（如需求分析完成后才能设计验收测试） • 灵活性低于敏捷开发
✅ 测试覆盖全面 • 每个开发产物（需求/设计/代码）都有对应测试验证 • 减少遗漏风险	❌ 文档依赖强 • 需完整的需求/设计文档支撑 • 不符合敏捷"轻文档"原则
✅ 降低返工成本 • 避免编码后才发现需求或设计错误 • 例如系统设计问题能在早期发现	❌ 流程冗长 • 阶段划分严格（系统设计→系统测试设计） • 不适合快速迭代项目
✅ 适合复杂系统 • 高可靠性领域（嵌入式/金融） • 提供完整的测试追溯保障	❌ 成本高 • 需专职测试团队早期介入 • 人力与时间投入较大