探索式軟體測試是一種強大的黑盒測試思考方法，但卻被廣泛誤解。在某些情況下，它可以比自動化測試更加有生産力。它是一種經過深思熟慮的測試方式，沒有測試腳本，可以使你的測試超出各種明顯已經測試過的場景。
什麼是探索式測試
探索式測試（Exploratory Testing）是一種軟體測試方法，也可以說是一種測試思維方法，最先是 Cem Kaner 在 1983 年提出的。這是一種強調個人自由與責任的測試方法，讓獨立測試人員可以借用不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時改善測試案例達到相輔相成的效果。
它的本質是測試政策，邊學習、邊設計、邊測試、邊思考。換句話說，探索式測試是測試人員自發進行的測試工作，在執行測試的同時根據所獲得的資訊來設計測試政策的方法。它強調要根據目前的實際情況來選擇最合适的測試技術，進行測試。測試人員使用探索式測試從客戶的角度評估軟體的實際工作方式。它更注重的是「思考」和「學習」，不斷的發現新的問題。
一般在時間相對較緊張，且測試對象說明不完善，即我們常說的「靈活開發模式」的情況下，探索式測試可以起到突出的效果（但并不是說探索式測試是靈活模式下特有的軟體測試方法）。
為什麼探索式測試很重要
采用靈活開發流程迫使測試團隊在更短的時間周期内完成測試。以前需要數周或數月才能測試的團隊，現在必須加速測試，以便在幾小時或幾天内提供更全面的測試結果。是以，必須在極大的時間壓力下進行測試，不僅如此還需要減少資源和預算。
由于探索式測試不需要預先進行費時費力的計劃，是以團隊通常會在開發完成後立即開始測試新功能。這促進了在極短的開發周期内快速檢測缺陷。
探索式測試是以使用者的角度來測試，它為傳統的結構化測試（即從底層開始測試）做了補充，以保護頻繁疊代的使用者體驗。這意味着探索式測試不僅關注系統設計是否良好，還關注使用者體驗，是以它更容易發現比結構測試更嚴重的缺陷。
探索式測試正在被越來越多的被應用于使用者體驗測試。它通常與傳統結構化測試形成對比，後者僅側重于系統邏輯驗證（即，是否滿足要求/使用者故事中概述的驗收标準）。結構化測試保障已知風險，而探索式測試主要側重于分析潛在風險。
雖然不用事先建立測試用例，但是測試人員通過發散性的思維去思考每個子產品、每一步甚至每個按鈕可能會出現的缺陷問題，可以讓測試人員的時間和精力更多地集中在創造性地思維上，發現更多隐藏的缺陷。
比如:
我模拟成為一個使用者做一些常用操作，一定可以發現傳統測試測不到的 BUG
在發現 BUG 的地方，一定可以發現更多的 BUG
在了解開發的架構後，一定可以找到更隐蔽的更深層的 BUG
……
對于對産品品質有近乎完美的「偏執狂」來說，發散性的思維是一個完美測試人員的利器，一些隐藏的難以發現的缺陷，确實要求測試人員有發散性思維才能比普通的測試看的更多更廣更犀利。
探索式測試準備
了解探索式測試有兩個前提：
1、測試之前一定會有一個全局的方針戰略，即整體的測試計劃，它可以避免走錯大方向、該測的部分沒有覆寫到或者投入了大量時間到計劃之外的部分。
2、測試一旦開始，沒有固定的思路，測試人員不受任何先入為主的條條框框限制，根據測試途中擷取的資訊，指導各自走不同的路徑，最終目的就是發現潛藏的缺陷。
探索式測試的類型
探索式軟體測試一共分為以下 4 種：
自由式探索式測試
基于場景的探索式測試
基于政策的探索式測試
基于回報的探索式測試
如何進行探索式測試
1、從産品需求文檔（PRD）和原型等文檔中擷取需要測試的範圍和深度，識别軟體的根本目的，确定需要測試的核心功能點。
2、與項目組産品、開發人員溝通，擷取更多業務資訊和系統架構資訊，以确定更多的風險點。
3、與其他測試人員溝通，确定風險點最高的子產品或功能點。
4、制定探索式測程（Session）：測程表（Session Sheet）、時間盒（Time Box）、主題（Charter）。（可參見 Session-Based Test Management）
5、執行探索式測試計劃，在此過程中邊測試、邊學習、邊設計、邊思考，并根據具體情況随時更改測試政策。
6、測試的過程中記錄軟體邏輯，發現 BUG，給開發人員建立缺陷。
基于旅行者的全局探索性測試方法
我們可以将軟體的測試比做是去一個城市的旅遊。那麼我們如何快速的去到我們想去的地方呢？一個辦法就是我們對這個城市很熟悉。另外一個辦法就是找一個導遊或者一份地圖，用來指導我們去在這個城市旅遊。
對于軟體測試來說，我們同樣需要對被測軟體很熟悉，同時也需要一份測試地圖或者測試指南，來幫助我們更好的探索性測試。
拿到地圖後，我們可以根據地圖将城市按照功能分為各種區域，而每個區域對應軟體相應的功能。比如：
商業區：銷售特性，對應軟體包裝上面的對應特性，類似我們的需求。
曆史區：繼承特性，上一個版本遺留下來的代碼、問題或則曾經出現多次 BUG 的功能或者特性。
旅遊區：噱頭特性，即對應産品的新特性，能夠去更好的吸引新的使用者。
娛樂區：輔助特性，對應軟體的輔助特性和功能，可以做完補充測試。
旅館區：平台或維護特性，對應軟體内部的一些互動，不一定是由使用者來觸發的。
破舊區：問題高發區，對應軟體的曆史穩定的代碼，一般很少人去接觸。
每個區都有特定的測試方法，有興趣的朋友可以去買『探索式軟體測試』這本書詳細了解。
這裡我們拿「Web 應用更新部署」來實踐該方法。
1.首先，我們先了解需要測試的子產品、功能點以及相關的内部邏輯。
2.然後，我們根據項目的時間确定本次測試的主題和範圍，建立一次探索式測試計劃，如下圖：
1.執行探索式測試計劃，在測試的過程中按照旅行者測試方法的思路來建立用例：
按照旅行者測試方法的區域寫出目前區域可能會發生的問題，然後套用每個區域的方法引申出更多的潛在問題，并依此進行測試。
1.記錄用例的測試結果：
1.測試完畢
哪個測試點出了問題，那麼我們就應該重視該問題，并在此基礎上發散，比如：
「系統重新開機後應用無法啟動」，我們知道了是因為磁盤沒有挂載，導緻啟動失敗，那麼伺服器防火牆被重置是否也會造成無法啟動呢？那麼這個問題将在下次測試的時候執行。
最後，來看下我們的探索式地圖的設計：
可以看到通過探索性測試方法已經分析出來了一些測試點，探索性測試另外一個重要的地方就是邊測試邊寫測試點，過程中不斷分析、不斷學習，然後行程新的探索性測試點，這樣才能完成一次成功的探索性測試。
另外還有局部探索式測試和混合探索式測試方法，本文因篇幅問題将不展開論述。
結論
探索式測試試圖把制定計劃，進行測試，重新制定計劃等多個過程有機地結合起來，每次隻前進一小步，但這每一步都是由軟體過去和目前的運作狀況，軟體在測試時表現出來的各種行為和軟體運作時留下的種種蛛絲馬迹來即時确定的。有效地利用探索式測試技術可以幫助我們釋出一個高品質的軟體産品。
作者為
飛蛾測試進階測試工程師