注重BUG分析的良好习惯

王爬爬 · 发表于 2008-3-24 22:40:32

我觉得Bug报告并不是软件测试工程师的终极体现，如何引导开发工程师解决BUG才是王道！

goog_616 · 发表于 2008-3-24 11:00:31

顶！

www888 · 发表于 2008-3-22 12:48:26

学习中……

marysnow · 发表于 2008-3-21 10:31:51

楼主写得不错，学习了。

mianbaoshu · 发表于 2008-3-18 23:26:21

写的真好

glyw168 · 发表于 2008-3-18 17:24:28

值得学习！

vanceinfo · 发表于 2008-3-18 16:36:11

好文

偶刚进测试领域时，当时的Leader就要求我们来这么做，当时的想发和也和楼上几位的想法相似“很细致，不过是不是很麻烦呢”。不过还好坚持了下来。
楼主解释了缺陷的几种状态，以及这些状态出现的原因，处理方法。虽然有些状态很少会用到，而且这样的处理流程看起来分支复杂，但是在实际的缺陷处理流程是很实用的。
测试缺陷是开发人员和测试人员之间的一个交互点，开发人员和测试人员之间的交流就是依赖于这个测试缺陷里所表述的文字。所以需要测试人员对于缺陷描述要简介，准确；测试缺陷的状态则是这个交互开始的触发点，什么样的状态应该做出什么样的反应，双方就可以依据测试开始前定义的缺陷处理流程来展开工作。
另外，偶同意缺陷由缺陷的提交人来关闭。理由很简单，提交人最清楚自己提交的问题；假如问题由指定的负责人来关闭，问题多了，这个负责人就是忙死，也处理不完，同是会产生一个结果，降低了测试缺陷提交人的责任心。

lazyapril · 发表于 2008-3-18 12:49:09

写的很详细，学习。

zfl_zl · 发表于 2008-3-18 10:55:02

阿七 · 发表于 2008-3-13 16:06:56

胜读10年书哦

sense · 发表于 2008-3-13 15:37:29

写得不错，新人都应该注意这些问题，但我不同意第二个观点“最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发现bug的人才能够确信bug是否真正的已被修复。”
个人认为这要看公司产品定义，职责划分，每个模块都有固定的负责人时，建议最好由负责人进行BUG确认工作，能了解到别人测试的角度，可以思考为什么别人能发现这个问题，减少测试的盲区，提高测试

rting · 发表于 2008-3-10 13:49:25

恩，写的好，测试员就是应该注意这些细节的地方与他人方便也就是给自己方便

chen217222 · 发表于 2008-3-10 13:23:01

自己也尝试过，确实能学到东西。

badfeiyang · 发表于 2008-3-10 11:27:56

Yes ,yes~~

kelly6772 · 发表于 2008-3-6 11:11:41

说的不错，有所收获了，谢谢！

syren · 发表于 2008-3-4 15:21:24

写的很好，学习了

lovetesting52 · 发表于 2008-3-4 15:12:59

bug从某种程度上来说可以反映一个测试人员的水平，测试: 也需要慢慢的积累经验

janwarly · 发表于 2008-3-4 14:57:32

补充一点: 描述BUG一定要精辟易懂,必要时附上照片,以便软件工程师利用短时间内确认并改善

阡陌 · 发表于 2008-3-4 13:21:11

事情的开始总是能做到认真，细致，问题是同样的事情，做几遍，甚至十几遍，几十遍后，还能坚持这么认真细致吗？
那个时候简直觉得枯燥极了，开始的认真细致也慢慢磨没了。还是也缺不了耐心啊

cuiyz · 发表于 2008-3-3 15:58:38

分析的很透彻啊.顶!

		自动登录	找回密码
密码			(注-册)加入51Testing

[资料] 注重BUG分析的良好习惯

学习下

OK

站长推荐 /1