1、BUG的影响
　　精神的摧残
　　谁会愿意得到垃圾团队的称号？
　　BUG有着无穷的生命力，你会很悲观，认为自己已经无能为力了，这种情绪会在长时间的工作后加重。
　　大家都厌倦重复处理相同的问题，测试人员也已经烦透了长长的BUG列表，精神压力与日俱增。
　　低生产率和低等产品质量，耗费了大量的资源。有时管理层并没有意识到发生了什么问题，为了保证项目的终交付，他们为项目输送了源源不断的新人，由于培训无法跟进，终导致了整个产品开发的崩溃。
　　形象的损失
　　如果某些公司的某些产品出现了重大BUG，势必会牵连降低公司的形象，至少我们有理由相信该公司的产品质量不稳定。
　　电子商务更能体现形象，如果网站很长时间才能响应客户服务，或者出现了丢失订单、混乱订单的现象，这样的网站会很快被客户抛弃，客户一旦离开很难回头。
　　形象的损失带来的后果是巨大的，产品不被市场所认可，甚至公司也不再被市场所认可。
　　财富的流失
　　产品的开发需要资金，公司的运转需要资金，坏的市场形象需要公司花费更多的资金来挽回声誉。
　　有BUG的软件产品后期维护也是一个大问题
　　2、BUG的产生
　　交流的误解
　　羞涩。跟客户交流的时候总是用很小的声音说明自己的观点，表现力度不够；或者静静地坐在会议室的角落，没有任何思想地观看别人的激烈讨论。
　　胆怯。项目参与人员缺乏对客户的了解，造成盲目跟从心理。交流的时候只是去听，从不敢反驳或者提出相反的意见。
　　依赖。部分项目参与人员认为交流的时候，只要有一个人做会议笔记可以了，总是找一种感情上的依托。
　　轻视。拥有专业知识的项目人员不重视客户所说的，或者认为客户所说的简直是天方夜谭，毫无科学根据。
　　健忘。自信能记住会议上所有讨论内容而不作笔记，结果在实际的设计或者开发过程中遗忘了部分要点和注意事项。
　　误解。这是人类相互之间普遍存在的一种现象。
　　大家的认知层面、各自拥有的知识、处事原则各不相同，难免会产生这种情况，可以通过相互培训及有效的交流来避免这种情况的发生。
　　软件的复杂性
　　程序员的错误
　　过于疲劳。让程序员持续地开发，疲于奔命地完成某项任务，这时候的他认为休息比编码质量有更重要的意义。
　　不守规矩。程序员按照自己心中的蓝图去描绘一个美丽的乌托邦，或者随心所欲地使用自我编码格式，完全不遵守项目的开发准则。
　　过于热心。程序员经常犯这样的错误，没有经过严格的验证和全局的考虑，任意修改设计并且认为这会产生更好的效果。
　　心不在焉。
　　需求变化
　　客户并不了解需求变化所带来的后果，算知道了他们还是会坚持这么做。并且在客户的眼里，他们只需要看到变化，却从不考虑变化所需的额外工作时间。
　　需求变化的后果可能会造成重新设计或者日程调整，已完成工作、重做或者被完全抛弃，整个项目环境可能要因此改变等。
　　频繁小的变化或者几次重大的变化，项目各部分之间已知或者未知的依赖关系会相互影响，从而导致更多问题的出现。
　　需求变化增加了项目操作的复杂性，产生了大量不确定因素，并且还可能打击参与人员的工作积极性。一个需求变化频繁的项目或者产品是没有任何测试价值的。
　　时间压力
　　时间是一种宝贵的资源。
　　所有软件项目时间都需要被精确估算。可是夹杂着预计、猜测这些不稳定的因素，当终期限迫近和关键时刻到来之际，错误也跟着出现了。
　　文档贫乏
　　贫乏或者差劲的文档使得代码维护和修改变得异常艰辛，其结果是带来许多错误。
　　区分职业实现人员的方法并不是看他有几年的编码经验，而在于其是否有良好的先文档后实现的习惯。
　　文档代表着一种特殊的记忆，没有它的存在对人对己都不利。
　　软件开发工具
　　总是希望通过更加先进的工具来避免BUG的出现，这患上了典型的银弹综合症。
　　开发工具可能使我们摆脱某些问题的出现，并且提高工作效率。实际上，现代的开发工具对整个软件质量尤其是可靠性并没有什么重大的影响。
　　3、Bug如何穿透测试
　　代价太大
　　正规的软件公司会引入QA，对项目整个过程进行全方位的质量保证工作。但是执行QA需要调用很多的资源，比如要检查和复审需求阶段输出的标准工件，需要高水平的分析员加入，但是通常他们时间很少很宝贵，并且不会有太多的精力顾及此事。
　　在设计和实现阶段，随着大量审查工作的介入，所有该阶段的参与人员都要付出更多的时间和精力来参与。
　　这些形式的检查、审查和测试延长了整个项目的开发过程，这些附加的工作时间都会直接变成附加费用，大大增加了整个项目的造价。
　　市场决策
　　即使测试人员发现了产品中的BUG，但是公司会觉得修复BUG将延长整个产品的发布时间，有可能错过销售的旺季（可能是每年的5-10月份），并且会打乱整个公司针对该产品的销售计划，在确认产品中的BUG不是非常严重的情况下，软件被销售了。但是，如果这是航天、医疗、股票交易的管控软件系统，如带有BUG，则发布后果是非常严重的，但是对于某些行业这样的做法是可行的。
　　时间紧迫
　　测试要花费大量的时间，至今尚未有一种自动化的测试工具能够全面和高效率地测试一套软件产品。
　　测试项目经理接到测试任务后表现得过于乐观，没有考虑任务的风险。
　　开发人员过高估计自己的能力，认为所有的BUG都是微不足道、便于修复的。他让测试工作和编码工作同时进行，这样根本没办法保证测试的正确性。并且在时间紧迫的时候，大多数测试员只是选择明显的几条程序路径测试或者输入不完整的测试数据，这些都造成了大量的BUG纰漏。
　　现场证据
　　有时会遇到这种问题，发现了BUG但是不知道怎么把它明显地表示出来。不能向开发人员提供足够的证据报告，是测试人员的耻辱，开发人员同样会根据这样的报告讥笑测试人员的所作所为。
　　BUG的可重现性，与导致BUG出现的原因有着密切的联系。
　　BUG的可重现性也体现了测试人员对软件系统的熟悉程度。
　　BUG的可重现性，也体现在操作的顺序上。
　　过于自信
　　开发人员是非常不诚恳的测试人员，他们总是说“我做的肯定没问题”或者“不可能呀，它在我的机器上跑得好好的”。有的时候项目管理者也很自负，过于相信团队成员的表现，而不去理会测试人员或者客户的抱怨。
　　Titanic灾难充分体现了人类的自信，我们有足够的水密舱算破了5个船也不会沉。
　　没有详细的测试计划，没有严谨的测试行为，不再关注每个细小的环节，这样BUG从旁边悄悄溜走了。
　　模糊提交
　　测试环境
　　缺少必要的测试工具和设备。在一个比较大型的网站中，系统在正常负载情况下的性能非常重要，如果测试人员没有一种有效的测试工具或者必要的硬件设备，那么很难去模拟、再现系统负载的环境。
　　缺少必要的系统配置。如果是Java开发的程序，我们可能会在多种操作系统上去验证它的正确性和稳定性。
　　缺少必要的测试用例。好的测试模型可以减少更多的BUG，也可以发现更多潜在的BUG。好的测试用例不仅仅是一系列测试方法的组合，它更大的用处在于和历史积累BUG记录的对比分析。
　　4、Bug的种类
　　需求阶段的BUG——来源：
　　模糊不清的需求
　　忽略的需求
　　冲突的需求
　　分析、设计阶段的BUG——来源：
　　忽略设计
　　混乱的设计 ：这样的情况发生在两种设计性质完全相反的情况中，如果在实际的系统中，某块地址规定不允许被多线程访问，而方案却被设计成以多线程方式进行，则会在此层面上产生BUG，严重的会造成整个系统的崩溃。
　　模糊的设计：模糊BUG产生的原因在于设计人员对需求没有清晰的认识，或者需求本身是含糊不清的。
　　实现阶段的BUG——来源：
　　遗漏的功能
　　内存溢出：属于一种比较严重的软件BUG类型。例如，软件执行了某些强行向操作系统保护地址写入数据的指令，导致整个环境的彻底崩溃；再如：数值除零导致堆栈溢出
　　其他实现：表现为出现的错误难以定位其类型，比如在产品化阶段，测试人员或者终用户提出的部分提高程序运行效率的建议，当然开发人员并不完全处理这些问题，但是这些建议将成为一种特殊的BUG类型，被保留在项目数据库中。
　　配置阶段的BUG
　　配置阶段的BUG是危险的，往往体现在软件交付或者后的系统测试中。
　　配置阶段的BUG出现的原因是复杂的，比较典型的是旧的代码覆盖了新的代码；或者测试服务器上的代码和实现人员本机新代码版本不一致。这些情况造成了错误代码被修改后，经过一个时间段再次回归测试时又会出现同样的问题。
　　配置阶段的BUG解决方案也很简单，项目组可以指定专人（集成员）进行配置和集成管理，集成员保证正确集成整个系统，并将新的代码发布到测试服务器或者客户服务器上。这个阶段由QA（质量保证）部门负责监管和控制，规定集成的时间间隔和佳集成时间，统一维护一份项目组集成人员和集成时间列表。
　　短视将来的BUG
　　很多软件BUG都是设计人员或者实现人员的眼光短浅造成的，出名的例子是“千年虫”问题。
　　其他短视的BUG例子还有我们以前的身份证号码，原来的15位的编号根本不符合一人一号的设计要求，重码的现象相当严重。所以出现了18位号码。
　　再如：中国移动开发了134号段的号码。现在又有了159号段。
　　静态文档的BUG
　　文档BUG的定义很简单，即说明模糊、描述不完整和过期的都属于文档BUG。
　　说明模糊特指无充分的信息判断如何正确地处理事情。例如设计文档中说明了对类实例方法的调用，却没说明边界条件和特殊的调用顺序。
　　描述不完整特指文档信息不足以支持用户完成某项工作。例如某套软件的某一项操作有具体的前置条件，而客户从文档上并没有获取关于该前置操作的相关信息，客户便认为软件存在着BUG。
　　过期文档本身是错的并且无法弥补，这种现象经常发生在后期对系统功能修改而没有及时更新对应的文档，造成了文档的不一致性。