我将bug依据复现的难易程度分为：必现的bug，比较容易复现的bug，很难复现的bug。
对于必现的bug，我通常淡定地称为其不是bug，因为，通过不断地复现，不断地调试，这些bug通常都能被解决，被解决了，还是bug么？
对于比较容易复现的bug，所谓比较容易复现，就是通过不太复杂操作，尝试几次、十几次，现象就可出现的bug，因为复现操作变得复杂，所以，为了每次复现能够获得更多的信息，尽量多地增加调试信息，以期望问题复现后，极大地缩小问题原因的范围。毕竟复现问题是一件颇为繁琐、枯燥的事情。
对于很难复现的bug，所谓很难复现，就是尝试了各种复现方法，复现了几十次，甚至上百次都无法复现的bug。首先，分析造成那个bug的所有可能的原因，然后尽量针对每个可能的原因，增加对应的调试信息记录，以期望在复现过程中，一旦出现，就能定位问题，不过做到这一点其实是很难的，但是做总比不做强。在第一家公司的时候，我们曾经在交付客户使用的产品中，增加了bug追踪信息记录，以期望找到在测试过程中发现的一个仅出现过一次的bug。
在产品设计和开发过程中，对于异常的处理和保护是保证产品可靠性和可用性的关键，下面说说自己关于这些的一些想法：
- 对异常进行危险等级分类，对于不同的等级采取不同的办法；所采取的办法通常包括：
- 给用户以提示，但是不执行用户的错误操作，譬如用户输入的参数超出了允许范围等，参数的格式不满足要求等；
- 软件的一部分功能崩溃，要尽量不影响其他部分，譬如上位机软件崩溃，不能影响下位机设备的正常运行；前端界面的崩溃，不能污染数据库；
- 自动应急处理，譬如提供冗余设备，当一套设备故障，备用设备立即启用；提供看门狗功能，设备故障后，尽快重新启动，并且从硬存储中恢复距离事故最近的状态；
- 给用户提供应急措施，譬如对于可能造成人体伤害的设备，都需要提供一个紧急停止按钮，该按钮的标示还要非常醒目；
- 通过用户的操作日志，确认用户是否存在非法操作，以确认事故的责任；
- 错误追踪信息，一方面可以帮助工程师分析产品发生异常的原因，一方面可以帮助产品开发者分析产品使用过程中可能存在的问题，以帮助进一步改进产品；
无论是产品开发过程中，还是产品使用过程中日志记录和错误追踪功能都非常重要，关于这两个功能，简单总结一下自己的经验：
- 如果是桌面程序，可以将日志记录和错误追踪作为文本文件保存在硬盘上；
- 如果是嵌入式程序，则可以将日志以编码的方式记录在非易失的存储介质中（非易失的要求是保证当设备掉电或者重启，以保证日志不会丢失；另外，对该介质的访问速度有一定要求，不能太慢了，否则会影响设备的性能），然后通过网络或者其他方式将这些编码读出、解析；
- 在保证系统性能的基础上，日志信息能加多少，就加多少；（当遇到问题时，你会非常庆幸自己有一份非常详细的日志在手，呵呵）
- 日志需要必须包含两个要素：时间、做了什么；尽量包含以下要素：操作是否成功、失败的原因；
- 尽量避免日志的循环往复记录，譬如系统循环往复地发生一种错误，如果每发生一次错误，就记录一条，那么有限的日志记录空间就只有这一条日志了，留给工程师分析问题的信息就太少了，可以采取这样一种方式：错误发生时记录一条，错误消失时再记录一条，以此，就可以确认错误持续的时间，而且也不会覆盖掉其他的日志信息；