探索式
测试（Exploratory
Test）经常被简称为ET，由 Cem Kaner 1983年建立的测试概念，这几年随着
敏捷方法而大行其道。敏捷方法的迭代频率很快，每个迭代时间很短，自然想到如何减少文字
工作，避免写
测试用例，ET自然是一个很好的选择。ET简单理解为测试设计与执行同步进行。
不过，我们以前熟悉测试中的错误猜测法、Ad hoc测试等方法，不管Cem Kaner承认不承认，ET概念很有可能来源于这些先前的概念，在这些概念的基础上丰富它，试图给ET建立一个比较系统的体系，例如引入基于上下文驱动 （Context-driven）、基于session的测试等。想当初，我们用错误猜测法、Ad hoc测试方法时，一定也会考虑业务或功能的上下文关系，没有上下文还做什么测试？也会考虑某些场景，更多会考虑一些特别的场景，如人们常说的 corner case，right？ 当然，ET和错误猜测法、Ad hoc测试是有区别的。
谈谈探索式测试与基于脚本的测试（Script-base Test 或 Scripted Testing，ST）之关系，不论是在传统测试流程还是在敏捷测试中， 这两者是相辅相成的，谁也不能代替谁，正如James Bach也谈到“Balancing Exploratory Testing with Scripted Testing，... two approaches to testing are fully compatible” 。而且在不同的场景有各自的优势，例如：
● 发现问题来看，探索式测试效率会更高些，甚至高得多；
● 测试乐趣看，也会优先选择探索式测试；
● 敏捷中新功能测试会选择探索式测试；
● 探索式测试不易实现自动化，所以自动化测试先需要脚本，然后执行；
● 归测试比较确定，需要不断运行，自然会选择基于脚本的测试（ST）；
● 产品线来看，开发周期长，复用会大大提高效率，ST也具有很大优势。
所以，在一个项目中，经常是同时采用这两种方法——ST和ET，而且不同的组织环境或项目环境，随时间的投入是不一样的，这就是那两条神奇的曲线：
当初我没有在线上标ST和ET，就是因为每根线都可能是ET或ST，例如：
1、如果自动化测试水平低或没有自动化测试，就需要在前期有更多的ET，在发现产品问题的同时学习产品、更深地理解产品，并通过发现问题来完善测试用例。而为了降低产品质量风险，后期需要进行更系统的测试，特别是要完成大量回归测试、对产品质量有一个完整的评估，需要执行ST。由于自动化水平低，这时人力都投在ST上，就没有经历做ET，而且也不必要。
2、如果自动化水平高，前期需要开发脚本，ST的投入自然大。但自动化执行时，虽然会运行大量用例，但解放了生产力，测试人员有更多时间投入ET。
实际环境所处的场景会更多，不管怎样，先要清楚自己测试工作中有什么问题，然后采用合适的方法来解决问题。或者说，要清楚自己的目标，是让团队获得激情还是让公司处在稳定的不败之地、还是为了尽快发现Bug还是提高产品的质量，方法何时使用、如何使用、谁使用等都可能不同。即先问Why？What？然后才考虑How、Who、Where？
关于探索式测试和脚本测试还有许多东西可以谈，时间关系，今天就谈到这里。
出自：http://blog.csdn.net/kerryzhu/article/details/7489319