【软件测试】（概念篇）《需求的概念，测试用例（case)，软件错误（bug），开发模型以及测试模型》---详解

一. 衡量软件测试结果的依据 — 需求

1.需求的概念：

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求

IEEE 给的定义：

软件需求是：

（1）用户解决问题或达到目标所需的条件或权能（Capability）。

（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

（3）一种反映上面（1）或（2）所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准，或者设计限制。

在多数软件公司中，需求通常分为两部分：一部分是用户需求，另一部分是软件需求。

（1）用户需求

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

用户的需求五花八门，往往只是一句话，比如：实现一个声控灯，实现一个软件的登录功能。

（2）软件需求

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

大多数公司在进行软件开发时，会把用户需求转化为软件需求，而开发人员和测试人员工作的直接依据就是软件需求。

理解起来就是用户需求就是一句话，软件需求是一个文档（详细描述用户需求如何实现），日常工作中通常是用软件需求进行开发测试。

⽤⼾需求和软件需求有什么不同呢？看看下⾯的案例

⼥朋友饿了的例⼦
⽤⼾需求：
⼥朋友说, 我饿了, 这是⼀个⽤⼾需求. 很简略.
软件需求：
需要你和她反复的沟通了解更加详细具体的需求, 来制定解决⽅案.
⽐如你问她, "想吃啥?", 她说, "随便"
"吃⽶饭炒菜?", "不想吃"; "那你想吃啥?", "随便"
"吃油泼⾯?", "不想吃"; "那你想吃啥?", "随便"
…
最终理解清楚⽤⼾需求之后, 知道⼥朋友想吃的是你做的红烧⾁, 那么再去研究⾁怎么买, 怎么做等等
的具体步骤, 是软件需求.

在⼯作中我们实际⻅到的软件需求⽂档类似于下⾯的表述：

软件需求规格说明书
⼀、⽤⼾需求：
平台⽀持邮箱注册
⼆、软件需求：
1.1.1.1 注册账号

1.1.1.1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。

1.1.1.1.2 用户角色
匿名用户。

1.1.1.1.3 前置条件
无。

1.1.1.1.4 输入

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

1.1.1.1.5.1 基本事件流
1、用户选择注册；
2、系统展现用户协议界面，并请用户确认是否同意用户协议。
若用户不同意协议，系统禁止用户注册。
若用户同意协议，用户进行注册信息填写。
3、用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、用户提交注册信息；
5、系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2 扩展事件流
用户注册并激活成功后，第一次登录平台时，提示用户完善信息；

1.1.1.1.5.3 异常事件流
若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出
用户注册成功

1.1.1.1.7 后置条件
该模块为用户登陆等的前置模块。

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

为什么要有需求？

有需求才有目标，做事就需要有明确的需求。

2.从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例时，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后针对每个测试需求点设计测试用例。

过程如下：业务需求 –> 软件功能需求点 –> 测试需求点 –> 测试用例

以“用户登录”为例，来阐述一下整个过程：

3.为什么需求对软件测试人员如此重要

从软件功能需求出发，无遗漏地识别出测试需求是至关重要的，这将直接关系到测试用例的覆盖率。

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

4.如何才可以深入理解被测试软件的需求

测试工程师应在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件原始业务需求的最好时机。

只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

二.测试用例（Case）的概念

测试用例（Test Case）是为了实施测试而向被测试系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了两大问题：测什么，怎么测。

测试用例的作用：

• 指导测试执行，避免遗漏；

• 便于回归测试和版本迭代；

• 衡量测试覆盖率；

• 方便测试人员之间的协作与交接。

1.举例如下：

【测试用例：淘宝购物下单】

• 测试环境：淘宝 APP（Android 端 / iOS 端）

• 操作步骤：打开 APP，搜索商品，加入购物车，提交订单，完成支付

• 测试数据：商品名称、收货地址、支付方式（支付宝/微信）、优惠券

• 预期结果：订单提交成功，支付成功，订单状态变为“待发货”

• 序号：1、2、3….

• 标题：商品成功下单并完成支付

【测试用例：taobao-001】

测试用例 taobao-001:
用户成功购买商品
——————————————————————————–
步骤动作: | 期望的结果:
——————————————————————————–
打开淘宝 APP，登录账号 | 登录成功，进入首页
——————————————————————————–
搜索指定商品并进入商品详情页 | 商品详情页正常展示，包含价格、库存、评价等
——————————————————————————–
选择商品规格（颜色、尺码），点击加入购物车 | 提示加入购物车成功，购物车数量+1
——————————————————————————–
进入购物车，勾选商品，点击结算 | 进入订单确认页面，商品信息、收货地址正确
——————————————————————————–
选择收货地址，选择支付方式，提交订单 | 订单提交成功，跳转到支付页面
——————————————————————————–
完成支付（支付宝/微信） | 支付成功，订单状态变为“待发货”
——————————————————————————–
测试方式 | 手工
——————————————————————————–
重要性 | 重要
——————————————————————————–
测试环境 | Android 13 / iOS 16
——————————————————————————–
测试前提 | 账号已登录，收货地址已添加，网络正常
——————————————————————————–
功能模块 | 购物下单

2.为什么要有测试用例

测试过程中可能会遇到以下问题：

• 不知道是否较全面地测试了所有功能；

• 测试的覆盖率无法衡量；

• 对新版本的重复测试很难实施；

• 存在大量冗余测试，影响测试效率。

测试用例的产生就是为了解决上述问题。

• 测试用例可以提高测试人员的工作效率，降低测试人员工作的重复性。

• 测试用例是建立自动化的基础。（自动化就是把测试人员的双手解放出来，让代码代替人工执行测试）

三.软件错误（BUG）的概念

第一个 bug：

1945 年 9 月的某天，在一间老式建筑里，从窗外飞进来一只飞蛾。此时 Hopper 正埋头工作在一台名为 Mark II 的计算机前，并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器（电子机械装置，那时还没有使用晶体管）。突然，Mark II 死机了。Hopper 试了很多次还是不能启动，她开始用各种方法查找问题，最后定位到了某个电路板的继电器上。Hopper 观察这个继电器，惊奇地发现一只飞蛾已经被继电器打死。Hopper 小心地用镊子将飞蛾夹出来，用透明胶布贴到“事件记录本”中，写上“第一个发现虫子的实例”。Hopper 的事件记录本，连同那只飞蛾，现在都陈列在美国历史博物馆中。

软件错误的一般定义：程序与规格说明之间不匹配。

注意： 以上说法是片面的。准确地说：当且仅当规格说明（软件需求 / 规格说明书）是存在的并且正确，程序与规格说明之间的不匹配才是错误（预期结果 != 执行结果）。

当需求规格说明书没有提到的功能时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

四.开发模型和测试模型

1.什么是模型

随着软件⼯程学科的发展，⼈们对计算机软件的认识逐渐深⼊。软件⼯作的范围不仅仅局限在程序编写，⽽是扩展到了整个软件⽣命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运⾏维护，直到软件被更新和替换新的版本。软件⼯程还包括很多技术性的管理⼯作，例如过程管理、产品管理、资源管理和质量管理，在这些⽅⾯也逐步地建⽴起了标准或规范。

2.软件的⽣命周期

认识具体的开发模型之前先了解软件的⽣命周期。

什么是⽣命周期？

⽣命周期指的是从⽣命的开始到⽣命结束的⼀段时间。以⼈为例，⼈类的⽣命周期是从⽣命孕育的开始，中间会经历幼年，童年，少年，⻘年，⽼年，最终直⾄死亡。
⽽软件/产品的⽣命周期也是如此，需求的开始是软件⽣命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直⾄软件不再进⾏维护便到了⽣命的重点。

案例：

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

因此，我们就得到了软件（开发）的⽣命周期：

需求分析⸺计划⸺设计⸺编码⸺测试⸺运⾏维护

对于软件的⽣命周期中，每个阶段都在做什么呢？

【测试报告】

项目名称： 学生信息管理系统
开发： 张三
测试： 李四
产品经理： 王五
Bug 描述：
在学生信息管理系统中，当用户进入 “学生列表” 页面，点击 “新增学生” 按钮并提交表单时，如果表单中 “学号” 字段为空，系统没有给出明确的错误提示，而是直接保存了一条学号为空的学生记录。该问题导致学生列表中出现异常数据，影响后续查询和统计功能。

测试周期： 5 天（6.01 – 6.05）
开发周期： 10 天（5.20 – 5.30）

风险：
低风险。该问题不会造成系统崩溃或数据泄露，但会影响数据准确性，建议在后续版本中增加表单校验和错误提示

最后一个阶段运行维护

具体产出：项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面，分别为修复性维护、完善性维护和预防性维护。

如果出现线上问题，此时测试人员需要协助开发定位问题 + 解决问题。

3.测试模型 —— 瀑布模型（Waterfall Model）

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

阶段产出：

• 需求分析：输出需求文档
• 计划：确定项目起止时间与排期
• 设计：输出技术文档（包含接口、数据库表、消息队列、定时任务等内容）、UI 视觉稿
• 编码：程序代码开发
• 测试：执行测试用例、提交缺陷、开展验收

(1) 优点

• 开发过程划分成清晰独立的阶段，阶段性强
• 重视项目前期规划与需求调研工作
• 重视产品测试环节
• 每个阶段的工作内容与交付物明确清楚
• 模型为线性流程，各阶段仅执行一次，是很多其他软件开发模型的基础框架

(2) 缺点

• 测试滞后：前期各阶段埋下的问题，往往等到测试阶段才暴露，极易引发大规模返工，错失早期修复缺陷的机会
• 需要预留充足的测试时间；若测试时间不足，测试覆盖不全，缺陷会直接交付给用户，影响产品质量
• 项目整体周期偏长，可用产品交付很晚，容易出现需求过时、功能不符合当下业务的情况
• 高度依赖前期一次性需求调研，很难应对需求中途变更
• 流程单向不可逆，项目过程中积累的经验，无法反向优化本项目前面的开发环节
• 项目风险大多到后期测试阶段才显现，没办法尽早纠正

瀑布模型的⼀个最⼤缺陷在于，可以运⾏的产品很迟才能被看到。这会给项⽬带来很⼤的⻛险，尤其是集成的⻛险。因为如果在需求引⼊的⼀个缺陷要到测试阶段甚⾄更后的阶段才发现，通常会导致前⾯阶段的⼯作⼤⾯积返⼯，业界流⾏的说法是：“集成之⽇就是爆炸之⽇”。尽管瀑布模型存在很⼤的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后⾯的阶段，⽽在后⾯阶段发现这些错误时，可能已经很难回头再修正，从⽽导致项⽬的失败。但是⽬前很多软件企业还是沿⽤了瀑布模型的线性思想，在这个基础上做出⾃⼰的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺⼊迭代的思想。在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有⾜够的时间预留给测试活动，否则将导致测试不充分，从⽽把缺陷直接遗留给⽤⼾

（3）适用的项目

比如那些需求固定的小型项目适用于这种模型。

4.测试模型 —— 螺旋模型（Spiral Model）

⼀般在软件开发初期阶段需求不是很明确时，采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的代表之⼀。
这对于那些规模庞⼤、复杂度⾼、⻛险⼤的项⽬尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有⼀段独⽴的测试时间和阶段，测试必须跟随开发的迭代⽽迭代。因此，回归测试的重要性就不⾔⽽喻了。

（1）优点

• 对项目全流程开展严格的风险管控。
• 重视软件每个开发阶段的质量保障。
• 在项目过程中可以评估项目价值，判断是否继续推进项目。
• 引入风险分析机制与原型开发。
• 在每个迭代周期内同步完成风险评估与原型搭建，降低各阶段遗留隐患，规避线上故障。

（2）缺点

• 模型对风险识别、评估、管控的要求很高；项目风险管控效果，很大程度取决于风险负责人的专业能力，对人员技术经验要求高。
• 风险评估存在误判可能性；同时，单独配备风险分析人员会带来额外人力、资金与时间开销，抬高项目整体成本。

（3）适用的项目

适合规模大、业务复杂、潜在风险较高的项目。 该模型属于迭代开发模式，对软件测试提出新要求：不存在独立完整的测试阶段，测试工作需要跟随开发迭代同步开展，回归测试在此模型中尤为关键。

5.开发模型 —— 增量模型、迭代模型

• 增量模型：把庞大的需求拆解成若干独立的小功能模块，逐个完成开发并上线。

• 迭代模型：先交付一个基础版本，该版本覆盖全部业务功能，但实现效果比较简易，后续不断迭代优化升级。

增量开发可以有效降低项目风险，搭配软件持续构建的思路，是目前软件工程领域很主流的实践方式。增量模型支持收集用户反馈，在每一轮迭代中，开发团队按照可预期的循环模式推进产品研发。在该模式下，每一轮迭代都可能带来需求调整，同时产出新的可运行程序版本，测试工作需要高频开展，测试人员要和开发人员紧密配合。

增量开发和迭代开发经常被混淆，但二者核心思路不一样：增量侧重分模块逐步搭建；迭代侧重在整体雏形上反复打磨完善。

举个例子：画人像。

• 增量思路：先画头部，接着画躯干，最后补全四肢，一块一块完成。

• 迭代思路：先勾勒完整人像轮廓，得到粗略初稿，之后不断细化线条、填充色彩，持续优化整张画。

伴随着互联网行业发展，很少有企业单独使用其中某一种模型，大多会把增量与迭代模型结合起来落地。

适用场景：大型项目、需求模糊不确定的项目。

6.开发模型 —— 敏捷模型

早期迭代瀑布模型曾广泛用于项目开发，但在实际落地时，开发人员会遇到不少难题。最突出的问题就是项目开发阶段很难处理客户提出的需求变更，一旦改动，往往要投入大量时间与成本去适配这些变更。为了解决瀑布模型存在的这些短板，敏捷软件开发模型在 20 世纪 90 年代中期被提出。

敏捷模型的核心目标，是让项目能够快速响应需求变动，以此助力项目高效交付。想要实现这一点就需要依靠敏捷性：让开发流程适配项目本身，剔除对当前项目没有必要的工作，摒弃一切会浪费人力与时间的活动。

在敏捷模型里，整体需求会被拆分为多个小型模块，采用增量 + 迭代的方式进行开发。每一个模块都在迭代周期内完成开发；单次迭代体量小、容易管控，一般几周内就能完成。团队会针对每一轮迭代进行规划、开发并交付给客户，不会制定跨度很长的项目计划。

敏捷模型里有一份核心文档 ——《敏捷宣言》，内容如下：

• 个体和交互，高于流程和工具（看重高效沟通）
• 可运行的软件，高于详尽的文档（提倡精简文档，文档不作为验收标准）
• 客户协作，高于合同谈判（主动持续了解客户真实需求）
• 响应变化，高于固守计划（主动接纳需求变动）

宣言采用对比表述，但每一组对比里，并不是说后者毫无作用，只是我们会优先看重前者，不会完全否定后者的价值。

从敏捷宣言能够提炼出敏捷模型四大特征：文档轻量化、流程轻量化、聚焦目标、重视可交付成果。敏捷开发包含多种实践框架，Scrum 就是其中应用十分广泛的一种。

从这份宣言也能看出，敏捷本质上属于软件开发中的社会工程学。敏捷最大的价值，在于它关注如何调动开发人员的工作积极性，而这一点在软件工程过去几十年的发展中，常常被忽视。

（1）Scrum

敏捷开发包含多种实现框架，Scrum 是应用十分广泛的一种，它属于迭代增量式软件开发模型。Scrum 框架包含三大核心角色与五项关键会议。

a. 三个角色

Scrum 团队由产品负责人（Product Owner）、Scrum Master 以及研发团队构成。

• 产品负责人（Product Owner）：梳理用户故事，明确各项需求的业务价值，对需求优先级排序，制定产品发布规划，全权对最终产品负责（主要工作：收集整理需求）。产品负责人是连接业务方与研发团队的桥梁，需要持续与客户、用户沟通，确保团队始终朝着正确的业务方向推进。
• Scrum Master：组织各类项目会议，协调项目内各类事务，为研发团队扫清障碍、提供支持。Scrum Master 是 Scrum 流程的守护者，负责确保团队遵循 Scrum 的规则与实践，帮助团队持续改进工作方式，提升协作效率，同时保护团队免受外部干扰，让团队成员能够专注于迭代目标。
• 研发团队：集合各类专业技能人员，依靠团队紧密协作完成每一轮迭代任务，交付可用产品。团队包含前端、后端开发、测试、交互、设计等岗位人员。研发团队是自组织的，成员之间相互配合、共同对交付质量负责，在每一轮 Sprint 中自主认领任务、评估工作量，并通过每日站会同步进度、及时暴露风险，确保迭代目标能够按时达成。

b. 迭代开发

和瀑布模型不一样，Scrum 把整个产品开发拆分为多个短小的 Sprint 迭代周期，周期时长范围为 1～4 周，最长不超过 4 周。团队规模一般维持在 5～9 人。每一轮迭代要完成的用户故事在迭代开始就确定下来，每次迭代结束都会产出可交付成果。

c. scrum 的基本流程

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

•  产品负责⼈负责整理user story，形成左侧的product backlog。
•  发布计划会议：product owner负责讲解user story，对其进⾏估算和排序，发布计划会议的产出就是制定出这⼀期迭代要完成的story列表，sprint backlog。
• 迭代计划会议：项⽬团队对每⼀个story进⾏任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责⼈，并完成⼯时的初估计。
•  每⽇例会：每天scrum master召集站⽴会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
•  演⽰会议：迭代结束之后，召开演⽰会议，相关⼈员都受邀参加，团队负责向⼤家展⽰本次迭代取得的成果。期间⼤家的反馈记录下来，由po整理，形成新的story。
•  回顾会议：项⽬团队对本期迭代进⾏总结，发现不⾜，制定改进计划，下⼀次迭代继续改进，以达到持续改进的效果。

Scrum 敏捷开发模型完整的迭代循环流程：

(2）敏捷中的测试

• 轻⽂档和快速迭代

7.软件测试 —— V 模型

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

V 模型：V 模型是瀑布模型的变种，开发阶段和测试阶段一一对应：

左侧：开发阶段

右侧：对应的测试阶段

V 模型特点:

V 模型清晰划分出各类测试活动，直观展示测试阶段与软件开发各阶段之间的对应关系，有助于提升测试工作的质量与效率。模型左侧代表开发流程，右侧代表测试流程，整体思路和瀑布模型相近。

V 模型的核心观点：

• 单元测试与集成测试，用来校验程序实现是否符合软件设计规定；
• 系统测试，检验系统的功能、性能等指标是否满足系统需求；
• 验收测试，确认软件成品能否满足用户需求或是合同约定。

优点：将测试工作拆分为多种不同类型，分工明确。

缺点：只把测试当成编码完成之后才开展的工作，测试活动无法提前介入需求阶段。和瀑布模型存在相同短板：测试人员参与项目时间偏晚，缺陷发现的时机滞后。

V 模型覆盖的范围不只是编码环节，它贯穿软件产品开发的全部流程阶段。

8.软件测试 —— W 模型（双 V 模型）

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

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

W 模型特点

测试对象不只是代码程序，需求文档、设计方案等产出物同样需要开展测试；测试活动和开发活动同步推进，开发工作形成一个 V，对应的测试工作同步形成另一个 V。

优点：

测试人员可以提前介入需求阶段，能够更全面地挖掘项目缺陷。比如需求分析工作一完成，测试人员就能参与需求的核查与确认，尽早发现问题。 同时，对需求进行测试，也能帮助团队提前评估项目难点与测试风险，提前准备应对方案，大幅缩减整体测试耗时，加快项目推进速度。

缺点：

需求、设计、编码等工作依旧被看作串行任务。测试和开发在一定程度上还是线性先后关系，必须等上一个阶段全部结束，下一个阶段才能正式启动，很难适配需求频繁变动的场景，不支持敏捷开发。 W 模型偏重固定流程，面对当下复杂多变的软件开发场景，无法完全解决测试管理遇到的各类难题。