探索式軟件測試是一種強大的黑盒測試思考方法，但卻被廣泛誤解。在某些情況下，它可以比自動化測試更加有生產(chǎn)力。它是一種經(jīng)過深思熟慮的測試方式，沒有測試腳本，可以使你的測試超出各種明顯已經(jīng)測試過的場景。

什么是探索式測試

探索式測試（Exploratory Testing）是一種軟件測試方法，也可以說是一種測試思維方法，最先是 Cem Kaner 在 1983 年提出的。這是一種強調(diào)個人自由與責任的測試方法，讓獨立測試人員可以借用不斷的學習來改善測試的規(guī)劃與測試的執(zhí)行，而在測試的過程中也會同時改善測試案例達到相輔相成的效果。

它的本質(zhì)是測試策略，邊學習、邊設計、邊測試、邊思考。換句話說，探索式測試是測試人員自發(fā)進行的測試工作，在執(zhí)行測試的同時根據(jù)所獲得的信息來設計測試策略的方法。它強調(diào)要根據(jù)當前的實際情況來選擇最合適的測試技術，進行測試。測試人員使用探索式測試從客戶的角度評估軟件的實際工作方式。它更注重的是「思考」和「學習」，不斷的發(fā)現(xiàn)新的問題。

一般在時間相對較緊張，且測試對象說明不完善，即我們常說的「敏捷開發(fā)模式」的情況下，探索式測試可以起到突出的效果（但并不是說探索式測試是敏捷模式下特有的軟件測試方法）。

為什么探索式測試很重要

采用敏捷開發(fā)流程迫使測試團隊在更短的時間周期內(nèi)完成測試。以前需要數(shù)周或數(shù)月才能測試的團隊，現(xiàn)在必須加速測試，以便在幾小時或幾天內(nèi)提供更全面的測試結果。因此，必須在極大的時間壓力下進行測試，不僅如此還需要減少資源和預算。

由于探索式測試不需要預先進行費時費力的計劃，因此團隊通常會在開發(fā)完成后立即開始測試新功能。這促進了在極短的開發(fā)周期內(nèi)快速檢測缺陷。

探索式測試是以用戶的角度來測試，它為傳統(tǒng)的結構化測試（即從底層開始測試）做了補充，以保護頻繁迭代的用戶體驗。這意味著探索式測試不僅關注系統(tǒng)設計是否良好，還關注用戶體驗，因此它更容易發(fā)現(xiàn)比結構測試更嚴重的缺陷。

探索式測試正在被越來越多的被應用于用戶體驗測試。它通常與傳統(tǒng)結構化測試形成對比，后者僅側重于系統(tǒng)邏輯驗證（即，是否滿足要求/用戶故事中概述的驗收標準）。結構化測試保障已知風險，而探索式測試主要側重于分析潛在風險。

雖然不用事先創(chuàng)建測試用例，但是測試人員通過發(fā)散性的思維去思考每個模塊、每一步甚至每個按鈕可能會出現(xiàn)的缺陷問題，可以讓測試人員的時間和精力更多地集中在創(chuàng)造性地思維上，發(fā)現(xiàn)更多隱藏的缺陷。

比如:

我模擬成為一個用戶做一些常用操作，一定可以發(fā)現(xiàn)傳統(tǒng)測試測不到的 BUG

在發(fā)現(xiàn) BUG 的地方，一定可以發(fā)現(xiàn)更多的 BUG

在了解開發(fā)的架構后，一定可以找到更隱蔽的更深層的 BUG

……

對于對產(chǎn)品質(zhì)量有近乎完美的「偏執(zhí)狂」來說，發(fā)散性的思維是一個完美測試人員的利器，一些隱藏的難以發(fā)現(xiàn)的缺陷，確實要求測試人員有發(fā)散性思維才能比普通的測試看的更多更廣更犀利。

探索式測試準備

理解探索式測試有兩個前提：

測試之前一定會有一個全局的方針戰(zhàn)略，即整體的測試計劃，它可以避免走錯大方向、該測的部分沒有覆蓋到或者投入了大量時間到計劃之外的部分。

測試一旦開始，沒有固定的思路，測試人員不受任何先入為主的條條框框約束，根據(jù)測試途中獲取的信息，指導各自走不同的路徑，最終目的就是發(fā)現(xiàn)潛藏的缺陷。

探索式測試的類型

探索式軟件測試一共分為以下 4 種：

自由式探索式測試

基于場景的探索式測試

基于策略的探索式測試

基于反饋的探索式測試

如何進行探索式測試

從產(chǎn)品需求文檔（PRD）和原型等文檔中獲取需要測試的范圍和深度，識別軟件的根本目的，確定需要測試的核心功能點。

與項目組產(chǎn)品、開發(fā)人員溝通，獲取更多業(yè)務信息和系統(tǒng)架構信息，以確定更多的風險點。

與其他測試人員溝通，確定風險點最高的模塊或功能點。

制定探索式測程（Session）：測程表（Session Sheet）、時間盒（Time Box）、主題（Charter）。（可參見?Session-Based Test Management）

執(zhí)行探索式測試計劃，在此過程中邊測試、邊學習、邊設計、邊思考，并根據(jù)具體情況隨時更改測試策略。

測試的過程中記錄軟件邏輯，發(fā)現(xiàn) BUG，給開發(fā)人員建立缺陷。

基于旅行者的全局探索性測試方法

我們可以將軟件的測試比做是去一個城市的旅游。那么我們?nèi)绾慰焖俚娜サ轿覀兿肴サ牡胤侥?？一個辦法就是我們對這個城市很熟悉。另外一個辦法就是找一個導游或者一份地圖，用來指導我們?nèi)ピ谶@個城市旅游。

對于軟件測試來說，我們同樣需要對被測軟件很熟悉，同時也需要一份測試地圖或者測試指南，來幫助我們更好的探索性測試。

拿到地圖后，我們可以根據(jù)地圖將城市按照功能分為各種區(qū)域，而每個區(qū)域?qū)浖鄳墓δ堋１热纾?/p>

商業(yè)區(qū)：銷售特性，對應軟件包裝上面的對應特性，類似我們的需求。

歷史區(qū)：繼承特性，上一個版本遺留下來的代碼、問題或則曾經(jīng)出現(xiàn)多次 BUG 的功能或者特性。

旅游區(qū)：噱頭特性，即對應產(chǎn)品的新特性，能夠去更好的吸引新的用戶。

娛樂區(qū)：輔助特性，對應軟件的輔助特性和功能，可以做完補充測試。

旅館區(qū)：平臺或維護特性，對應軟件內(nèi)部的一些交互，不一定是由用戶來觸發(fā)的。

破舊區(qū)：問題高發(fā)區(qū)，對應軟件的歷史穩(wěn)定的代碼，一般很少人去接觸。

每個區(qū)都有特定的測試方法，有興趣的朋友可以去買『探索式軟件測試』這本書詳細了解。

這里我們拿「Web 應用升級部署」來實踐該方法。

首先，我們先了解需要測試的模塊、功能點以及相關的內(nèi)部邏輯。

然后，我們根據(jù)項目的時間確定本次測試的主題和范圍，創(chuàng)建一次探索式測試計劃，如下圖：

執(zhí)行探索式測試計劃，在測試的過程中按照旅行者測試方法的思路來創(chuàng)建用例：

按照旅行者測試方法的區(qū)域?qū)懗霎斍皡^(qū)域可能會發(fā)生的問題，然后套用每個區(qū)域的方法引申出更多的潛在問題，并依此進行測試。

記錄用例的測試結果：

測試完畢

哪個測試點出了問題，那么我們就應該重視該問題，并在此基礎上發(fā)散，比如：

「系統(tǒng)重啟后應用無法啟動」，我們知道了是因為磁盤沒有掛載，導致啟動失敗，那么服務器防火墻被重置是否也會造成無法啟動呢？那么這個問題將在下次測試的時候執(zhí)行。

最后，來看下我們的探索式地圖的設計：

可以看到通過探索性測試方法已經(jīng)分析出來了一些測試點，探索性測試另外一個重要的地方就是邊測試邊寫測試點，過程中不斷分析、不斷學習，然后行程新的探索性測試點，這樣才能完成一次成功的探索性測試。

另外還有局部探索式測試和混合探索式測試方法，本文因篇幅問題將不展開論述。

結論

探索式測試試圖把制定計劃，進行測試，重新制定計劃等多個過程有機地結合起來，每次只前進一小步，但這每一步都是由軟件過去和當前的運行狀況，軟件在測試時表現(xiàn)出來的各種行為和軟件運行時留下的種種蛛絲馬跡來即時確定的。有效地利用探索式測試技術可以幫助我們發(fā)布一個高質(zhì)量的軟件產(chǎn)品。