bug像是一个被过分宠爱的小孩子，得到了特别多的关注。它们在开发者的IDE里悄然无声的诞生，但在现身之刻却引来一片喧闹"——bug的一生
Bug的出生证明
1945年9月9日，下午三点。哈珀中尉正领着她的小组构造一个称为"马克二型"的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。
突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布贴到"事件记录本"中，并注明"第一个发现虫子的实例。"
从此以后，人们将计算机错误戏称为虫子（bug）
软件测试中bug的生命周期
对于测试人员来说，bug的生命周期一般分为：发现bug—>提交bug—>验证bug，那在这三个阶段中如何体现测试的专业度呢？
第一阶段：发现bug
1、充分利用80/20法则
80/20法则，又称为，马特莱法则、二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则。
80/20法则揭示了80%的成果源自仅仅20%的行动，体现了投入与产出不平衡的"普遍真理"。
一般情况下，80/20法则适用于以下软件测试情景：
80%的软件缺陷存在于20%的软件代码中（软件缺陷的"群集"现象）
80%的软件缺陷归因于20%的软件缺陷原因（软件缺陷的"群集"现象）
在分析、设计、实现阶段的复审和测试工作只能够发现和避免80%的软件缺陷，而系统测试也只能找出其余Bug中的80%。
2、跟开发人员有效沟通
跟开发人员有效沟通，既可以沟通个人之间的友情，还可以获得开发相关的知识，更可以得到有益于软件测试的信息。
3、从不同角度进行测试
从管理层的角度考虑，我们要了解被测产品在公司众多产品中的优先级，做到软件测试的有效性，即确保软件缺陷的有效性。
从开发人员的角度考虑，获知开发人员认为软件产品中那些模块开发难度大，缺乏信心，从而快速定位我们的测试重点。
从最终客户的角度考虑，尽可能从他们的既有的使用习惯和可能的问题出发，也就是用户体验出发，找出尽可能多的软件缺陷。
4、选择简易有效的测试工具
比如，网页的链接测试，如果选择一些简单易用的链接测试工具，既能提高覆盖率，又能发现较多的软件缺陷。
5、进行专项测试
比如，安装测试，卸载测试，双（多）字节测试，查询测试，上传附件测试，快捷键测试，UI整体风格测试（包括按钮、成功信息、警告信息）等等。
6、参照单元测试结果
可以帮我们定位软件测试重点，做到花费较少的时间，找出较多的软件缺陷。
7、参照其他测试人员报告的软件缺陷
每个人的思维都是有局限性的，我们可以参照其他测试人员报告的软件缺陷，获取新的测试思路，从而发现以前未曾发现的软件缺陷。
8、错误推测法
对于有一定软件测试经验的人来说，是一个短时间内发现较多软件缺陷见效较快的方法，体现了经验的价值。
第二阶段：提交bug
1. 确保bug有效。
提交的Bug必须是有效的，就要求我们在提交Bug时，确认：①交付过程中测试者需按照设定好的模块，对Bug进行归类提交；②Bug的类型默认为UI问题、功能问题、崩溃问题，提交Bug时不能弄错；③需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性；④避免提交设计如此、操作错误、重复的、已知的Bug；⑤尽量少花时间在边界值、页面显示问题上，多提业务逻辑功能、交互测试方面的问题。
2. 写好bug描述。
1）bug描述精确、没有歧义，详细简洁的测试步骤。
2）保证各个字段内容与实际现象一致。比如：版本、复现率等
3）对于复现率低的问题，尽可能提供一些可参考信息：截图、视频、日志、可能的步骤、可能原因等（如果你能通过各种手段定位到问题的原因，开发大神也会对你刮目相看的）
4）对于特殊的测试场景，附带相关的数据，比如1024kb的图片等
第三阶段：验证bug
1. 确认好bug的复现前提及操作步骤。
2. 确认bug产生的原因及修复方法。
1） 明确bug产生的原因，触类旁通，分析其他模块可能存在的问题
2 ) 通过bug产生的原因，积累测试经验，扩展测试思路
3） 通过bug的修改方法，分析修改是否能修复问题？是否回引发其他问题？
4） 积累bug经验，在后续相关问题发现时，快速定位问题，提供解决思路
3. 确认bug的回归范围及用例。
在了解清楚bug产生的原因及修复方法基础上，再根据业务关联、功能模块关联确认回归范围，确保bug修复全面且没有引起新的bug。
总结：
bug千奇百怪，不是每个bug都需要经历所有流程的。每个步骤都有它的难点。 有些bug难在事发点的定位，比如多线程，异步逻辑中的bug； 有些bug难在原因很难分析，多数是你看不懂代码； 有些bug难在你不敢改，那是你的修改方案没有做好充分的分析。