传统测试，包括冒烟测试、系统测试、回归测试需要依赖于测试用例，测试的方式方法受到一定的束缚，尤其在项目时间比较紧张的情况下，往往只进行了系统测试，回归测试，没有时间去进行探索性测试，对一些比较复杂的场景没有覆盖到，而因此可能遗漏缺陷。
探索性测试，又称自由测试，随机测试，系统测试用例即使覆盖了需求的所有功能点，但你仍然不能保证你没有遗漏，依据著名的80-20原则，软件80%的缺陷隐藏在20%的功能之中，按照理想测试来说，如果开发人员的代码质量足够高，业务、开发、测试人员对需求的理解完全100%吻合，那么依据测试用例执行发现的缺陷将少之又少，因此探索性测试必不可少。
首先它是在系统功能测试已基本通过，测试还有大量的时间来进行测试，所谓广阔天地大有作为，这时，探索性测试就可以粉墨登场了；
其次，要对系统的业务需求比较了解，则可以比较有的放矢的进行探索性测试，因为如果对系统不够熟悉，因为往往探索性测试发现的问题需要去甄别，因为有的可能就是需求所包含的正确结果。
第三，探索性测试往往会耗费大量的时间，因为你没有一个参考，不知道预期结果会是什么，有的时候一个步骤可能去要重复的执行，同时当发现bug时，还要去再确定重现的场景，有时你可能会灰心，思考探索测试的价值究竟会不会发现bug，而当你费尽周折发现一个隐藏较深的严重的缺陷时，喜悦之情，油然而生，为之提刀而立，踌躇满志。
推荐本书《探索式软件测试》，作者对探索式测试进行了深入的阐述，并对许多测试方法进行了总结归类，比如针对软件特性的探索式测试，分为5类，如：
商业区：即软件的主要特性
历史区：即出现较多缺陷的功能或遗留缺陷
旅游区：新功能新特性
娱乐区：辅助性功能次要功能
破旧区：比较不常用的功能
版权声明：本文出自 岁月无声 的51Testing软件测试博客：http://www.51testing.com/?316844
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
