测试过程中如何区分什么是功能bug..获奖名单公布）（2012.11.13）
本周的问题为“测试过程中如何区分什么是功能bug，什么是需求bug，什么是设计bug？”此话题由会员wjtest提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖土土的豆豆50元移动充值卡6#
功能bug是没有达到已知需求的明确功能要求。比如:需求明确说说的功能到达的是种一棵10米高的树，而实际s实现功能种出来的树是15米高。
需求bug是在整理需求的时候，没有正确描述出用户的预期效果。比如:用户说是做一个方形的桌子出来，而在整理需求的时候，描述成了做一个圆形桌子出来，后来在完成功能的人就做了一个圆形桌子出来，但根因是由于需求本身是错误的。
设计bug是在有明确且正确的需求下，设计完成这个需求的方法或者步骤是有缺陷的，导致没有完成需求的预期效果。比如需求是盖一座房子，应该是先打地基，再建楼。但是在设计上就搞错了，导致实现需求过程的不合理，最终没有完成预期的需求 功能bug是需求明确的情况下，未达到需求所要实现的功能的bug
需求bug是整理需求时发现需求不够明确，或功能不能满足客户隐性需求等一系列关于需求的bug
设计bug是在设计功能时发现功能与需求不符，或功能存在问题等一系列bug 本帖最后由 laoxin511 于 2012-10-29 16:24 编辑
bug简单来说就是程序的漏洞，但是不同的bug归属的责任角色不同。大部分是反馈给开发的，还有一些会反馈给设计或需求人员。
功能bug是开发人员实现功能时引入的问题，它是需求明确的情况下，程序的实现需求不符，
1是功能未实现，比如登陆功能，输入用户名密码点击登录按钮，不能加载下一个环节；
2是需求的功能主体实现了，但是其他的一些地方仍然有潜在的缺陷，比如UI规范，比如容错性设计。
需求bug是需求人员提取需求时引入的问题。
1是需求人员提取的需求点与用户或客户的期望不符，比如客户想要一个公司办公楼，需求人员却定义成商业购物中心；
2需求bug还包括隐式需求不明确的情况。
设计bug是设计人员在系统设计时引入的问题。
1是在设计与需求不符，比如需求是做一个10层的办公楼，每层100间办公室，设计图出来是100层每层10间办公室；
2是设计思路有重大的缺陷，比如需求的资源和客户环境不兼容，比如系统架构本身存在缺陷
RE: 什么是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从根本上分析不属于一个维度。但是也是很基本的概念。
以上是我个人拙见，请大家补充指正。谢谢！ BUG就是软件的缺陷，功能BUG顾名思义就是系统的功能未能到达要求，所以设计BUG和需求BUG都应该归属为功能BUG，他们之前没有确切的划分界限，可以将设计BUG和需求BUG同称为功能BUG。而设计BUG 和需求BUG的区分就很明显了 上面有人说了概念了，就不多说了
不过 我认为
设计bug 应该还是属于功能bug的一类，是功能bug的一个细分
即功能bug是按照需求设计，但是体现在软件中，具体的实现上有问题
需求bug是在实现上偏离了用户的实际需求 所有不能满足用户需求的问题，就是BUG 软件缺陷是存在于软件之中（文档、数据、程序）的那些不希望或不可接受的偏差，是开发的软件与软件需求说明书、设计说明书的不一致，软件的实现未能满足应达到目标的用户潜在需求。bug的产生有很多原因，比如交流有问题、软件太过于复杂、程序员的错误、需求变化、时间的压力、文档贫乏等等，这种种原因就导致对应的bug种类也有很多种，比如需求的bug、设计阶段的bug、功能bug、配置bug、性能bug、静态文档bug等等。
1. 需求bug：比如需求本身模糊不清、需求被有意或无意的忽略、需求本身有冲突等
应对策略：对需求进行仔细分析，剔除模糊不清的需求和本身有冲突的需求，最后产生详细的需求分析说明书，并和用户确认，直到需求分析说明书通过，并作为开发人员开发的依据
2. 设计bug：比如设计过程中忽略了某些部分、设计混乱（比如在实际的系统中，某块地址规定不允许被多线程访问，而方案却被设计成以多线程方式进行，则会在此层面上产生bug，严重的会造成整个系统的崩溃）、设计模棱两可（产生的原因在于设计人员对需求没有清晰的认识，或者需求本身就是含糊不清的）等
应对策略：仔细分析需求，成立委员会进行设计评审
3.功能bug：比如GUI错误（在界面描述中，“Login”代表着进入系统，“Exit”代表着放弃登录系统，如果“Exit”表现为清楚输入框“User ID”、“User Name”中的数据，那么就是bug）、功能欠缺（比如系统应该支持Excel格式的数据导入，但是在实际应用中出现了“Data Import Error”，那么就是功能欠缺bug，这种bug产生的很大原因是由于实现人员马虎或者匆忙赶工造成的）、内存溢出bug（属于一种比较严重的软件bug类型，例如软件执行了某些强行向操作系统保护地址写入数据的指令，导致整个环境的彻底崩溃，或者数值除零导致堆栈溢出）、其他难以定位或建议性的bug（这些建议作为一种特殊类型的bug被保留在数据库中）等
需求说明书是软件缺陷的罪魁祸首，说明书编写的不全面、不完整和不准确，而且经常更改，或者整个开发组没有很好地沟通和理解，都会导致需求bug的产生；设计bug是缺陷的第二大bug，设计方案是程序员开展软件计划和构架的地方，片面、多变、理解与沟通不足都会导致设计bug的产生；如果按照严重度划分，3中bug种类中，需求bug和设计bug是致命的，功能bug是严重的。 小的,路过 看看!! {:4_91:} 需求：跟用户要求不一致
设计：跟需求不一致
功能：跟需求不一致，实现不了设计的功能 如何区分需求Bug、设计Bug、功能Bug？
首先什么是需求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：开发、测试工程师 本帖最后由 rolei 于 2012-11-1 16:41 编辑
“什么是功能bug，什么是需求bug，什么是设计bug”
--质量是要靠整个团队的责任。分析BUG的出处是为了防微杜渐，切不可拿做他用，更不可以此来推卸责任。
测试发现的问题都可以称之为BUG，但关于“XX的BUG”是否可以换个方法来区别：BUG来源，也就是bug's root source。因此可以由此对BUG的来源进行归类。
（往往产生的问题总是由于需求描述不清造成的，不能简单的把BUG归咎于需求，更多的应当考虑在对需求评审的过程中，设计、开发、测试是否对产生的BUG需求描述给予了足够多的重视或疑问。）
个人理解：
系统实现的表现是功能操作的展现，落脚点是需求的符合度，而系统实现复杂度和效率则由设计决定。
１）需求是对系统实现目标以及系统功能的描述（需求人员）；
２）设计是对系统实现方法、层次、效果的描述（设计人员）；
３）功能是对系统需求、设计的实现展现（开发人员）；
从测试角度看，对待测系统的测试步骤一般可采用：
１）是否可以运行；
２）系统运行是否能够完成目标操作流程；
３）已完成流程是否符合需求的描述；
即：是否可用-->是否可操作-->是否合规，需求、设计、功能则是由提出者、设计者、实现者来分别完成，最终的验证的标准来源于需求。
正如盖房子，如果需求要求只是盖房子，设计人员就来个二层小楼，施工人员依此施工。
如果盖出来的房子是个危房，当然是房子本身的问题，也就是功能问题，由施工人员负责；
如果盖出来的房子不符合常规的房子构造，不适合人居住，当然是设计问题。
如果要求盖出来的是个平房，而结果是个二层小楼，又是什么样的问题？需求、设计，还是功能？ 来学习的 根据我自身的理解，功能上的BUG是未实现需求中要求的功能；需求BUG是需求中要求的功能相互冲突，或是不符合正常逻辑；设计BUG是指各种设计都完成后，在具体实现设计的过程中，发现设计的内容，逻辑不严密，有漏洞，或是有重复，导致系统不严谨。如在数据库设计好后，程序员编码过程中，发现需要某个字段来实现某个判断，而数据库表中无该字段时，这就是数据库设计缺陷的一种； BUG的定义：
1.需求没提，功能有开发。-----需求BUG
2.需求提了，功能未开发。-----功能BUG
3.需求提了，功能开发有误。----设计BUG
4.需求提了，功能开发正确了，但效率、易用性差。 ----设计BUG 需求bug：在明确需求范围时引入的问题: 需求中的各需求要求相互矛盾/需求描述的功能不符合实际要求/需求未描述但应该有的功能/调研不清楚与外部系统接口要求不一致等
设计bug：在设计实现功能的方式时由于设计不利引入的问题。比如应该用number型的用了字符型/本来应该分为2个页面的功能在一个页面实现了/对功能的输入理解不清晰，再设计阶段遗漏了逻辑
功能bug：上面说的主要是bug的来源，而功能bug是bug的类型。以上2种bug都有可能是功能bug 需求BUG：需求文档没有说明，但此功能客户有需求，开发方面（已开发或未开发）；
开发BUG：需求文档正确的情况下，开发方面未开发；
功能BUG：需求文档正确的情况下，开发已完成的状态下，功能未达到需求文档的要求；
