到底什么样的问题才算bug?什么样的问题算是软件有待完善的地方?

楼主
我是社区第56927位番薯,欢迎点我头像关注我哦~
本帖最后由 满屏幕的bug 于 2014-12-17 21:56 编辑

我相信很多对软件提bug的楼主都遇到过找个情况, 就是自己觉得是个bug,但版主或者管理员或者工程师却回复说这个算是软件有待完善的地方,而不算是bug。
我这里说下我对bug和有待完善的地方的理解。


什么是bug?
我觉得下面两种情况可以算是bug:
1.程序代码处理不当,引起的明显的问题,比如软件崩溃、卡死、交互显示错误,这些没有异议,都算是bug;
2.研发工程师没有想到而实际又会出现的情况,但怎么区分他有没有想到呢?其实这就要看研发工程师了,比如你给他提一个这种情况的问题,他的第一个反应时“卧槽!忘了还有这种情况了!”,那就好说了,这就是个bug。但如果研发工程师看到后的反应是“哦,这个情况我考虑到了,但是没想好要不要加这个功能,没想好这个功能加上去会不会鸡肋,所以还没加”,这样就不算是bug,所以这个评定标准只能看研发工程师了。
总结下就是代码错误,或者研发人员想法的疏漏引起的问题应该都算是bug。

那什么是有待完善的地方呢?
我觉得区分标准和区分bug的第二条很类似,也是要看工程师的反应,比如工程师看到这个问题后,反应是这样的“这个功能有点意思,如果加上,应该会更好使”,那我觉得这样的情况就应该算是有待完善的地方了。


描述的可能不是很清楚,我用帖子举例再阐述下我的观点。
比如这个帖子http://bbs.fanruan.com/forum. ... 04&page=1#pid205292,这是自定义的图标没法删除的问题。,这个是帖子的楼主其实是更加倾向认为他是个bug的。但我当时回复说是我觉得是软件未完善的地方。但他到底算不算bug?其实我俩说了都不算,得找研发这个功能的工程师,让他说。
这么说吧,如果研发工程师看到这个问题的时候,第一个反应是“我操,忘了加删除功能了!”或者是“啊!确实应该有个删除功能,之前忘记了”,这样就很明显了,它是个bug,因为这样来看的话,这个问题是研发工程师没有处理好或者没想全引起的问题。
但研发工程师如果说“哦,这个我想到了,但我觉得没必要加删除功能,或者是还没想好加不加,得看大家反馈”,这样其实他就算是一个有待完善的地方了。


最后总结一下吧,大家遵从自己的内心,认为它是个问题,就向研发工程师或者版主楼主反馈,毕竟这些都是自己付出了努力的,得到回报或者争取得到回报都是应该的。而作为版主或研发工程师的我们,也要遵从自己的内心,不要明知他是个bug或者明知他可能有问题,却说这个没问题,而在下一个版本中改掉了。


最最后提个建议!
可不可以考虑把用户提出的会被收录的建议也算奖励?这样就不用区分上面的情况了,执行起来更加轻松。况且很多时候,提出一个合理的建议甚至比找到一个bug对软件的帮助更大~

以上仅仅是我个人的一些观点,肯定不会所有人都同意,也肯定不会是判断是否为bug的标准,主要是说出来,希望能够给大家提供多一种思路,同时希望能够使测试人员和审核人员能够更加相互理解。
大家忽视没美感的排版和没文采的文字吧_(:з」∠)_


分享扩散:

沙发
发表于 2014-12-18 08:48:21
写的蛮好的!
板凳
发表于 2014-12-18 09:02:03
赞一个{:5_133:}
地板
发表于 2014-12-18 09:14:49
前段时间已经讨论过这个问题了。。。bug的定义和划分。。另外,版主说的建议。。这个fr也很开始执行了。。测试组现在是将需求和bug一样给于奖励了。。。。所以版主可以方宽心了。。。多提bug和需求。。多多拿钱{:8_198:}
5楼
发表于 2014-12-18 09:20:17
{:8_209:}写得不错,已加精。关于你对bug的这种理解,我个人比较赞同,我会推荐我们测试人员看下你这个帖子。
至于你最后提到的,算是有用的需求(你说的合理的建议)是否奖励的问题,9月份我们搞过一个“产品需求征集令第一季“的有奖活动,我们把需求和bug的征集活动进行了区分,原因主要是合一起会增加难度和周期,凡是需求还得经过产品组(不同人员负责的模块也不同)去确认,而且产品的需求一般会分为多个等级,奖励的设置也需考虑。
不过随着我们办此类活动的经验逐渐丰富,以后会在每次活动中,对于那些能对FR有帮助的反馈都给予适当的奖励。
6楼
发表于 2014-12-18 09:40:43
赞一个{:8_209:}
膜拜楼主~提bug高手
7楼
发表于 2014-12-18 09:47:24
顶礼膜拜呀,楼主是嫌钱拿的不够多呀!
8楼
发表于 2014-12-18 10:40:59
{:5_133:}
9楼
发表于 2014-12-18 15:42:19
佩服楼主,你是我的偶像,支持一下{:8_209:}
10楼
发表于 2014-12-19 07:59:12
{:8_209:}         
11楼
发表于 2014-12-22 14:35:28
顶起。分析的很详细。
实际操作中有的问题确实不是很好区分,因为设计者和用户对于“应该”的理解不同。
12楼
发表于 2014-12-23 10:09:26
V587{:8_209:}
13楼
发表于 2014-12-29 09:40:40
怎么才算BUG到现在还真没研究过
14楼
发表于 2014-12-31 09:41:36
是不是BUG^研发说的不算^得看产品,如果产品说有这个设计,并跟设计不符……就算BUG^只是能解决或者不能解决的问题……比如有些设计确实应该这样子……但作出来由于技术原因还达不到要求……这样的确实是BUG,但是却属于无法解决的BUG。另外还有一点我也很奇怪,JAVA开源的代码很多,所以经常有“第三方引用”……但是我觉得把这个拿来作为不解决BUG的理由就有点说不过去了……既然明知第三方有BUG为啥不提前在文档里面说明或者干脆就改造第三方的jar呢[很多都是开源的]……给客户一个“第三方JAR就没有这个方法,第三方JAR就有这个问题”这不是有点推卸责任的么?客户买的是你的产品,你用什么第三方客户肯定是不关心的,但是你不能出问题就把责任推给别人,说白了,钱你拿了,责任让别人担这本身就是不合理的。
15楼
发表于 2015-2-14 11:30:26
{:8_209:}{:8_209:}
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

返回顶部 返回列表