51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3379|回复: 18
打印 上一主题 下一主题

[讨论] 请问,你们有没有问过开发人员bug错误的原因

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-11-16 10:31:03 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
我想bug错误的原因首先因该从开发人员那里学习,我们公司的缺陷跟踪工具每次开发人员回复的都是“已解决”,一直想好好的测一个项目的同时,了解bug产生的具体原因,每次写小结总觉得不够深入。
希望各位谈谈,你们有了解过吗,一般有些啥原因,最好分的细点,知道了以后才能自己就判定呀。谢谢~~~~~~~~~~

数据问题;
逻辑错误;
控件问题;
等等,大家还知道什么请补充!

[ 本帖最后由 nakata_fy 于 2005-11-18 13:04 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

19#
发表于 2005-12-7 12:21:23 | 只看该作者
其实我个人认为首先测试人员与开发人员沟通的最好也是最直接的东西就是公司的缺陷跟踪管理工具,上面应详细的记录了开发人员与测试人员共同的结晶,bug。提到bug,其实就涵盖了bug的生命周期,它的生命周期末期就是bug的关闭,当然也涵盖了它中期的解决情况。所有的这些过程才能完全的定义一个bug,否则它是有缺漏的。
   谁都知道,coding时产生bug是正常的,就因为有了这种自我宽恕的心态,才会导致bug不断产生,修改完bug后在不想去问津的局面;大家也知道,人的一生难免有几次犯错误的时候,似乎只有这样才能称为完善的人生;但是聪明人往往很看重自己曾经犯错的经历,并且善于总结它,分析它,找出原因,而后在以后的道路中去避免它。我认为只有做到这点才算是完善的人生。同样我们对bug的处理也应该这样来做,无论是开发人员还是测试人员都应该善于去定位它,分析它,总结它,吸取教训,coding时去避免,testing时去注意,这才不枉这个bug的“亮相”。
    个人想法,望你大伙探讨。
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2005-12-6 10:30:45 | 只看该作者
打破沙锅问到底,还要问沙锅在哪里。
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2005-12-6 08:34:40 | 只看该作者
在我们这里,bug的产生原因一般都是询问项目经理,我们现在的这个项目不算小,分了3个组,每个组有一个小的项目经理。老大说,主要听听他们的意见就好了。程序员的可以不必询问。我不知道这样是否正确,大概是怕程序员互相推拖责任的缘故吧。因为牵连性比较大,所以,我测试的时候,一个bug可能要找好几个人呢。呵呵~~!
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2005-12-5 23:08:12 | 只看该作者

与开发,产品人员的沟通

我感觉我最大的缺点就是跟开发人员及产品人员的勾通问题。有些事情总是不好意思问,或这样那样的原因。导致事情被放下,一直到最后被当初被认为不重要的问题,最后出现了bug。对自己的工作会产生很大的负面影响。所以跟开发人员,产品人员的勾通,是做为一个测试人员必须要做到的一件重要的事情。
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2005-11-21 13:08:28 | 只看该作者
开发人员在解决一个bug后,应在注释里注明产生bug的原因,以及如何解决这个bug的。这样对于测试人员,能更深层次的了解程序的内部结构。对于测试人员发现类似的和更深层次的问题有很大的帮助
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2005-11-21 12:45:05 | 只看该作者
关于缺陷的原因分析实际上涉及到缺陷分析技术,比如柏拉图法、鱼骨图法、5个why法等,大家感兴趣可以上网查查看。
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2005-11-21 08:45:33 | 只看该作者
对,开发人员、测试人员、需求编写人员之间要多交流。



--------------
训练测试思维——《软件测试实战——测试Web MSN》在我的个人网站www.TestTip.com
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2005-11-19 13:00:51 | 只看该作者
开发和测试必须要多交流,当他们有机的结合在一起的时候,产品才会有质的提高和飞跃~
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2005-11-18 13:55:55 | 只看该作者
当然要问!不然怎么决定还要在这个Bug上投入多少精力呢。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2005-11-18 11:11:45 | 只看该作者
Bug产生的原因据我所知有:
数据问题;
逻辑错误;
控件问题;
等等,大家还知道什么请补充!
回复 支持 反对

使用道具 举报

该用户从未签到

9#
 楼主| 发表于 2005-11-17 16:23:14 | 只看该作者

明天测试组开会,会上讨论讨论

。。。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2005-11-16 12:27:37 | 只看该作者
缺陷管理工具不只是提供给测试人员进行详细提交和跟踪的,开发人员在FIXED一个BUG的时候是应该详细说明问题是怎么修改的,而且还要说明问题产生的原因。。。

如果你们开发人员没有通过缺陷管理工具进行清晰交流的话,那就是开发人员的工作问题了,不妨找个时间在这方面做一下系统的交流和沟通~~~~~~~~~
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2005-11-16 12:11:05 | 只看该作者
有些什么原因呢往往?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2005-11-16 11:53:21 | 只看该作者
我遇到的程序员,有的很配合,特别是女生的程序员,比较简单的问题自己能明白,较难或比较难以重现的,我们有时候讨论一下,或者自己凭经验仔细想想也能知道大概的原因,有时候bug发生的原因还是俺帮着想出来的呢,很有成就感。跟男生交流起来就比较难了。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-11-16 11:12:37 | 只看该作者
我们公司,在bugtrack中有Root Cause\Solution两栏。但是开发的一般都不填,除非我追着问他们,我自己做几笔纪录。

呵呵,感觉自己在要债阿。测试,还有待重视啊。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2005-11-16 11:02:25 | 只看该作者
在缺陷跟踪单,或者问题单中有一个环节,必须有开发人员针对缺陷写出具体的原因和修改结果。因为回归测试时这些都是依据。如果测试人员发现开发人员没有写这些内容,或者写得不明白,可以向他们询问,或者直接将问题单返回,要求重写!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2005-11-16 10:41:59 | 只看该作者
我问过,他们说逻辑错误,可能因为我没搞过开发,仅仅是学校学过些编程语言,我觉得这样回答不够,因此希望你们谈一下开发人员是怎么和你们说的,这样等到测下一个项目时我可以更主动的和他们交流。
回复 支持 反对

使用道具 举报

该用户从未签到

2#
发表于 2005-11-16 10:38:31 | 只看该作者
楼主公司的开发人员做工作不到位,按理说,修改情况应该由开发人员详细写明,具体修改了哪些东西,产生BUG的原因是什么。更好的是提供修改后的单元测试报告。测试人员也可以和开发人员进行交流,了解其中的原因。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-9-22 07:05 , Processed in 0.098070 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表