1. 常见软件开发与测试模型

1.1 瀑布模型

瀑布模型是⼀种传统的软件开发模型，开发过程按照固定顺序推进，每个阶段完成后，才能进⼊下⼀个阶段。

优点：
1.流程规范，便于管理。
2.文档完整，适合大型组织协作。
3.阶段目标明确，容易进行进度控制

缺点：
1.不适合需求频繁变化的项目。
2.测试介入较晚，问题发现较晚。
3.如果需求前期理解错误，后期返工成本很高。

适用场景：
适合需求非常明确、变化较少的项目，例如:
1.政府系统
2.银行内部系统
3.传统企业管理系统
4.合同制外包项目

1.2 V模型

V模型是在瀑布模型基础上发展出来的测试模型。它强调开发阶段和测试阶段之间的对应关系。

适⽤场景
适合以下类型项⽬：
1. 银⾏系统
2. 医疗系统
3. 政府系统
4. 航空、交通等⾼可靠性系统
5. 需求较稳定的⼤型企业系统

优点
1. 测试阶段清晰。
2. 便于提前设计测试计划和测试⽤例。
3. 能够让测试⼈员更早理解需求和设计。
4. 有利于控制项⽬质量。

缺点
1. 对需求变更的适应能⼒较弱。
2. 仍然偏重阶段式开发。
3. 不适合快速变化的互联⽹项⽬。

1.3 W模型

W模型是对V模型的改进。V模型虽然强调测试和开发对应，但测试仍然容易集中在后期。W模型进⼀步强调：测试应该从需求阶段就开始。

适⽤场景
适合以下项⽬：
1. 周期较⻓的⼤型系统。
2. ⽂档要求较⾼的企业项⽬。
3. 需求分析复杂、业务规则多的系统。
4. 出错成本较⾼的项⽬。

优点
1. 可以在需求和设计阶段提前发现问题。
2. 减少后期返⼯成本。
3. 测试⼈员参与更早，对业务理解更深⼊。
4. 有利于提⾼整体质量。

缺点
1. 流程相对较重。
2. 对⽂档和评审要求较⾼。
3. 不适合节奏⾮常快、需求频繁变化的⼩团队项⽬。

1.4 敏捷模型

• 包含三个角色和五个重要会议
  • 三个角色： 产品经理、项目经理、研发团队
  • 五个重要会议：

敏捷开发是⼀种迭代式、增量式的软件开发模式。它不追求⼀次性把所有需求做完，⽽是把项⽬拆成多个⼩版本，每个迭代完成⼀部分功能。

常⻅流程：
需求梳理 → 迭代计划 → 开发 → 测试 → 缺陷修复 → 评审 → 回顾 → 下⼀轮迭代

特点
1. ⼩步快跑，持续交付。
2. 需求可以根据反馈调整。
3. 开发、测试、产品协作频繁。
4. 每个迭代都有相对完整的测试和交付。
适⽤场景
适合以下项⽬：
1. 互联⽹产品
2. 移动 App
3. 电商系统
4. 在线教育系统
5. 需求变化较快的项⽬
6. 初创团队或快速迭代团队
优点
1. 能够快速响应需求变化。
2. 可以持续交付可⽤版本。
3. 测试⼈员可以持续参与项⽬。
4. 有利于快速发现问题和调整⽅向。
缺点
1. 对团队沟通能⼒要求⾼。
2. 如果需求频繁变化但没有管理，容易造成混乱。
3. 对测试⼈员要求较⾼，需要快速理解需求、快速设计⽤例、快速执⾏回归。

2. 敏捷开发测试流程

2.1 需求评审

• 关注点：
  1. 需求清晰度
  2. 异常场景（过期优惠券、退款处理）
  3. 边界条件（数量、权限）
  4. 影响范围（已有功能、多端同步）
  5. 业务规则冲突

2.2 测试点拆分

• 工具：XMind
• 示例（购物车）：

1. 添加/修改/删除商品
2. 库存不足/下架处理
3. 价格变动
4. 登录态（未登录、多端同步）

2.3 测试用例设计

• 方法：
  • 等价类划分
  • 边界值（如商品数量：0, 1, 99, 100）
  • 场景法
  • 错误推测
  • 判定表

2.4 提测与冒烟测试

• 开发提测说明：
  • 功能范围、自测情况、环境配置、数据库/接口变更
• 冒烟测试：
  • 系统启动
  • 核心流程（登录→购物车→订单→支付）

2.5 测试执行与缺陷跟踪

• 记录：
  • 版本、环境、账号、缺陷详情（标题/步骤/预期/实际/附件）
• 缺陷管理：
  • 状态跟踪（新建→修复→验证）
  • 优先级/严重程度

2.6 回归测试

• 范围：修复点 + 关联功能（如优惠券修复后验证满减、退款）

2.7 Sprint评审与复盘

• 评审：完成度、上线标准、遗留问题
• 复盘：需求变更、Bug分布、测试效率、环境稳定性

---

3. 几种模型对比总结

模型	特点	适用场景	优点	缺点
瀑布模型	阶段顺序推进	需求稳定项目	流程清晰	变更成本高
V模型	开发阶段对应测试阶段	质量要求高、需求稳定项目	测试计划清晰	灵活性不足
W模型	测试从需求阶段开始	大型复杂项目	缺陷发现早	流程较重
敏捷模型	迭代开发、持续交付	需求变化快的项目	响应快、反馈快	沟通成本高

4. 软件测试避坑指南：如何制定靠谱的测试策略与风险控制？

4.1 到底什么是“测试策略”？

简单来说，测试策略就是测试工作的“作战方案”。它不需要长篇大论，但必须能回答以下 8 个灵魂拷问：

1. 测什么？（测试范围）
2. 重点测什么？（测试重点）
3. 先测什么？（测试优先级）
4. 怎么测？（测试类型）
5. 谁来测？（资源安排）
6. 用什么工具测？
7. 时间不够时怎么取舍？
8. 上线风险怎么控制？

4.2 拆解测试策略的五大核心要素

我们以一个电商系统为例，把测试策略拆解开来看：

4.2.1. 测试范围：明确边界

首先要搞清楚本次迭代包含哪些模块。比如电商系统通常包括：登录注册、商品搜索、购物车、订单提交、支付、优惠券、退款、后台管理等。

4.2.2. 测试重点：好钢用在刀刃上

资源永远是有限的，不能“眉毛胡子一把抓”。测试重点通常由以下因素决定：

• 用户使用频率高
• 业务风险高（尤其涉及资金、数据安全）
• 改动范围大
• 历史Bug较多
• 影响核心流程

💡 举例： 电商项目中的支付、订单、库存、优惠券、退款就是绝对的高风险模块。这些一旦出问题，直接跟钱过不去，必须优先测！

4.2.3. 测试类型：多维度覆盖

根据项目情况选择合适的测试手段，比如：功能测试、接口测试、UI测试、兼容性测试、性能测试、安全测试、回归测试、冒烟测试、数据库测试、异常测试等。
💡 举例： 针对订单模块，我们可以这样安排：

• 功能测试：验证下单、取消、支付、退款流程。
• 接口测试：验证订单提交、查询、退款接口。
• 数据库测试：验证订单状态、支付状态、库存变化是否落库正确。
• 性能测试：验证大促期间订单接口能否抗住高并发。

4.2.4. 测试优先级：时间不够时的“保命符”

时间充裕当然要全覆盖，但如果时间紧张，请务必死保：核心主流程 > 高风险模块 > 本次改动模块 > 关联模块 > 历史Bug多发模块。
💡 举例： 如果电商项目只剩1天测试时间，优先测：登录 → 商品浏览 → 加购 → 提交订单 → 支付 → 订单查询 → 退款主流程。
至于页面样式细节、低频筛选条件、非核心提示语、冷门配置项，统统延后！

4.2.5. 资源安排：排兵布阵

明确人员分工、测试环境、测试数据、测试工具、时间节点以及风险负责人。

💡 举例： 订单模块由A测试，优惠券由B测试，涉及资金的支付和退款交给经验丰富的老手；接口测试用Postman，Bug管理用禅道，数据库校验用MySQL。

---

4.3 从策略到落地：测试执行的节奏

有了策略，接下来就是按部就班地执行。一个成熟的测试流程通常包括：
需求评审 → 拆分测试点 → 编写测试用例 → 准备测试数据 → 确认测试环境 → 冒烟测试 → 功能/接口测试 → 提交跟踪Bug → 回归测试 → 输出报告 → 上线评审
其中有两个关卡极其重要：

• 准入标准（开发提测前）： 必须自测通过、主流程走通、提测说明完整、环境部署完毕、无阻塞级Bug。
• 准出标准（测试完成后）： 核心用例执行完毕、阻塞/严重级Bug已修复、主要功能回归通过、遗留问题已评估风险、产品/开发/测试三方确认上线。

---

4.4 实战中的风险控制：遇到突发怎么办？

项目从来都不是一帆风顺的，常见的风险及应对策略如下：

风险类型	常见场景	应对策略
时间风险	开发提测延期，5天测试压缩成2天	调整优先级，先保核心流程；缩减低风险测试深度；风险暴露给项目经理。
需求风险	需求不清晰或频繁变更	评审时追问异常/边界；对变更部分及时调整用例。
环境/数据风险	测试环境经常超时，缺乏优惠券/库存测试数据	提前准备造数据脚本；环境问题及时抛出并推动运维解决。
业务风险	涉及资金、订单、隐私数据	优先且深度测试高风险模块，增加数据库层面的校验。

🚨 上线前发现严重Bug怎么办？
不能简单说“上”或“不上”，要先评估：影响范围、出现概率、是否有临时方案。如果影响支付/订单/资金，坚决阻塞上线；如果影响较小，可由产品、开发、测试共同评估“带病上线”的风险，并明确修复时间和应急预案。

🚨 上线前风险评审必须确认：

1. 核心功能是否通过？
2. 严重Bug是否清零？
3. 遗留问题是否可接受？
4. 是否准备回滚方案？
5. 是否安排上线后值班观察？

---

4.5 实战案例：一个隐藏的“库存回滚”Bug

之前测试订单取消功能时，页面上看似一切正常：用户取消未支付订单，订单状态变成了“已取消”。但我多留了个心眼，去数据库查了一下，结果发现库存表里的可售库存并没有加回来！
随后我继续验证“超时自动取消订单”，同样存在库存不恢复的问题。经开发排查，原因是：取消订单的代码只更新了订单状态，忘记调用库存回滚逻辑。
修复后，我立刻补充了以下测试场景：

1. 用户主动取消未支付订单，库存恢复。
2. 订单超时自动取消，库存恢复。
3. 支付后退款，库存是否恢复。
4. 多个用户同时抢购最后一件商品，库存不能扣成负数（并发问题）。
5. 取消订单后，优惠券和积分是否正确返还。
6. 订单状态和库存状态是否始终一致。

面试表达Tip： “之前测试订单取消功能时，发现用户取消未⽀付订单后，库存没有正确恢复。页面上看不太明显，所以我⼜查了数据库，发现订单状态已经变成已取消，但库存表⾥的可售库存没有加回来。后来开发确认是取消订单时只更新了订单状态，没有调⽤库存回滚逻辑。修复后，我补充了用户主动取消、超时⾃动取消、⽀付后退款、多用户抢购等场景，并且重点回归了订单状态、库存变化、优惠券返还和积分返还。”

---

总结： 测试不仅是点点点，更是一场运筹帷幄的战役。制定清晰的测试策略，把控好风险优先级，遇事不慌抽丝剥茧，你就能从“测试执行者”蜕变为“质量守门员”。