3.4 优先怀疑曾经有“前科”的模块和开发人员

　　如果有些模块，以前曾经出过问题，那么以后如果再有类似问题，应该优先怀疑这些曾经出过问题的模块。

　　某个地方除了问题，往往是因为代码写的不太合理。当某个问题修改过之后，有时候又会造成新的问题，所以说某些模块曾经出过某个问题，那么如果以后又有模块出现类似的问题，完全可以怀疑类似这些模块和模块的开发人员。

　　一般在开发的时候，有时候会互相拷贝代码，如果正好这段代码有问题，那么软件的缺陷就会扩散出去。所以可能某个问题在这个模块中解决了，但在别的模块中仍然可能存在，所以说遇到某个问题以前曾经发生过，是应该去找曾经解决过这个问题的开发人员的。

　　3.5 推测开发人员的行为

　　在第二章里面，有模拟用户行为的测试方法，用来发现问题。在本小节里面，使用推测开发人员行为的方法，来发现一些隐藏的比较深的BUG。

　　技术上的很多行为，归根到底其实也并没有什么大不了的算法。而绝大多数的BUG，根源也不在某些具体算法上，而在于一些逻辑的错误。在开发中，很多设计思想，都可以用一些很简单，很通俗的语言来描述。测试人员在测试的时候，完全可以设想一下假设自己是开发人员，会如何来完成这个功能？其实同一件事情，大多数人使用的方法是相同的，并没有什么特别先进或者落后的方法。因此测试人员可以想一下这些问题：如果我是开发这个功能的人，我会怎么做？我会用什么方法来完成？我会注意什么细节？我可能忽略什么细节？等等。

　　推测开发人员的行为，对测试人员有较高的要求。如果测试人员能了解一些开发方面的知识，将会非常有帮助。这同时也是一个经验的提高过程，在测试的时候，不妨大胆地推测开发人员的行为，即使错了也不要紧。如果能有机会阅读源代码，就可以更加方便地进行推测了。

　　3.6 不要放过任何细节

　　经常有这种情况，很多事情只知道有问题，却不知道为什么有问题。有些BUG，虽然是必现的，但确描述不清楚。这是为什么？

　　一般情况，如果一个界面上的BUG是必现的，那在界面上十有八九是可以看出来的。我们看一些例子：

　　9462. 添加好友，选择组时，如果先点添加组，然后点旁边的下拉箭头，客户端会僵死。

　　这个BUG，从描述上看，还是相当的灵异的，而且又是必现，所以有这样一个BUG，对开发人员和测试人员都是一个挑战。然而仔细观察选择组的界面，就会发现，添加按钮和下拉箭头按钮，两个按钮中间有一小部分会一直在闪动，这是不正常的。而这个BUG的根源恰恰就是因为这个小细节引起的。真正的原因是，由于这两个按钮互相有覆盖的地方，所以会互相影响，互相触发绘制的操作，结果造成了一个间接的死循环，客户端僵死的原因也就找到了。

　　所以说，某个现象发生的时候，是有蛛丝马迹可以寻找的。当有情况发生的时候，要冷静观察屏幕上的一切变化，有敏锐的眼光，不放过任何细节，这样BUG就无所遁形了。

　　4、总结

　　测试技巧有无数，但归根到底就是本文列举的两个方法。只要方法正确，加上平常掌握的技巧和使用的工具，没有什么BUG是找不到，也没有什么BUG是重现不出来的。

　　测试是一件非常有技术含量的工作，不是体力活，完全是脑力劳动。所以测试工程师平常一定要注意劳逸结合，只有保持冷静的头脑，才能把软件中的缺陷都找出来。

　　在前言的测试和开发关系小节中提到“正如一个优秀的开发人员，应该具备一些测试方面的知识和能力；一个优秀的测试人员，同样需要了解一些开发方面的知识。”测试人员在有时间的时候，可以学习一些开发方面的知识，编程语言有很多，开发思想却都是相同的。到了开发知识积累到一定程度之后，如果能对照代码进行测试，针对代码设计测试用例，效果会非常好。以后的白盒测试的时候也用得到这些知识。

　　如果一个软件的开发和测试过程中，开发人员能从测试人员的角度来进行开发工作，测试人员也能按照开发人员的想法来进行测试，那发布出去的软件，一定会是一个接近完美的软件。让我们通力合作，共同努力吧！！