探索式测试（Exploratory Testing，以下简称ET）是什么？

　　现在可能越来越多的测试同仁们，测试论坛开始讨论ET。ET现在炙手可热，但是否ET适合自己所处的环境？是否适合任何一个项目？执行ET的过程中又碰见哪些问题呢？传统的瀑布流又在什么位置呢？我们来一起做一下探讨吧！

　　首先不要认为ET就是Free Style，和传统意义上的ad hoc test有本质的区别。传统的随机测试是指测试人员没有目的的对一个软件进行测试，从而在过程中发现产品的缺陷。相反的，ET的过程是一个根据上下文，有策略，有方法的进行测试。探索式测试自身是有很多方法支持（由于方法太多，就不进行详细说明了，有兴趣的读者可以购买相关的书籍学习）。这里举两个例子，比如A心中想着一个数字让B猜测，B每猜一个数字，A会告诉B是比心中想的数字大了还是小了。最终B会准确的猜出A心中所想的数字。再比如你去超市shopping，除了你直接有目的性的之外，大部分情况都是会先进行物品的挑选，无论是种类，还是价格的比较，最终挑选出符合你想要的那个商品。这两个例子是生活中经常见的场景，其也是探索性方法的一种实现。这里不得不提的就是联系上下文的测试，两个例子都是根据上下文进行一种探索，最终达到了自己的一个目的。

　　现在很多的呼声会说ET只适合于中小企业和迭代周期快的项目。说的很对，但是笔者的理解却稍有不同。只要企业的产品有测试这个环节，无论你是一个资深测试还是一个初入测试门的新人，只要想进行ET，那么无论项目大小，无论测试人员多少，无论项目进行到哪个节点都能够进行ET。

　　大部分的企业目前都是处于使用ST（Script-base Test或ScriptedTesting）的方法进行测试。那么我们应该怎么适当的使用ET，让ET能够在不降低当前产品质量的前提下很顺利的合入公司的测试活动中呢？下面会进行详细的说明，不过在这之前，我们需要来明确一些前提，只有在理解这些前提的情况下，才能够做好测试：

　　● ST和ET不是万能的方法，不能仅仅依靠其中的某种方法一路走到底。

　　● 计划永远赶不上变化，测试活动必须适当的适应实际情况

　　● 任何的测试都应该基于风险的评估

　　● 任何的测试都应该基于上下文环境进行实施

　　● ST中所有的步骤在ET并非是省略，而是进行适当的简化，从而达到更高的测试效率

　　● 测试活动并非局限于一个周期，而是一个长期的活动，是一个循序渐进，不停改进总结提升的过程。

　　认同这些前提之后，我们来看一下在实施ET的过程中可预见的一些问题以及解决的方法：

　　1、公司或者测试团队如何先踏出第一步

　　首先如果你是一个leader或者manager，你想推ET的话需要先考虑好过程中的一些细节问题，怎么推，怎么考评，怎么引导大家去做等。考虑成熟之后再进行推广，否则不仅不会提升测试的效率还会弄的公司一团糟。如果公司的上层很好沟通，那么你可以选择和公司上层直接进行沟通表达测试团队接下来会引入一种新的测试方法以及引入带来的利弊。上层并非那么容易说服的话，那么你可以先和你团队中经验丰富的测试先进行一部分功能的ET，将结论总结好然后再去和上层交涉，这样的话相对也更加有说服力。针对测试团队来讲，应该进行相应的概念和方法的培训，让测试团队的每个成员充分的了解什么ET，ET和ST的区别是什么，ET的优缺点分别是什么，测试团队为什么要引入这样的方法等。以上这些是你要推广和实施ET前必须要做的事情。

　　2、怎么在风险可控的前提下施行ET，ET中的人员KPI又怎么评定

　　其实测试的模式中有很多的模式能够很好的辅助进行ET。

　　其中一个方法就是交叉测试。无论哪个测试人员，其测试的时候总会有所谓的测试盲点，总会有某些测试点遗漏。此时交叉测试模式既能够加强ET测试的覆盖面又能够同时给测试人员带来更多的想法。不失为一种很好的方法。

　　另外一个方法就是结对测试。结对测试主要的作用是能够让一个测试新人更快的积累经验，更快的成长。一般情况下是一个资深测试和一个测试新人结对同时进行测试，资深的测试人员可以对测试过程中对于业务和测试方法进行指导，同时也可以学习新人进行测试时候的思想并总结。