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

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

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

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

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”。啊。。 糊涂了。。。

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

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

。。。。。

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

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

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

所以?xún)蓚€(gè)關(guān)鍵因素：前面問(wèn)題的答案＋有效的策略。

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

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

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

測試自動(dòng)化就是把手工測試的每個(gè)步驟有測試自動(dòng)化工具來(lái)完成。好處是不用人做了，缺點(diǎn)是測試過(guò)程中仍然沒(méi)有思考沒(méi)有變通。

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

探索性測試和測試自動(dòng)化各有各的優(yōu)缺點(diǎn)。至于什么時(shí)候開(kāi)始測試自動(dòng)化，什么時(shí)候開(kāi)始ET，先測試自動(dòng)化后ET,還是先ET后測試自動(dòng)化需要看項目產(chǎn)品具體情況了。沒(méi)有絕對對錯，以盡早發(fā)現bug,發(fā)現更多的的bug為宗旨。另外既然ET和測試自動(dòng)化的各自?xún)?yōu)缺點(diǎn)，微軟有些組最近兩年在嘗試“探索性測試自動(dòng)化”的方式來(lái)把探索性測試和測試自動(dòng)化相結合，充分發(fā)揮各自的優(yōu)點(diǎn)?？吹竭@里你可能要恨我了，我剛學(xué)會(huì )測試自動(dòng)化，你又提倡ET了；我剛搞清楚ET，你又開(kāi)始提倡探索性測試自動(dòng)化了。。。呵呵，人類(lèi)發(fā)展過(guò)程就是通過(guò)社會(huì )分工，揚長(cháng)避短。專(zhuān)注于做自己擅長(cháng)的事情，把自己不擅長(cháng)做的事情交給擅長(cháng)的人去做。社會(huì )發(fā)展是如此，云計算是如此，測試也是如此。有人說(shuō)過(guò)：“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?！?/P>

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