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

时光不染。回忆不淡

于 2024-09-05 11:07:16 发布

阅读量484

点赞数 11

分类专栏：软件测试文章标签： bug 经验分享

本文链接：https://blog.csdn.net/m0_74105656/article/details/141898957

版权

2 篇文章 0 订阅

订阅专栏

一.软件测试的生命周期

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

在这里插入图片描述

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

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

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

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

在这里插入图片描述

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