第一次听到探索性测试这个词是去年的10月份。一个微博上的朋友写了一篇关于探索式测试的blog，之后断断续续的阅读了不少相关资料，参加了数场相关讨论，但是还是没有得到一个系统的理解。8月29日晚上有幸聆听了测试顶级专家Micheal Bolton（不是唱歌的那个，是做测试的）关于探索性测试的演讲，解决了数个困扰我很久疑惑。我终于得以把这些知识理清，下面我会把我所理解的探索性测试跟大家做一个分享。

　　探索性测试的历史和主旨

　　探索性测试是近十几年内才形成体系的一种测试思想，它的核心理论由Jame Bach在1995年提出，并在数年间由学者和业界的测试工作者不断完善而形成的理论。测试大师Cem Caner在02年首次以“Exploratory Testing”（探索性测试）的名称在学界和业界开始相关的演讲和培训。探索式测试的方法论在这10余年期间不断被测试先锋们不断磨炼和修正，终于在11年，担任过微软和Google测试总监的James Whittaker出版了《探索性测试》一书，让探索式测试在业内获得了广泛关注，并掀起了一股学习和研究热潮。

　　探索性测试的核心思想是：测试是一个不断学习，不断探索的创造性过程。测试计划、分析、设计、执行其实是相辅相成，相互交织的。依照传统的测试理论，把这四部分在时间上严格区分会限制人的创造性和，进而影响测试效果。同时静态的测试方案和测试用例不足以覆盖对动态系统的测试。探索性测试强调不断的学习、探索，不断的修正测试方法，十分强调人的能动性是它最大的亮点。

　　探索性测试实际上是将戴明环方法（PDCA）做到了极致，也可以说做到了时间上的交织和同步------在做测试执行的时候，测试者也在做测试分析与设计，同时还可能在修改测试计划，这时候我们就会发现我们现在沿用的一些测试文档例如测试计划文档、测试需求、测试用例这些东西就不大好用了，因为修改频繁，全部记录下来代价太大，且强制划分文档类型会打乱思维。因此探索性测试强调灵活的记录测试的产物,而不必循规蹈矩，这在形式上与传统的测试（探索性测试将传统称为依托脚本的测试，script test）是有极大矛盾的，这也是探索性测试在业界引起的最大争议。

　　探索性测试有迹可循么？

　　答案是肯定的。比照一下探索性测试的思想和我们的日常工作，大部分测试者其实已经在做着某种程度的探索性测试的工作，如果你在发挥能动性，使用多种获取需求的方法，你在做探索性测试;如果你根据测试实际系统的反馈修正测试用例，你在做探索性测试;如果你在做我们常说的自由测试，你也在做探索性测试，但是这肯定不是全部。

　　探索性测试是有迹可循有具体实践方式的。Cem Kanner提供了一套详细的实践方案，你可以从下面链接获得：https://intranet2.arraynetworks.net/prx/000/http/www.testingeducation.org/BBST/exploratory/BBSTExploring.pdf

　　当然你也可以使用James Bash和Micheal Boltonl的方法：

　　http://www.developsense.com/resources/et-dynamics3.pdf

　　你也可以读一下James Whittaker的书：探索式软件测试方法（这本书跟上面两家不是一个流派，不过也能学到很多具体的测试方法，很实用。）

　　http://product.dangdang.com/product.aspx?product_id=20834199

　　以及我们国内一线测试人员写的一本中文书：探索式测试实践之路（还未读过）

　　http://product.dangdang.com/product.aspx?product_id=22844980

　　浏览上面的资源你可以得到相当具体的技术和方法，因此这里不在赘述了。除了James Whitaker那本书，剩下3份资源都应该属于上下文驱动流派（context-driven school），是一个路数。据我所知国内的一流测试专家邰晓梅女士也在实现一套基于测试驱动的探索性测试实践方案，让我们一起期待：）。

　　其实探索性测试和所谓的传统测试并不是冲突和矛盾的，在实践过程中也不会走两个极端。我在交流过程中问了Micheal Bolton他们是否矛盾的问题。他的回答是：“我们可以找两个端点，一端是把人当作生产线螺丝的严格依照脚本进行测试方式，一端是把人比作一个小孩的完全探索性测试，实际工作中，我们肯定是在这两个点连线中的某一个点。具体这个点在哪里，要看它在哪里能够更好的开展测试。”正所谓法无定法，我们其实完全没有必要去恪守、捍卫教条，并非争出个高下来，黑猫白猫，抓住老鼠就是好猫。