软件工程概念篇：需求、开发模型与测试模型全解析

类型	内容
用户需求	女朋友说：「我饿了」------很简略，就一句话
软件需求	需要你和她反复沟通，了解更详细具体的需求，制定解决方案

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

复制代码

软件需求规格说明书

一、用户需求：
平台支持邮箱注册

二、软件需求：
（详细描述邮箱注册的功能细节、输入输出、异常处理等）

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

二、软件的生命周期

2.1 什么是生命周期

生命周期指的是从生命的开始到生命结束的一段时间。以人为例，人类的生命周期从生命孕育开始，经历幼年、童年、少年、青年、老年，直至死亡。

软件/产品的生命周期也是如此：需求的开始是软件生命的起点，中间会经历需求的计划、设计、程序开发、程序测试等阶段，直至软件不再进行维护便到了生命的终点。

2.2 建房案例：房子的一生

假如我想要建造一套房子，房子的生命周期（流程）是什么样的？

步骤	总结	映射软件流程	关键产出/说明
为什么要建房子？商品房还是普通住宅？建造100层技术上是否可行？	明确合理的建房目标	需求分析	业务目标、用户需求、功能/非功能需求、可行性分析、需求规格说明书
什么时候开发建房？计划竣工时间？多久可以交房？	计划好时间	计划	WBS、里程碑、排期、预算、资源计划、风险清单
建房前明确流程：先打地基、做基础框架、砌墙、粉刷、水电工程......	设计好具体的建房流程	设计	架构设计、概要设计、详细设计、数据库/接口/UI设计、部署方案
按照前面的流程和时间实施建房中......	施工中	编码/开发	代码实现、模块集成、代码评审、CI/CD、版本控制
房屋建造完成，开发商验收成果、买家验收房子品质：是否牢固、漏水、偷工减料、按规定建造	检查房屋建造结果	测试/验收	单元测试、集成测试、系统测试、验收测试、缺陷跟踪、测试报告
检查结束开始逐步入住，使用中出现漏水、墙面掉皮、下水道堵塞等问题，一边使用一边找物业修理	使用并及时维护	运行维护	上线部署、监控告警、日志、工单、故障修复、版本迭代、SLA

精简流程链：

需求分析 → 计划 → 设计 → 编码/开发 → 测试/验收 → 运行维护

对应建房：

明确目标与可行性 → 定工期 → 出图纸和工序 → 施工 → 验收 → 入住与物业维护

2.3 软件生命周期各阶段详解

阶段	具体内容	产出
需求分析	分析用户需求是否合理，分别从市场需求、技术等方面进行分析	需求等文档
计划	对成立的需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能	计划等文档
设计	将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（架构设计、接口设计、技术选型）	技术等文档
编码	开发人员参考需求文档、设计文档、交互图等进行代码编写	代码文件等文档
测试	测试人员介入到软件测试中，参考测试用例对软件进行测试	测试用例、测试设计与计划、测试报告等文档
运行维护	项目测试结束后上线，并对产品进行线上维护	维护记录、版本迭代文档

运行维护的三个方向：

修复性维护：对项目中未发现的问题进行修复。
完善性维护：对功能进行完善。
预防性维护：居安思危，为了避免产品在线上出现一些其他不可预料的问题，进行一些防护手段。

三、常见开发模型

3.1 瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架 。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的一个最大缺陷在于：可以运行的产品很迟才能被看到 。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：「集成之日就是爆炸之日」。

尽管瀑布模型存在很大的缺陷，例如在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

瀑布模型优缺点总结

维度	优点 / 特点	缺点
阶段管理	强调开发的阶段性，阶段划分清晰	阶段之间串行推进，灵活性差
执行方式	线性结构，每个阶段只执行一次	无法适应需求频繁变更
模型地位	是其他模型的基础框架	过于理想化，实际项目很难完全按序执行
测试位置	------	测试后置
风险暴露	------	前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去及早修复的机会
测试充分性	------	必须留有足够时间给测试活动，否则测试不充分，缺陷直接暴露给用户（产品质量差）
交付周期	------	周期太长，产品很迟才能被看到和使用，可能导致需求/功能过时

适用场景 ：需求固定的小项目。

3.2 螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大 的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求：它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代 。因此，回归测试的重要性就不言而喻了。

螺旋模型优缺点总结

类型	内容
优点	强调严格的全过程风险管理
优点	强调各开发阶段的质量
优点	增加风险分析和原型
缺点	项目中可能存在的风险性与风险管理人员的技能水平有直接关系
缺点	需求人员、资金、时间的增加和投入，可能会导致项目的成本太高

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

3.3 增量模型与迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。

增量开发模型鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量开发和迭代开发往往容易被混淆，但两者是有区别的：

增量是逐块建造的概念
迭代是反复求精的概念

画人物画的例子

模型	过程
增量模型	先画人的头部，再画身体，再画手脚......
迭代模型	先画整体轮廓，再勾勒出基本雏形，再细化、着色......

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

3.4 敏捷模型

在早期，迭代瀑布模型非常流行来完成一个项目。但是现在开发人员在使用它开发软件时面临着各种各样的问题。主要困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。为了克服瀑布模型的这些缺点，在1990年代中期提出了敏捷软件开发模型。

敏捷模型主要旨在帮助项目快速适应变更请求 。因此，敏捷模型的主要目的是促进项目的快速完成。要完成这项任务，需要敏捷。敏捷性是通过使过程适应项目，删除对特定项目可能不是必需的活动来实现的。此外，避免任何浪费时间和精力的事情。

在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理，并且只能在几周内完成。一次为客户计划、开发和部署一个迭代。没有制定长期计划。

《敏捷宣言》

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

宣言中主要运用了对比的手法，然而，在每对对比中，后者并非全无价值，但我们更看重前者。

通过敏捷宣言可以总结出敏捷模型的四个特点：轻文档，轻流程，重目标，重产出。

Scrum 模型

敏捷开发有很多种方式，其中 Scrum 是比较流行的一种。Scrum 是敏捷模型中的一种，又称为迭代式增量软件开发模型。

三个角色：

角色	职责
Product Owner（产品经理）	负责整理 User Story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责
Scrum Master（项目经理）	负责召开各种会议，协调项目，为研发团队服务
Team（研发团队）	由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品

迭代开发：

与瀑布不同，Scrum 将产品的开发分解为若干个小 Sprint（迭代），其周期从 1 周到 4 周不等，但不会超过 4 周。参与的团队成员一般是 5 到 9 人。每期迭代要完成的 User Story 是固定的。每次迭代会产生一定的交付。

五个重要会议：

会议	内容
发布计划会议	Product Owner 负责讲解 User Story，对其进行估算和排序，产出这一期迭代要完成的 Story 列表，即 Sprint Backlog
迭代计划会议	项目团队对每一个 Story 进行任务分解，分解的标准是完成该 Story 的所有任务，每个任务都有明确的负责人，并完成工时的初估计
每日例会	每天 Scrum Master 召集站立会议，团队成员回答昨天做了什么、今天计划做什么、有什么问题
演示会议	迭代结束之后召开，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由 PO 整理，形成新的 Story
回顾会议	项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果

敏捷中的测试

轻文档和快速迭代
- 敏捷模型中强调轻文档，所以测试人员不应使用传统的 Excel 编写测试用例的方法，更多的是使用思维导图、探索性测试 （强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划）、自动化测试等。
- 敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究 Bug 出现的原因。

四、测试模型

测试模型中有两个非常重要且具有标志性的测试模型：V模型 和W模型。

它们讨论的核心问题是：

测试在软件开发过程中处于什么位置？测试和开发阶段如何对应？测试应该什么时候介入？

4.1 V模型

V模型最早由 Paul Rook 在 20 世纪 80 年代后期提出，目的是改进软件开发的效率和效果。它是瀑布模型的变种。

核心思想

V模型把开发过程和测试过程对应起来，左边是开发阶段，右边是测试阶段，形成一个大写的"V"字。

典型的对应关系如下：

开发阶段	对应测试阶段
需求分析	验收测试
概要设计	系统测试
详细设计	集成测试
编码	单元测试

也就是说：

单元测试、集成测试：检测程序执行是否满足软件设计的要求；
系统测试：检测系统功能、性能等质量特性是否达到系统要求的指标；
验收测试：确定软件实现是否满足用户需要或合同要求。

优点

明确标注了测试过程中存在的不同类型测试；
清楚描述了测试阶段和开发过程各阶段的对应关系；
有效提升测试的质量和效率；
让不同层次的测试有明确的依据和方向。

缺点

仅仅把测试作为编码之后的一个阶段；
未在需求阶段就介入测试；
缺点同瀑布模型：测试后置、风险发现晚、返工成本高。

一句话理解

V模型解决了"测试有哪些类型、分别对应开发哪个阶段"的问题，但没有解决"测试应该尽早介入"的问题。

4.2 W模型（双V模型）

V模型中未将测试前置的问题，在 W模型中得以解决。

W模型增加了软件各开发阶段中应同步进行的验证和确认活动 。W模型由两个 V 字型模型组成，分别代表测试过程 和开发过程，明确表示出了测试与开发的并行关系。

核心特点

测试的对象不仅是程序；
需求、设计等同样要测试；
测试与开发是同步进行的。

可以理解为：

开发线	测试线
需求分析	需求验证与确认
概要设计	设计验证与确认
详细设计	详细设计验证与确认
编码	单元测试、集成测试等
系统集成	系统测试
交付	验收测试

W模型强调：每个开发阶段都有对应的测试活动，测试不应该等到编码完成之后才开始。

优点

有利于尽早、全面地发现问题；
例如需求分析完成后，测试人员就应参与对需求的验证和确认；
可以尽早找出缺陷；
对需求的测试有利于及时了解项目难度和测试风险；
便于及早制定应对措施；
显著减少总体测试时间，加快项目进度。

缺点

需求、设计、编码等活动被视为串行的；
测试和开发活动也保持着一种线性的前后关系；
上一阶段完全结束，才可正式开始下一个阶段工作；
重流程，无法支持敏捷开发模式；
对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

一句话理解

W模型解决了"测试要尽早介入、与开发同步"的问题，但它仍然偏重流程和线性推进，不适合敏捷开发。

4.3 V模型 vs W模型对比

对比维度	V模型	W模型
别名	V模型	双V模型
基础	瀑布模型的变种	在V模型基础上发展
测试介入时间	编码之后	需求阶段就开始介入
测试与开发关系	开发完成后对应测试	测试与开发并行
测试对象	主要针对程序	程序、需求、设计等
优点	明确测试类型与开发阶段对应	尽早全面发现问题，降低风险
缺点	测试后置，同瀑布模型	串行、线性、重流程，不支持敏捷
适用思想	传统线性开发	强调验证与确认同步

五、总结与对比

5.1 开发模型对比

模型	核心思想	适用场景	主要缺点
瀑布模型	线性顺序，阶段一次性执行	需求固定的小项目	测试后置、周期长、风险发现晚
螺旋模型	迭代 + 风险管理 + 原型	规模庞大、复杂度高、风险大的项目	依赖风险管理人员水平、成本高
增量模型	逐块建造	大型项目、需求不明确	需要持续集成支持
迭代模型	反复求精	大型项目、需求不明确	需要频繁测试与协作
敏捷/Scrum	快速响应变化、轻文档、迭代交付	需求多变、追求快速交付的项目	对团队协作和自动化要求高

5.2 测试模型对比

模型	核心特点	优点	缺点
V模型	测试在编码之后，与开发阶段对应	明确测试类型与开发阶段的对应关系	测试后置，未在需求阶段介入
W模型	测试与开发并行，双V结构	尽早全面发现问题，测试前置	串行线性、重流程、不支持敏捷

5.3 一句话总结

需求是软件生命的起点，开发模型决定「怎么走」，测试模型决定「怎么验」。瀑布适合需求固定的小项目，螺旋适合高风险大项目，增量/迭代适合需求不明确的大型项目，敏捷适合快速变化的项目；V模型强调测试与开发的对应，W模型强调测试与开发同步。实际项目中，往往需要根据项目特点灵活选择和组合这些模型。

软件工程概念篇：需求、开发模型与测试模型全解析

一、需求：用户需求 vs 软件需求

1.1 用户需求

1.2 软件需求

1.3 两者的区别：女朋友饿了的例子

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

二、软件的生命周期

2.1 什么是生命周期

2.2 建房案例：房子的一生

2.3 软件生命周期各阶段详解

三、常见开发模型

3.1 瀑布模型

瀑布模型优缺点总结

3.2 螺旋模型

螺旋模型优缺点总结

3.3 增量模型与迭代模型

画人物画的例子

3.4 敏捷模型

《敏捷宣言》

Scrum 模型

敏捷中的测试

四、测试模型

4.1 V模型

核心思想

优点

缺点

一句话理解

4.2 W模型（双V模型）

核心特点

优点

缺点

一句话理解

4.3 V模型 vs W模型 对比

五、总结与对比

5.1 开发模型对比

5.2 测试模型对比

5.3 一句话总结

4.3 V模型 vs W模型对比