测试(6) - bug篇（上）

测试(6) - bug篇（上）

文章目录

• [测试(6) - bug篇（上）](#测试(6) - bug篇（上）)
• [1. 软件测试的生命周期](#1. 软件测试的生命周期)
• [2. 项目上线过程：](#2. 项目上线过程：)
• • • 沙盒：
    • 小流量：
    • 全流量：
• [3. 什么是 bug](#3. 什么是 bug)
• [4. 描述 bug 的要素](#4. 描述 bug 的要素)
• • [4.1 举例：](#4.1 举例：)
  • • chrome（谷歌浏览器）：
    • 火狐：
    • 总结：
  • [4.2 描述bug的基本要素](#4.2 描述bug的基本要素)
  • • 关于笔试：
• [5. 总结](#5. 总结)

1. 软件测试的生命周期

软件测试贯穿于软件整个生命周期，下面我们就一起来看看软件测试是如何贯穿软件全生命周期的。

软件测试生命周期 ，是指保障产品质量符合需求的标准化测试流程，由一系列按顺序执行的特定步骤组成。

在测试生命周期中，各项活动均按计划系统化开展，每个阶段都有明确的目标与对应的交付产物。

软件测试 的生命周期 如下：

文字表述为：

需求分析 → 测试计划 → 测试设计，测试开发 → 测试执行 → 测试评估 → 上线 → 运行维护

其实，我们和 软件 的生命周期，对比一下，会发现，其实相同的点还是有的。

需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护

针对各个阶段，具体如下：

阶段	内容
需求分析	用户角度：软件需求是否合理 技术角度：技术上是否可行，是否还有优化空间 测试角度：是否存在业务逻辑错误、冗余、冲突等问题
测试计划	制定测试计划： 1. 什么时候开始测试 2. 什么时候结束测试 3. 耗时多久
测试设计与开发	参考需求文档、技术文档等编写测试用例编写测试文档，明确标注使用到的测试方法，测试工具，测试形式等
测试执行	充分利用测试用例和测试工具对项目尽可能做到全面的测试覆盖
测试评估	测试是否通过，本次测试是否有遗留的 BUG，最终测试人员需要产出一个测试报告 测试报告，一般是通过邮件发送，发送给这个需求相关的产品，测试负责人，开发人员
上线	项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线测试环境下软件的运行是否正确
运行维护	测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作项目非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与在用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人

2. 项目上线过程：

在实际工作中，项目上线，需要分为多个步骤，其中就有这些：

1. 沙盒
2. 小流量
3. 全流量

解释三个过程之前，我们需要明确一件事：测试环境，开发环境和线上环境，是完全不一样的，因此，上述的每一个步骤，测试人员都需要跟进，一起测试。

这几个环境的解释，是这样的：

• 开发环境：开发人员编写代码所用的机器。
• 测试环境：测试人员验证程序功能所用的机器。
• 生产环境（线上环境）：项目最终发布、对外提供服务的机器，对系统稳定性要求极高。

将程序部署至生产环境的过程 ，称为部署 （也叫上线）。程序部署成功后，即可被所有的普通用户访问。

若程序存在 BUG，该问题也会同步暴露给所有用户。

沙盒：

这是企业内部提供的线上环境（可以认为是测试环境），可以供内部人员进行测试。

当作游戏上线来看的话，这个阶段是：内部人员进行游戏的整体测试

小流量：

部分线上真实用户可以使用到。

当作游戏上线来看的话，这个阶段是：游戏开放部分测试名额，供线上真实用户，体验游戏

如果关注游戏的话，这个阶段也叫做：游戏的一测，二测，三测

全流量：

项目正式上线，所有的线上用户都可以访问到

当作游戏上线来看的话，这个阶段是：游戏正式上线，供所有线上真实用户，体验游戏

其实也就是：游戏开始公测，开服，全平台上线，所有线上用户都可以玩这款游戏。

3. 什么是 bug

定义：在计算机程序中存在的一个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），这些 Bug 使程序无法正确的运行。

Bug 产生于程序的源代码或者程序设计阶段的疏忽或者错误。

准确的来说，满足下面任意一个点，都可以认为是 bug：

1. 当且仅当 需求规格说明书（即 需求文档） 是存在的并且正确，程序与 需求规格说明书（即 需求文档） 之间的不匹配才是错误（bug）。
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误（bug）。

4. 描述 bug 的要素

看到这里，应该会有人说：为什么描述bug还有要素要求？

我们来举个例子，大家就知道了。

4.1 举例：

我们分别使用 火狐和chrome（谷歌浏览器） ，打开同一个网页。

（这里就不放链接了，这个案例是之前找的，现在那个网页已经修复了这个 bug 了）

chrome（谷歌浏览器）：

我直接指出来了，bug是：登录窗口的显示，把扫码部分的 码，给遮住了，可能会导致用户扫码扫不出来。

这个时候，如果没有学 bug的描述，你应该会这么说：坏了，我使用浏览器打开你提供的链接，扫不到那个二维码啊。

此时，这个 bug的描述，是错误的，原因是：你没有描述清楚，你使用的是哪个浏览器打开的链接。

火狐：

这个页面是正常的。没有发生遮挡。

总结：

像上述，因为浏览器不同，引发的 bug描述，是一种典型的错误，这种错误，是浏览器的兼容性bug。

作为测试人员，我们应该明白这么一件事：

描述bug 的目的 是：要让开发人员知道，他们如何复现这个 bug，并解决。

而上述错误的 bug描述：坏了，我使用浏览器打开你提供的链接，扫不到那个二维码啊。

该描述中未明确说明使用的浏览器，也未说明失败的具体表现，无法为开发人员提供更多有效信息，会导致沟通效率低下、工作质量下降等问题。

4.2 描述bug的基本要素

描述bug的基本要素：

1. 问题出现的版本
2. 问题出现的环境
3. 问题出现的步骤（复现路径）
4. 预期结果
5. 实际结果
6. ......

将上述的 bug ，进行准确的描述（描述 bug的格式）：

1. 问题出现的版本：chrome（谷歌浏览器）版本 133.0.6943.127（正式版本）（64 位）
2. 问题出现的环境：windows11，版本号XXX
3. 问题出现的步骤（复现步骤） ：
   1. 打开谷歌浏览器
   2. 输入网址：https://www.101edyun.com/
   3. 页面展示第一个背景图上的小程序二维码
4. 预期结果：小程序二维码不会被登录模块遮挡，二维码可以正确扫描
5. 实际结果：小程序二维码被登录模块遮挡，二维码不可以正确扫描

关于版本：指的是 软件版本

若是web系统，这里的版本是浏览器的版本

若是APP，这里的版本就是软件的版本（例如：XXX2.31测试环境）

描述bug的基本要素，还可以有这些：序号、标题、bug级别、bug所在的功能模块......

其中，上述 5 个基本要素，是必须要有的。

当然，描述bug以及提交bug，在企业中，会有专门的文档，告诉你这些事：

1. 应该在哪里提交bug（bug提交平台，一般是 Jira）
2. 提bug单的时候，需要填写哪些内容
3. 必填的内容，应该要怎么填写
4. 需求ID
5. bug所在的功能模块
6. ............

如果是移动端的bug ，可能还需要提供截图，在软件的测试环境中，上传日志，便于开发排查问题。

关于笔试：

如果你选择的岗位是测试岗位，笔试中，一定会有 bug 的描述题目。一定要完全按照上面的格式来描述bug

笔试的时候bug数量写的越多越好。

建议按照表格的形式来写：

	问题出现的版本	问题出现的环境	问题出现的步骤	预期效果	实际效果
1
2
3
4
5

5. 总结

这篇博客，讲述了下面这些内容：

1. 软件测试 的生命周期：

   需求分析 → 测试计划 → 测试设计，测试开发 → 测试执行 → 测试评估 → 上线 → 运行维护

2. 项目上线过程

3. 什么是bug

4. 如何描述一个 bug

最后，如果这篇博客能帮到你的，请你点点赞，有写错了，写的不好的，欢迎评论指出，谢谢！

下一篇博客：测试(7) - bug篇（下）