通过寻找bug来推动软件质量的提高，是软件测试的基本目的。而通过何种思考方式去寻找bug，则是测试工程师在日常工作中所需要关注的重点。

　　在测试中目前有逆向思考、组合思考、发散思考、比较思考等，而其中的逆向思考和发散性思考则是我们需要重点去关注的，以下就是这两种思考的定义。

　　逆向思考

　　在业界，有这么一个比喻，开发是盖房子的，测试是拆房子的，其实这种看法或许存在某种偏见。实际上开发、测试大家的目标其实是一致的，都是为设计出满足用户需求的高质量软件。只是由于分工不同造成了开发和测试因为工作性质而造成了天生的对立，开发是将需求实现出来，而测试是验证开发的实现是否满足需求，这种验证就是带着一种怀疑的眼光和不信任的心态，这其实就是造成了我们在测试工作上要与开发不一样的逆向思考。而且事实证明，这种思考越强烈发现bug的问题就越多。

　　测试的目的是发现bug，说明程序有错，要证明程序有错就要有说服力的数据，而这些有说服力的数据就是bug。如果我们在设计测试用例的时候仅从正向思考去出发，设计的测试用例自然而然就是正向的，这其实与开发进行设计实现走的是同样的路，即验证程序是按需求实现了，能够达到预期，但是实现的功能有没有问题，不得而知。

　　逆向思考的方法，其实就是走不寻常之路，这也是开发人员常常忽视的地方。大家都在走同样的路，我却往反方向走，用与正向思考相反的思考方式设计用例，发现新bug。这是一种历练，也是历练中的摸索、创新。通过这种不同寻常的历练，经常能够帮助我们总结出适合自己的方法，自己也能得以提高。

　　发散性思考

　　发散性思考其实就是一种寻求多种答案，最终使问题获得解决的思考方法。因为其眼光开阔，思维活跃，所以能产生大量独特的新思想。

　　概括来说，发散性思考在测试工作中可以分为以下两个阶段来体现：

　　1、测试设计阶段的发散

　　可以理解为测试方案，即测试思路的形成阶段。以下为说明例子：

　　某嵌入式软件有用U盘导出数据的功能，请写出测试此功能的思路。

　　2、用例执行阶段的发散

　　我们都知道，用例执行时必须严格按照已经设计好的用例来执行，其实在实际工作中，软件测试不能进行穷举测试，用例对代码的覆盖率不能够做到100%，尤其是一些组合的用例，更难去覆盖全面。根据这一特点，我们在进行用例执行完成后，都会进行随机测试，其实这就是发散性测试。就是说我们在进行测试时，可以不用按照已规定的流程去走，而是可以跳过某个步骤提前去结束，其结果往往就能发现问题。随机测试就是跳出已知的步骤，可以来回反反复复进行操作，这种过程，本身就是另外一种用例设计的过程。

　　除了发散，我们还需要严谨，不能无边无限的去发散，就像一匹野马，如果控制不住，就会弄巧成拙。