SoftwareTest2 - 软件测试相关概念
软件测试答疑篇
- 目标
- 一 . 什么是需求
- 二 . 测试用例
- 三 . 什么是 BUG
- 四 . 开发模型
-
- 4.1 软件的生命周期
-
- 需求分析
- 计划
- 设计
- 编码
- 测试
- 运行维护
- 4.2 软件测试的生命周期
-
- 需求分析
- 测试计划
- 测试设计与开发
- 执行测试
- 测试评估
- 4.3 常见模型
-
- 瀑布模型
- 螺旋模型
- 增量模型、迭代模型
- 敏捷模型
-
- scrum模型
-
- 三个重要角色
- 基本流程
- 测试模型
-
- V 模型
- W 模型
Hello , 大家好 , 又给大家带来新的专栏喽 ~
这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .
那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html
希望大家都能够拿到好的 Offer
目标
- 了解软件测试的基本概念
- 需求
- 测试用例
- BUG
- 开发测试和模型
一 . 什么是需求
需求就是 衡量软件测试结果的依据
在企业中 , 通常把需求分为 用户需求 和 软件需求
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
那么我们举个栗子 :
我们针对走廊的声控灯想要实现效果 , 可以提出多少需求 ?
- 听到声响 , 声控灯需要亮
- 听到声响 , 声控灯需要什么亮度
- 听到声响 , 声控灯会喊"欢迎回来"
- 声控灯由黄金制作
那么我们简单的提出了四个需求 , 其中需求1 需求2还好 , 需求 3 和需求 4 明显就有些离谱 , 所以用户的需求有的时候是有些离谱的 , 需要产品经理去筛选出合适的需求 .
筛选的基准 :
- 产品经理的筛选
- 市场调研
- 用户的需求是否是合理的
- 有没有实现的必要
- 投入的成本是否大于产出
而且我们观察 , 用户需求一般都比较简略 , 比如我们提出来的这四个 , 就都很简短 .
那么我们产品经理在筛选整理之后 , 有开发的必要 , 产品经理就会将用户需求转换成软件需求文档
那么我们小结一下 : 用户的需求是五花八门的 , 用户的需求不可以直接作为测试 / 开发的工作的依据 , 用户的需求不一定是正确的、合适的 , 需要进行用户需求的提取和分析
那么我们再举个栗子 , 来辨析一下用户需求和软件需求
女朋友提出了需求 : 我要喝奶茶
软件需求需要跟女朋友反复地去确认
哪个门店的 ? 加小料吗 ? 几分甜 ? 热的凉的 ?
最终了解了用户需求之后 , 就可以去对应的门店购买具体的奶茶
二 . 测试用例
测试人员在执行测试之前需要编写测试用例 , 测试用例的好坏与产品测试质量具有很大的关联关系
比如我们现在看百度的搜索框
我们现在针对这个搜索框进行测试 , 能设置出哪些测试用例 ?
- 什么都不输入 , 检查结果
- 输入一个关键词 , 检查结果是否跟关键词相关
- 输入拼音 , 检查结果是否达到预期
- 输入空格 , 检查结果
- 是否存在 SQL 注入的情况
…
那么我们不事先列举出测试用例的话 , 仅通过头脑风暴 , 是很容易漏测的
测试用例的存在能够提高测试覆盖率 , 如果我们不设计测试用例 , 可能就会造成漏测的风险
虽然在测试行业里面有这样一句话 : “不可能做到完全的测试” , 但是测试人员要尽可能的去避免漏洞 , 至少保证线上不会出现明显的问题
那么测试用例的出现 , 主要解决了两个问题 : 测什么 , 怎么测
目前讲解的 , 都是测试用例表面的东西
那么我们再来看一下测试用例的定义 : 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果 等要素。
那么我们就按照这个定义 , 简单的写一下测试用例
输入一个空格 , 检查结果
测试用例1 :
标题 : 输入框输入空格
测试环境 : Windows 系统
谷歌浏览器 版本 94.0.4606.61（正式版本） （64 位）
操作步骤 :
- 打开浏览器 , 输入网址 : www.baidu.com
- 在上面搜索框输入关键词 “空格” , 回车展示结果
测试数据 : 空格
预期结果 : 不进行跳转
那么假如针对某个功能 , 测试人员需要设计几十个甚至上百个测试用例 , 那么这样编写测试用例是很麻烦的
所以现在的互联网企业 , 测试人员在工作中就不再需要借助这么繁琐的编写测试用例的方式 , 在企业中主要使用思维导图的方式来编写测试用例
因为这样编写测试用例省时又方便 , 所以它是一种敏捷的工作模型
那我们为什么还要给大家介绍通过这种方式设计测试用例呢 ?
如果我们将来应聘的是测试岗位 , 那么面试就会要求你按照测试用例的要素来编写测试用例
三 . 什么是 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 软件的生命周期
开发模型也可以理解为 : 开发流程 / 项目推进流程
也可以视为软件的生命周期
那么我们举个栗子来引出软件的生命周期
加入我们现在想盖个房子 , 那么房子的生命周期是什么 ? (想盖个房子 这其实就是用户需求)
- 需求分析
首先我们要知道 , 为什么要盖房子 . 盖什么类型的 ? 民用的还是商用的 , 盖在哪里 , 盖多少层 , 如果要是盖 100 层以上的技术上可行吗 ?
那假如可以盖超过 100 层的 , 我们就可以行动了- 计划
什么时候开始盖 , 什么时候房子开始竣工 ,多久可以招商招住户 ?- 设计
设计图纸 , 然后分配工作 , 谁负责买材料 , 谁负责打地基 , 谁负责刷墙 …- 编码
正式开工, 踏踏实实盖房子- 测试
我们要交房子之前 , 先要看看房子质量过不过关- 运行维护
让用户先进去住一段时间 , 除了特殊情况再去积极处理
那么我们通过这个例子就总结出了软件的生命周期 :
需求分析 -> 计划 -> 设计 > 编码 -> 测试 -> 运行维护
我们就分别说一下这六大步 , 每步都在做什么
需求分析
在这一个阶段 , 我们主要进行市场分析 , 看看有没有需求量 , 也就是调查一下是否存在大量的需求用户 , 再看看投入和收益的占比(不能亏钱) , 技术上是否可以实现
计划
这个阶段主要商讨 什么时候开始 , 大约什么时候结束 , 耗时多久
设计
这个阶段就是要把需求细化成一个个任务 , 进行技术设计(要设计哪些接口 , 用到什么样的框架 , 采用哪些技术…)
比如我们的 B 站
编码
这个时候开发人员就要参考需求文档和技术文档等来进行编码
测试
开发人员已经把功能完成 , 接下来就是我们测试人员开干了 !
我们参照测试用例来执行测试
注意 ! 我们不是这个时候写测试用例 , 测试用例是在之前就应该写好的 , 现在直接进行测试就好了 .
运行维护
这里有三个方面需要了解
- 修复型维护 : 对项目中之前未发现的问题进行修复
- 完善性修复 : 对功能进行完善
- 预防性修复: 为了避免产品在线上出现一些意想不到的问题 , 进行一些预防的手段 , 这个过程实际上就是居安思危 , 怕出事所以我们把预防措施准备妥当
4.2 软件测试的生命周期
那么我们来看这整个流程
需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护
但从这个流程来看 , 我们的测试是在后面 , 但是我们说过 : 软件测试是贯穿于软件的整个生命周期的 , 那不就跟开发模型发生冲突了吗 ?
其实我们的软件测试也是有生命周期的 , 他也是一直在勤勤恳恳工作 , 只不过真正发力在后期的测试阶段
那么软件测试的生命周期如下 :
需求分析 -> 测试计划 -> 测试设计与开发 -> 执行测试 -> 测试评估
需求分析
需求分析阶段其实在我们的开发模型里面也有啊 , 那么我们软件测试这里面的需求分析又有什么不同呢 ?
软件测试里面的需求分析实际上是站在了用户的角度考虑的问题 , 研讨这个功能在技术上是否可行 , 所以说软件测试人员往往是最了解需求的人 .
测试计划
我们的测试人员也需要编写测试计划文档 , 里面标明了有多少个测试人员负责完成哪项任务 , 什么时候开始测试 , 大概所需时间是多少
测试设计与开发
我们的测试人员需要借助需求文档和技术文档来编写测试用例
执行测试
测试评估
我们的产品在测试完成之后是要进行评估的 , 看看这个版本的产品完成度如何
4.3 常见模型
瀑布模型
瀑布模型跟我们的软件的生命周期很像
从中 , 我们可以看出 : 瀑布模型是一个线性结构 , 意思就是只有执行完需求分析才能去进行计划阶段 … , 意思就是等前一个阶段结束后一个阶段才能开始 , 这就容易导致风险往往在后期的测试阶段才被发现 , 但是已经没有改正的机会了 , 不能很好的迎接变化
而且我们可以看到 , 测试被放到了后面 , 这就意味着 : 瀑布模型实际上是不重视测试的 , 我们需要留给测试的时间要足够长 , 要不然问题得不到充分解决 , 就很有可能把问题提交给线上环境了 , 就把问题暴露给用户了
但是这些都不是瀑布模型最大的缺陷 , 瀑布模型最大的缺陷在于 : 可以运行的产品要很久之后才可以看到
举个栗子 : 我们上线一个线上聊 App , 用户的需求是不光能实现文字交流 , 我们还需要实现发送语音功能 , 如果采用瀑布模型 , 可以运行的产品要很久之后才可以看到 , 所以当我们的录音功能上线之后 , 用户不需要了 , 人家现在需要视频聊天功能 , 你这就属于是吃屎都赶不上热乎的
适用场景 : 需求固定的小型项目
螺旋模型
其实我们把线抻开 , 就是瀑布模型
螺旋模型在瀑布模型的基础上 , 增加了风险分析 (第一象限)
那么我们这里的原型指的是什么呢 ?
原型 , 也叫做原型图 , 指的就是一个大概的模型
举个栗子 : 我们画一只猫咪
原型图就是他的素描图(简单勾画一下)
设计图就是按照原型图画出来的具体的猫咪
瀑布模型增加了风险分析阶段 , 必然是耗时耗力的 , 所以公司一般都会招聘风险分析人才 , 所以这个团队需要耗费一定资金和时间去招聘风险分析人才
他的适用场景 : 需求不确定 , 变化的可能性很大的大型项目
增量模型、迭代模型
增量模型将项目模块化 , 使其每个模块都能够独立的开发和上线
优势 : 产品能够在较短时间内尽快的交付给用户去使用
那么迭代模型呢 ?
迭代模型就是一期一期的进行迭代 , 举个栗子
某个产品具有 5 个功能 A B C D E
增量模型就是 A B C D E 一个一个去完成 , 迭代模型会先完成这五个功能的基础版本 , 会再经历一期一期的进行迭代 , 直到这五个功能都非常完美
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚 , 而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
敏捷模型
Manifesto for Agile Software Development
敏捷大会说 : 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
个体与交互重于过程和工具 : 强调团队内部人员尽可能的进行高效的沟通
可用的软件重于完备的文档 : 敏捷模型最终的标准就是可交付的软件
我们在瀑布模型中 , 每个过程都会产生一系列文档 , 而敏捷模型就不需要 , 敏捷模型需要的是成品而不是一大堆文档
客户协作重于合同谈判 : 客户可能随时更换需求 , 所以要及时沟通
响应变化重于遵循计划 : 有问题及时提出 , 不能循规蹈矩
在每对比对中，后者并非全无价值，但我们更看重前者。
由此可以得出 : 敏捷宣言的特点
- 轻流程
- 轻文档
- 重目标
- 重产出
scrum模型
三个重要角色
- product owner ( 产品经理 ) : 负责整理 user story (用户故事/用户需求)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。( 收集用户需求 , 最终转变为软件需求 , 推动研发团队的功能开发 )
- scrum master ( 项目经理 ) : 很多企业是没有项目经理的 , 是由产品经理担当的 . 项目经理一般都是在合理的周期内 , 去推进项目如期进行 , 负责召开各种会议，协调项目，为研发团队服务 ( 催进度 )
- team ( 研发团队 ) : 由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品 .
基本流程
Scrum 模型中每个迭代周期为1～4周，通常情况下为⼀周
测试模型
我们之前讲解的几个模型其实都是不重视测试的 , 但是测试同样重要 , 所以现在就衍生出了测试模型
V 模型
特点 : 明确了测试有不同类型 , 并且说明了每个类型的测试和前期的开发工作之间的对应关系
局限性 : 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试
W 模型
优势 : 测试从一开始就介入 (软件测试贯穿于软件的整个生命周期) , 有利于全面地发现问题
缺点 :
- W 模型里面开发和测试虽然是同步的 , 但是仍然是线性的关系 , 用户需求结束后才能进行 用户需求 V&V 验收测试准备 阶段 , 虽然看起来是同一排 , 实际上并不是
- 不支持敏捷模型(太重文档 太重过程了)
喜欢的同学们一键三连哟~
