【软件测试】软件测试-----什么是Bug?Bug是如何分级的?Bug的生命周期是怎样的?如何描述一个Bug?

博客目录

一.软件测试的生命周期
二.BUG的定义和级别
- [2.1 bug的概念.](#2.1 bug的概念.)
- [2.2 如何描述一个bug.](#2.2 如何描述一个bug.)
- 2.3bug的级别
- - [2.3.1 bug分级的意义.](#2.3.1 bug分级的意义.)
  - [2.3.2 bug的四种级别.](#2.3.2 bug的四种级别.)
三.BUG的生命周期.
四.当与开发人员发生冲突该如何处理(高频面试)
五.总结

一.软件测试的生命周期

软件测试贯穿于软件的整个生命周期，针对这句话我们一起来看一下软件测试是如何贯穿软件的整个生命周期。
软件测试的生命周期是指测试流程(从开始测试到测试全部完成)，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物.

各个阶段的具体工作内容以及交付产物:

需求分析	测试计划	测试设计与开发	测试执行	测试评估	上线	运行维护
用户角度 : 软件需求是否合理.技术角度 : 技术上是否可行,是否还存在优化空间. 测试角度: 是否存在业务逻辑错误,冗余,冲突等问题	制定测试计划: 什么时候开始测试, 什么时候结束测试,测试要持续多长时间	测试设计 : 根据需求文档,技术文档等相关文档编写测试用例 . 测试开发 : 这个阶段结束之后会产出一个测试文档, 明确接下来的测试过程中要使用到的测试方法,测试工具,测试形式等等	测试执行: 充分利用测试设计与开发阶段编写的测试用例, 测试文档对项目尽可能做到全方位的测试	评估 : 测试是否通过, 测试是否还留有BUG,这个阶段结束之后,会产出一个测试报告	测试结束之后,会将项目发布到线上环境,测试人员需要继续跟进进行测试,确保程序在线上环境下能够正常运行	测试人员需要在项目运行之后继续跟进,进行后续的维护,有问题及时反馈给负责人

二.BUG的定义和级别

2.1 bug的概念.

定义: 一个计算机bug指的是在计算机程序当中存在一个错误, 缺陷, 疏忽, 或者故障, 这些bug使程序无法正常运行. bug产生于程序的源代码或者程序设计阶段的疏忽或者错误.
准确的来说:
- 当且仅当规格说明书是存在且正确的, 程序与规格说明说之间不匹配就是错误.
- 当需求规格说明书没有提到的功能, 判断的标准最终以用户为准: 当程序没有实现用户合理预期的功能要求时,就是软件错误.下图就是一个软件没有实现用户合理功能预期的软件错误

2.2 如何描述一个bug.

描述bug的基本要素:
1. 问题出现的版本号.------>比如你在谷歌浏览器的128.0.6613.120（正式版本）（64 位）发现问题. 就需要要把出现问题的版本号告诉开发人员.
2. 问题出现的环境.------>问题出现的环境可能是Linux,也可能是Windows.
3. 问题出现的步骤.------>如何操作才能出现这个bug, 需要把这个过程告诉开发人员.
4. 预期出现的结果.------>开发人员按照上述步骤,预期会出现什么结果.
5. 实际出现的结果.------>开发人员按照上述步骤,实际会出现什么结果. 实际结果和预期结果往往是不同的.
举个例子:
- 问题出现的版本--->128.0.6613.120（正式版本）（64 位）
- 问题出现的环境--->Windows家庭版
- 问题出现的步骤:
  1. 打开谷歌浏览器, 输入网址 https://www.baidu.com/
  2. 等待网页首页渲染完成.
- 预期结果:
- 实际结果:

2.3bug的级别

2.3.1 bug分级的意义.

合理分配资源：根据Bug的严重性分配开发资源，确保重要问题得到优先解决。
制定修复策略：不同等级的Bug有不同的修复时间要求，有助于项目管理和进度控制。
提高沟通效率：明确的Bug分级使得开发与测试团队之间的沟通更加顺畅，减少误解。
提升用户体验：及时处理影响用户体验的Bug，确保产品的稳定和可靠。
促进持续改进：鼓励提出改进建议，持续优化产品功能和性能。

2.3.2 bug的四种级别.

Blocker（崩溃）：此级别的Bug会影响整个产品，例如系统崩溃、数据丢失等。具体例子包括严重的内存泄漏、用户数据丢失、系统崩溃、模块无法启动以及导致无法测试的错误如服务器500错误。这些问题需要立即解决，否则整个产品无法正常工作。
Critical（严重）：此级别的Bug会影响主要功能，但不会导致系统崩溃。具体问题包括功能未实现、功能错误、数据通讯错误、轻微的数值计算错误以及安全性问题。这类问题也需要尽快解决，以确保产品功能正常。
Major（一般）：此级别的Bug会影响某些功能或用户体验，但不会对系统整体造成严重影响。具体包括操作界面错误、边界条件下错误、提示信息错误、性能问题以及兼容性问题。这些问题可以稍后解决，但需要在下一个版本发布前修复。
Minor（轻微）：此级别的Bug主要是界面、性能缺陷或建议性问题。具体如界面格式不规范、辅助说明描述不清楚、个别错别字及文字排列不整齐。这些问题通常是非关键性的，可以在后续版本中逐步改进。
Suggestion（建议）：此级别的Bug涉及对产品的优化和改进建议，不会影响现有功能。例如产品设计方面的意见和建议、界面优化以及增强用户体验的建议。这些问题可以根据项目进度和资源情况灵活处理。

三.BUG的生命周期.

New : 新发现的bug, 未经评审决定是否指派给开发人员进行修改。
Open : 确认是Bug，并且认为需要及进行修改，指派给相应的开发人员。
Fixed : 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
Rejected：如果认为不是Bug，则拒绝修改。
Delay : 如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

四.当与开发人员发生冲突该如何处理(高频面试)

先检查自己, 是否是bug描述不清楚.
- 反省自己: 是不是在测试的时候出现了操作失误, Bug描述是不是不够清楚,开发人员没有get到bug点.
站在用户的角度考虑,并抛出问题
- 功能正常只是测试的一部分, 还需要考虑用户的使用感受--->如果你是用户,这样设计你能接受吗?
BUG的定级需要有理有据
- bug定级描述文档拿出来, 然后将bug的表现和bug的定级描述文档进行匹配,说服程序员.
提高自身的业务技术水平, 做到不仅要能够提出问题, 也要能够提供解决bug的参考意见
- 良好态度,相互协助才能开发出一款好的产品.

如果上述的方法还是说服不了开发人员,此时就需要进行bug评审:
- Bug评审主要有三个代表: 测试代表(通常是你和你的领导) , 开发代表(通常是开发人员和他的领导) , 产品代表
- Bug评审主要解决的问题:
  1. 首先要决定如何处理这个bug
  2. 分析缺陷产生的原因,找出预防的策略.

五.总结

Bug对用户而言是出现与用户预期结果不同的现象. 对开发测试人员来说就是测试出现的结果和软件需求文档预期的结果不同.
描述一个bug就是给开发人员描述你咋什么样的环境下出现了bug, 描述就是要让开发人员能够复现bug.
bug的分级,以及bug的生命周期,理解那张流程图.