一、百度百科定義探索性測試
探索性測試可以說是一種測試思維技術。它沒有很多實際的測試方法、技術和工具，但是卻是所有測試人員都應該掌握的一種測試思維方式。探索性強調測試人員的主觀能動性，拋棄繁雜的測試計划和測試用例設計過程，強調在碰到問題時及時改部測試策略。
1.定義
對探索性測試最直白的定義是：同時設計測試和執行測試。探索性測試有時候會與即興測試（ad hoc testing）混淆。即興測試通常是指臨時准備的、即興的Bug搜索測試過程。從定義可以看出，誰都可以做即興測試。由Cem Kaner提出的探索性測試，相比即興測試是一種精致的、由思想的過程。
在對測試對象進行測試的同時學習測試對象並設計測試，在測試過程中運用獲得的關於測試對象的信息設計新的更好的測試。這個有趣的過程如下圖所示。
探索性測試
強調測試設計和測試執行的同時性，這是相對於傳統軟件測試過程中嚴格的“先設計，后執行”來說的。
測試人員通過測試來不斷學習被測系統，同時把學習到的關於軟件系統的更多信息通過綜合的整理和分析，創造出更多的關於測試的主意。
2.基本過程
（探索性測試的實施）
識別軟件系統的目的；
識別軟件系統提供的功能；
識別軟件系統潛在的不穩定的區域；
在探索軟件系統的過程中記錄關於軟件的信息和問題；
3.類型
探索式測試一共分為自由式探索式測試、基於場景的探索式測試、基於策略的探索式測試和基於反饋的探索式測試。下面將詳細介紹4種類型的應用場景。
一：自由式探索式測試（類似於自由測試，效果跟經驗有很大關系）
自由式探索式測試指的是對一個應用程序的所有功能，在以任意次序、使用任何如數進行隨機探測，而不考慮哪些功能是否必須包括在內。自由式測試沒有任何規則和模式、只是不停的去做。很不幸，很多人認為所有的探索式測試都是自由式，從長遠的觀點來看，這種看法低估了探索式測試技術的能力，我們在隨后將看到這類測試的一些變種。
一個自由測試用例可能會被選中成為一個快速的冒煙測試，用它來檢查是否會找到重大的崩潰或者嚴重的軟件缺陷，或是在采用先進的技術之前通過它來熟悉一個應用程序。顯然，自由式探索式無需也不應該進行大量的准備規則。事實上，它更像是“探索”而不是“測試”，所以我們應當相應的調整對它的期望值。
自由式測試不需要多少經驗或者信息。但是，同以下提到的探索式技術相結合后，它將成為一個非常強大的測試工具。
二：基於場景的探索式測試
基於場景的探索式測試和傳統的基於場景的測試有類似之處。兩者都涉及到一個開始點，就是用戶估時或者是文檔化的端到端場景的開始之處，那也是我們所期望的最終用戶開始執行應用程序的地方。這些場景可以來自用戶研究、應用程序、以前版本的數據等，並作為腳本用於測試軟件。探索式測試是對傳統場景測試的補充，把腳本的應用范圍擴大到了更改、調整和改變用戶執行路徑的范疇。
使用場景作為指導的探索式測試人員經常會修改他感興趣的輸入或者是追尋一些並沒有包括在腳本種的潛在副作用。不過，由於最終的目標是完成給出的場景，這些測試上的彎路、最終總是會回到腳本文件記載的用戶主要執行路徑。
三：基於策略的探索式測試（主要是根據對產品的熟悉程度和經驗來進行有針對性的測試，目的是很快的發現軟件存在的風險）
將自由式測試探索式與具有測試老手的經驗、技能和感知融合在一起，就成為基於策略的探索式測試。它屬於自由式的探索，只是他是在現有的錯誤搜索技術下引導完成的。基於策略的探索式測試應用所有的已知技術（如邊界值分析或組合測試）和未知的本能（如異常處理往往容易出現軟件缺陷），來指導測試人員進行測試。
這些已知的策略是基於策略的探索式測試成功的關鍵，存儲的測試知識越豐富，測試就會更有效率。這些策略緣於積累下來的知識，它們指導軟件缺陷隱藏在哪里，如何綜合人工輸入數據，哪些代碼路徑常常出現故障。
基於策略的探索式測試結合了測試老手的經驗和探索型測試人員的隨機性。
四：基於反饋的探索式測試（通過分析當前的質量以及前面的測試情況來指導后面的探索性測試）
基於反饋的探索式測試緣於自由式測試，但是隨着測試歷史的形成，測試人員們就會利用反饋來指導今后的探索。“覆蓋”就是典型的例子。一名測試人員通過咨詢那些覆蓋指標（代碼覆蓋、用戶界面覆蓋、特性覆蓋、輸入覆蓋或者其中的某一些組合）來選中新的測試用例，以使這些覆蓋指標得以提高。覆蓋指標只是收錄反饋信息的標志之一。我們也會看其他標志，如代碼改動數量和軟件缺陷密集程度等。
基於反饋的探索式測試是一種“上一次測試”：在上一次我根據應用程序的最后狀態選了每某一個輸入之后、下一次我就會選中另外一個輸入。或者是，在上一次遇到這個界面時我用A屬性，這一次我就會用B屬性。
基於反饋的探索式測試工具是非常有價值的，它可以是測試人員保存、搜索測試歷史並據此采取實時行動。不幸的是這樣的工具很少。
4.適用時機（探索性測試的應用場景）
1）當測試這是新手，可以一邊訓練一邊測試
2）當需要快速的對程序進行評估
3）在傳統的測試腳本（Test Script）中發現新的問題需要快速驗證
4）當有需要去確認另一位測試者的工作狀態
5）當團隊內有熟悉相關領域知識（Domain Knowledge）的測試者
6）當需要做冒煙測試
7）當程序設計完成后並沒有預先規划並准備好測試腳本
8）當專案使用敏捷軟件開發
9）專案很復雜並且難以了解
10）當測試者並沒有權限去創建測試案例
11）當想要針對某個程序錯誤進行深入調查
12）當專案尚未穩定到可以執行腳本測試（Script Test）
13）當想要擴大腳本測試的多樣性時
探索性測試尤其適合於那些需求不是很明確的測試任務。
5.優點與缺點
- 優點
—— 可增加機會找到新的、未知的程式缺陷。
探索性測試可以用來找到深層次的BUG。
因為探索性測試人員是優秀的觀察者，他們觀察不正常和不期望的結果，並進行認真的思考，這種狀態和按部就班的執行用例是不一樣的，因此，它更容易發現一些隱藏的很深的問題。
—— 探索性測試可以加深測試人員對被測系統的了解。
探索性測試強調對被測試對象的學習，並且是在測試過程中的學習，並在此基礎上設計測試，因此，它使測試人員更容易深入的理解被測系統。
—— 允許測試者花較多的時間去測試一些有趣或復雜的狀況。
—— 可較快速的對受測的系統做出快速的評量。
—— 可讓你知道系統是否容易使用。
—— 可變通的，有彈性的。
—— 它比腳本測試有趣，因為它不會一成不變。
- 缺點
—— 無法對系統作全面性的測試。
—— 提供有限的測試可信度。
—— 非常的依賴測試者的領域知識（domain knowledge）以及技術。
—— 無法保證最重要的程序錯誤一定被發現。
—— 並不適用要執行很久的測試（例如執行一整個晚上的測試）。
二、探索性測試的目標
1.理解應用程序如何工作，它的接口看起來怎么樣，它實現了哪些功能：（找到軟件切入點）
2.強迫軟件展示其全部能力：（滿足所有的功能上的需求）
3.找到缺陷：（樹立明確的目的，而不是漫無目的尋找影子）
三、探索性測試實踐
1.基於旅行者的探索性測試方法
我們可以將軟件
探索測試的核心是什么？
怎么判斷是不是探索性測試
軟件缺陷密集性、分布情況的分析，有助於執行基於反饋的探索式測試
探索性測試強調測試過程中學習，那么測試依據從何而來？是不是要前置於常規測試？
https://www.jianshu.com/p/39a837590a9f