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

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

發(fā)表于：2023-06-24來源：infoQ：崔康點(diǎn)擊數(shù)：標(biāo)簽：

如何正確理解探索性測試的含義探索式測試(ExploratoryTesting)是敏捷測試中的重要組成部分，其價(jià)值與一般性測試如用戶故事測試或者自動化測試不同，它所關(guān)注的是“意料之外”的軟件缺陷，探索式測試作為一個研究性、啟發(fā)性和嚴(yán)肅性并存的測試方法，是一般性

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

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

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

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

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

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

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

誤區(qū)2：探索式測試是一種黑盒測試。

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

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

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

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

伴隨著對產(chǎn)品的了解越來越深入，探索式測試會逐步發(fā)現(xiàn)更多的隱藏的潛在風(fēng)險(xiǎn)，通常情況下在白盒狀態(tài)下的探索式測試更具價(jià)值，因?yàn)槠涑晒际墙⒃趫?jiān)實(shí)的知識和理解基礎(chǔ)上，其指向更有針對性。

誤區(qū)3：探索式測試就是隨機(jī)測試。

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

下面我們來看一看JamesWhittaker博士在討論軟件故障模型(SoftwareFaultModel)時(shí)，對用戶界面??采用探索式測試提出幾條的啟發(fā)式建議：

確保所有類型的輸入錯誤