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

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

　　誤區1：探索式測試是一種測試技術(shù)。

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

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

　　具體來(lái)說(shuō)，測試工程師在某個(gè)時(shí)刻準備按照事先編寫(xiě)好的測試用例開(kāi)始測試某個(gè)網(wǎng)站用戶(hù)注冊的頁(yè)面時(shí)，一步步的走下去，輸入框、日期選擇器......一切看起來(lái)都很順利，但是等一下，探索式測試是一種啟發(fā)式的方法，在循規蹈矩地做著(zhù)一般性功能測試的時(shí)候，我們需要同時(shí)來(lái)點(diǎn)不一樣的東西。

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

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

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

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

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

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

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

　　伴隨著(zhù)對產(chǎn)品的了解越來(lái)越深入，探索式測試會(huì )逐步發(fā)現更多的隱藏的潛在風(fēng)險，通常情況下在白盒狀態(tài)下的探索式測試更具價(jià)值，因為其成果都是建立在堅實(shí)的知識和理解基礎上，其指向更有針對性。

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

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

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

　　確保所有類(lèi)型的輸入錯誤信息都觸發(fā)一次，努力找出開(kāi)發(fā)人員可能會(huì )忽視的無(wú)效值。

　　針對所有輸入域，嘗試錯誤類(lèi)型的數值和可能會(huì )被錯誤對待和處理的字符串。研究產(chǎn)品運行的操作系統和編程語(yǔ)言的局限性和差異性，創(chuàng )建一些存在問(wèn)題的字符串，并執行測試。

　　在每個(gè)輸入域，鍵入所允許的最長(cháng)字符。

原文轉自：http://kjueaiud.com