BUG描述规范

BUG描述规范

一、    标题:

1.  简单清晰的描述在什么样的位置,什么样的条件下,发生什么样的结果,不能完全复制详细描述中的语言;

2.  为方便识别,标题可包含关键词:故障、异常、重复、失败、问题等;

3.  标题格式:功能模块+步骤+影响/环境描述+影响;

二、    描述要求:

1.  问题描述步骤:

a)   BUG的位置和条件;

b)   BUG重现的步骤,尽可能附带相应的链接,截图;

c)   期望结果;

d)   实际结果;

e)   其他信息:BUG提出人造成的处理优先级提升、个人推测的问题产生的原因并给出的建议等。

2.  简单,尽量每次只提交一个问题;

3.  一些同类问题,整理成文档=》添加附件,批量处理;

4.  简洁,每个步骤尽可能简单明了。只解释事实、演示、必要步骤,不要写无关信息;

5.  一般情况下,问题应该可在自己电脑上重现方才提交;

6.  被激活的BUG,在原有的问题后面新增备注日期,问题的必要信息、截图、链接等;

7.  格式包含:

a)   问题重现步骤;

b)   问题截图;

c)   问题必要的链接;

d)   物件ID、会员ID(手动输入,方便复制);

 

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值