軟件開發面臨著快速交付的壓力，一些企業開始嘗試實踐敏捷開發方法，有些測試人員開始接觸探索性測試，以適應于敏捷開發過程。什么是探索性測試？它能夠給測試工作帶來哪些好處？通常在開始實踐探索性測試又易于陷入哪種誤區？本文將帶你一起探討這些問題。

探索性測試不是具體的某種測試技術或測試方法，而是一種測試風格或測試思維，它貌似即興的漫游測試，但是又有著本質的不同。探索性測試是有目的的漫游測試，即帶著使命在某個空間中漫游，但沒有預先確定的路線，探索包括對產品與技術的深入研究和基于成果的應用實踐。換句話講，在探索性測試思維中，沒有把測試用例的設計和執行完全分離開，而是強調了兩者在一定程度上的并行，二者相輔相成，測試用例設計指導測試執行，同時基于對測試執行結果的分析同時要改進和補充測試用例的設計。

先來看一下探索性測試產生的由來，即測試工作中的哪些問題導致了人們最終提供并實踐了探索性測試。很多企業軟件測試工作都面臨類似這樣的問題：測試人員嚴格地按照測試過程，進行測試用例設計、測試用例的評審，測試執行時又百分百地全覆蓋，可是產品到了用戶那里依然問題不少。要尋找“罪魁禍首”，好像大家都很無辜，測試用例設計人員說了，我可是按照測試策略和計劃要求對各測試項進行了設計，并且還經過了專家的有效評審；測試執行人員更是理直氣壯，所有測試用例都執行了，而且有完整的測試記錄和測試報告。問題到底出在哪里呢？傳統的測試思維其實是建立在一種假設上，即在測試執行前是可以設計出全面的、無誤測試用例，自然按照這樣的用例執行完測試是可以放心地把產品交給客戶。然而，這樣的假設真的成立嗎？非也。正是大量的測試實踐告訴我們，在沒有執行測試前，通常這時也沒有看到實際的產品是什么樣子，僅僅根據軟件需求規格說明書很難設計出全面、有效的用例，如果測試執行過程中，不對測試用例進行動態的調整，僅僅以跑完之前所設計的用例作為測試執行的目標，產品的質量根本無法保證。因此，有人提出了探索性測試的思維，這種思維是建立在另一種假設之上，即我們無法在一開始就設計出完美的測試用例，在測試執行過程中，隨著測試人員在測試執行過程中對產品不斷深入理解，而不斷地調整或重新設計測試用例，從而更加有效地發現產品缺陷，保證產品質量。

不少測試人員在剛開始接觸了探索性測試之后興奮不已，認為終于可以擺脫了測試相關的各種文檔編寫之苦了。這種想法正是很多人對探索性測試認識上的普遍誤區，探索性測試不是即興測試（ad hoc testing），更不是給你混亂的測試工作過程起一個好聽的名字。首先，探索性測試同樣需要一份經過精心設計的測試策略和測試計劃，測試策略告訴我們測試的目標在哪里，哪些是測試的重點，準備應用哪些測試的方法和工具，等等；測試計劃為后續工作有效的組織提供輸入，也是不可少的。那么測試用例文檔就不必寫了吧？非也，測試用例文檔一點都不少，只不過寫的過程有所不同。傳統的風格下，測試用例一蹴而就，后面改動很小，而采用探索性測試思維，測試用例編寫與測試執行交疊在一起。首先在測試沒有執行前，要根據當前對產品的認識設計出部分用例，這時不要嘗試設計出所有的用例，因為由于當前對產品認識不夠，你所設計的很多用例有可能到執行時沒有絲毫用途，浪費了寶貴的時間。在測試執行過程，要不斷地對測試結果進行思考和總結，加深對產品的應用和操作場景的理解，再設計用例以發現之前用例無法發現的問題。或許你還是在糾結為何要把測試用例寫出來，難道不寫不可以嗎？可以，但是承擔不寫的代價。眾所周知，同一個測試點要被多次重復測試的，如回歸測試會導致重復測試，版本升級后也會導致大量的重復測試，如果測試用例沒有文檔化，如何保證下次測試時不遺漏？如何保證測試人員變換后仍然執行了你在頭腦中所設計用例？

探索性測試是一種新生的測試思維，在不誤用和濫用探索性測試的前提下，在某些情況下它不失為更合適的一種工作風格，它消除了過去“官僚式”的作為，下達命令（設計測試用例），然后執行，而是給測試執行人員更大的權力，當然能力要求也更高，并且把過去枯燥被動的執行測試活動變成了有趣的、充滿創意的工作。