（Jira）Bug提单规范小结

青旅半醒 2022-02-20 05:19 451阅读 0赞

> 最近在规范公司bug提报规范，简单整理了一下目前的规范要求，形成如下小结，部分条目可能不适用于其他项目，还是要根据实际项目运转情况来灵活调整。  
> 公司用Jira来管理缺陷的，所以本规范中字段值都是根据Jira来设置的。

# Bug提报规范 #

## 1） Bug提报原则 ##

*  规范问题单提报的目的，是为了提高问题处理效率。
 *  所有问题都要提单，有条件重现，无规律重现，难重现的一样提单。
 *  问题出现需要先定位，抓包、日志、数据库、截图。
 *  问题初步定位后，及时提单，避免遗忘，也给开发留有充足的时间修复。
 *  P0级别Bug及时通知开发，尽快修正，避免阻塞其他测试。
 *  其他级别的Bug直接跟踪，不需要挨个确认。
 *  低级别bug（文字符号、提示信息等）可以汇总一起提个单，在描述中分条目列出。

## 2） Bug提报信息填写规范 ##

*  项目：Bug归属的项目组
 *  主题：简明扼要地描述是什么问题
 *  详细描述：
    
     *  测试步骤/问题描述：
        
         *  对于简单的问题，简明扼要地描述测试步骤或直接描述问题；
         *  对于复杂的问题，需要细化测试步骤、预期结果和实际结果，以便开发人员能更好的理解问题。
     *  测试数据：提供测试数据，以便开发人员可以重现问题。
     *  截图/日志：有截图提供截图，有日志提供日志，截图和日志可以帮助开发人员花较少的时间来定位问题。
     *  问题分析：测试人员通过抓包、日志、检查数据库等工具和手段来初步定位出问题，主要目的是帮助开发人员快速定位出问题。（实际情况下，测试人员一方面要培养自己定位问题的能力，另一方面也要合理安排自己的测试进度，避免出现死磕一个问题，而影响整体测试进度的情况。）
 *  报告人：bug提出人
 *  经办人：开发对象
 *  Bug优先级（严重等级）：
    
    <table> 
     <thead> 
      <tr> 
       <th>Bug优先级（严重等级）</th> 
       <th>描述</th> 
       <th>紧急程度</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>致命P1</td> 
       <td>阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷；</td> 
       <td>紧急，需要立即解决</td> 
      </tr> 
      <tr> 
       <td>严重P2</td> 
       <td>主要功能未实现、未达标、不可用，可能还会引起其他部分功能失效；</td> 
       <td>紧急，尽快解决</td> 
      </tr> 
      <tr> 
       <td>一般P3</td> 
       <td>一般的缺陷，不影响主要功能和流程的实现；</td> 
       <td>一般</td> 
      </tr> 
      <tr> 
       <td>提示P4</td> 
       <td>优化建议，最好修改，但不是必须的，不影响上线发布。</td> 
       <td>不紧急</td> 
      </tr> 
     </tbody> 
    </table>
 *  Bug状态：
    
    <table> 
     <thead> 
      <tr> 
       <th>Bug状态</th> 
       <th>描述</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>Active</td> 
       <td>测试人员发现bug并提交，待修改状态。</td> 
      </tr> 
      <tr> 
       <td>Resolved</td> 
       <td>开发人员修改完bug，bug变更为已解决状态，可验证。</td> 
      </tr> 
      <tr> 
       <td>Closed</td> 
       <td>测试人员回归通过，变更为已通过状态。</td> 
      </tr> 
      <tr> 
       <td>Obsoleted</td> 
       <td>重复和非bug的，经过测试人员确认后，变更为废弃状态。</td> 
      </tr> 
     </tbody> 
    </table>
 *  Sprint：指定目标项目组的active sprint，问题就会出现在项目组的backlog中。
 *  Epic：项目有Epic时，关联相应的Epic，方便统计。
 *  Release to：没有Epic时，关联story，方便统计。

## 3） Bug提报格式 ##

*  项目
 *  主题
 *  报告人
 *  描述
    
     *  【预置条件】
     *  【测试步骤】
     *  【期望结果】
     *  【实际结果】
     *  【问题描述】
     *  【截图】
     *  【日志】
 *  经办人
 *  Epic Link
 *  Sprint
 *  Release to
 *  bug状态
 *  Bug优先级