文章目录
- Bug篇
- 软件测试的生命周期
- Bug
- Bug的概念
- Bug的要素
- Bug的级别
- Bug的生命周期
- 与开发发生争执怎么办
Bug篇
大部分的Bug都是测试人员提出的，因此在Bug篇的开始会先介绍软件测试的生命周期。同时，了解软件测试的生命周期能帮助我们了解测试的工作，如果面试官问我们测试的工作有哪些时，我们得有话可讲。
软件测试的生命周期
软件测试贯穿于软件的整个生命周期，软件测试的生命周期指的是测试流程，这个流程是按照一定顺序执行一系列的阶段或者步骤，旨在确保软件质量。
软件测试的生命周期如下：（比经典版本更加详细，只多不少，更贴近实际项目流程）
各个阶段的具体内容：
| 需求分析 | 测试计划 | 测试设计、测试开发 | 测试执行 | 测试评估 | 上线 | 运行维护 |
|---|---|---|---|---|---|---|
| 参与需求评审；理解需求；分析需求的可测试性，检查需求是否存在逻辑错误、冗余、冲突等问题并提出改进建议，输出需求测试性分析报告；确定测试范围，输出测试范围文档；识别项目风险，输出测试风险分析报告 | 制定详细的测试计划，明确测试策略（方法）、资源、时间，输出测试计划文档 | 设计测试用例和测试脚本，准备测试数据和测试环境，输出测试用例文档、测试环境设置文档等 | 执行测试用例，记录测试结果，识别和报告缺陷，输出测试执行报告、缺陷报告 | 评估测试结果，分析测试覆盖率，总结测试活动并提出改进建议，输出测试总结报告、测试度量数据 | 将经过测试的软件部署到生产环境，确保其正常运行。上线也有流程，会经过沙盒、小流量、全流量等测试阶段 | 在生产环境中监控系统性能、处理用户反馈并修复缺陷，执行回归测试，最终输出缺陷修复记录 |
- 沙盒环境 是一个与生产环境隔离的测试环境，是企业内部线上环境，这意味着只有企业内部人员可以访问，测试完毕后输出沙盒环境测试报告。
- 灰度发布（小流量） 即：将新功能发布到小部分用户或特定区域，监控项目在小流量的真实线上环境的运行，最终输出灰度发布监控报告。
- 全量发布（全流量） 即：将新功能发布给所有用户，在全流量的线上环境中监控项目运行，输出全量发布报告。
Bug
Bug在我们编码过程中无处不在，它使我们的程序无法按照预期运行，但我们在排除Bug的过程中也无形的提高了我们的debug能力。但是学习中的Bug不同于工作中的Bug，有关这一话题的内容我们慢慢展开。
Bug的概念
在软件测试中，Bug 指 软件系统中存在的错误、缺陷、疏忽或者故障，并导致系统无法按照预期的方式运行或满足需求。Bug通常产生于程序的源代码或者程序设计阶段的疏忽或者错误。
具体来说，Bug可以从多个角度理解，以下是常见的角度（工作中只要满足这些描述，就能向开发人员提Bug）：
-
从规格说明的角度：
当且仅当规格说明书存在且是正确的，程序与规格说明之间的不匹配就是Bug
-
从用户需求的角度：
当需求规格说明书没有提到的功能，判断标准以用户为准：当程序没有实现最终用户合理预期的功能要求时，就是Bug
-
从性能和安全的角度：
当软件在性能（响应速度、资源占用）或安全性（如数据泄露、漏洞）方面存在问题，即为Bug
-
从兼容性的角度：
当软件在特定环境（如操作系统、浏览器、设备）中无法正常运行，即为Bug
实际工作中，测试人员需要根据规格说明、用户需求和实际场景，综合判断是否存在 Bug，并将其记录和跟踪，直至修复。而不是以自身的感觉角度为准。
Bug的要素
作为测试人员，除了要认识Bug，还要能够描述Bug，要想准确的描述一个Bug便离不开Bug的要素。
首先，我们先看一个案例：访问网址：https://www.101eduyun.com
使用谷歌浏览器访问：
使用火狐浏览器访问：
注意观察两张截图的小程序二维码的右侧部分：
使用谷歌浏览器访问的网页的二维码被遮挡了一部分，而使用火狐浏览器访问网页的二维码是完整的，虽然说实际扫描二维码时可以正确访问小程序，但是如果或者说我们在这里假设谷歌浏览器访问的二维码被遮挡了很大一部分导致用户扫描失败，毋庸置疑，这就是一个Bug。
接下来我们以上面的Bug为例，展开讨论。
如果现在让我们描述这个Bug，我们可能会说：使用谷歌浏览器访问xxx页面显示的小程序二维码被遮挡了。试想，站在开发人员的角度上，他能理解我们这个Bug吗，恐怕不行吧，具体为什么，等我们了解完描述Bug的要素后就能理解。
描述Bug的要素有很多，但是有些要素是必须的，因为它们提供了问题的核心信息，是描述Bug的基础，便于开发人员理解和修复；而有些要素是可选的，它们提供了额外的上下文或辅助信息，有助于更全面地分析问题。 当然，在实际工作中，公司也会有他们自己的规范，比如将某个可选的列为必选的，但是对于大多数企业来说，接下来介绍的必选项就是必须的。另外，有关上述例子的具体要素对应的内容都在示例展示：
一、必须的要素
-
Bug标题
-
内容：简洁的语言概括Bug的核心问题
-
示例：“登录界面的二维码被遮挡，无法扫描”
-
-
Bug描述
- 内容：详细描述Bug的现象、背景和上下文，让开发人员进一步理解问题
- 示例：“在登录界面，小程序的二维码被右侧的登录框遮挡，导致用户无法扫描二维码访问小程序”
-
环境信息
- 内容：描述Bug发生的环境配置，包括操作系统、浏览器、设备、软件版本等信息
- 示例：“操作系统：windows xxx；浏览器：Chrome 版本 133.0.69；设备：xxx
-
重现步骤
- 内容：详细列出重新Bug的具体步骤
- 示例：
- 打开谷歌浏览器，输入网址：https://www.101eduyun.com
- 选择顶栏的“首页”页面，找到第一个背景图的小程序二维码
- 观察二维码是否被右侧的登录框遮挡
-
预期结果
- 内容：描述在正常情况下，系统应有的正常行为
- 示例：“二维码应该显示完整，用户可以正常扫描登录”
-
实际结果
- 内容：描述 Bug 的实际行为
- 示例：“二维码被右侧的登录框遮挡，用户无法扫描”
二、可选的要素
- Bug级别
- 内容：评估Bug的紧急性和影响
- 示例：“级别：严重”
- 附件
- 内容：与 Bug 相关的截图、日志文件、视频等
- 其他上下文
- 内容：补充相关上下文，如 Bug 的发现者、发现时间、所属模块等
经过Bug要素的讨论相信我们已经能够理解为什么之前的一句话描述不准确了，很多环境信息以及重现操作都是存在很多细节问题的，如果我们不按照规范将Bug的要素列举出来，开发人员很有可能看不到Bug。
既然描述Bug的要素这么多，我们每个Bug都要写一遍吗？ 是也不是，对于每个Bug的要素的具体内容肯定是不一样的，但是针对每一个项的名称一定是相同的，我们可以采用表格的形式来描述Bug而无需将“重现步骤”、“预期结果”等关键词重复书写，就像这样：
| 标题 | 描述 | 环境信息 | 重现步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|---|
| 登录界面的二维码被遮挡，无法扫描 | 在登录界面，小程序的二维码被右侧的登录框遮挡，导致用户无法扫描二维码访问小程序 | 操作系统：windows xxx； 浏览器：Chrome 版本 133.0.69； 设备：xxx | 1. 打开谷歌浏览器，输入网址：https://www.101eduyun.com 2. 选择顶栏的“首页”页面，找到第一个背景图的小程序二维码 3. 观察二维码是否被右侧的登录框遮挡 | 二维码应该显示完整，用户可以正常扫描登录 | 二维码被右侧的登录框遮挡，用户无法扫描 |
- 使用什么载体描述Bug不重要，实际工作中会有公司规范工具，但是针对笔试，我们就不得不采用上面的形式来书写了。这里讨论的最终目的是让大家了解如何描述Bug，而不是规定你就该使用什么工具来写Bug文档。
Bug的级别
在软件测试中，Bug的级别用于描述Bug对系统和用户体验的影响程度。同时也不难理解，Bug的级别也衡量了Bug处理的优先级，级别高的Bug的处理优先级通常更高。合理划分Bug的级别有助于团队优先处理高影响的问题，确保资源分配合理。具体公司对Bug级别的划分有自己的规范，我们会介绍一种简洁且实用的分类方式：崩溃、严重、一般、次要，其覆盖了大多数 Bug 场景
| 崩溃 | 严重 | 一般 | 次要 |
|---|---|---|---|
| 系统无法正常运行或核心功能那完全失效，数据丢失或损坏 例如：登录功能失效、所有用户无法进入系统；数据库崩溃，导致数据无法保存或读取；系统频繁闪退 | 核心功能受到影响，但系统仍可部分运行 例如：某一支付功能失败，但用户可以通过其他方式完成支付；搜索结果不准确，但用户仍能浏览部分内容；重要数据无法导出或导入 | 次要功能或非核心功能被影响，系统整体运行正常 例如：页面布局错乱，但不影响功能操作；提示信息不准确，但用户仍能完成任务 | 对系统功能影响较小，通常是界面或者用户体验问题 例如：按钮颜色不符合设计规范；错别字；图标位置偏移 |
- 有的级别划分还会加入建议，该级别严格来说不属于Bug，而是对系统功能或用户体验的改进建议，例如：增加一个新的功能选项；优化页面加载速度
- 高级别的 Bug 通常优先级较高，但并非绝对。例如，一个致命 Bug 可能只影响少数用户，优先级可能低于一个影响大量用户的严重 Bug，除此之外，还取决于业务需求和项目进度。
Bug的生命周期
在软件测试中，Bug的生命周期是指一个Bug从被发现到最终被关闭的整个过程。了解Bug的生命周期有助于团队更好地追踪和管理问题，确保每个Bug都得到妥善处理。Bug生命周期模型有很多，它们的阶段可能会有一点差别，但是核心是不变的。我们将介绍一种简洁实用的Bug生命周期模型，它描述的Bug存在以下状态：
- New（新建）：新发现的Bug并报告，将其记录到缺陷管理工具中，处于未经评审决定的状态
- Open（已打开）：确认时Bug，并且认为需要修改，指派给相应的开发人员进行修复
- Fixed（已修复）：开发人员完成Bug修复，并将修复后的代码提交到代码库，等待测试人员的回归测试验证
- Rejected（已拒绝）：开发人员认为不是Bug或无法重现，拒绝修改
- Delay（延期）：Bug的优先级较低，暂时不需要修改，可以将其延期到后续版本中处理
- Closed（已关闭）：已修复状态下的Bug通过测试人员的回归测试验证，已完全修复，正式关闭
- Reopen（重新打开）：经回归测试后发现Bug未完全修复或引入新的问题，需要重新打开Bug，开发人员修改
上述状态通过流程图的方式演示便一目了然：
- New，判断是否成立；不成立则Rejected，成立则Open
- 针对已打开的Bug，判断是否修改；不修改则Delay，修改则进行修改变为Fixed
- 已修复的Bug，验证是否通过；不通过则Reopen，通过则Closed
- 重新打开的Bug要继续如流程图循环直到被验证完全修复，而延期的Bug最终也会被完全修复
与开发发生争执怎么办
在实际的测试工作中，难免会与开发人员发生争执，此时作为一名合格的测试人员应该怎么做呢？
-
先检查自身，是否Bug描述不清楚？ 如果测试人员发现写完一个Bug后，还有很多关于Bug的信息没有表达出来，或者难以使用书面语表达出来时，就应该在提交Bug后，马上找相关的开发人员解释刚才录入的Bug，而不能让开发人员自己了解更多的信息，确保程序员能够理解Bug。
-
Bug的定级要有理有据。 如果开发人员对Bug定级有疑问，则需要将Bug定级描述文档拿出来，将Bug的表现和Bug定级描述文档进行匹配，同时还要考虑Bug是否会影响到流程，往往用户的Bug和我们的是有区别的，需要站在用户的角度考虑定位级别。
-
作为测试人员，总要不断提高自身技术和业务水平，做到不仅能提出问题，最好也能提出解决方案。 当我们提出一些建议且开发人员认为建议具有可行性时，我们可以和开发人员进行讨论，在讨论中解决问题确保不会继续发生争执。（注意：可以给出解决方案，但是不能喧宾夺主地以命令式的口吻要求开发人员按照自己的想法修改，因为开发人员的对于开发业务的理解往往比测试要深刻）
-
当上述尝试都已经执行但还是存在争执或是友好沟通不能解决问题，则需要召开Bug评审会议。
Bug评审会议的目的是解决问题，而不是争论对错。会议期间主要解决：- 决定如何处理Bug
- 分析Bug产生的原因，找出改进和预防的对策
Bug评审会议需要多方参加，包括测试代表、开发代表、产品代表等，其中测试和开发代表需要提前准备好相关证据（如日志、代码、测试用例）。如果问题不是特别严重，不要召开Bug评审会议，因为很可能耽误很多工作。
一定要知行合一，付诸行动
完
