软件测试核心概念拆解：需求、开发模型与测试模型全解析

做软件测试，绕不开 “需求怎么看”“项目按什么流程开发”“测试该在哪个阶段介入” 这三个核心问题。这些问题的答案，就藏在需求定义、开发模型和测试模型里。

一、先理清：需求不是 “一句话”，分用户需求和软件需求

很多人以为 “需求” 就是用户提的一句话，比如 “做个登录功能”“搞个声控灯”，但实际工作中，需求要分两层 —— 用户需求和软件需求，后者才是开发和测试的真正依据。

1. 用户需求：“一句话的模糊诉求”

用户需求是甲方或终端用户的原始诉求，通常很简略，（没有经过合理的评估），甚至只有一句话。比如：

• 终端用户说 “我要能在软件上用邮箱注册”；
• 这类需求只讲 “要什么”，没说 “怎么做”“有什么限制”，根本没法直接用来开发或测试。

2. 软件需求：“落地可执行的详细方案”

软件需求（也叫功能需求）是对用户需求的细化，（通过评估后，可以用户需求可以实现的）会明确开发人员要实现的具体功能、输入输出、异常处理等，是开发人员和测试人员执行工作的依据，是测试人员设计用例、执行测试的核心依据。

还是用 “邮箱注册” 举例，软件需求会详细到这种程度：

• 输入要求：姓名 6-15 位字符、密码隐藏显示、验证码、邮箱必填；
• 处理流程：用户同意协议→填信息→提交→收激活邮件（24 小时有效）→激活账号；
• 异常情况：没收到邮件可重发、激活超期需重新发送。

就像说 “饿了”，你得追问出 “想吃你做的红烧肉”，再细化到 “买哪个部位的肉、放多少调料、炖多久”—— 这些具体步骤，就是 “软件需求”。

3. 关键提醒

用户需求不能直接用！必须经过产品经理的需求分析（评估技术可行性、市场可行性、成本收益等），转化为软件需求后，才能作为开发和测试的依据。

二、软件开发模型：不同项目，用不同 “流程模板”

1. 什么是“模型”

你以为的模型：

实际上的：

规范的流程是在时代的演变下逐渐成型的，不是一开始就是规范的流程。

软件开发不是想到哪做到哪，而是有固定的 “流程模板”，这就是开发模型，软件生命周期实际就是软件的开发模型。

不同项目规模、需求明确度，要选不同的模型。先从 “软件生命周期” 说起，这是所有模型的基础。

2. 软件生命周期：从 “出生” 到 “退休” 的全流程

软件和人一样有 “生命周期”，从需求提出到停止维护，要经历 6 个核心阶段，用 “建房子” 的例子类比会更直观：

用户需求：“建房子”

所有开发模型，都是基于这个生命周期的 “不同排列组合”。

补充：

维护：

设计技术文档：

计划文档中：

不同的角色，完成某个动作，所需要的时间。

3. 4 种常见开发模型：特点、优缺点、适用场景

（1）瀑布模型：“线性流程，一步到位”

• 核心逻辑：按 “需求分析→计划→设计→编码→测试→维护” 线性推进，同软件的生命周期基础流程。
• 特点：每个阶段只做一次，线性的，像瀑布一样单向流动。
• 优点：流程清晰、阶段明确，是所有模型的基础。
• 缺点：测试 “后置”—— 前面阶段的问题（比如需求错了）要到测试阶段才发现，容易导致大面积返工，从头再来。可运行的产品很迟才能被看见，产品成型晚，可能上线就过时。测试时间紧张，测试不充分，将产品缺陷暴露给用户（产品质量差）。
• 适用场景：需求固定、规模小的项目（比如开发一个简单的内部工具）。

（2）螺旋模型：“边开发边控风险”

• 核心逻辑：以 “风险分析” 为核心，分多次迭代开发，每次迭代都要先评估风险（比如技术难点、需求变更），再推进开发和测试。
• 特点：各个阶段中，都引入了“风险分析+原型”。
• 优点：全程重视风险，能提前规避大问题；适合需求不明确的项目。
• 缺点：需要额外招聘专业的风险分析人才，耗时耗力。各个阶段是否有遗留问题，完全取决于风险分析人员，与相关人员的技术能力直接挂钩，对风险管理人员要求高。增加了风险分析环节需求人员、时间、资金等投入，成本和时间投入更多。
• 适用场景：规模大、复杂度高、风险高的项目（比如开发大型金融系统）。

引入了“风险分析+原型”的目的：

减少各个阶段遗留的风险问题，避免把问题留到后面的阶段。

（3）增量 / 迭代模型：“分块做” vs “反复改”

增量模型：

一个需求，分析一下分为多个小需求，分别将这些小需求，设计为不同的增量（每个小需求独立开发上线）

迭代模型：

先一个基础版本，之后一版一版增加功能的上线。

很多人会混淆这两个模型，其实核心区别很明显：

• 增量模型：“分块建造”—— 像画人物画，先画头、再画身体、最后画手脚，每个 “块”（增量）开发完就测试、发布，逐步完善产品。
• 迭代模型：“反复求精”—— 先画人物轮廓，再细化五官、上色，每次迭代都优化现有功能，让产品逐渐成熟。
• 优点：降低项目风险，能快速响应用户反馈；测试频繁，问题早发现。
• 适用场景：大型项目、需求不明确（比如开发一款新的社交 APP、购物软件）。

两者通常搭配使用。

（4）敏捷模型：“快速迭代，轻装上阵”

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

一款产品的功能是不断在变化的，eg：微信APP

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

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

• 关键原则：看《敏捷宣言》就懂了 ——“个体交互重于流程工具”“可用软件重于完备文档”“客户协作重于合同谈判”“响应变化重于遵循计划”（不是否定后者，而是更看重前者）。
• 特点：轻文档、轻流程、重目标、重产出。
• 常见形式（Scrum）：
  • 3 个角色：（product owner）产品经理（收集整理需求，产出需求文档）、（scrum master）项目经理（协调会议）、（team）研发团队（由好多角色组成执行开发、测试）。
  • 迭代周期：scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，每次迭代只做少量需求，参与团队成员一般是5-9人，完成后立即交付、收集反馈。
  • 5 个会议：迭代计划会（拆任务）、每日例会（同步进度）、演示会（展示成果）、回顾会（总结改进）。
• 敏捷中的测试（轻文档和快速迭代）：
  • 轻文档：不用传统 Excel 写用例，改用思维导图、探索性测试（边设计边执行）；
  • 重协作：测试人员提前主动和开发沟通需求，一起排查 bug。
• 适用场景：需求变化快、追求快速上线的项目（比如互联网创业公司的产品）。

scrum的基本流程如上图所示：

• 产品负责人负责整理user story（用户需求），形成左侧的product backlog。

• 发布计划会议：product owner负责讲解user story，对其进行估算和排序（优先级高的先），发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

• 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责人，并完成工时的初估计。

• 每日例会（站会）：每天scrum master召集站立会议，团队成员回答昨天做了什么（明确每个人各自任务进度）、今天计划做什么（今日目标计划）、遇到什么问题（有问题及时解决，保证产品在规定的迭代周期内正常交付）。

• 演示会议：迭代结束之后，召开演示会议，相关人员（包括甲方大大）都受邀参加，团队负责向大家展示本次迭代取得的成果（演示所产出的一个可交付的软件）。期间大家的反馈记录下来，由po（产品经理）整理，形成新的story。

• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，回顾上次迭代流程中的问题，下一次迭代继续改进，不断优化，以达到持续改进的效果。

三、测试模型：明确 “测试该在什么时候做”

开发有模型，测试也有对应的 “行动指南”，最核心的是 V 模型和 W 模型，解决的是 “测试阶段与开发阶段如何配合” 的问题。

1. V 模型：“测试跟着开发走，编码后才开始”

• 核心逻辑：是瀑布模型的变种，左边是开发阶段（需求分析→系统设计→详细设计→编码），右边是对应的测试阶段，呈 “V” 字结构：明确的标注了测试过程中存在的不同类型的测试。
  • 单元测试（测单个代码模块），参照详细设计。
  • 集成测试（测模块间接口），参照概要设计。
  • 系统测试（测整体功能性能），参照需求分析与系统。
  • 验收测试（测是否满足用户需求），参照用户需求。
• 优点：明确了 “不同开发阶段对应什么测试”，提升测试针对性。
• 缺点：测试 “后置”—— 需求、设计阶段不介入测试，容易遗漏早期问题（比如需求理解错了，到验收测试才发现），同瀑布模型缺点。

2. W 模型（双 V 模型）：“测试与开发同步，需求阶段就介入”

• 核心改进：解决了 V 模型 “测试不前置” 的问题，把 “验证和确认” 融入每个开发阶段，形成两个并行的 “V”（开发 V 和测试 V）：
  • 需求分析阶段：同步做 “需求验证”（测需求文档是否合理）+ 验收测试准备；
  • 系统设计阶段：同步做 “设计验证”+ 系统测试准备；
  • 编码阶段：同步做 “单元测试准备”。
• 优点：测试更早介入，能提前发现需求、设计里的问题，减少后期返工。测试对象不只是程序代码，还包括需求文档、设计文档等，都要测试。测试和开发是同步进行的。
• 缺点：需求、设计、编码等活动被视为串行的。测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。重流程，无法支持敏捷开发模式（轻文档、轻流程）。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

软件测试的核心是 “保障质量”，而理解这些基础概念，就是找到 “高效保障质量” 的第一步。后续不管是设计用例还是执行测试，都能更有方向感～