软件测试中怎么判断是不是bug，该不该提交

如何对进行缺陷管理那？

一般来说，明显的错误（如程序不能继续运行，出现明显的错误提示框，数据存储错误等）大家都知道肯定是bug，经常有疑问的是对于期望结果模糊，GUI（界面，操作模式等）不友好，对比其他的软件的问题。
        由于工作的原因，参与了项目的一些开发过程，发现其实如果从开发的角度看看问题，就更容易下定提交bug的决心的。根据bug的来源，以下是我的一些总结：
1。由于代码引起的bug
        所有的程序都会有bug,而且所有的程序员都会制造bug.这个道理如同bug是不可能被完全消灭一样.对于一般的开发人员，经常出现的问题是由于没有良好的编程习惯和技术能力。每个人从新手到高手都是有个阶段的，成长的过程总是充满错误的。开发人员多少会在修改bug的过程中成长。有些可能他们认为无法实现的操作是有可能实现的。所以这种情况要提交bug，即使不能修复，开发人员也会在bug里填写理由，这样对测试人员和开发人员都是有利的。
        那么对于高级的开发人员，低级错误的发生概率相对来说少很多，大多的bug是由于功能定义不清晰,完善或是架构，语言的局限引起的。有些严重的问题大家可以一起商量解决的.

2。项目时间紧迫造成的bug
        基本上每个项目都有加班的时候，开发人员在紧迫的时间里能做的就是尽可能的完成功能需要要求的功能，主要的功能。然后有时间再去通过修复bug来完善代码。所以测试人员也不要诧异为什么会有那么多的bug，要作的就是尽可能的提交你所发现的bug。
        在我参与的开发中，项目经理经常会询问开发人员的进度，如果他发现你已经实现了某一个模块功能需求的功能后不是马上开始下一个模块的开发，而在花时间在竭力地凭着自己的猜想去完善模块时，项目经理一定会要求你把模块提交给测试人员测试，并马上开始下一个模块的开发

3。项目定义模糊造成的问题
        有些项目在开始编码时可能只是一个大概的项目定义，甚至连具体功能的定义都不是很清楚.有时客户对产品的最终结果都不清晰，需要一个有形的东西让自己不断的开发出自己的需求。那么这时开发人员大多都是根据自己的经验或常识来实现代码。
        还有就是大多数地需求和设计文档不是面面俱到,只是描述了主要的业务定义.对于一些非主流或异常的处理并没有详细的定义.很多情况下程序在负面的操作时就会出现错误.
        测试人员可能就会发现很多不合理或和其他软件不同造成的用户界面的问题，或者有时更会发现负责代码实现的开发人员误解了需求定义人员对功能的解释，甚至从从源头上需求定义人员对功能就存在误解。

        虽然有很多原因会引发bug,但是不管什么原因测试人员都要提交自己认为是问题的问题,即使后来发现bug是由于某种局限造成的，但对于自己乃至整个项目组都是一个财富。
        只是在bug提交的时候要切记中立客观,对事不对人.即便开发人员拒绝修改bug,都应该不卑不亢的询问原因.如果还有问题就让你们的上级决定,他们会本着对项目考虑的原则从大局上把握好问题的.[Page]

        以上的我在开发过程中的一些总结。工作这么长时间，角色也不断在转变，发现自己刚进测试这一行业的有些想法是错误的。而且体会最深的就是在从别人的角度多去思考问题，这样有些问题根本就不是问题。 
        开发和测试的关系永远都应该是水乳交融的，互相促进的。建议大家在出现问题的时候多想想为什么会出现从这样的问题，问题最终是如何解决的，这样才不失为经验积累的好方法。

原文转自：http://www.ltesting.net