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