BUG描述规范

本文档主要是目的是规范BUG的描述,清晰简单描述好BUG,编写有效的BUG实例,帮助开发人员有效的进行BUG定位,重现错误,从而去有效的定位错误,修改错误。

一、BUG级别定义

1. P0级别

阻碍开发或测试工作;严重的产品质量问题、系统功能基本不可用;系统崩溃;数据库数据丢失;严重影响项目进度等问题。

该级别BUG需立即解决。

详细分类

  • 重要或者紧急需求没有实现
  • 功能设计与需求严重不符
  • 正常使用场景下系统卡死、崩溃无法恢复、内存泄漏
  • 任何一个主要功能不可用且无法恢复
  • 其它导致无法测试的错误, 如服务器500错误
  • 用户数据丢失或破坏
  • 严重安全问题等

2. P1级别

系统核心功能部分缺失、用户数据丢失、系统不稳定等,导致模块无法测试,但不影响其他功能的测试。

该级别BUG需尽快修复解决

详细分类

  • 模块功能未实现(任意需求没有实现至少P1)
  • 核心功能实现不完整、不正确或业务逻辑不正确等
  • 核心功能中的部分功能不可用
  • 非主流场景下的系统卡死、崩溃无法恢复、内存泄漏
  • 影响功能使用的性能问题
  • 安全性问题

3. P2级别

系统存在功能、性能等问题,但不影响用户的正常使用或影响有限。

该级别BUG在实际测试中存在最多,合理安排解决即可

详细分类

  • 一般功能性问题
  • 不能接受且必须修改的UI体验问题,例如页面错乱影响理解等
  • 不影响使用的性能问题,例如响应慢等
  • 兼容性问题

4. P3级别

界面、文案显示等建议优化类BUG。

该级别BUG优先程度低,在保障进度和质量的前提下尽量安排修改

详细分类

  • 提示优化类,例如提示文字未采用行业专业术语、提示不友好等
  • UI布局优化类,例如字体大小,按钮大小不合适,文字排列不对齐
  • 辅助说明描述不清楚
  • 个别不影响产品理解的错别字

二、BUG描述规范

1. BUG标题

BUG标题应简洁明了,从BUG标题可以直接看出问题点在哪里,标题长度尽量要控制在正常显示的范围内。

2. BUG描述

前置条件:需要说明操作前提以及环境等要素,前提条件包括平台、系统版本、设备型号等

操作步骤:操作步骤是用来复现BUG的,要做到不熟悉的人按操作描述可以复现BUG,因此要尽可能的详细。

实际结果:当前问题表现的结果,明确当前的问题

期望结果:表示正确的结果,需要准确清晰,开发才能知道修改成什么样,不能模棱两可

备注:用于备注一些关键信息,如IP地址、账号信息、其它类似问题等

如果遇到的是概率性问题,则在BUG描述里需说明问题出现的概率,如10%,或只出现1次。

3. BUG归属

选择相应的项目、版本、模块,每个BUG应该都是有模块归属的,尽量避免在根路径下。

4. BUG级别

严重程度:表示BUG是什么级别的问题,级别越高越是要修改或尽早修改,是重要的判断依据之一。分为4个级别,P0、P1、P2、P3,具体可以阅读前面的BUG级别定义。

5. BUG优先级

紧急:缺陷必须被立即解决
较紧急:缺陷严重需要优先考虑
正常:缺陷需要正常排队等待修复或者列入软件发布清单
不紧急:缺陷可以在方便时去修正

6. BUG类型

表示BUG属于哪一类问题,对后续BUG分析有重要支撑作用,可以明确软件的问题集中区。
常见类型有:

  • 需求问题
  • 代码错误
  • 性能问题
  • 安全问题
  • 环境问题
  • 配置问题

7. 测试阶段

测试阶段:根据项目的各个里程碑进行选择,进入测试之前都会明确下来。在验证BUG的时候属于当前的测试阶段。比如当前是第一轮测试结束了,在验证开发修改的BUG,还未正式进入第二轮,在此阶段发现的BUG,选择第一轮测试。
常见的测试阶段:

  • 冒烟测试
  • 第一轮测试
  • 第N轮测试
  • 回归测试
  • UAT测试

8. 附件

  • 遇到UI相关的问题,必现提供截图,截图要截完整的图
  • 遇到概率性问题,如果有客户端或服务端日志,需将log一并上传到BUG附件中
  • 3
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
回答: Redmine提bug规范可以根据实际需求和公司内部的规定来制定。一般来说,以下是一些常见的Redmine提bug规范: 1. 标题:Bug的标题应该简明扼要地描述问题,包括关键词和问题的概要。 2. 描述:在描述中,应该详细说明Bug的复现步骤、期望结果和实际结果。可以提供相关的截图、日志或其他支持材料。 3. 优先级:根据Bug的紧急程度和影响范围,设置适当的优先级,如高、中、低。 4. 分配给:将Bug分配给适当的负责人,以确保问题得到及时处理。 5. 类型:根据Bug的性质,选择适当的类型,如缺陷、改进、任务等。 6. 状态:根据Bug的处理进度,更新Bug的状态,如新建、确认、处理中、已解决等。 7. 标签:使用标签来分类和组织Bug,如模块、版本、严重程度等。 8. 评论:在Bug的评论中,可以提供额外的信息、讨论或解决方案。 以上是一些常见的Redmine提bug规范,具体规范可以根据实际情况进行调整和补充。\[1\]\[2\]\[3\] #### 引用[.reference_title] - *1* *2* *3* [开源Bug管理系统Redmine安装和使用心得](https://blog.csdn.net/langresser/article/details/24476359)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^koosearch_v1,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值