今天朋友的公司的团队要建立，问到偶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的意见：
