注册 | 登录
互联网金融行业，产品爱好者，市场运营人
产品经理就业班，12周特训，测、练、实战，22位导师全程带班，200+名企内推，保障就业！
自从我干上软件开发这一行，并且使用了Bug跟踪系统，我们在每一个项目里都会纠结一个基本的问题：你怎么能把Bug与功能需求区分开来?
当然，如果程序崩溃了，这毫无疑问是Bug。不过，那也许只占你每天所处理问题的10%。为了避免项目的彻底失败，真正的杀手级Bug——有它存在就不能发版的Bug——会很快被消灭。而在Bug跟踪系统里留下来的绝大部分Bug，就落入了没人管的灰色地带。用户报告的是Bug吗?不完全是。用户在要求一个新功能或完善某个既有功能吗?也不完全是。好吧，那到底是什么?
这是一个令人犯难的问题。进一步说，我认为大部分Bug跟踪系统都在“坑”我们，因为它们让我们非要回答这种无聊问题，逼着我们站队——要么海菲茨，要么麦考伊斯((译者注请见文末);要么可口可乐，要么百事可乐;要么是Bug，要么是功能需求——这是一个痛苦的抉择，选择哪一方均在一念之差，因为大部分时候两者皆可。从用户的角度看，Bug和功能需求是没有区别的。如果你想用一个软件(或者网站)做某件事情，但因为某个功能没有实现而无法完成;相比于你在使用过程中因为出错而不得不停下来，两者之间有区别吗?
我们来看一个例子：在开发Windows应用程序的时候，Visual Studio没有使用正确的字体。这算是一个Bug还是功能需求呢?
我个人觉得这是一个Bug。我猜微软也是这么认为的(至少理论上是这样)，因为那个问题已经在Microsoft Connect系统里存在了4年多。当你开发一个Windows应用程序，除非你刻意想要使用一种特殊字体，你难道不希望使用操作系统的默认字体吗?好吧，如果你在Visual Studio 2008里创建一个新的窗体，然后添加一个标签控件，看看会是什么情况吧：
仿佛一下子回到了1996年，因为你看到的是“可爱的”MS Sans Serif字体。那是所有新窗体的默认字体。你也别见怪了，所有新开发的应用程序看起来都丑陋无比——我的措辞已经很克制了!
下面是一个对比：一行标签用了默认字体，另一行标签显式设置了默认的GUI字体。
纵观我所使用过的应用软件，我发现，大部分Windows程序员根本不关心设计。这可不妙!甚至更糟糕的是，这种对设计的漠视被Visual Studio携带，从2002年开始不断地感染着每一位用户。
当然，设计方面的问题是很主观的。在Windows图形用户界面的字体使用方面，要是我们能有一些参考资料，那该多好啊!某种类似于标准的东西。就比如微软给Windows Vista用户体验定义的那些规范：
使用Aero主题和系统字体(Segoe UI)
使用通用控件和通用对话框
使用标准的窗体边框，慎用透明效果……
这样的规范总共有12条。不过，我想要找的恰恰就是第一条：应用程序应该使用系统字体。
我为Windows Vista的整体质量扼腕叹息，为此我也写过满满的一篇文章。上述这份清单看起来很欢乐，其实已经不言而喻。特别是第12条：预留时间提升“整体质量”，让我不禁大笑。在开发Windows Vista的时候，微软想必对这条规范耿耿于怀。值得注意的是，这些都出自于一个热爱Vista的家伙。
对不起，我跑题了。
尽管Visual Studio 2008里的窗口字体行为违背了微软自家的设计规范(中的第一条)，这个“Bug”却4年多来一直没有被修正。它被悄悄地归类为“功能需求”，然后被束之高阁了。毕竟，没什么恶劣影响——使用错误的字体不会让程序崩溃或降低生产力。另一方面，想象一下，自从微软践踏自家的设计规范以来，有多少大公司的应用软件已经被开发出来了啊。要么因为开发人员没有意识到应用程序的字体与操作系统不匹配的问题，要么他们没时间写一些必要的权变代码来加以纠正。
没错，这是一个小问题。我相信，修正这个问题不会让Visual Studio更好卖，比如多卖给大公司几千个使用授权。这也是它没人管的原因吧。
问题依旧：这是一个Bug，还是功能需求?
我很喜欢用UserVoice(Stack Overflow采用的就是这个工具)，它最让我心动的一点是，它故意模糊了Bug与功能需求之间的界线。不管怎么说，用户搞不明白它们之间的区别;更糟糕的是，程序员可能会据以搪塞用户。他们把不想做的事情归类为“功能需求”，从此以后就置之不理了。他们会据理力争，嚷嚷着说某个被报告为“Bug”的问题显然不是Bug，自然也就不必修复了。罢了吧，别再区分Bug和功能需求了，让它们都见鬼去吧!
我希望，我们全行业都能少花点时间在概念的口舌之争上，别再煞费苦心地把用户反馈区分成“Bug”或是“功能需求”。面对用户反馈，我们应该多花点时间做一些有建设性的事情。(译者/陆其明)
译者注：美剧《Hatfields & McCoys》，又名《血仇》，聚焦于美国声名狼藉的两个家族(Hatfields和McCoys)之争。两大家族的争执源自于美国南北战争时期，Anse Hatfield和Randall McCoy本是要好的哥们儿，但不想后来生变，二人结下仇怨，甚至引得弗吉尼亚州和肯塔基州都不安宁。由此，这两大家族联手制造了美国史上最臭名昭著的血腥争端。
本文译者 有点精神病、英语原文，来源：产品中国
赞赏是对原创者的最大认可
收藏已收藏 | 1赞已赞 | 1
互联网金融行业，产品爱好者，市场运营人
产品经理群
运营交流群
数据分析群
文案交流群
Axure交流群
关注微信公众号
大家都在问
9个回答6人关注
2个回答1人关注
10个回答5人关注
16个回答18人关注
19个回答20人关注
14个回答18人关注博客分类：
写给我的团队成员（一）—— 什么是BUG？
什么是BUG？每个写过代码或者使用过软件的人似乎都知道它是什么。然而，我们的很多工作年限有限的开发人员总是简单认为：程序跑通了，自己测了N遍了就很少有BUG了。这是个危险的观念，没有理解深刻这一点的人会在自己的进步过中走很多弯路。更会给产品和团队带来各种大大小小的危机。
对抗BUG是我们程序员永恒的主题，要在这场战斗中获胜，首先要做到“知己知彼”——什么是BUG?
现在，我们来一起把BUG分为以下几个种类，你在Coding的时候要随时随地的想到这些：
最最普通的BUG。 我实在缺乏用语言来给这类BUG下定义的能力，因此你现在能够识别，这就是BUG的东西，应该可以归属于这一类。
编译不通过。 你可以认为这是最简单的BUG，根本不需要特别考虑，如果编译不过，Eclipse会在设计时给你个红XX 来提示的。但是，在下面的情况中，你可能看不到红XX，但BUG依然存在。
spring的xml。缺省的eclipse可不会在design time时给任何检查。你写错一个字母，都会让你无法运行。跟业务逻辑相关的依赖关系，更别指望eclipse替你找出来。
jsp中引用的java代码。不用我解释了吧，大家可能都有体验。至少我目前还没找到完全可靠的jsp plugin 可以帮助 eclipse来随时随地找出jsp中的代码错误。（除非你把上千个jsp文件都关闭并重新打开一遍）。
业务逻辑实现错误。 这就不需要过多赘述了。地球人都知道。
缺乏必要的事务。 在99.9%的“开发时”，事务不是必须的。在仅挨着的两条insert语句执行的瞬间，出现系统失效的可能性微乎其微。然而，一旦进入了生产环境，用“事务”来保持你要进行的这个action的完整性就显得非常重要了。当然，并不是所有的业务逻辑步骤都需要用事务来保护，况且让容器帮你你管理事务也是一种懒惰但有效的做法，但与此同时自己去考虑一下“这里如果没有事务，我是否安全？“的问题，对你的进步更有好处。
团队使用的基本库出错。 不要认为团队自己开发的基本类库是100%正确的，轻信不完善的API的思想是大量顽固BUG的藏身之处。团队自己生产的代码还在不断的完善和发展，毕竟咱们积累的这些”精华“与外面OpenSource的东西（而他们同样有BUG）相比，还差懂得远呢。我丝毫不怀疑里面存在超过100个算法缺陷和200个不安全的使用方式。因此，不要”拿起来就用“，而要”三思而后行“。
性能陷阱。 为了尽快实现业务逻辑。我们在第一次编码的时候往往不先考虑性能问题。这个想法不算太错误，但这个想法不能太过分。特别是涉及到一些”性能敏感”的代码段，比如我们产品中多处涉及到的Tcp Server的内核。这些部件的代码1天可能遭受几百万次的访问，瞬时绝对并发100是最正常的情况。因此0.1秒的性能损失，也会带来100x0.1=10秒的性能损耗。10秒，足以使一个TCP Server达到实际“不可用”的严重程度！10行马虎的代码，可能毁掉客户对我们团队辛苦生产的100万代码的信任。切记！切记！
安全隐患。 某些安全隐患在我们刚开始写实验性的代码时往往可以忽略，但绝不能忘记。你必须在这个产品进入到下一阶段的时候加上必要的安全检查代码和与安全相关的逻辑验证代码。回忆一下，你是否忽略了下面的工作：
http session检查。 尽管我们可以用框架来保证这一点。但你还是要检视一下，是否在某些功能的实现上，你确实忘记它了。
参数类型校验。 当你把一个'a'传递到servlet用Internet.parse（）来处理的时候，你是否考虑了可能出现的异常情况。等等此类。
NullException。 特别注意，千万不要让NullException出现在jsp中，否则你很难在系统部署后排查错误。在你第一次编写jsp代码时，你就必须考虑你所使用的对象或者属性是否可能为Null。
Anti-flood。 最容易被初级程序员忽略的要点之一。因为这个bug永远不会出现在你的eclipse开发运行环境里。也往往被功能测试组的人忽略。但一旦存在这个隐患，一个最菜的Hacker用最普通的teardrop也会让你tear drop。
线程安全。 永远不要忘记，你的代码需要在一个多线程的环境中运行，随时随地都有可能出现并发的情况。你的产生的临时文件名是否用uuid来避免重名了？你的静态（或单态）变量是否线程安全。你是否忘记将spring里定义的bean设置为scope=prototype？
忘记删除临时文件。 在上传文件、生成验证图片、生成缩略图的时候，你都可能用到临时文件。你是否在使用完毕后及时的删除了它？你是否考虑过在发生异常后，仍然安全的删除了这个文件？特别需要指出的是，我们在编码阶段的测试时，很难发现遗漏临时文件清理的工作。单在系统上线运行后，大量滞留在目录下的过期临时文件将用光客户的服务器磁盘空间，降低系统IO的性能。
极不友好的UI操作。 极不友好的UI操作同样是严重的BUG。比如：
当用户提交表单的时候可能填写了错误格式的信息，而你的程序再提示错误，重新显示表单的时候清除了用户已经填写的数据。这对你的软件的使用者来说是极其恼火的体验，对于创造这个代码的您来说则是一种耻辱。
另一种“极不友好的UI操作“可能发生在这种情况——你必须跟测试人员解释——他体验到这次系统出错的原因是他（测试人员）操作的步骤或顺序不正确。天那，这是噩梦，不仅是用户的噩梦，也是你的噩梦。如果你坚持你的做法没错，我将决定在系统上线后，把你的手机和家里的电话号码做为HELP放在你创造的界面的显著位置呈现给使用它的80万用户。
浏览: 852422 次
来自: 北京
弄了半天,参照你的方法解决了.特来感谢,知道可能是先加载,但是 ...
请问怎么使用，运行之后d盘符没有生产音频文件呢？
chenghong726 写道你好，我也遇到你这样的问题，按照 ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'没有更多推荐了，
不良信息举报
举报内容：
软件测试过程中如何区分什么是功能bug，什么是需求bug，什么是设计bug？
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！如何给苹果提交Bug或功能需求？
发表于 10:17|
来源idlelife|
作者pockry
摘要：在苹果的Bug Reporter中，开发者可以提交自己发现的任何问题或功能需求，并查看已提交问题的处理情况。这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道。
自从Swift推出以来，很多开发者已经第一时间尝鲜并且尝试用它进行开发了。不过，由于Swift还是个演进中的语言，Xcode对它的支持并不完善，偶尔会出这样那样的小问题。有些开发者在发现问题后，顶多发个博客记录一下然后就不管了，我们是否有更好的办法，比如给苹果提交这个bug，让它快速修复呢？答案是有的，并且仅对苹果的开发者开放，即苹果的。Radar or GTFO在苹果的Bug Reporter里，你可以提交你发现的问题或者功能需求，你也可以查看你提交的问题的处理情况。问题会被分配一个ID，并带上rdar://这样的URI链接，因此给苹果提Bug被称为“file a Radar”，意味着你的问题出现在了苹果工程师的雷达上面，十分形象。在国外苹果开发者中间有一句广为流传的话叫做“Radar or GTFO(Get The f*ck Out)”，意思是除非你发布了一个Radar，否则苹果不会处理你的问题。无论你在个人博客或者苹果的开发者论坛上面提交Bug，即使苹果工程师看到也会被忽略掉的，这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道（如果是和App审核、苹果设备相关的问题，你可以寻找对应的客服）。如何写一个Radar？使用苹果开发者账号登录到Bug Reporter后，你可以提交问题。苹果的这个系统和其它的Bug追踪系统并没有太大的差别，你需要先选择发生问题的产品、问题类型、复现频率，然后用标题和文字来尽可能清晰的描述你的问题细节。编写问题细节并没有固定的格式，你需要提供出问题的系统或软件版本，如果有截图或者其他文件证据可以作为附件添加。需要注意的是，你需要用英文编写问题。不过，虽然没有格式，作为完美主义者的苹果还是对问题细节的描述做出了诸多规定和建议。比如，标题部分：Safari is slow.（坏的）Safari is slow allocating JavaScript arrays. (Include JavaScript sample with your bug report.)（好的）问题细节也需要包含以下几个部分：复现问题的步骤预期结果实际结果变通方案回归测试和条件隔离情况（Regression/Isolation）具体内容可以看苹果关于。提交Radar的技巧提交Radar可能会遇到一个情况，那就是这个问题之前已经有人提交过，那么它会被标注为“duplicate”，不要惊慌，其实这里包含着一个提交Radar的技巧。前面说过，向苹果反馈bug的唯一途径是Bug Reporter，在其它地方闹得满城风雨也没有用，苹果也不建议这么做，如果你做得太过分了，还可能受到苹果的惩罚。那么，如何让苹果重视你提交的问题呢？Daniel Pasco，一位有经验的苹果开发者在他的里这样向我们传授经验：工程师团队总是面对太多需要解决的问题，工程师们定期的和它们的上级主管开会，对问题进行分类，以决定接下来需要解决哪个问题。一个问题被报告得越多，说明它越需要关注，工程师在下判断时也会更容易。对于所有软件公司来说都是这样，当你发布了一个产品，人们很有可能会报告一两个边缘用例（edge case）下的问题，你当然会想在时间允许的情况下修复它，但如果有数百人报告相同的问题，说明问题很严重，并亟待解决。苹果在这方面和其它公司并无不同。从某种意义上来说，提出重复的问题是一种投票，或是对已存在问题的一个支持。一个问题获得的重复次数越多，说明它的优先级越高。因此，如果你发现了一个问题，在提出Radar之后，可以将Radar原文发布到自己的博客或者论坛上，号召其它开发者提出相同的Radar，促使苹果工程师重视这个问题。不过也要有所克制，注意不要滥用。除了提交重复问题，还有一个可能不太常用的技巧是，你可以去勾搭苹果工程师，如果你提交的Radar好几天了都没动静，你可以联系苹果工程师，以求获得一个反馈。当然，这里如何勾搭和勾搭的技巧就需要大家自己琢磨了。看到这里你是不是蠢蠢欲动，想去Bug Reporter上提交几个bug？但国外的苹果开发者对这个Radar系统却并不怎么买账，为什么呢？Fix Radar or GTFO苹果的这个Bug Reporter系统最大的问题是，开发者提交问题之后，无法快速收到有效的反馈。一般的场景是这样，你提交了一个问题，然后它被标为duplicate并关闭，然后就没有然后了。别的开发者无法看到你的提交的Radar，你无法看到苹果的工程师对于此问题的回复，你也无法得知你提交的问题何时能得到修复。（如果你提交的Bug非常紧急或有一些其它问题，苹果也可能会直接联系你，不过这种情况很少）Mattt大神，一个Radar在提出足足7年之后才被修复，除了提交Radar的技巧之外，缺乏有效的沟通手段也是造成这一结果的原因。另外，这个Bug Reporter系统还有UI不美观，完全不像苹果出品，对于开发者不够友好的缺陷。在2012年，一些苹果开发者再也无法忍受如同黑洞一般的Bug Reporter系统，发起了“”活动，呼吁开发者提交重复性的Radar，想让苹果改进这个Bug收集系统，让它变得更加开放。另外一些人则做了一个，开发者在提交到官方的Bug Reporter之余，也可以将他们的Radar提交到这里，开发者可以看到别人的Radar并进行讨论。开发者的这些努力收到了一定的效果，2013年9月，苹果对Bug Reporter系统进行重新设计，改进了它的UI和使用体验，但是，对于开发者们开放Radar的要求则未予满足，你仍然不知道你提交问题之后究竟发生了什么。不过，也有开发者对“Fix Radar or GTFO”运动并不以为然，像这篇所说的：其实开发者并不需要一个Radar，需要Radar的是苹果，如果Radar对于苹果来说工作得很好，那么就没什么问题。比如在是否开放Radar上面，如果开放Radar会造成一些不好的后果，比如Bug被恶意利用、Radar优先级被活跃用户干扰等等，那么还不如不开放。开发者需要做的是“file and forget（提交并遗忘）”，提交Bug已经尽到了开发者的责任，接下来的就留给苹果吧。是的，也许我们走过头了，如果我们知道，提交的Radar会被认真对待，那么其实没有必要要求更多，毕竟对于改进产品最迫切的是苹果，而不是开发者。所以，信息不对称是万恶之源，那么就让我们来看看，一个Radar被提交后，苹果是怎么处理的吧。苹果内部是如何处理Radar的？一个曾参观过苹果内部的开发者道：苹果内部有一个专门的Mac app用于处理提交的Bug，在这个app里面，苹果工程师能够对问题进行标记和分类，不同的工程师能对同一个问题进行讨论，最终进行优先级的评定，比如评定为“Show-Stopper”状态的问题是必须第一时间解决的，否则不会发布下一个更新。事实上，苹果非常重视提交到Bug Reporter的问题，一位曾在苹果工作过的开发者：所有的问题都会被很快的分类并进行讨论，只是问题是，讨论多涉及到苹果内部的技术，而由于苹果的保密措施，所以即使是讨论也是难以对外分享的。所以，你可以放心的提交Bug而无需担心它受到冷落，而另一方面，也不要太期待从苹果得到反馈，如果苹果修复了这个问题，那么你是幸运的；如果苹果没有修复，说明这个问题的优先级还不够高，工程师们有其它要做的事情。如果你认为你发现的问题很重要，你可以尝试一下上面提到的技巧。重要的是态度，其实你和苹果的目标是一致的，都想解决你提出的问题，所以没有必要闹得不愉快。据苹果最新的财报显示，中国已经是iPhone最大的发售地了，中国的iOS开发者数量也居世界前列，苹果本身也越来越重视中国。但相比之下，苹果软件在中国的本地化仍然存在一些问题，有不少问题值得报告；中国的iOS开发者也显得太低调，无论是开发者之间的交流，还是和苹果之间的交流都很少。我想，向苹果提交bug和功能需求是一种沟通和表达自己的手段，无论是对于开发者自己，还是对提高中国在苹果软件开发生态的地位都是有帮助的。所以还等什么呢？快去提交Radar吧！~参考链接：：Daniel Pasco的博客，讲解了如何提Radar，提Radar的技巧，以及一些范例。：另一篇关于提交Radar的文章，里面提到Radar系统的一些问题，以及提交Radar的tips。：一个功能需求的Radar范例。：“Fix Radar or GTFO”的官网，已有600+开发者提交了相同的Radar。：Hacker News上对于此运动的讨论，基本上大家对于Radar系统都不满意。：请自备梯子。对Radar系统缺乏透明度，开发者自己弄的一个变通方案。：同为开发者，对“Fix Radar or GTFO”的批评。：对苹果改进Bug Reporter的报道。本文转载自：（责编/唐小引）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章 上传我的文档
 下载
 收藏
粉丝量：71
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
BUG管理和分析方法
下载积分：9000
内容提示：BUG管理和分析方法
文档格式：PDF|
浏览次数：341|
上传日期： 07:22:26|
文档星级：
全文阅读已结束，如果下载本文需要使用
 9000 积分
下载此文档
该用户还上传了这些文档
BUG管理和分析方法
关注微信公众号