* 收集“现场数据”
BUG是表象，我们要发现内部原因还是需要更多的表象数据去推理。我们需要收集到足够的“现场数据”。比较初级的、基本的、也是被大家常用的方法就加print语句，将BUG现场周围的“证据”输出到屏幕上或者文件中，这样你能更直观的看到;当然我这里是不推荐Print语句的，因为不够专业、不够高效;拿起你的源代码调试工具，诸如GDB来完成这一功能吧;有时候现场数据可以通过你的程序运行日志而直接得到这样就更简单了，调试阶段这种日志要保持尽量详细且必要;如果是运行在客户现场的程序，你无法添加Print，也无法GDB调试，那么你需要在测试环境下重现BUG表象，然后再利用工具收集数据。重现BUG表象多数情况较容易，但是也不乏找不到重现条件的时候;这时候你就只能根据已有的运行日志等通过“顺藤摸瓜”的业务逻辑分析去“猜测”可能的重现步骤，逐一尝试，做好尝试记录，隔一段时间对记录进行分析，找出一些“蛛丝马迹”，也许会帮助你节省些时间。
* 定位问题所在
有了“现场数据”，需要你用“火眼金睛”从这一堆数据中找出你真正需要的;如果无法直接识别出真数据，那么可以根据数据做几组不同数据组合的模拟测试，在数据变化中“去伪存真”，找到那个“真悟空”。有了信赖的真实数据，你一般都可以根据代码逻辑推理出问题所在。但有些时候还是需要通过隔离代码、缩小嫌疑代码范围等方法才能锁定一些较难BUG的具体问题所在。
* Fix and Test
既然找到问题所在了，那剩下的工作就是修正它并重现验证;新用例同时也补充了你的单元测试用例库。如果修正失败，那就从头开始新一轮分析过程吧。
BUG真的是种类繁多，情况多样。 上面也仅仅是一些常见BUG解决过程的体会。如果你已经在一个BUG上整整消耗了一天时间了，那么建议你休息一会儿，小憩一会儿，甚至是睡一觉到天亮。也许梦中你会发现问题所在。要知道大脑潜意识是会帮助我们的，估计很多人都有过类似经历，不是吗?
定期回顾你自己“出产”的BUG列表，你会发现很多BUG是你在预防阶段做的不够好而导致的，特别是一些涉及内存操作的BUG，如果前期预防工作没有做好的话，那么后期解决BUG花费的精力会很多;定期回顾还有一个好处就是强化你的思维意识，让你以后尽量不再犯同一个错误。
文章来源于领测软件测试网 https://www.ltesting.net/
