如何正確理解敏捷測試中的探索性測試的含義

　　探索式測試(Exploratory Testing)是敏捷測試中的重要組成部分，其價值與一般性測試如用戶故事測試或者自動化測試不同，它所關注的是“意料之外”的軟件缺陷，探索式測試作為一個研究性、啟發性和嚴肅性并存的測試方法，是一般性測試的重要補充。隨著敏捷測試的推廣，探索式測試逐漸受到大家的關注和重視。本文主要探討了測試工程師在探索式測試方面的一些誤區，并嘗試糾正這些問題。

　　誤區1：探索式測試是一種測試技術。

　　探索式測試本身不是一種測試技術，相反，它是一種可以應用于廣泛測試技術的方式或態度。所以很遺憾，測試工程師可能在現實世界中找不到一款名為“探索式測試工具”的軟件來幫助他們直觀地完成探索式測試?！稖y試計算機軟件》作者Cem Kaner明確地將探索式測試定義為“一種強調每位測試人員自由和責任的測試，每個測試人員通過將學習、測試設計、測試執行和測試結果解釋作為貫穿項目的平行活動，從而持續地優化他們的工作價值”。

　　例如，在Web應用項目中，UI功能測試必不可少。探索式測試作為一種思想就可以而且應該貫穿于UI功能測試中。

　　具體來說，測試工程師在某個時刻準備按照事先編寫好的測試用例開始測試某個網站用戶注冊的頁面時，一步步的走下去，輸入框、日期選擇器......一切看起來都很順利，但是等一下，探索式測試是一種啟發式的方法，在循規蹈矩地做著一般性功能測試的時候，我們需要同時來點不一樣的東西。

　　盯住用戶注冊界面!大腦或許可以這樣開始思考：我看到光標在閃動，噢，我之前測試是用鼠標點擊的，如果用戶只用鍵盤操作，光標在各個輸入域的遍歷是順序的嗎?動手測試之!接下來，鼠標點擊一下提交按鈕，注冊成功!噢，如果失敗會是什么樣子?用戶需要重新填寫所有數據嗎?動手測試之!下一步，用戶注冊頁面測試完畢，不過，它有幫助文檔或者提示信息嗎?作為測試工程師我們可能已經非常熟悉產品了，可第一次訪問網站并準備注冊信息的用戶了解必要的內容嗎?注冊完的用戶到底知不知道自己有什么權限呢?動手測試之......

　　凡此種種，都是些啟發式思維的小例子，從中可以看出，探索式測試作為一種方法，可以運用于任何一般性測試中，如單元測試、功能測試、性能測試、系統測試等等，只要有探索性的思想并貫徹于實踐中，探索式測試就會發揮它的重要作用，找到一般性測試沒有涵蓋的危險區域。

　　誤區2：探索式測試是一種黑盒測試。

　　測試工程師和測試經理對黑盒測試并不陌生。黑盒測試指的是測試人員把待測產品看做一個包裝完好的盒子，無法看到其中的實現細節，只通過產品規格說明書、用戶反饋等途徑來設計測試用例并執行、分析。探索式測試作為一種測試方法，在黑盒測試中確實可以得到??很好地應用，比如在上面提到的UI功能測試中，探索式測試可以作為一種有益的補充發現常規測試顧及不到的測試點。但是，探索式測試提倡的原則之一就是“努力深入了解待測產品”。常規測試用例覆蓋范圍不全面的一個重要原因就在于對產品的理解不夠深刻，所以難以挖掘出深層次的問題。探索式測試更趨近于白盒測試，要求測試工程師對產品有比較透徹的理解，從而創造性地提出和執行一些“出乎意料”的測試。

　　舉個例子，假設我們正在測試一款Web應用，部署在java/" target="_blank" >Java虛擬機為基礎的Web服務器(以WebSphere Application Server為例)上。按照常規測試用例，我們可能測試了多用戶并發訪問的情況、集群環境的情況等等，看起來黑盒測試就OK了。

　　接下來，我們嘗試從白盒測試的角度開始探索式測試。瞧瞧產品用例和源代碼，噢，看到了“synchronized (......)”、“lock.unlock()”這樣的語句，很自然地，我們意識到產品在使用多線程編程，這意味著什么呢?多核!哦，常規測試中產品是在單核還是多核環境中?單核上的性能怎么樣?多核上的性能有提高嗎?線性程度有多大?負載均衡嗎?這些問題成為了探索式測試的獵物，設計測試用例，并動手執行之，然后分析結果。

　　接著看代碼，看到了很多“new ......”，還看到了產品代碼中預分配了一些內存池，很自然地想到內存管理，當然Java的內存管理都由Java虛擬機掌控，測試工程師還能做些什么?有的!如果仔細研究Java虛擬機的機制，就會發現初始堆大小、最大堆大小、垃圾回收日志是否輸出、垃圾回收的不同算法等設置，默認情況下Web應用的運行情況如何?隨著用戶增加，堆會不會由于太小而導致運行失敗?堆大小變化了，原來的垃圾回收算法是否能夠保證Web應用的響應時間如之前快捷?這些問題又是探索式測試的啟發式線索，我們據此可以設計用例、執行測試。

　　伴隨著對產品的了解越來越深入，探索式測試會逐步發現更多的隱藏的潛在風險，通常情況下在白盒狀態下的探索式測試更具價值，因為其成果都是建立在堅實的知識和理解基礎上，其指向更有針對性。

　　誤區3：探索式測試就是隨機測試。

　　探索式測試與隨機測試的關系有些微妙。隨機測試一般是指??在無文檔、無計劃下的軟件測試，通常能夠在測試初期快速地發現重要的缺陷或者在測試末期快速地進行回歸測試，在某些資料中，將隨機測試作為探索式測試的一部分。從表面上看，“隨機”和“探索”兩個詞之間的確存在著一些聯系，但是細一想，探索并不意味著隨機，雖然是啟發式的思維方法，但是其仍然遵循著一定的有序過程，雖然這種過程無法用文字記錄下來，也無法適用于所有測試場景，但是其思維過程仍然具有合理性、有序性。所以，探索式測試是更高級的隨機測試，它借鑒了隨機測試中自由、開放的特質，但是又融入了啟發式思維的元素，較之更為嚴謹、正式。

　　下面我們來看一看James Whittaker博士在討論軟件故障模型(Software Fault Model)時，對用戶界面??采用探索式測試提出幾條的啟發式建議：

　　確保所有類型的輸入錯誤信息都觸發一次，努力找出開發人員可能會忽視的無效值。

　　針對所有輸入域，嘗試錯誤類型的數值和可能會被錯誤對待和處理的字符串。研究產品運行的操作系統和編程語言的局限性和差異性，創建一些存在問題的字符串，并執行測試。

　　在每個輸入域，鍵入所允許的最長字符。

原文轉自：http://www.anti-gravitydesign.com