探索性測試揭秘

第第頁探索性測試揭秘探索性測試揭秘

發(fā)表于：2023-07-02來源：msdn：billliu點擊數(shù)：標簽：探索性測試

最近看了不少有關(guān)探索性測試的討論和觀點，老實說越看越糊涂。所以忍不住吐槽一下，在這里和大家討論一下探索性測試。希望對于想學習和嘗試探索性測試的朋友有所幫助澄清，或者是更加糊涂，^_^。探索性測試有很多很多的定義：百度百科的定義

最近看了不少有關(guān)探索性（測試）的討論和觀點，老實說越看越糊涂。所以忍不住吐槽一下，在這里和大家討論一下探索性（測試）。希望對于想學習和嘗試探索性測試的朋友有所幫助澄清，或者是更加糊涂，^_^。

探索性測試有很多很多的定義：

百度百科的定義："同時設(shè)計測試和執(zhí)行測試'。嗯。。什么意思?

Cem老人家的正式定義："astyleofsoftwaretestingthatemphasizesthepersonalfreedomandresponsibilityoftheindividualtestertocontinuallyoptimizethequalityofhis/herworkbytreatingtest-relatedlearning,testdesign,testexecution,andtestresultinterpretationasmutuallysupportiveactivitiesthatruninparallelthroughouttheproject'。啊。。糊涂了。。。

有人說："手工測試就是探索性測試'。更糊涂了。。。

又有人說："探索性測試就是一遍探索一遍測試'。徹底糊涂了。。。。

。。。。。

那么探索性測試到底是啥玩意啊?

我們先來看一個例子吧。很多人都玩過猜數(shù)字的游戲吧。我心里想一個數(shù)字，你來猜。你可以問任何問題，我回答"是'還是"不是'。然后你通過不斷問問題和我的回答來最終猜到我心想的數(shù)字。在猜對的情況下問的問題越少得分越高。比如，我心里想了一個數(shù)字。你可以問"大于零?'，我說"是'。你現(xiàn)在知道是正數(shù)了，你然后問"小于100?'，我說"是'。你現(xiàn)在知道是小于100的正數(shù)，你然后問"小于50?'，我說"不是'。你現(xiàn)在知道是介于50和100間的數(shù)。你繼續(xù)再問幾次后因該就能猜對了。

在這個簡單的游戲中有兩個策略至關(guān)重要：

你要根據(jù)前面問題的答案來分析和設(shè)計下一個問題。第一個問題可能不著邊，但是第二個問題會讓你跟接近你想要的答案。第三個會更加靠近，以此類推。

僅僅根據(jù)前面問題的答案來設(shè)計下一個問題可以最終幫你猜對數(shù)字，但是要想用最少的問題來猜對數(shù)字不僅要根據(jù)前面問題的答案，而且需要對問題本身其它知識加以綜合運用使用其它策略和技術(shù)。比如在知道是小于100的正數(shù)后，你可以使用binarysearch，最多猜6次就可以猜對;如果你不知道binarysearch，你可以猜是否小于90?小于80?小于70?猜上十幾次也可以猜對;或者猜是否小于99?小于98?小于97?猜上幾十次也可以猜對。所以采用不同策略直接決定你猜對的速度。

所以兩個關(guān)鍵因素：前面問題的答案+有效的策略。

探索性測試和猜數(shù)字游戲完全一樣。在這里要猜的數(shù)字就是你要找的（bug）。你問的問題就是你做的測試，每個問題的答案就是你測試過程中產(chǎn)品的輸出。第一輪你只有一個非常模糊的范圍比如測試某個模塊的某個功能。在你測試的時候通過觀察產(chǎn)品的反應(yīng)和輸出來判斷分析下一步做什么會發(fā)現(xiàn)（bug）。當然實際測試中不會像猜數(shù)字那樣直接和簡單。

下面我們來看一下一個真實的測試例子。有一次我在測試一個用戶界面的錄入頁面。用戶可以輸入比如姓名，年齡，等等很多信息，最后系統(tǒng)根據(jù)輸入的內(nèi)容處理保存到數(shù)據(jù)庫中。當然我對每一個輸入框都會嘗試不同的數(shù)據(jù)比如空值，很長的字符串，空格等等，系統(tǒng)都沒有問題。但是我注意到每次保存的時候系統(tǒng)都會生成一個本地文件，該文件的名字是其中一個輸入框的我的輸入。該輸入框的唯一限制就是不可以為空不可以超過255個字符。我想到文件名字中不可以有斜杠"\'，于是我就在該輸入框中如入"ab\cd'，它通過了輸入校驗，但是保存的時候系統(tǒng)就崩潰了。這就是探索性測試一個非常典型的例子，通過觀察分析上一次測試的產(chǎn)品反應(yīng)和輸出來判斷系統(tǒng)會有問題的地方，然后設(shè)計調(diào)整步驟和測試數(shù)據(jù)反復(fù)嘗試直到完全驗證模塊沒有問題或找到bug.

探索性測試和手工測試的區(qū)別：手工測試通常是指完全按照預(yù)先設(shè)計好的步驟一步一步人工測試直到驗證了所要驗證的功能。如果結(jié)果和預(yù)期結(jié)果一致，則驗證通過;如果不一致，則是bug.可以看出手工測試過程單調(diào)沒有思考沒有變通。在上面的猜數(shù)字的游戲中你明明已經(jīng)知道是正數(shù)，你還在按照游戲開始前設(shè)計的步驟問大于-100?大于-90?。。。。當然現(xiàn)實生活中沒有這樣的傻子，在你"手工'測試的時候你或多或少已經(jīng)使用"探索性'了，只不過你沒有意識到罷了。所以很多人誤認為探索性測試是個時髦新測試技術(shù)，研究了半天又不知道到底新在那里和自己一致做的有什么不同?；蛘呋腥淮笪蛟瓉碜约阂呀?jīng)探索了很多年了。但是探索性測試有效率高和效率低之分，所以有人干脆就把效率高ET的才叫ET,效率低的ET叫手工測試。這也是讓人糊涂的原因之一吧。

測試（自動化）就是把手工測試的每個步驟有測試（自動化）工具來完成。好處是不用人做了，缺點是測試過程中仍然沒有思考沒有變通。

Ad-hoc測試(隨機測試)：沒有預(yù)先設(shè)計好的步驟，也沒有明確目標，也沒有策略。在上面猜數(shù)字的游戲中你明明知道是正數(shù)，你還在東一榔頭，西一棒槌的亂猜等于100?等于-100?等于0?。。。當然也有可能被你一不小心蒙對了。

探索性測試和測試自動化各有各的優(yōu)缺點。至于什么時候開始測試自動化，什么時候開始ET，先測試自動化后ET,還是先ET后測試自動化需要看項目產(chǎn)品具體情況了。沒有絕對對錯，以盡早發(fā)現(xiàn)bug,發(fā)現(xiàn)更多的的bug為宗旨。另外既然ET和測試自動化的各自優(yōu)缺點，微軟有些組最近兩年在嘗試"探索性測試自動化'的方式來把探索性測試和測試自動化相結(jié)合，充分發(fā)揮各自的優(yōu)點?？吹竭@里你可能要恨我了，我剛學會測試自動化，你又提倡ET了;我剛搞清楚ET，你又開始提倡探索性測試自動化了。。。呵呵，人類發(fā)展過程就是通過社會分工，揚長避短。專注于做自己擅長的事情，把自己不擅長做的事情交給擅長的人去做。社會發(fā)展是如此，云計算是如此，測試也是如此。有人說過："Thecomputerisincrediblyfast,accurate,andstupid(test