---

前言

在上一篇文章中，我们了解了“什么是测试”以及测试与开发的区别。今天，我们来深入探讨软件测试中的核心概念：需求、开发模型和测试模型。

无论你是测试新手还是正在准备面试，这些内容都是必须掌握的基础知识。

---

一、什么是需求？

在多数软件公司中，需求分为两部分：用户需求和软件需求。

1.1 用户需求

用户需求可以简单理解为甲方提出的需求，如果没有甲方，那就是终端用户使用产品时必须完成的任务。这类需求一般比较简略，通常就是一句话。

例如：

• 实现一个声控灯
• 实现软件的登录功能

用户的需求五花八门，往往只是一句话。而产品经理需要把这些“一句话需求”转化成开发人员能看懂的技术文档。

---

1.2 软件需求

软件需求（也叫功能需求）会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

经典案例：女朋友饿了

用户需求：女朋友说“我饿了”——这就是一个典型的用户需求，很简略。

软件需求：你需要和她反复沟通，了解更详细具体的需求：

• “想吃啥？”——“随便”
• “吃米饭炒菜？”——“不想吃”
• “那你想吃啥？”——“随便”
• “吃油泼面？”——“不想吃”
• “那你想吃啥？”——“随便”

最终搞清楚：女朋友想吃的是你亲手做的红烧肉。

然后，你需要研究肉怎么买、怎么做等具体步骤——这就是软件需求。

实际工作中的软件需求文档示例

---

以“平台支持邮箱注册”为例，软件需求文档会详细描述：

序号	栏位名称	栏位说明	长度	类型	备注
1	姓名	必填，录入个人姓名	6-15位	字符型
2	电子邮箱	必填	-	字符型
3	密码	必填，隐藏显示	6-15位	字符型
4	确认密码	必填，隐藏显示	6-15位	字符型
5	验证码	必填	-	字符型
6	注册	注册操作	-	操作型

还包括基本事件流、扩展事件流、异常事件流等详细说明。

注意：用户需求不能直接作为开发和测试的依据。 产品经理需要进行需求分析（技术可行性、市场可行性、成本收益等）后，才能将其转变为软件需求。

---

二、开发模型

2.1 什么是模型？

随着软件工程学科的发展，软件工作的范围从单纯的程序编写扩展到整个软件生命周期：概念形成、需求分析、设计、实现、测试、安装部署、运行维护，直到被新版本替换。

你以为的模型

实际的模型

2.2 软件的生命周期

类比人类生命周期(孕育→幼年→童年→少年→青年→老年→死亡）
软件的生命周期为：需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护

案例

假如我想要建造⼀套房⼦（别问，问就是⼀个⼈造房⼦），房⼦的⽣命周期（流程）是什么样的？

各阶段详解：

步骤	总结	映射软件流程
为什么要建房⼦？商品房还是普通住宅？建造100层技术上是否可⾏？	明确合理的建房⽬标	需求分析
什么时候开发建房⼦？计划竣⼯时间？多久可以交房？	计划好时间	计划
建房前明确流程：先打地基，做基础框架，砌墙、粉刷、⽔电⼯程…	设计好具体的建房流程	设计
按照前⾯的流程和时间实施建房中…	施⼯中	编码
房屋建造完成，开发商验收成果、买家验收房⼦品质（房⼦是否牢固，是否漏⽔及其他偷⼯减料的地⽅，是否按照规定来建造的）	检查房屋建造结果	测试
检查结束开始逐步⼊住，使⽤中出现了各种情况如房屋漏⽔、墙⾯掉⽪、下⽔道堵塞等问题，⼀边使⽤⼀边找物业修理	使⽤并及时维护	运⾏维护

软件开发的生命周期：

阶段	具体内容	产出
需求分析	分析用户需求是否合理（市场、技术等方面）	需求文档
计划	制定执行计划，明确时间节点和功能	计划文档
设计	将需求细化成任务，进行技术设计	技术文档
编码	开发人员编写代码	代码文件
测试	测试人员介入测试	测试用例、测试报告
运行维护	上线并维护，包括修复性、完善性、预防性维护	维护记录

---

2.3 常见开发模型

2.3.1 瀑布模型

瀑布模型是所有其他模型的基础框架，每个阶段只执行一次，呈线性顺序。

优点

• 强调开发的阶段性；
• 线性结构，每个阶段只执⾏⼀次
• 是其他模型的基础框架

缺点

• 测试后置，风险推迟到测试阶段才发现
• 产品很迟才能被看到，可能导致需求过时
• 必须留有足够测试时间，否则产品质量差

适用场景

• 需求固定的小项目

---

2.3.2 螺旋模型

适合规模庞大、复杂度高、风险大的项目，尤其在开发初期需求不明确时。

特点

• 强调严格的全过程风险管理
• 增加风险分析和原型
• 测试必须跟随开发迭代

缺点

• 对风险管理人员技能要求高，可能导致成本过高

---

2.3.3 增量模型 vs 迭代模型

很多人容易混淆这两个概念：

模型	概念	类比
增量开发	逐块建造	先画头部，再画身体，再画手脚
迭代开发	反复求精	先画轮廓，再勾勒雏形，再细化着色

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

---

2.3.4 敏捷模型

在1990年代中期提出，旨在帮助项目快速适应变更请求。

敏捷宣言

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

敏捷模型的四个特点

• 轻文档、轻流程、重目标、重产出

---

Scrum框架

Scrum是敏捷模型中最流行的一种，又称为迭代式增量软件开发模型。

三个角色

• Product Owner（产品经理）：整理用户故事，定义商业价值，制定发布计划
• Scrum Master（项目经理）：召开会议，协调项目，服务研发团队
• Team（研发团队）：5-9人，紧密协同完成迭代目标

五个重要会议

1. 发布计划会议
2. 迭代计划会议
3. 每日例会
4. 演示会议
5. 回顾会议

---

敏捷中的测试

由于强调轻文档和快速迭代，测试人员不应使用传统的Excel编写测试用例，而应更多使用：

• 思维导图
• 探索性测试（设计和执行同时进行）
• 自动化测试
• 主动与开发人员沟通协作

---

三、测试模型

测试模型中有两个重要标志：V模型和W模型。

3.1 V模型

V模型是瀑布模型的变种，明确标注了测试过程中不同类型的测试及其与开发阶段的对应关系。

优点

• 明确单元测试、集成测试、系统测试、验收测试与开发阶段的对应关系
• 有效提升测试质量和效率

缺点

• 仅把测试作为编码后的阶段，未在需求阶段介入
• 同瀑布模型的问题

3.2 W模型（双V模型）

W模型解决了V模型中“测试未前置”的问题，增加了各开发阶段中应同步进行的验证和确认活动。

特点

• 测试对象不仅是程序，需求、设计等也需要测试
• 测试与开发同步进行

优点

• 有利于尽早、全面地发现问题
• 需求分析完成后，测试人员即可参与需求验证
• 及早了解项目难度和风险，加快项目进度

缺点

• 需求、设计、编码等活动仍被视为串行
• 上一阶段完全结束后才能开始下一阶段
• 重流程，无法支持敏捷开发

---

四、总结对比

模型	核心特点	适用场景	主要缺陷
瀑布模型	线性顺序，阶段单一	需求固定的小项目	测试后置，风险高
螺旋模型	渐进式，风险分析	大规模、高风险项目	成本高，依赖人员技能
敏捷模型	迭代，轻文档，快适应	需求变化快的项目	文档少，需强协作
V模型	测试与开发对应	传统开发模式	测试未前置
W模型	测试同步开发	需求明确的传统项目	不支持敏捷

---

五、高频面试题速记

1. 用户需求和软件需求的区别？

• 用户需求：一句话描述，来自甲方或用户
• 软件需求：详细的技术文档，是测试的基本依据

2. 软件生命周期包含哪些阶段？

• 需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护

3. V模型和W模型的核心区别？

• V模型：测试在编码后
• W模型：测试与开发同步，需求阶段即可介入

4. 敏捷模型的核心特点？

• 轻文档、轻流程、重目标、重产出
• 快速适应变化，迭代交付

---

掌握需求、开发模型和测试模型的概念，是软件测试入门的关键一步。无论是面试还是实际工作，这些基础知识都会反复用到。

下一篇文章我们将深入讲解测试用例设计方法，敬请期待！

你对哪个模型最感兴趣？欢迎在评论区留言讨论！

---