一个高质量的BUG需要具备以下要素
上面有位作者提到BUG三要素:位置\操作\现象,是很基本的.我也做了几年测试,凭我的经验我觉得一个好的BUG还要应具备以下要素:预期的结果\实际的结果\问题分析要写出预期结果就要熟悉了解被测东东的需求,了解客户的需求，或者对产品多年的积累.
要写出实际结果就比较容易了,包括出错的现象,还有问题所在
要分析问题就比较有挑战了,这也是衡量测试人员水平的要素.分析错误大概出在哪里.从两个方面来分析,技术上分析:使程序员更容易定位问题.业务上分析:因为有的程序员没有经验,他只知道一个模块,有深度,但是没有广度,他不知道整个项目的需求,更不知道客户的要求.他很有可能不知道要如何去修改这个BUG,如果你给他思路他会很感激的.
所以测试人员需要了解的东西需要比较广泛最好做过程序员,另外业务知识很重要,对于做项目测试尤其明显.业务知识的积累有很多途径,如去项目现场参观. 我个人并不赞同测试人员提交过于详细的测试记录。
你的预期结果，实际体现在测试用例而不是测试记录中，至于问题分析，你是否能保证分析的全部正确，如果错误误导了程序员会如何，如果错误过多会给程序员造成不良印象。
测试人员的工作是测试，提交问题。解决问题是程序员的工作，就像一个经理偏要做工友的工作，效果和效率会如何？
对测试人员来说，代码级绝对不如开发人员熟悉，测试人员可以猜测问题的发生，也可以在程序员需要协助的时候提交自己的看法，但我个人认为把此提交到缺陷记录中是不合适的。
这不是测试人员水平的问题，是一个是否有必要的问题，应该使用简单的处理方法，就是多一事不是少一事。
当然，如果公司的制度是测试人员对此提交问题分析，就当我上面的都是废话好了。
你的见解有一定道理
我觉得提交BUG时,不能只是告诉他出现的一些表面现象,而应进一不发掘错误发生在根源. 晕，不用开个新帖子吧，直接在原先的帖子中回复就可以了。关键的是时间和效率问题。
你测试的时间有很多吗？反正我们都是紧赶慢赶的，而且对问题的理解，测试不可能如开发那么熟悉，怎么软件也是他们开发的。
你说错误的原因对了无所谓，但是10个问题中你说错了一句，开发会记一年，何必找不自在呢。
你找原因用半个小时，人家可能一看就知道可能出错在哪个代码行，值得吗？
你可以找原因，自己记住就可以了，验证的适合去看看缺陷修改记录自己是否正确，至于写报告上，我还是认为不很合适。
我同意版主的看法。
我同意版主的看法。经理要求这样做啊
我以前公司的测试经理就要求这样做,BUG只描述出现的问题现象的话,就认为你的水平不够.因为部门有个高级测试工程师是做过程序员的,所以测试时总会描述问题可能在哪个SESSION,后来我们跟着开始学习JAVA编程.就这样我们被逼成这样了.不过现在的公司不要求这样做.不过心理深有体会了. 这也许就是公司制度的问题吧。
测试人员的工作是发现问题，至于问题如何发生以及问题的解决，看是否有时间和精力了。 问题尽可能的描述清晰，在提交bug时尽可能的去掉一些无关的信息，这些都是必须的，但至于定位到某行代码上这个恐怕就没必要了，除非是做单元测试
页:
[1]
