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。
　　过期文档本身就是错的并且无法弥补，这种现象经常发生在后期对系统功能修改而没有及时更新对应的文档，造成了文档的不一致性。
        5、BUG的生命周期
　　BUG初始状态（Unconfirmed&New态）
　　BUG分配状态（Assigned态）
　　BUG重新分配状态（Reassigned态）
　　BUG修复状态（Resolved&Fixed态）
　　BUG验证状态（Vertified&Fixed态）
　　BUG重新打开状态（Reopen态）
　　BUG关闭状态（Closed&Fixed态）
　　6、BUG生命历程的5种典型过程
　　（1）BUGStart--> BUG初始状态 -->BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG关闭状态
　　测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告
　　进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确
　　认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整个生命周期终结了
　　（2）BUGStart--> BUG修复状态 --> BUG验证状态 -->BUG关闭状态
　　回归测试后，如果部分登记BUG再次出现，测试人员可直接将已登记的Closed&Fixed状态的BUG转入修复流程，等实现人员修复BUG后将该BUG置为
　　Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整
　　个生命周期终结了
　　（3）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态
　　测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告
　　进行BUG确认，确认失败后该BUG状态被置为Reassigned状态并发送回BUG起始阶段
　　（4）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG重新打开状态
　　测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告
　　进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态，但是实现人员发现该BUG与其他实现人员
　　的BUG有关联关系，可能导致本次修复无效，所以实现人员将该BUG置为Reopen状态发送回BUG起始阶段
　　（5）BUGStart--> BUG初始状态 --> BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG重新打开状态
　　人员接到该BUG通告进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。测试人员对实现人员
　　修复后的BUG进行确认测试，验证成功后测试人员怀疑该BUG并非真正修复，将该BUG置为Reopen状态发送回BUG起始阶段
　　7、BUG的流转状态关键字
　　未确定的（Unconfirmed）。这个BUG最近才被发现，还没有人确认它是否真的存在，如果有别的测试人员碰到了同样的问题，就可以将这个Bug标志为New，或者将这个Bug删除，或者做上closed标记。
　　新加入的（New）。这个BUG最近被测试人员添加到Bug列表中，已经被证实存在且必须修改的。即将被分配，如果分配了可以标志为Assigned，未分配则将保留New标志，或者做上Resolved标记。
　　确认分配的（Assigned）。测试人员将BUG的修复任务分配给具体的实现人员，如果BUG不属于被分配实现人员的范围，可置为Reassigned，等待被重新指定相关修改人员。
　　重新分配的（Reassigned）。该BUG不属于被分配实现人员的范围，可置为 Reassigned等待被重新指定相关修改人员。
　　需要帮助的（Needinfo）。测试人员或实现人员无法对发现的BUG进行精确定位或描述，需要相关实现人员协助，以更深刻地认识和修复这个Bug。
　　重复出现的（Reopened）。该BUG已经不是第一次被发现，它可以被标志为Assigned或者Resolved。
　　已解决的（Resolved）。实现人员对被分配给自己的BUG进行修改，修改完以后，修改状态。
　　重新启用的（Reopen）。当实现人员发现某些BUG具有关联性，即使该BUG被正确修复了，也会被发送到起始状态等待回归再次确认。或测试人员发现该BUG没有被真正修改后，重置状态。
　　正在验证的（Verified）。测试人员对标记为Resolved状态的BUG进行验证。
　　安全关闭的（Closed）。该BUG已经被完全解决。
　　8、BUG的解决关键字
　　已经修复（Fixed），该BUG被正确修复了，并且得到了测试人员的确认。
　　无法修复（Wontfix），发现的BUG永远不会被修复，或者该BUG牵涉面太广需要委员会决定。
　　下版本解决（Later），发现的BUG不会在产品的这个版本中解决，将在下一个版本中被修复。
　　无法确定（Remind），发现的BUG可能不会在产品的这个版本中解决，也可能会。
　　重复的（Duplicate），发现的BUG是一个已存在BUG的复件。
　　无法证实（Incomplete），用了所有的方法都不能再现这个BUG，没有更多的线索来证实这BUG的存在，即使看程序源代码也无法确认这个Bug的出现。
　　测试错误（NotaBUG），BUG报告出现了错误，将正确的软件过程报告成BUG了。
　　无效的（Invalid），描述的问题不是BUG，属于测试人员输入错误，通过此项来取消。
　　问题归档（Worksforme），所有要重现这个BUG的企图都是无效的，如果该BUG有更多的信息出现，则重新分配这个BUG，而现在只把它列入问题归档。
　　9、BUG的严重等级
　　危急的（Critical)，能使不相关的系统内软件（或整个系统）损坏，或造成严重的信息遗失，或为安装该软件包的系统引入安全漏洞。
　　重大的（Grave)，使该软件包无法或几乎不可用，或造成数据遗失，或引入一个允许侵入此软件包用户之帐号的安全漏洞。
　　严重的（Serious)，该软件包违反了“必须”或“必要”的规定，或者是软件包维护人员和测试人员认为该软件包已不适合发布。
　　锁定的（Blocker)，这个Bug阻碍了后面的操作，需要马上或者尽快排除。
　　重要的（Important)，该错误影响了软件包可用性，但不至造成所有人都不可用。
　　常规的（Normal)，为默认，适用于大部份的错误。
　　轻微的（Minor)，该错误不致影响软件包的使用，而且应该很容易解决。
　　微不足道的（Trivial)，该错误无关紧要，多指外观GUI上的字符拼写错误，不影响整个项目。
　　10、BUG处理的优先等级
　　立刻修复（Immediate），这个BUG已经阻碍了开发工作或者测试工作，需要立刻修改。
　　马上修复（Urgent），这个BUG阻碍了软件的一部分应用，如果不修复它将妨碍下面计划的实施。
　　尽快修复（High），真实存在的并不是很严重，在版本发布之前修复。
　　正常修复（Normal），有充足的时间来修复这个问题，并且这个BUG给现行的系统的影响不大。
　　考虑修复（Low），不是什么关键BUG，当时间允许的时候可以考虑修复。