SoftwareTest2 - 软件测试相关概念

偏执的太偏执、 2024-03-08 09:01 76阅读 0赞

#### 软件测试答疑篇 ####

*  目标
 *  一 . 什么是需求
 *  二 . 测试用例
 *  三 . 什么是 BUG
 *  四 . 开发模型
 *   *  4.1 软件的生命周期
     *   *  需求分析
         *  计划
         *  设计
         *  编码
         *  测试
         *  运行维护
     *  4.2 软件测试的生命周期
     *   *  需求分析
         *  测试计划
         *  测试设计与开发
         *  执行测试
         *  测试评估
     *  4.3 常见模型
     *   *  瀑布模型
         *  螺旋模型
         *  增量模型、迭代模型
         *  敏捷模型
         *   *  scrum模型
             *   *  三个重要角色
                 *  基本流程
         *  测试模型
         *   *  V 模型
             *  W 模型

> Hello , 大家好 , 又给大家带来新的专栏喽 ~  
> 这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .  
> 那也欢迎大家订阅此专栏 : [https://blog.csdn.net/m0\_53117341/category\_12427509.html][https_blog.csdn.net_m0_53117341_category_12427509.html]  
> 希望大家都能够拿到好的 Offer  
> ![在这里插入图片描述][f9e88143330449019fa6887b7b557ffd.gif_pic_center]

## 目标 ##

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

## 一 . 什么是需求 ##

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

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

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

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

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

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

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

## 二 . 测试用例 ##

测试人员在执行测试之前需要编写测试用例 , 测试用例的好坏与产品测试质量具有很大的关联关系  
比如我们现在看百度的搜索框  
![在这里插入图片描述][1c102a9958b240d49bfaeff645b99884.png]

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

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

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

> 输入一个空格 , 检查结果
> 
> 测试用例1 :  
> 标题 : 输入框输入空格  
> 测试环境 : Windows 系统  
> 谷歌浏览器 版本 94.0.4606.61（正式版本） （64 位）  
> 操作步骤 :
> 
> 1.  打开浏览器 , 输入网址 : www.baidu.com
> 2.  在上面搜索框输入关键词 “空格” , 回车展示结果

测试数据 : 空格

> 预期结果 : 不进行跳转

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

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

## 三 . 什么是 BUG ##

![在这里插入图片描述][4c4c1c2463254c559e7c64931174eff1.png]

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

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

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

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

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

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

上面这个就是一个软件需求文档  
那么下面这个就是我们对应的网页  
![在这里插入图片描述][7c48d2098a61457ab8145572e2759fea.png]

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

再举一个例子 :  
![在这里插入图片描述][1989c1d3c15c4249849796a0b169502d.png]

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

## 四 . 开发模型 ##

### 4.1 软件的生命周期 ###

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

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

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

#### 需求分析 ####

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

#### 计划 ####

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

#### 设计 ####

这个阶段就是要把需求细化成一个个任务 , 进行技术设计(要设计哪些接口 , 用到什么样的框架 , 采用哪些技术…)  
比如我们的 B 站  
![在这里插入图片描述][702ce0a75b864f76b4d2e1bc9739e2dc.png]

#### 编码 ####

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

#### 测试 ####

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

#### 运行维护 ####

这里有三个方面需要了解

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

--------------------

### 4.2 软件测试的生命周期 ###

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

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

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

#### 需求分析 ####

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

#### 测试计划 ####

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

#### 测试设计与开发 ####

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

#### 执行测试 ####

#### 测试评估 ####

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

### 4.3 常见模型 ###

#### 瀑布模型 ####

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

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

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

#### 螺旋模型 ####

![image.png][]  
其实我们把线抻开 , 就是瀑布模型  
螺旋模型在瀑布模型的基础上 , 增加了风险分析 (第一象限)  
![image.png][image.png 1]  
那么我们这里的原型指的是什么呢 ?

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

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

#### 增量模型、迭代模型 ####

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

#### 敏捷模型 ####

[Manifesto for Agile Software Development][]  
![image.png][image.png 4]  
敏捷大会说 : 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观

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

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

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

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

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

##### scrum模型 #####

###### 三个重要角色 ######

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

###### 基本流程 ######

![image.png][image.png 5]  
Scrum 模型中每个迭代周期为1～4周，通常情况下为⼀周

#### 测试模型 ####

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

##### V 模型 #####

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

##### W 模型 #####

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

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

--------------------

喜欢的同学们一键三连哟~  
![在这里插入图片描述][95fd16bf24c24f57b0e60ddf67b63571.gif_pic_center]

[https_blog.csdn.net_m0_53117341_category_12427509.html]: https://blog.csdn.net/m0_53117341/category_12427509.html
[f9e88143330449019fa6887b7b557ffd.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/404ad6030cd047fa8e5dd99b2f3a6595.png
[1c102a9958b240d49bfaeff645b99884.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/d04bfa4618464d23a99bb0cd292db500.png
[4c4c1c2463254c559e7c64931174eff1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/493e2c3d369b410da8fffe694d799045.png
[c1090a08986b430d9da50aa4209811d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/1a8edf21f00a4cd49cdb84f6751f4768.png
[7c48d2098a61457ab8145572e2759fea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/1485d2fbbb1b4713a9a7a1e3214fb5de.png
[1989c1d3c15c4249849796a0b169502d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/048a9fc0e8cd4b30b9bde1c1f28885d3.png
[702ce0a75b864f76b4d2e1bc9739e2dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/131da82fa0e14c0095fd9192686dcbc7.png
[ce7ec0c46492666b37883d3a8c1f454d.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/35b78c67557f4714802607e8e2c8d161.png
[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/348d06739dcc4c0b9ceea2e4c0646c36.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/44cce6039ea946e5a03226a3630c06bd.png
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/8dbd84dfb8804ea49d8acea1205ae1e7.png
[image.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/f13220b398dd4af3b5a1bd2f925892e2.png
[Manifesto for Agile Software Development]: http://agilemanifesto.org/
[image.png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/e5abe55bd7324168901a3a8337ee446a.png
[image.png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/ee1cf1ad9adf4ac59a7522eff3b6d076.png
[image.png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/bf179be3dd884a44bbc0af0c3cc0965f.png
[image.png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/b89c817211db4cf287e55e6e2a96f80d.png
[95fd16bf24c24f57b0e60ddf67b63571.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/564eaf3dc77e4a22bd853dda6c697974.png