1、BUG的影响
2、BUG的产生
3、Bug如何穿透测试？
4、Bug的种类
5、BUG的生命周期
6、BUG五个典型的生命过程
7、BUG关键状态关键字
8、BUG解决关键词
9、BUG的严重等级
10、BUG优先级
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灾难充分体现了人类的自信，我们有足够的水密舱即使破了五艘船也不会沉。
没有详细的测试计划，没有严格的测试行为，不再关注每一个小环节，所以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，当时间允许的时候可以考虑修复。