7. Bug管理规范

Myth丶恋晨 2024-04-18 11:59 50阅读 0赞

# 1. Bug状态管理 #

<table> 
 <thead> 
  <tr> 
   <th>状态</th> 
   <th>描述</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Active</td> 
   <td>测试人员发现bug并提交，待修改状态。</td> 
   <td>Bug初始状态</td> 
  </tr> 
  <tr> 
   <td>Resolved</td> 
   <td>开发人员修改完bug，bug变更为已解决状态。</td> 
   <td>Bug中间态</td> 
  </tr> 
  <tr> 
   <td>Closed</td> 
   <td>测试人员回归通过，变更为已通过状态。</td> 
   <td>Bug完成态</td> 
  </tr> 
  <tr> 
   <td>Postpone</td> 
   <td>经确认不需要在本次发布范围之内修改，变更为推迟修改状态/挂起状态。</td> 
   <td>Bug中间态</td> 
  </tr> 
  <tr> 
   <td>Rejected</td> 
   <td>开发人员确认不是bug，变更为非bug状态。</td> 
   <td>Bug中间态</td> 
  </tr> 
  <tr> 
   <td>Obsolete</td> 
   <td>重复和非bug的，经过测试人员确认后，变更为废弃状态。</td> 
   <td>Bug完成态</td> 
  </tr> 
 </tbody> 
</table>

# 2. Bug生命周期流转 #

Resolve

Fail

Pass

Not a bug/Duplicated

Confirm

Active

Resolved

Closed

Rejected

Obsolete

Postpone

# 3. Bug等级与优先级 #

*  Bug等级与优先级的定义
    
    <table> 
     <thead> 
      <tr> 
       <th>Bug严重程度</th> 
       <th>描述</th> 
       <th>优先级与紧急程度</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>P1，致命的</td> 
       <td>阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷。</td> 
       <td>最高优先级，紧急，必须立即解决（可以设定时间标准，比如必须2小时内解决，供参考）。</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>

# 4. Bug类型 #

*  从测试类型上来分：功能性缺陷、性能缺陷、易用性缺陷、安全性缺陷等；
 *  从缺陷引发的阶段类型来分：需求缺陷、设计缺陷、编码缺陷、环境问题、数据配置问题、测试操作问题等。
    
    Bug类型的归类，是质量分析的重要参照物，可以根据当前项目质量分析的程度，来决定要不要启用。

# 5. Bug提报规范 #

1.  Bug提报原则
    
     *  规范问题单提报的目的，是为了提高问题处理效率。
     *  所有问题都要提单，有条件重现，无规律重现，难重现的一样提单。
     *  问题出现需要先定位，抓包、日志、数据库、截图。
     *  问题初步定位后，及时提单，避免遗忘，也给开发留有充足的时间修复。
     *  P1级别Bug及时通知开发，尽快修正，避免阻塞其他测试。
     *  其他级别的Bug直接跟踪，不需要挨个确认。
     *  低级别bug（文字符号、提示信息等）可以汇总一起提个单，在描述中分条目列出；这种情况要跟开发说清楚，避免看bug时遗漏
2.  Bug提报格式
    
     *  项目
     *  主题：【xx需求】xxx问题
     *  报告人
     *  描述
        
         *  【预置条件】
         *  【测试步骤】
         *  【期望结果】
         *  【实际结果】
         *  【问题描述】
         *  【截图】
         *  【日志】
     *  经办人
     *  Epic Link
     *  Sprint
     *  bug状态
     *  Bug优先级
     *  Release to
3.  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：当前的迭代信息。
     *  Epic：项目有Epic时，关联相应的Epic，方便统计。
     *  Release to：没有Epic时，关联story，方便统计。

# 6. Bug管理与跟踪 #

1.  Bug的解决时效根据优先级来跟踪。
2.  Bug的状态需要及时更新。
3.  原则上，有未解决的Bug不能发版，需要经过项目经理、开发测试leader和产品一起评估后，才能决定是否将Bug挂起。
4.  挂起的Bug要在迭代结束后确认好解决版本，并修改相应信息。