探索性測試和手工測試的比較和分析

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

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

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

Cem 老人家的正式定義：“a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project”。啊。。 糊涂了。。。

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

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

。。。。。

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

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

在這個簡單的游戲中有兩個策略至關(guān)重要：
1.你要根據(jù)前面問題的答案來分析和設(shè)計下一個問題。第一個問題可能不著邊，但是第二個問題會讓你跟接近你想要的答案。第三個會更加靠近，以此類推。
2.僅僅根??前面問題的答案來設(shè)計下一個問題可以最終幫你猜對數(shù)字，但是要想用最少的問題來猜對數(shù)字不僅要根據(jù)前面問題的答案，而且需要對問題本身其它知識加以綜合運用使用其它策略和技術(shù)。比如在知道是小于100的正數(shù)后，你可以使用binary search，最多猜6次就可以猜對；如果你不知道binary search，你可以猜是否小于90？小于80？小于70？… 猜上十幾次也可以猜對；或者猜是否小于99？小于98？小于97？… 猜上幾十次也可以猜對。所以采用不同策略直接決定你猜對的速度。

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

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

下面我們來看一下一個真實的測試例子。有一次我在測試一個用戶界面的錄入頁面。用戶可以輸入比如姓名，年齡，等等很多信息，最后系統(tǒng)根據(jù)輸入的內(nèi)容處理保存到數(shù)據(jù)庫中。當(dāng)然我對每一個輸入框都會嘗試不同的數(shù)據(jù)比如空值，很長的字符串，空格等等，系統(tǒng)都沒有問題。但是我注意到每次保存的時候系統(tǒng)都會生成一個本地文件，該文件的名字是其中一個輸入框的我的輸入。該輸入框的唯一限制就是不可以為空不可以超過255個字符。我想到文件名字中不可以有斜杠“”，于是我就在該輸入框中如入“abcd”，它通過了輸入校驗，但是保存的時候系統(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？。。。。當(dāng)然現(xiàn)實生活中沒有這樣的傻子，在你“手工”測試的時候你或多或少已經(jīng)使用“探索性”了，只不過你沒有意識到罷了。所以很多人誤認為探索性測試是個時髦新測試技術(shù)，研究了半天又不知道到底新在那里和自己一致做的有什么不同?；蛘呋腥淮笪蛟瓉碜约阂呀?jīng)探索了很多年了。但是探索性測試有效率高和效率低之分，所以有人干脆就把效率高ET的才叫ET, 效率低的ET叫手工測試。這也是讓人糊涂的原因之一吧。

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

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

探索性測試和測試自動化各有各的優(yōu)缺點。至于什么時候開始測試自動化，什么時候開始ET，先測試自動化后ET,還是先ET后測試自動化需要看項目產(chǎn)品具體情況了。沒有絕對對錯，以盡早發(fā)現(xiàn)bug,發(fā)現(xiàn)更多的的bug為宗旨。另外既然ET和測試自動化的各自優(yōu)缺點，微軟有些組最近兩年在嘗試“探索性測試自動化”的方式來把探索性測試和測試自動化相結(jié)合，充分發(fā)揮各自的優(yōu)點。看到這里你可能要恨我了，我剛學(xué)會測試自動化，你又提倡ET了；我剛搞清楚ET，你又開始提倡探索性測試自動化了。。。呵呵，人類發(fā)展過程就是通過社會分工，揚長避短。專注于做自己擅長的事情，把自己不擅長做的事情交給擅長的人去做。社會發(fā)展是如此，云計算是如此，測試也是如此。有人說過：“The computer is incredibly fast, accurate, and stupid （test automation）. Man is unbelievably slow, inaccurate, and brilliant (exploratory test). The marriage of the two is a force beyond calculation。”

其實我們可以看到探索性測試入門容易或者你已經(jīng)在做了多年了，難得是有效地探索性測試，或者做效率高的ET（否則被別人不屑為手工測試了J）。