探索性測試揭秘

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

發(fā)表于：2023-07-02來源：msdn：billliu點擊數(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ù)再問幾次后因該就能猜對了。

在這個簡單的游戲中有兩個策略至關重要：

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

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

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

探索性測試和猜數(shù)字游戲完全一樣。在這里要猜的數(shù)字就是你要找的（bug）。你問的問題就是你做的測試，每個問題的答案就是你測試過程中產(chǎn)品的輸出。第一輪你只有一個非常模糊的范圍比如測試某個模塊的某個功能。在你測試的時候通過觀察產(chǎn)品的反應和輸出來判斷分析下一步做什么會發(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)品反應和輸出來判斷系統(tǒng)會有問題的地方，然后設計調(diào)整步驟和測試數(shù)據(jù)反復嘗試直到完全驗證模塊沒有問題或找到bug.

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

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

Ad-hoc測試(隨機測試)：沒有預先設計好的步驟，也沒有明確目標，也沒有策略。在上面猜數(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