OK
自己也尝试过，确实能学到东西。 恩，写的好，测试员就是应该注意这些细节的地方与他人方便也就是给自己方便 写得不错，新人都应该注意这些问题，但我不同意第二个观点“最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发现bug的人才能够确信bug是否真正的已被修复。”个人认为这要看公司产品定义，职责划分，每个模块都有固定的负责人时，建议最好由负责人进行BUG确认工作，能了解到别人测试的角度，可以思考为什么别人能发现这个问题，减少测试的盲区，提高测试 胜读10年书哦
学习下
:victory: 写的很详细，学习。:) 好文:victory:偶刚进测试领域时，当时的Leader就要求我们来这么做，当时的想发和也和楼上几位的想法相似“很细致，不过是不是很麻烦呢”。不过还好坚持了下来。
楼主解释了缺陷的几种状态，以及这些状态出现的原因，处理方法。虽然有些状态很少会用到，而且这样的处理流程看起来分支复杂，但是在实际的缺陷处理流程是很实用的。
测试缺陷是开发人员和测试人员之间的一个交互点，开发人员和测试人员之间的交流就是依赖于这个测试缺陷里所表述的文字。所以需要测试人员对于缺陷描述要简介，准确；测试缺陷的状态则是这个交互开始的触发点，什么样的状态应该做出什么样的反应，双方就可以依据测试开始前定义的缺陷处理流程来展开工作。
另外，偶同意缺陷由缺陷的提交人来关闭。理由很简单，提交人最清楚自己提交的问题；假如问题由指定的负责人来关闭，问题多了，这个负责人就是忙死，也处理不完，同是会产生一个结果，降低了测试缺陷提交人的责任心。 值得学习！ 写的真好 楼主写得不错，学习了。 学习中…… 顶！ 我觉得Bug报告并不是软件测试工程师的终极体现，如何引导开发工程师解决BUG才是王道！:victory: 测试人员正在不知不觉减少公司的开发成本
这句话希望各个公司的管理着可以很深刻的认识 在发现一个Bug并填写完bug report之后，在review的时候，需要特别注意的一点是：这个bug report会不会让其他人还有联想或发挥的空间。一个好的bug report是不可以细分的,换句话说就是这个bug是不会让他人觉得你还有些地方需要在测试一下，或许还有其他的问题。例如，有个测试人员发现在输入16这个数字（允许范围内）且提交时系统会返回一个错误：不能输入48以下的数字。这确实是一个错误，但是如果就只按现在的步骤提交，另一个可能会有这样的想法：是不是输入48以下的数字都会有这样的问题呢？这样他有可能要求你在测试其他的数据。这样就延长了这个bug的生命期，而且浪费了大家的时间。
可以看出楼主的细致，学习了！ 学习进步:call: 刚刚走上测试岗位，谢谢楼主！很有意义！ 呼,细节细节...
