关于BUG报告的几点

缺陷的生命周期：

提交->确认->分配->修复->验证->关闭

bug报告当中一些必备的内容：

硬件平台和操作系统：

1）测试应用的硬件平台（Platform），通常选择“PC”

2）测试应用的操作系统平台（OS）

a) 版本

提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本

b) Bug报告优先级

c) Bug状态

d) Bug的编号

e) 发现人

f) 提交人

g) 指定处理人

h) 概述

i) 从属关系

j) 详细描述

k) 严重程度

l) 所属模块

m) 附件

n) 提交日期

高质量的软件缺陷（Bug）记录的标准：

5C标准：

Correct（准确）： 每个组成部分的描述准确，不会引起误解

Clear（清晰）： 每个组成部分的描述清晰，易于理解

Concise（简洁）： 只包含必不可少的信息，不包括任何多余的内容

Complete（完整）： 包含复现该缺陷的完整步骤和其他本质信息

Consistent（一致）： 按照一致的格式书写全部缺陷报告

当开发人员说不是BUG时，你如何应付？

1.确定需求：

可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改

2.这种情况不可能发生，所以不需要修改

可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？把这个问题提出来,跟开发经理和测试经理进行确认。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认

所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复

发生这种现象的主要原因如下：

没有足够的时间资源：

在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改

有些缺陷只是特殊情况下出现：

这种缺陷处于商业利益考虑，可以在以后升级中进行修复

不是缺陷的缺陷：

我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理

最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定