最近在解Bug的时候发现自己有一种思维定势：
也就是如果这个Bug确实存在的话，那么大多数情况下也一定存在，所以很多时候没有按照文档上的步骤进行复现！
虽然大多数情况下都能复现到了，但是也有一些Bug没有复现到，那么当时我就认为复现不到了，可是当其它人员来帮我复现的时候总能很快的复现到！
其实最直接的问题是我没有按照文档上面的步骤进行操作，因为我认为如果这是一个问题，那么这个问题肯定是普遍存在的，所以我有一种这样的思维定势！
所以以后工作的过程需要改掉这个坏毛病，培养自己看待问题的敏锐度。
可以从下面几个方面进行改进：
一丶不同的环境会出现不同的问题
曾几何时很多问题在开发的环境下都不能复现，当时就拍着胸脯说这个问题不存在，肯定是他们操作失误了等等的借口。
殊不知不同的环境真的会出现不一样的问题，所以一定要有这种思想认识，就像我们每一个人都不一样，不要认为我是这样想的，别人也是这样想，如果是这样，你就错了。
二丶问题总有它存在的理由
如果当一个问题来到了你身边的时候，不管是多大的问题，第一不要慌张。
可能在很多时候有一些问题是测试人员不懂需求配错了数据引起的问题，所以要有耐心的去讲解，但过多的这样问题就需要好好跟测试人员上一堂课了。
所以任何一个问题都有它存在的理由，不管大小都要认真对待。
三丶复现问题
这是解决Bug最重要的环节了，因为如果这一步做好了，接下来解决问题就是对代码的理解程度的问题了。
所以重现问题是解决Bug的关键所在，下面是重现Bug的常见步骤：
①首先通读一下Bug文档，看看它描述的是什么(理解它在讲什么，这个很重要)
②然后按照描述的步骤进行一步一步的操作
③如果能够重现问题这个阶段就完成了
④如果不能重现，你可以先考虑一下几点：
I，是不是由于环境引起的
II，是不是由于多线程，网络等导致的死锁，断线等原因
III，是不是测试人员写的步骤不完整或者漏掉，可以直接请测试人员来帮你重现问题
四丶接着分析问题的表象，从而去联想代码
首先这个要建立在你对系统代码比较熟悉的情况下！
先不要急着调试，因为你在没有分析问题之前就急急忙忙的调试会做很多无用功！
如果系统有日志组件，首先通过看日志来查看是否有异常出现等等 → 查看日志记录是分析问题的重要手段。
五丶最后再通过调试来解决问题
如果上面的步骤都没有让你一下子定位到问题所在，那么就只能通过调试来解决问题了。
其实很多时候如果你对系统代码有足够了解的话，很多问题不要通过调试就能定位哪里出问题(通过问题的表象来分析)，
所以在以后的工作中，要慢慢培养自己看待问题的敏锐度。
作为以为程序猿，对待软件Bug要有一个专业的态度，嘿嘿！
以同步至：个人文章目录索引