我最近发现很多成员都会经常卡在一些小问题上，一旦问道原因，回答基本都是“很奇怪”、“找不到原因”之类的。有些问题经常换个思路清晰的人很快就弄完了，这就不得不说说解决问题的思路。

  这里就说说黑盒的测试，代码写完了，一运行就出个莫名其妙的错误，看代码本身看不出来任何问题。这个时候有人就开始瞎猜测，甚至说这台电脑有问题，或者就是漫无目的的瞎尝试，弄了半天也没啥结论。这样显然对解决问题没有太大帮助，就是蒙对了，你不知道原因对自己提高也没有任何帮助。最怕的就是以为弄对了，其实问题压根没解决彻底。到底怎么解决问题才算合理？

  首先，观察现象，如果能通过固定的办法让问题稳定重现，那样才能针对问题进行测试。如果很难重现的问题，那要多想想是不是由于某个特定的输入、或者运行到一定的时间、或者多线程并发等不稳定因素下才会有的。不能稳定重现的问题解决起来也将非常困难，重现问题是能快速解决问题的关键一步。

  其次，由于问题出的让人摸不到头脑，那么先缩小出错的范围。整个工程运行一次，你要弄半天操作才能让那个问题重现，那么我们能不能把这个代码抽出来，单独写个足够简单的小程序试试，或者我们就针对这个代码写个单元测试。然后不断删减无关代码或者单元测试精确到更具体的方法来缩小范围。这至少让出错的问题就定位在这一小块代码中了，这样才能确保你后面在尝试解决方案的时候针对的问题是真正出现问题的地方。

  再次，既然知道错在哪了，就要检查是为什么错了。具体查错的办法就很多了。1. 最简单的就是找一个同样足够简单的demo代码比一下，找出不一样的地方，看看是不是哪里考虑有疏漏。2. 最好的办法就是搞清楚原理，如果使用开源框架，那一定要看下源码到底是怎么走的，那也能很快找到问题。3. 当然上网去搜也是个不错的办法，我这里有个经验就是如果网上根本找不到提相同问题的人，那你这个问题极有可能是sb问题，仔细看看自己是不是犯了低级错误。4. 还有一个比较常用的办法就是试错，对问题的原因给予假设，不断去验证想法，最后得出一个自己的结论，这个结论在大多数情况下都可以帮助你解决问题，但你千万别自己骗自己，至少拿你的结论出来说能让别人信服。

  最后奉劝一句，千万在测试的时候不要随意编写测试代码，不要以为一会注释一句为方便代码编写就能更快解决问题，一旦你写的测试反复几次没解决问题，经常会因为你代码本身的混乱让自己思路更不清晰，甚至会因为改来改去一没注意把测试代码写错而找不到问题。

  总的来说，就是要先重现问题，再缩小范围，最后针对现象理清思路重点排查。让奇怪的问题变的不奇怪，定位出原因才能真正解决。