早在1983年，Cem Kaner提出了探索式测试的概念。
探索式测试是一种软件测试风格，它强调独立测试人员的个人自由和职责，为了持续优化其工作的价值，将测试学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目实现过程中并行地执行。
很多测试人员把探索式测试理解为“发散找缺陷”，这是不恰当的理解。探索式测试是一种软件测试风格，或者说是一种“测试的价值观”，希望可以边学边测，重视反馈，持续优化调整，其和敏捷的价值观很贴合。
和探索式测试对应的是脚本式测试（Script Testing，ST），脚本式测试要求测试人员编写测试脚本去记录所有的测试用例（包括测试操作和预期），然后通过脚本来实施测试。脚本式测试有利于测试执行和测试设计的分离，这可以让测试设计、测试执行、自动化分离等适合流水线作业。脚本式测试也有利于测试的管理、度量和评估。但是过于详细的测试设计、测试用例本身也是一种巨大的开销，这会让测试变得过重。另外，脚本式测试要求测试人员严格按照测试用例来执行，这会使测试过程变得过于机械。
探索式测试和脚本式测试的差别（James Bach版本）
在脚本式测试中，测试人员先设计测试用例，再在一段时间后执行这些测试用例，或者测试用例被其他测试人员执行。而在探索式测试中，测试用例是在测试执行时被设计的，而且大部分测试用例不需要详细的记录。
探索式测试有可能带来如下问题。
1）测试人员会有短期无法弥补的能力短板。
2）学习能力不足的测试人员不能快速抓到测试重点，上手慢。
3）探索失败会给测试人员带来挫败感，会对项目交付造成影响。
4）更多的沟通，不一定是有效的沟通。
5）测试人员的独立人格会使合作性变差。
6）经验传承会成为一种瓶颈。
7）探索式测试快节奏、不断学习和变化的特点会引发测试人员的疲惫感，这一点团队人员不一定都可以接受。
这就需要测试人员能够更有策略地开展探索式测试。例如以脚本式测试为主，探索式测试作为补充，或将探索式测试的思想运用到一些测试活动中。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
