问题描述：
　　过程中如何区分什么是功能，什么是需求bug，什么是设计bug？
　　精彩答案：
　　会员 土土的豆豆：
　　本期问题其实主要是针对不同方面或纬度上对于bug的一个归类和定位。
　　个人认为，从测试生命周期上分析的话，三者从开发测试阶段应该是需求bug、设计bug、功能bug。（这里仅针对提问排比）
　　需求问题可以包括设计问题和功能问题，当然还有非功能性缺陷等。
　　需求bug，简而言之就是对于业务需求不清晰或者理解有偏差产生的问题。可能包括业务分析人员不专业因素、开发与测试人员思维不一致、产品未满足客户实际需求（想法）等一系列bug。
　　功能问题大部分理应该是附属于需求说明书上的功能模块，因为开发、设计、实现等原因故而产生功能bug。但也不仅限于需求上列举出的功能，因为一个项目/产品，完全有可能因为相关协作的功能模块或整合的第三方程序导致产生bug。所以功能bug既可能是需求bug，也可能是需求外的bug。这里对于bug的优先级和安全级别等不作赘述。
　　设计问题可以认为是开发架构师/人员在项目设计编码前遗留的&历史&问题。因为设计bug还是根据需求说明书来进行开发设计，故而一些业务逻辑上的关系、代码算法的优化、数据库/表的关联等都属于设计bug。
　　个人认为，需求bug最为麻烦，也是后期维护成本最高的bug。设计bug次之，因为一个产品/项目设计层面问题较多的话，无论修复或改进多少，在代码编写结束后，开发人员很难重头再整理一套框架，即便目前没有设计bug，以后产生的风险也是很大的。
　　功能bug最平凡，但是也是基础。除去客户业务需求上的变更因素，整个项目/产品的质量好坏最基本的就是取决于功能是否按需求进行了实现，其问题是否很多。我们大部分测试阶段的bug以功能问题为主。
　　当然还有其他一些bug类型，本期问题所列3个bug从根本上分析不属于一个维度。但是也是很基本的概念。
　　以上是我个人拙见，请大家补充指正。谢谢！
　　会员 TesterChen：
　　首先什么是需求Bug、设计Bug、功能bug？
　　需求Bug，指由于客户需求描述不清晰或错误、需求收集人员自身原因及需求本身模糊难于分析、获取等原因，导致客户需求获取不准确，后期产品不能满足客户、用户的要求
　　设计Bug，是指产品在最初设计时由于未考虑全面，而使产品在使用中存在的一些潜在的缺陷。
　　功能Bug，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
　　建议从以下几点进行区分：
　　1、产生的时间不相同：　　需求Bug：产生于项目前期　　设计Bug：产生于项目前期或中期　　功能Bug：产生于项目中期或后期
　　2、产生的原因不相同：　　需求Bug：客户需求描述不清晰或错误、需求收集人员不够专业、需求本身模糊难于分析、获取等原因　　设计Bug：系统框架、通讯模式、库表设计、编写语言等选择不当，导致后期扩展棘手、安全性低等　　功能Bug：开发工程师需求理解错误、代码编写缺陷等原因
　　3、造成的影响不相同：　　需求Bug：对整个项目的影响极大，会直接拖后项目的进度、加大项目成本、降低客户对公司的评价　　设计Bug：后期功能扩展、性能、安全性等可能会遭到威胁　　功能Bug：影响用户使用体验、影响数据、资金安全
　　4、处理方式不相同　　需求Bug：重新收集需求，重新设计和开发（需求Bug是对项目成本和进度影响最大的因素）　　设计Bug：重大缺陷必须修复，小设计缺陷在下一次发布时更新（一般难于修复或修复成本较大）　　功能Bug：直接修复缺陷，重新发布或更新
　　5、Bug的直接责任人不相同　　需求Bug：业务人员、需求专员、项目经理等　　设计Bug：架构工程师、工程师、技术经理、项目经理等　　功能Bug：开发、测试工程师
　　原帖地址：
版权声明：本文由会员土土的豆豆、TesterChen首发于51Testing软件测试论坛每周一问活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
阅读(...) 评论()我现在的工作是问题分析处理（出现bug或者疑难的问题），但是我想进一步成为软件需求分析师..._百度知道
我现在的工作是问题分析处理（出现bug或者疑难的问题），但是我想进一步成为软件需求分析师...
xure和visio等工具都可以用，现在不知道学习的方向，求解答，拜谢，我还需要做什么才能每天都能提高自己，orcale数据库也很熟悉
我有更好的答案
想成为需求分析师就多和客户接触，尤其是你所处行业的业务流程，专业定义等内容。所有BUG都是系统出的，系统是根据设计做的，设计是根据需求做的，往后逆推，你应该从发现BUG找到需求上存在的问题，然后分析。慢慢就OK了
采纳率：36%
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。注册 | 登录
互联网金融行业，市场运营人，少点儿品味
专为互联网人打造的365天成长计划，500门视频课程随便看，构建你的产品、运营知识体系。
自从我干上软件开发这一行，并且使用了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赞已赞 | 0
互联网金融行业，市场运营人，少点儿品味
产品经理群运营交流群营销交流群
文案交流群
Axure交流群
区块链学习群
关注微信公众号
27个回答31人关注
18个回答22人关注
16个回答28人关注
12个回答15人关注
19个回答57人关注
10个回答22人关注那不是Bug，是新需求 - 文章 - 伯乐在线
& 那不是Bug，是新需求
自从我干上软件开发这一行，并且使用了Bug跟踪系统，我们在每一个项目里都会纠结一个基本的问题：你怎么能把Bug与功能需求区分开来？
当然，如果程序崩溃了，这毫无疑问是Bug。不过，那也许只占你每天所处理问题的10%。为了避免项目的彻底失败，真正的杀手级Bug——有它存在就不能发版的Bug——会很快被消灭。而在Bug跟踪系统里留下来的绝大部分Bug，就落入了没人管的灰色地带。用户报告的是Bug吗？不完全是。用户在要求一个新功能或完善某个既有功能吗？也不完全是。好吧，那到底是什么？
这是一个令人犯难的问题。进一步说，我认为大部分Bug跟踪系统都在“坑”我们，因为它们让我们非要回答这种无聊问题，逼着我们站队——要么海菲茨，要么麦考伊斯；要么可口可乐，要么百事可乐；要么是Bug，要么是功能需求——这是一个痛苦的抉择，选择哪一方均在一念之差，因为大部分时候两者皆可。从用户的角度看，Bug和功能需求是没有区别的。如果你想用一个软件（或者网站）做某件事情，但因为某个功能没有实现而无法完成；相比于你在使用过程中因为出错而不得不停下来，两者之间有区别吗？
译者注：美剧《Hatfields & McCoys》，又名《血仇》，聚焦于美国声名狼藉的两个家族（Hatfields和McCoys）之争。两大家族的争执源自于美国南北战争时期，Anse Hatfield和Randall McCoy本是要好的哥们儿，但不想后来生变，二人结下仇怨，甚至引得弗吉尼亚州和肯塔基州都不安宁。由此，这两大家族联手制造了美国史上最臭名昭著的血腥争端。
我们来看一个例子：在开发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，还是功能需求？
我很喜欢用（采用的就是这个工具），它最让我心动的一点是，它故意模糊了Bug与功能需求之间的界线。不管怎么说，用户搞不明白它们之间的区别；更糟糕的是，程序员可能会据以搪塞用户。他们把不想做的事情归类为“功能需求”，从此以后就置之不理了。他们会据理力争，嚷嚷着说某个被报告为“Bug”的问题显然不是Bug，自然也就不必修复了。罢了吧，别再区分Bug和功能需求了，让它们都见鬼去吧！
我希望，我们全行业都能少花点时间在概念的口舌之争上，别再煞费苦心地把用户反馈区分成“Bug”或是“功能需求”。面对用户反馈，我们应该多花点时间做一些有建设性的事情。
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2018 伯乐在线}