前记：写这个文章，主要有两个目的：

　　1. 答应过InfoQ 中文站的霍泰稳，要写篇关于探索式测试的文章发表在InfoQ上

　　2. 一年前写过<在淘一年> 的文章，而且期望自己在淘宝的每一周年的时候，都可以写篇文章纪念下之前的那篇文章是关于测试人生和测试生活相关的，自己虽然工作快五年了，淘宝也是我工作时间最长的一家公司了，这次就来个偏技术一点的文章吧。

　　前段时间的北京QConf 大会里面有个探索式测试的分享，是Erik Petersen 演讲的，我由于一些原因，没有在现场向大师学习，之后发现他讲的非常好，效果也很好，引起了很多人对于探索式测试的兴趣。这里也感谢InfoQ的给力，我把Erik的PPT看了两遍，有非常深刻的体会。也确实在某些方面开导了我。自己本身学习探索式测试快一年有余了，也不乏和国外的ET的一些大师（James Bach， Cem Kaner）进行交流。

　　这里我先抛一个问题出来：为什么产品提交到测试这边，我们的测试工程师可以发现很多开发或用户都发现不能的Bug呢？ 大家可能觉得这个原因肯定有很多，比如有这些：

　　1.  我们是测试工程师，我们是专门干这个的

　　2.  我们很好的理解了需求，我们使用了很多且很好的测试设计技术

　　3.  我们有较多时间进行测试执行

　　4.  开发人员或用户没有时间去进行测试

　　5.  开发人员或用户没有时间不知道怎么去进行测试

　　6.  我们的运气好，突然发现了这些好的Bug

　　（当然还有很多其他的因素，这里就不列出所有的了）

　　那么再有一个问题出来：为什么有些测试人员能发现其他测试人员不能发现的Bug呢？大家可能觉得这个原因肯定有很多，比如有这些：

　　1.  其他测试人员对于业务需求不熟悉，该测试人员对于业务非常精

　　2.  其他测试人员没有很好的状态，注意力不够集中

　　3.  其他测试人员的测试经验较少， 该测试人员测试经验非常丰富

　　4.  其他测试人员的运气不怎么好，该测试人员是突然灵感出来发现的

　　5.  其他测试人员的测试环境和测试数据不一样

　　（当然还有很多其他的因素，这里就不列出所有的了）

　　同样的问题还有很多，比如：为什么我们很多好的bug都不是通过我们已经写好的测试用例发现的呢？其实这里面我并不是想去搞清楚很多不同的原因，根据80/20原则，我只想关注一个主要的，那就是经验丰富的测试是如何进行测试的，是如何进行探索式测试的，它的思维过程到底是什么样的，和我们通常的测试有什么不一样的。

　　很多人都会问到底什么是探索式测试，也有很多人知道很多时候我们就是在做探索式测试（只是我们自己不知道而已），不管怎样，我们都期望把很好的测试方法或手段传承下去，让新加入测试行业的同学都可以吸收这个武林秘籍。根据看Erik的PPT，我这边大概抽象了下探索式测试的思维过程：

　　这个思维模型简称为CPIE

　　简要说明：Collation，这个action注意就是我们需要收集所有关于SUT的所有信息，去了解和理解。

　　Prioritization，我们要对所有需要测试的任务或模块或特性进行优先级的划分，这里不说划分原则。

　　Investigation，划分好后，就需要对应确定即将测试的任务进行仔细的分析并预测其可能输出的结果。

　　Experimentation，这个action就是需要我们实际的去进行测试，看看我们的预测是否正确，我们的信息是否正确，就会变化到去影响Collation阶段。