上次说到了理想中的测试模型，有很多测试手段，细心地人可以发现那里面加了一个很关键的一个测试手段就是探索性测试。其实这里面把它叫为测试手段不是很科学，而且容易产生歧义。
所以后面把它叫做一种测试方法。
自己研究探索性测试快半年了，对其有一定的了解，而且在国内也有相关的介绍，个人认为：
1. 大部分是正确的
2. 相当浅显的介绍探索性测试
3. 没有介绍探索性测试的实践情况
自己看过了探索性测试（以下简称ET）的3个核心人物的一些关于ET的paper，也小小的实践了一个ET的一种形式，有很多感慨。但一直没有去写，有以下原因：
1. 不知道怎么表达出来比较好，一直都认为自己理解ET不深
2. 为了不让大家对ET存在误区，且自己对于ET某些的认识也是存在不同的看法（随着与James bach的沟通变得不一样）
3. 自己对于ET具体的测试方法的抽象还存在部分疑惑
最后发现了一点点的感觉了，就想把自己了解的一些情况记录下来Share给大家，希望能给大家带来不一样的认识。也希望不要给大家带来ET认识上的误区。
这里把ET叫做一种测试方法，而非测试技术，是有理由的。我们先可以分析下我们目前的测试模型，是集成在spiral或waterfall或类似的开发模型下，这就存在如下的几个特点：
1. 测试文档（计划和设计和用例）必须非常详细和明确
2. 测试设计和测试用例对于开发的文档的依赖非常大
3. 测试执行的时候对于测试用例的依赖非常大
4. 测试执行的时候对于需求变更的应对力较差
我们可以把有以上特点的测试方法叫Scripted based testing（简称ST），显然我们目前就是这种测试方法，由于这个方法有些缺点，从而产生了一个新的测试方法：ET。
下面我们对于ET和ST进行了一些简单的比较：
| ST | ET | |
| 测试与测试用例的关系 | 测试用例在之前就设计和记录好，过后再测试执行或被其他测试人员执行 | 测试设计和执行时在同一时间完成，而且他们不是必须记录下来，但也有可能 |
| 与测试执行的关系 | 可以控制测试执行 | 可以提升测试设计 |
| 过程的交互性 | 就像做个已准备好的演讲，由之前想好的想法引导着 | 就像一个对话，是自动向导的 |
在这里我们可以看到一点就是ET似乎就是弥补ST的一些缺点，理智的人就会想到能不能ST和ET结合起来。这样带来的效果是不是更好呢？
