探索式
測試（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。
實際環境所處的場景會更多，不管怎樣，先要清楚自己測試工作中有什么問題，然后采用合適的方法來解決問題?；蛘哒f，要清楚自己的目標，是讓團隊獲得激情還是讓公司處在穩定的不敗之地、還是為了盡快發現Bug還是提高產品的質量，方法何時使用、如何使用、誰使用等都可能不同。即先問Why？What？然后才考慮How、Who、Where？
關于探索式測試和腳本測試還有許多東西可以談，時間關系，今天就談到這里。
出自：http://blog.csdn.net/kerryzhu/article/details/7489319