http://www.infoq.com/cn/articles/ck-explore-test-mistakes
探索式測試（Exploratory Testing）是敏捷測試中的重要組成部分，其價值與一般性測試如用戶故事測試或者自動化測試不同，它所關注的是“意料之外”的軟件缺陷，探索式測試作爲一個研究性、啓發性和嚴肅性並存的測試方法，是一般性測試的重要補充。隨着敏捷測試的推廣，探索式測試逐漸受到大家的關注和重視。本文主要探討了測試工程師在探索式測試方面的一些誤區，並嘗試糾正這些問題。
誤區1：探索式測試是一種測試技術。
探索式測試本身不是一種測試技術，相反，它是一種可以應用於廣泛測試技術的方式或態度。所以很遺憾，測試工程師可能在現實世界中找不到一款名爲“探索式測試工具”的軟件來幫助他們直觀地完成探索式測試。《測試計算機軟件》作者Cem Kaner明確地將探索式測試定義爲“一種強調每位測試人員自由和責任的測試，每個測試人員通過將學習、測試設計、測試執行和測試結果解釋作爲貫穿項目的平行活動，從而持續地優化他們的工作價值”。
例如，在Web應用項目中，UI功能測試必不可少。探索式測試作爲一種思想就可以而且應該貫穿於UI功能測試中。
具體來說，測試工程師在某個時刻準備按照事先編寫好的測試用例開始測試某個網站用戶註冊的頁面時，一步步的走下去，輸入框、日期選擇器......一切看起來都很順利，但是等一下，探索式測試是一種啓發式的方法，在循規蹈矩地做着一般性功能測試的時候，我們需要同時來點不一樣的東西。
盯住用戶註冊界面！大腦或許可以這樣開始思考：我看到光標在閃動，噢，我之前測試是用鼠標點擊的，如果用戶只用鍵盤操作，光標在各個輸入域的遍歷是順序的嗎？動手測試之！接下來，鼠標點擊一下提交按鈕，註冊成功！噢，如果失敗會是什麼樣子？用戶需要重新填寫所有數據嗎？動手測試之！下一步，用戶註冊頁面測試完畢，不過，它有幫助文檔或者提示信息嗎？作爲測試工程師我們可能已經非常熟悉產品了，可第一次訪問網站並準備註冊信息的用戶瞭解必要的內容嗎？註冊完的用戶到底知不知道自己有什麼權限呢？動手測試之......
凡此種種，都是些啓發式思維的小例子，從中可以看出，探索式測試作爲一種方法，可以運用於任何一般性測試中，如單元測試、功能測試、性能測試、系統測試等等，只要有探索性的思想並貫徹於實踐中，探索式測試就會發揮它的重要作用，找到一般性測試沒有涵蓋的危險區域。
誤區2：探索式測試是一種黑盒測試。
測試工程師和測試經理對黑盒測試並不陌生。黑盒測試指的是測試人員把待測產品看做一個包裝完好的盒子，無法看到其中的實現細節，只通過產品規格說明書、用戶反饋等途徑來設計測試用例並執行、分析。探索式測試作爲一種測試方法，在黑盒測試中確實可以得到??很好地應用，比如在上面提到的UI功能測試中，探索式測試可以作爲一種有益的補充發現常規測試顧及不到的測試點。但是，探索式測試提倡的原則之一就是“努力深入瞭解待測產品”。常規測試用例覆蓋範圍不全面的一個重要原因就在於對產品的理解不夠深刻，所以難以挖掘出深層次的問題。探索式測試更趨近於白盒測試，要求測試工程師對產品有比較透徹的理解，從而創造性地提出和執行一些“出乎意料”的測試。
舉個例子，假設我們正在測試一款Web應用，部署在Java虛擬機爲基礎的Web服務器（以WebSphere Application Server爲例）上。按照常規測試用例，我們可能測試了多用戶併發訪問的情況、集羣環境的情況等等，看起來黑盒測試就OK了。
接下來，我們嘗試從白盒測試的角度開始探索式測試。瞧瞧產品用例和源代碼，噢，看到了“synchronized (......)”、“lock.unlock()”這樣的語句，很自然地，我們意識到產品在使用多線程編程，這意味着什麼呢？多核！哦，常規測試中產品是在單核還是多核環境中？單核上的性能怎麼樣？多核上的性能有提高嗎？線性程度有多大？負載均衡嗎？這些問題成爲了探索式測試的獵物，設計測試用例，並動手執行之，然後分析結果。
接着看代碼，看到了很多“new ......”，還看到了產品代碼中預分配了一些內存池，很自然地想到內存管理，當然Java的內存管理都由Java虛擬機掌控，測試工程師還能做些什麼？有的！如果仔細研究Java虛擬機的機制，就會發現初始堆大小、最大堆大小、垃圾回收日誌是否輸出、垃圾回收的不同算法等設置，默認情況下Web應用的運行情況如何？隨着用戶增加，堆會不會由於太小而導致運行失敗？堆大小變化了，原來的垃圾回收算法是否能夠保證Web應用的響應時間如之前快捷？這些問題又是探索式測試的啓發式線索，我們據此可以設計用例、執行測試。
伴隨着對產品的瞭解越來越深入，探索式測試會逐步發現更多的隱藏的潛在風險，通常情況下在白盒狀態下的探索式測試更具價值，因爲其成果都是建立在堅實的知識和理解基礎上，其指向更有針對性。
誤區3：探索式測試就是隨機測試。
探索式測試與隨機測試的關係有些微妙。隨機測試一般是指??在無文檔、無計劃下的軟件測試，通常能夠在測試初期快速地發現重要的缺陷或者在測試末期快速地進行迴歸測試，在某些資料中，將隨機測試作爲探索式測試的一部分。從表面上看，“隨機”和“探索”兩個詞之間的確存在着一些聯繫，但是細一想，探索並不意味着隨機，雖然是啓發式的思維方法，但是其仍然遵循着一定的有序過程，雖然這種過程無法用文字記錄下來，也無法適用於所有測試場景，但是其思維過程仍然具有合理性、有序性。所以，探索式測試是更高級的隨機測試，它借鑑了隨機測試中自由、開放的特質，但是又融入了啓發式思維的元素，較之更爲嚴謹、正式。
下面我們來看一看James Whittaker博士在討論軟件故障模型（Software Fault Model）時，對用戶界面??採用探索式測試提出幾條的啓發式建議：
- 確保所有類型的輸入錯誤信息都觸發一次，努力找出開發人員可能會忽視的無效值。
- 針對所有輸入域，嘗試錯誤類型的數值和可能會被錯誤對待和處理的字符串。研究產品運行的操作系統和編程語言的侷限性和差異性，創建一些存在問題的字符串，並執行測試。
- 在每個輸入域，鍵入所允許的最長字符。
- 選擇一些能夠引起底層數據運算的輸入域，多次重複輸入相同的值，觀察結果是否相同。
- 對每一個輸出域，思考其在不同情況下出現的不同結果顯示，然後將這些情況分別應用到測試中，觀察輸出域是否和預料相同。
- 對每一個輸出域，思考哪些結果是不能或者不應該出現的，然後想辦法觸發這些非法的結果，看看是否能夠實現。
- 嘗試觸發遞歸式的函數調用，如文檔中嵌套自身文檔，超鏈接中嵌套自身鏈接，類似的錯誤。
- 嘗試觸發數據的存儲溢出，觀察由此導致的結果。
看到上面的建議，我們不會認爲這是在做隨機測試。針對用戶界面的探索式測試顯得很有“條理”，雖然隨機測試也可能會涉及到上面提到的幾條建議，但這是“隨機”的，測試工程師無法控制測試覆蓋的範圍。探索式測試則不同，它會存在文字記錄，會做覆蓋率分析，比隨機測試更爲有序和可控。
誤區4：探索式測試階段在一般性測試之後。
這是一個普遍的誤解，總有人認爲探索式測試是一種後期測試，當一般性測試都結束之後，再搬出探索式測試來找找漏洞。這裏再強調一遍，探索式測試是一種測試思想和方法，不是測試技術，它可以應用於廣泛的一般性測試之中。正因爲如此，在敏捷世界中，探索式測試和一般性測試所處的位置是一樣的，沒有前後之分，只要測試工程師需要探索式測試，那麼它就可以存在。
以一個迭代週期爲例，在計劃階段，測試工程師通過了解用戶的需求和用戶故事的制定和優先級評定來審視當前的測試計劃和流程，挖掘現有計劃中未覆蓋的重要測試點，這也是探索式測試的組成部分。在正式開發階段，測試工程師在測試過程中與開發人員不斷的交流，從中尋找潛在的產品問題，有時候開發人員的一句提醒就可以成爲測試的重要線索，而探索式測試就是要凸顯這些發現問題的機會。在收尾階段，測試工程師會總結此輪迭代的缺陷列表和分析，在回顧過程中可能發現其他的問題，爲下一次的探索式測試做準備。
如果探索式測試位於迭代的後期，那麼測試工程師就會錯失計劃、開發等階段深入參與項目的機會，或者說即使深入參與了項目，但是如果沒有探索式測試的意識貫穿於其中，那麼發現問題的機會往往會從身邊溜走，而這是測試工程師最忌諱的事情。所以，如果你需要探索式測試，那麼就把這種思想應用於測試的各個階段，儘可能最大化它的價值。
誤區5：探索式測試需要老手來做。
探索式測試看起來很神祕、很酷，所以大家可能有些望而生畏，覺得是一個很高深的東西，懷疑自己是否適合做探索式測試，導致的結果就是在一個測試團隊裏可能會把探索式測試重擔交給富有經驗的老手來做。這種做法正確嗎？我們不妨先來分析一下新手與老手的主要特點。
新手缺少測試經驗，沒有經過系統的學習和思維訓練， 喜歡按照指令來做事情，不過接受新事物能力強，偶爾會因爲不懂狀況而搞出一些“小意外”；老手則是久經沙場，對測試技術和方法有充分的理解，喜歡有所突破，不過慣性思維影響了接受新鮮事物的意識。這裏所說的特點是筆者在日常工作中觀察的結果。分析完特點，再回頭看看探索式測試，它是一種啓發式的思維方式，我們需要創新，需要跳出常規測試的條條框框，需要找到“意外”的問題。對照新手、老手的特點，探索式測試更適合誰呢？這不是一個是非問題，新手、老手各有其優點：新手能夠快速打開自己的創新思路，老手可以快速深入產品的內部機理。所以，不論是新手還是老手，都不要爲自己貼上標籤，探索式測試工程師需要一定的技能，具備了這些特質，你就可以出色地完成探索式測試，敏捷測試專家Lisa Crispin總結了必要的技能：
- 小心的觀察者：觀察不正常和不期望的結果，並對正確性的假定很小心，能夠細微的觀察軟件特徵或模式。
- 認真的思考者：在運行中檢查測試並將其改到非預期的方向上，能夠解釋尋找缺陷的邏輯並提供清晰的測試狀態。
- 系統的叛逆者：思維嚴密、系統化，同時還要具有多樣化的觀點。
- 資源的挖掘者：探索測試人員應該發掘更多他們可以使用的工具、技術、測試數據、朋友和信息源。
總結
探索式測試還處於摸索和發展階段，有關對它的認識還在不斷的演變當中，探索式測試作爲一種測試方法，值得測試工程師應用於廣泛的常規測試中，它需要建立在對產品深入瞭解的基礎上，不是黑盒測試，它雖是啓發式的思維方式，但是又具有條理性、可控性，探索式測試需要貫穿於整個測試周期中，以發揮其價值。探索式測試的適合人員不是以新手老手爲衡量標準，必要的技能纔是考量的要素。