软件的⽣命周期
需求分析⸺计划⸺设计⸺编码⸺测试⸺运⾏维护
一个标准的软件生命周期，通常包含这几个阶段：
- 需求分析：明确用户要什么、软件要解决什么问题，是整个项目的起点。
- 设计阶段：产品和架构师把需求转化为可执行的方案，比如产品原型、系统架构图、数据库设计等。
- 编码开发：程序员根据设计文档编写代码，把方案变成可运行的程序。
- 测试阶段：测试人员介入，验证软件是否符合需求、有没有缺陷，确保功能正常、稳定。
- 部署上线：通过测试的软件部署到线上环境，交付给用户使用。
- 维护迭代：软件上线后，修复线上问题、更新新功能，直到软件停止服务、退役。
在整个周期里，测试并不是只存在于 "测试阶段"，而是贯穿始终：需求阶段参与评审，设计阶段评估可测性，开发阶段做单元测试，上线后还要持续监控线上问题。
常⻅开发模型
瀑布模型
这是最经典的线性开发模型，流程是需求→设计→开发→测试→上线，每个阶段做完再进入下一个阶段，像瀑布一样单向流动。
优点：流程清晰，阶段明确，适合需求稳定的项目。
缺点：测试在项目后期才介入，如果前期需求有问题，后期修改成本极高，不适合需求频繁变更的项目。
敏捷模型
现在互联网项目最主流的开发模型，核心是迭代式开发、快速交付、持续反馈，它把大项目拆成多个小的迭代（Sprint），每个迭代都能交付一个可运行的软件版本。
- 特点：拥抱需求变化，用户和测试全程参与，能快速响应反馈，降低风险。
- 下面我们就重点拆解敏捷里的 Scrum 框架。
三个角色
| 角色 | 中文名称 | 核心职责 | 一句话定位 |
|---|---|---|---|
| Product Owner (PO) | 产品负责人 / 产品所有者（产品经理） | 1. 定义产品愿景和目标2. 维护并排序产品待办列表（Product Backlog）3. 决定需求优先级、发布内容和节奏4. 对产品价值和 ROI 负责 | 产品的 "价值负责人"，决定做什么 |
| Scrum Master (SM) | 敏捷教练 / Scrum 主管（项目经理） | 1. 保障 Scrum 流程的落地和团队协作2. 移除团队开发中的障碍（如跨部门沟通、资源问题）3. 组织会议、引导团队实践敏捷4. 保护团队免受外部干扰 | 团队的 "服务式领导者"，保障怎么做 |
| Development Team | 开发团队 | 1. 自组织、跨职能的小团队（通常 3-9 人）2. 负责将需求转化为可交付的产品增量3. 共同承诺迭代目标，完成 Sprint Backlog | 产品的 "实现者"，负责做出什么 |
五个重要会议
需求发布会议
五大重要会议
计划发布会议
每日会议
演示会议
这五个事件（会议）构成了一个完整的 Sprint 迭代周期，环环相扣，保障敏捷的透明、检查与适应。
1. Sprint（迭代本身）
- 核心定位：整个敏捷迭代的时间盒（Timebox），通常 2-4 周，是所有其他会议的载体。
- 目的：在固定周期内，交付一个 "潜在可发布的产品增量"。
- 特点：周期固定，中途不能随意变更目标，除非遇到重大问题终止 Sprint。
2. Sprint Planning（Sprint 规划会）
- 时机：每个 Sprint 开始时
- 时长：1 小时 / 周迭代，例如 2 周迭代不超过 2 小时
- 参与方：PO + SM + 开发团队
- 核心议题：
- 确定本次 Sprint 的目标（Sprint Goal）
- 从产品待办列表中，挑选高优先级的需求，放入 Sprint 待办列表
- 团队拆解任务，预估工作量，确认能完成的范围
3. Daily Scrum（每日站会）
- 时机：每个工作日，固定时间
- 时长：不超过 15 分钟
- 参与方：开发团队（PO/SM 可旁听）
- 核心议题：每个成员回答三个问题：
- 昨天我完成了什么？
- 今天我计划做什么？
- 我遇到了什么障碍？
- 目的：快速同步进度，暴露问题，对齐目标，而非汇报工作。
4. Sprint Review（Sprint 评审会）
- 时机：每个 Sprint 结束前
- 时长：1 小时 / 周迭代
- 参与方：PO + SM + 开发团队 + 相关干系人（客户、业务方）
- 核心动作：
- 团队向干系人演示本次 Sprint 交付的产品增量
- 收集反馈，确认需求是否符合预期
- 调整产品待办列表的优先级
- 目的：验证交付成果，对齐业务价值，获取用户反馈。
5. Sprint Retrospective（Sprint 回顾会）
- 时机：Sprint 评审会结束后
- 时长：1 小时 / 周迭代
- 参与方：PO + SM + 开发团队
- 核心议题：
- 本次 Sprint 中，哪些做得好？
- 哪些地方可以改进？
- 制定具体的改进计划，在下一个 Sprint 落地
- 目的：持续改进团队的流程、协作和效率，是敏捷 "持续优化" 的关键。
Scrum是敏捷模型中的⼀种，⼜称为迭代式增量软件开发模型。 在scrum模型中，主要有三个⻆⾊和五个重要会议
scrum的基本流程如上图所⽰：
螺旋模型
增量模型、迭代模
测试模型
V模型
W模型(双V模型）
BUG篇
bug的概念
简单来说，Bug 就是软件中不符合需求、影响用户正常使用的缺陷。
⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错 误
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤（入口不一样，结果也不一样）、预期结果、实际结果
bug级别
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配 优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
bug级别⼀般分为：崩溃、严重、⼀般、次要
bug的⽣命周期
Bug 生命周期：从测试发现新建，开发确认开启、进行修复，测试回归复测，验证通过则关闭；未通过则重新打开；不是 Bug 则置为无效；暂不修复则延后处理。
一个 Bug 从被发现到被解决，会经历完整的状态流转，这也是面试和工作中必须掌握的核心知识点：
**新建（New）**测试发现缺陷，刚提交，还没人处理。
**指派 / 确认（Open/Active）**开发负责人接收、确认这是真 Bug，准备修复。
**修复中（Fixed/Resolved）**开发改完代码，标记已修复，等待测试回归验证。
**复测（Retest）**测试人员进入环境，重新测试这个 Bug。
通过 / 关闭（Closed） 复测没问题，Bug 彻底修好，关闭。
不通过 / 重新打开（Reopen） 复测没修好、还有问题，重新打开，退回开发再改。
**暂缓 / 延后（Deferred）**不是严重 Bug，当前版本不急着修，放到后续版本再改。
**无效 / 作废（Invalid）**不是 Bug，是操作问题、理解误差、环境问题，直接作废关闭。
与开发产⽣争执怎么办（⾼频考题）
当和开发因 Bug 产生争执时，我会按五步处理：
第一，先自查，核对 Bug 描述、复现步骤、环境日志是否完整清晰，信息不全就主动当面补充沟通；
第二，站在用户角度说明 Bug 对业务和用户体验的影响，定级有理有据；
第三，提升自身业务技术能力，提 Bug 的同时给出合理优化思路，不强行指挥开发；
第四，保持友好理性沟通，就事论事；
第五，若协商无果，就发起Bug 评审会，拉上测试、开发、产品三方共同评估影响、修改风险和最终处理方案。