Hello , 大家好 , 又给大家带来新的专栏喽 ~
这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .
那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html
希望大家都能够拿到好的 Offer

目标

1. 了解软件测试的基本概念
   1. 需求
   2. 测试用例
   3. BUG
2. 开发测试和模型

一 . 什么是需求

需求就是 衡量软件测试结果的依据
在企业中 , 通常把需求分为 用户需求 和 软件需求
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
那么我们举个栗子 :
我们针对走廊的声控灯想要实现效果 , 可以提出多少需求 ?

1. 听到声响 , 声控灯需要亮
2. 听到声响 , 声控灯需要什么亮度
3. 听到声响 , 声控灯会喊"欢迎回来"
4. 声控灯由黄金制作

那么我们简单的提出了四个需求 , 其中需求1 需求2还好 , 需求 3 和需求 4 明显就有些离谱 , 所以用户的需求有的时候是有些离谱的 , 需要产品经理去筛选出合适的需求 .

筛选的基准 :

1. 产品经理的筛选
2. 市场调研
3. 用户的需求是否是合理的
4. 有没有实现的必要
5. 投入的成本是否大于产出

而且我们观察 , 用户需求一般都比较简略 , 比如我们提出来的这四个 , 就都很简短 .
那么我们产品经理在筛选整理之后 , 有开发的必要 , 产品经理就会将用户需求转换成软件需求文档

那么我们小结一下 : 用户的需求是五花八门的 , 用户的需求不可以直接作为测试 / 开发的工作的依据 , 用户的需求不一定是正确的、合适的 , 需要进行用户需求的提取和分析
那么我们再举个栗子 , 来辨析一下用户需求和软件需求

女朋友提出了需求 : 我要喝奶茶
软件需求需要跟女朋友反复地去确认
哪个门店的 ? 加小料吗 ? 几分甜 ? 热的凉的 ?
最终了解了用户需求之后 , 就可以去对应的门店购买具体的奶茶

二 . 测试用例

测试人员在执行测试之前需要编写测试用例 , 测试用例的好坏与产品测试质量具有很大的关联关系
比如我们现在看百度的搜索框

我们现在针对这个搜索框进行测试 , 能设置出哪些测试用例 ?

1. 什么都不输入 , 检查结果
2. 输入一个关键词 , 检查结果是否跟关键词相关
3. 输入拼音 , 检查结果是否达到预期
4. 输入空格 , 检查结果
5. 是否存在 SQL 注入的情况
   …

那么我们不事先列举出测试用例的话 , 仅通过头脑风暴 , 是很容易漏测的
测试用例的存在能够提高测试覆盖率 , 如果我们不设计测试用例 , 可能就会造成漏测的风险
虽然在测试行业里面有这样一句话 : “不可能做到完全的测试” , 但是测试人员要尽可能的去避免漏洞 , 至少保证线上不会出现明显的问题
那么测试用例的出现 , 主要解决了两个问题 : 测什么 , 怎么测
目前讲解的 , 都是测试用例表面的东西
那么我们再来看一下测试用例的定义 : 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果 等要素。
那么我们就按照这个定义 , 简单的写一下测试用例

输入一个空格 , 检查结果

测试用例1 :
标题 : 输入框输入空格
测试环境 : Windows 系统
谷歌浏览器 版本 94.0.4606.61（正式版本） （64 位）
操作步骤 :

1. 打开浏览器 , 输入网址 : www.baidu.com
2. 在上面搜索框输入关键词 “空格” , 回车展示结果

测试数据 : 空格

预期结果 : 不进行跳转

那么假如针对某个功能 , 测试人员需要设计几十个甚至上百个测试用例 , 那么这样编写测试用例是很麻烦的
所以现在的互联网企业 , 测试人员在工作中就不再需要借助这么繁琐的编写测试用例的方式 , 在企业中主要使用思维导图的方式来编写测试用例
因为这样编写测试用例省时又方便 , 所以它是一种敏捷的工作模型

那我们为什么还要给大家介绍通过这种方式设计测试用例呢 ?
如果我们将来应聘的是测试岗位 , 那么面试就会要求你按照测试用例的要素来编写测试用例

三 . 什么是 BUG

我们去看词典给出的翻译 : Bug , 有昆虫的意思 , 也有 漏洞 / 错误的意思
那么就给大家讲一个小故事

我们的 BUG 跟一位女程序员有关系 , 他叫做 格蕾丝赫柏 , 她是耶鲁大学第一位博士 , 也是美国第一位女性海军将士 , 同时他也是个女程序员 .
Bug 的创始人格蕾丝 · 赫柏 (Grace Murray Hopper) , 是一位为美国海军工作的电脑专家 , 也是最早将人类语言融入到电脑程序的人之一 . 而代表电脑程序出错的 “Bug” 这名字 , 正是由赫柏所取的 . 1945 年的一天 , 赫柏对Harvard Mark II 计算机设置好 17000 个继电器进行编程后 , 技术人员正在进行整机运行时 , 它突然停止了工作 . 于是他们爬上去找原因 , 发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾 , 这显然是由于飞蛾受光和热的吸引 , 飞到了触点上 , 然后被高电压击死 . 所以在报告中 , 赫柏用胶条贴上飞蛾 , 并把 “bug” 来表示 “一个在电脑程序里的错误” , “Bug” 这个说法一直沿用到今天。 .
与 Bug 相对应 , 人们将发现 Bug 并加以纠正的过程叫做 “Debug” (中文称作 “调试”) , 意即 “捉虫子” 或 “杀虫子” .

Bug 也叫做软件缺陷 , 软件缺陷就是当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

这里的规格说明书就是 : 软件需求文档
这里的正确的意思是 : 有可能产品经理老眼昏花 , 给出的软件需求文档里面有内容是错误的 , 所以这里要强调一下正确
比如这个例子 : 我们经常会有一些恶心软件有老带新活动 , 产品经理说 : 老用户拉到新用户之后 , 给老用户 5 元钱 . 现在 A 拉 B 下水了 , 那么 A 就是 B 的老用户 , 那么 B 又把 C 拽下水了 , 那么这时候 B 就是 C 的老用户 , 应该给 B 5元钱 , 但是这个时候 A 就不算老用户了吗 , 就不应该给 A 钱了吗 ?
所以这就是一个规格说明是错误的情况

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

序号	栏位名称	栏位说明	长度	类型	备注
1	姓名	必填 , 录入个人姓名	6-15	字符型
2	电子邮箱	必填 , 录入电子邮箱		字符型
3	密码	必填 , 输入的密码用 * 隐藏 , 最少六位	6-15	字符型
4	确认密码	必填 , 输入的密码用 * 隐藏 , 最少六位	6-15	字符型
5	验证码	必填 ,输入验证码		字符型
6	注册	注册操作		操作性

上面这个就是一个软件需求文档
那么下面这个就是我们对应的网页

如果我们在姓名那里输入 “12345” , 那么他就是 Bug , 因为我们的需求文档里面写的是姓名长度应为 6-15 , 所以我们输入 “12345” , 长度为 5 就是错误的

再举一个例子 :

假设这个下拉条 , 我们并没有在需求文档里面提到这个 , 但是加入我们要是有几十个选项的时候 , 那就让用户一直往下八楞鼠标滚轮 ? 这也不行 , 所以再来品一下这句话 :
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
虽然需求规格说明书并没有提到这个功能 , 所以把这个权利交给用户了 , 但是这并没有达到用户的预期 , 所以这还是个 Bug

四 . 开发模型

4.1 软件的生命周期

开发模型也可以理解为 : 开发流程 / 项目推进流程
也可以视为软件的生命周期
那么我们举个栗子来引出软件的生命周期

加入我们现在想盖个房子 , 那么房子的生命周期是什么 ? (想盖个房子 这其实就是用户需求)

1. 需求分析
   首先我们要知道 , 为什么要盖房子 . 盖什么类型的 ? 民用的还是商用的 , 盖在哪里 , 盖多少层 , 如果要是盖 100 层以上的技术上可行吗 ?
   那假如可以盖超过 100 层的 , 我们就可以行动了
2. 计划
   什么时候开始盖 , 什么时候房子开始竣工 ,多久可以招商招住户 ?
3. 设计
   设计图纸 , 然后分配工作 , 谁负责买材料 , 谁负责打地基 , 谁负责刷墙 …
4. 编码
   正式开工, 踏踏实实盖房子
5. 测试
   我们要交房子之前 , 先要看看房子质量过不过关
6. 运行维护
   让用户先进去住一段时间 , 除了特殊情况再去积极处理

那么我们通过这个例子就总结出了软件的生命周期 :
需求分析 -> 计划 -> 设计 > 编码 -> 测试 -> 运行维护
我们就分别说一下这六大步 , 每步都在做什么

需求分析

在这一个阶段 , 我们主要进行市场分析 , 看看有没有需求量 , 也就是调查一下是否存在大量的需求用户 , 再看看投入和收益的占比(不能亏钱) , 技术上是否可以实现

计划

这个阶段主要商讨 什么时候开始 , 大约什么时候结束 , 耗时多久

设计

这个阶段就是要把需求细化成一个个任务 , 进行技术设计(要设计哪些接口 , 用到什么样的框架 , 采用哪些技术…)
比如我们的 B 站

编码

这个时候开发人员就要参考需求文档和技术文档等来进行编码

测试

开发人员已经把功能完成 , 接下来就是我们测试人员开干了 !
我们参照测试用例来执行测试
注意 ! 我们不是这个时候写测试用例 , 测试用例是在之前就应该写好的 , 现在直接进行测试就好了 .

运行维护

这里有三个方面需要了解

1. 修复型维护 : 对项目中之前未发现的问题进行修复
2. 完善性修复 : 对功能进行完善
3. 预防性修复: 为了避免产品在线上出现一些意想不到的问题 , 进行一些预防的手段 , 这个过程实际上就是居安思危 , 怕出事所以我们把预防措施准备妥当

---

4.2 软件测试的生命周期

那么我们来看这整个流程
需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护
但从这个流程来看 , 我们的测试是在后面 , 但是我们说过 : 软件测试是贯穿于软件的整个生命周期的 , 那不就跟开发模型发生冲突了吗 ?

其实我们的软件测试也是有生命周期的 , 他也是一直在勤勤恳恳工作 , 只不过真正发力在后期的测试阶段

那么软件测试的生命周期如下 :
需求分析 -> 测试计划 -> 测试设计与开发 -> 执行测试 -> 测试评估

需求分析

需求分析阶段其实在我们的开发模型里面也有啊 , 那么我们软件测试这里面的需求分析又有什么不同呢 ?
软件测试里面的需求分析实际上是站在了用户的角度考虑的问题 , 研讨这个功能在技术上是否可行 , 所以说软件测试人员往往是最了解需求的人 .

测试计划

我们的测试人员也需要编写测试计划文档 , 里面标明了有多少个测试人员负责完成哪项任务 , 什么时候开始测试 , 大概所需时间是多少

测试设计与开发

我们的测试人员需要借助需求文档和技术文档来编写测试用例

执行测试

测试评估

我们的产品在测试完成之后是要进行评估的 , 看看这个版本的产品完成度如何

4.3 常见模型

瀑布模型

瀑布模型跟我们的软件的生命周期很像

从中 , 我们可以看出 : 瀑布模型是一个线性结构 , 意思就是只有执行完需求分析才能去进行计划阶段 … , 意思就是等前一个阶段结束后一个阶段才能开始 , 这就容易导致风险往往在后期的测试阶段才被发现 , 但是已经没有改正的机会了 , 不能很好的迎接变化
而且我们可以看到 , 测试被放到了后面 , 这就意味着 : 瀑布模型实际上是不重视测试的 , 我们需要留给测试的时间要足够长 , 要不然问题得不到充分解决 , 就很有可能把问题提交给线上环境了 , 就把问题暴露给用户了
但是这些都不是瀑布模型最大的缺陷 , 瀑布模型最大的缺陷在于 : 可以运行的产品要很久之后才可以看到

举个栗子 : 我们上线一个线上聊 App , 用户的需求是不光能实现文字交流 , 我们还需要实现发送语音功能 , 如果采用瀑布模型 , 可以运行的产品要很久之后才可以看到 , 所以当我们的录音功能上线之后 , 用户不需要了 , 人家现在需要视频聊天功能 , 你这就属于是吃屎都赶不上热乎的

适用场景 : 需求固定的小型项目

螺旋模型

其实我们把线抻开 , 就是瀑布模型
螺旋模型在瀑布模型的基础上 , 增加了风险分析 (第一象限)

那么我们这里的原型指的是什么呢 ?

原型 , 也叫做原型图 , 指的就是一个大概的模型
举个栗子 : 我们画一只猫咪
原型图就是他的素描图(简单勾画一下)
设计图就是按照原型图画出来的具体的猫咪

瀑布模型增加了风险分析阶段 , 必然是耗时耗力的 , 所以公司一般都会招聘风险分析人才 , 所以这个团队需要耗费一定资金和时间去招聘风险分析人才
他的适用场景 : 需求不确定 , 变化的可能性很大的大型项目

增量模型、迭代模型

增量模型将项目模块化 , 使其每个模块都能够独立的开发和上线
优势 : 产品能够在较短时间内尽快的交付给用户去使用
那么迭代模型呢 ?
迭代模型就是一期一期的进行迭代 , 举个栗子
某个产品具有 5 个功能 A B C D E
增量模型就是 A B C D E 一个一个去完成 , 迭代模型会先完成这五个功能的基础版本 , 会再经历一期一期的进行迭代 , 直到这五个功能都非常完美
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚 , 而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

敏捷模型

Manifesto for Agile Software Development

敏捷大会说 : 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。

个体与交互重于过程和工具 : 强调团队内部人员尽可能的进行高效的沟通
可用的软件重于完备的文档 : 敏捷模型最终的标准就是可交付的软件

我们在瀑布模型中 , 每个过程都会产生一系列文档 , 而敏捷模型就不需要 , 敏捷模型需要的是成品而不是一大堆文档

客户协作重于合同谈判 : 客户可能随时更换需求 , 所以要及时沟通
响应变化重于遵循计划 : 有问题及时提出 , 不能循规蹈矩
在每对比对中，后者并非全无价值，但我们更看重前者。
由此可以得出 : 敏捷宣言的特点

1. 轻流程
2. 轻文档
3. 重目标
4. 重产出

scrum模型

三个重要角色

1. product owner ( 产品经理 ) : 负责整理 user story (用户故事/用户需求)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。( 收集用户需求 , 最终转变为软件需求 , 推动研发团队的功能开发 )
2. scrum master ( 项目经理 ) : 很多企业是没有项目经理的 , 是由产品经理担当的 . 项目经理一般都是在合理的周期内 , 去推进项目如期进行 , 负责召开各种会议，协调项目，为研发团队服务 ( 催进度 )
3. team ( 研发团队 ) : 由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品 .

基本流程

Scrum 模型中每个迭代周期为1～4周，通常情况下为⼀周

测试模型

我们之前讲解的几个模型其实都是不重视测试的 , 但是测试同样重要 , 所以现在就衍生出了测试模型

V 模型

特点 : 明确了测试有不同类型 , 并且说明了每个类型的测试和前期的开发工作之间的对应关系
局限性 : 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

W 模型

优势 : 测试从一开始就介入 (软件测试贯穿于软件的整个生命周期) , 有利于全面地发现问题
缺点 :

1. W 模型里面开发和测试虽然是同步的 , 但是仍然是线性的关系 , 用户需求结束后才能进行 用户需求 V&V 验收测试准备 阶段 , 虽然看起来是同一排 , 实际上并不是
2. 不支持敏捷模型(太重文档 太重过程了)

---

喜欢的同学们一键三连哟~