一、百度百科定义探索性测试
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改部测试策略。
1.定义
对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、由思想的过程。
在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。这个有趣的过程如下图所示。
探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。
2.基本过程（探索性测试的实施）
识别软件系统的目的；
识别软件系统提供的功能；
识别软件系统潜在的不稳定的区域；
在探索软件系统的过程中记录关于软件的信息和问题；
3.类型
探索式测试一共分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。
一：自由式探索式测试（类似于自由测试，效果跟经验有很大关系）
自由式探索式测试指的是对一个应用程序的所有功能，在以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。自由式测试没有任何规则和模式、只是不停的去做。很不幸，很多人认为所有的探索式测试都是自由式，从长远的观点来看，这种看法低估了探索式测试技术的能力，我们在随后将看到这类测试的一些变种。
一个自由测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来熟悉一个应用程序。显然，自由式探索式无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以我们应当相应的调整对它的期望值。
自由式测试不需要多少经验或者信息。但是，同以下提到的探索式技术相结合后，它将成为一个非常强大的测试工具。
二：基于场景的探索式测试
基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开始点，就是用户估时或者是文档化的端到端场景的开始之处，那也是我们所期望的最终用户开始执行应用程序的地方。这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试是对传统场景测试的补充，把脚本的应用范围扩大到了更改、调整和改变用户执行路径的范畴。
使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本种的潜在副作用。不过，由于最终的目标是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。
三：基于策略的探索式测试（主要是根据对产品的熟悉程度和经验来进行有针对性的测试，目的是很快的发现软件存在的风险）
将自由式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。它属于自由式的探索，只是他是在现有的错误搜索技术下引导完成的。基于策略的探索式测试应用所有的已知技术（如边界值分析或组合测试）和未知的本能（如异常处理往往容易出现软件缺陷），来指导测试人员进行测试。
这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，哪些代码路径常常出现故障。
基于策略的探索式测试结合了测试老手的经验和探索型测试人员的随机性。
四：基于反馈的探索式测试（通过分析当前的质量以及前面的测试情况来指导后面的探索性测试）
基于反馈的探索式测试缘于自由式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人员通过咨询那些覆盖指标（代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合）来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只是收录反馈信息的标志之一。我们也会看其他标志，如代码改动数量和软件缺陷密集程度等。
基于反馈的探索式测试是一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。
基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。不幸的是这样的工具很少。
4.适用时机（探索性测试的应用场景）
1）当测试这是新手，可以一边训练一边测试
2）当需要快速的对程序进行评估
3）在传统的测试脚本（Test Script）中发现新的问题需要快速验证
4）当有需要去确认另一位测试者的工作状态
5）当团队内有熟悉相关领域知识（Domain Knowledge）的测试者
6）当需要做冒烟测试
7）当程序设计完成后并没有预先规划并准备好测试脚本
8）当专案使用敏捷软件开发
9）专案很复杂并且难以了解
10）当测试者并没有权限去创建测试案例
11）当想要针对某个程序错误进行深入调查
12）当专案尚未稳定到可以执行脚本测试（Script Test）
13）当想要扩大脚本测试的多样性时
探索性测试尤其适合于那些需求不是很明确的测试任务。
5.优点与缺点
- 优点
—— 可增加机会找到新的、未知的程式缺陷。
探索性测试可以用来找到深层次的BUG。
因为探索性测试人员是优秀的观察者，他们观察不正常和不期望的结果，并进行认真的思考，这种状态和按部就班的执行用例是不一样的，因此，它更容易发现一些隐藏的很深的问题。
—— 探索性测试可以加深测试人员对被测系统的了解。
探索性测试强调对被测试对象的学习，并且是在测试过程中的学习，并在此基础上设计测试，因此，它使测试人员更容易深入的理解被测系统。
—— 允许测试者花较多的时间去测试一些有趣或复杂的状况。
—— 可较快速的对受测的系统做出快速的评量。
—— 可让你知道系统是否容易使用。
—— 可变通的，有弹性的。
—— 它比脚本测试有趣，因为它不会一成不变。
- 缺点
—— 无法对系统作全面性的测试。
—— 提供有限的测试可信度。
—— 非常的依赖测试者的领域知识（domain knowledge）以及技术。
—— 无法保证最重要的程序错误一定被发现。
—— 并不适用要执行很久的测试（例如执行一整个晚上的测试）。
二、探索性测试的目标
1.理解应用程序如何工作，它的接口看起来怎么样，它实现了哪些功能：（找到软件切入点）
2.强迫软件展示其全部能力：（满足所有的功能上的需求）
3.找到缺陷：（树立明确的目的，而不是漫无目的寻找影子）
三、探索性测试实践
1.基于旅行者的探索性测试方法
我们可以将软件
探索测试的核心是什么？
怎么判断是不是探索性测试
软件缺陷密集性、分布情况的分析，有助于执行基于反馈的探索式测试
探索性测试强调测试过程中学习，那么测试依据从何而来？是不是要前置于常规测试？
https://www.jianshu.com/p/39a837590a9f