bug report的注意要点

   　　今天朋友的公司的团队要建立，问到偶bug的管理，于是顺便小结一下，做bug report的注意要点，有如下这些．首先是bug的一般形式，实践表明，最好是按如下的形式去搞一个bug

 

bug编号：

bug标题：简要阐述

 

Bug的简单阐述：

bug发现时间：

 

产品名称：测试产品的名称。   
产品子系统：测试产品的子系统，如果产品比较小，该项可以忽略。   
产品模块：测试产品发现问题的模块的名称。   
测试版本：当前的测试版本，包括主，次版本号
测试平台：

测试工具：

 

bug所产生的阶段：

 问题级别：紧急、严重、一般、建议，级别越高的问题处理。   
优先级别：must   fix、should   fix、fix     if     time、low   priority   
问题来源：测试、工程故障、升级、其他   
问题类型：功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错   
   
测试人员：发现Bug的测试人员   
抄送：该Bug需要抄送给相关的开发人员或测试人员。一般来说，一个Bug除了发送给改Bug的开发负责人和测试负责人外，还需要抄送给项目经理、测试经理、该产品开发小组其他人员，该产品测试小组其他人员   

 Bug的详细描述：

 

  （1） 测试要点：测试用例的测试要点  
  （2） 测试配置：如果有特殊的配置，需要在Bug描述中说明  
  （3） 测试环境：发现Bug的测试环境  
  （4） 测试步骤：详细描述发现Bug的操作步骤和流程  
  （5） 实际结果：按照测试步骤测试后实际出来的操作结果  
  （6） 预期结果：按照测试步骤测试后原本预期的操作结果  
  （7） 测试结论：通过对比实际结果和预期结果，“诊断”程序出错原因   
     附件：对于一些特殊的问题或者不能用语言很好地描述的问题，可以增加图形说明或参考资料或详细日志等附件。   

 

bug的处理意见：
测试组负责测试的员工的处理意见：
测试组负责人意见：

项目组项目负责人意见：

项目经理意见：比如有承认该bug,修复，到下一个周期再修复，修复意见

 

bug的实际处理情况：由开发人员填写．
测试组复审该bug的情况：
项目经理复审该bug的意见：