探索性測試揭秘
探索性測試有很多很多的定義:
百度百科的定義:“同時設計測試和執行測試”。 嗯。。什么意思?
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”。啊。。 糊涂了。。。
有人說:“手工測試就是探索性測試”。 更糊涂了。。。
又有人說:“探索性測試就是一邊探索一邊測試”。 徹底糊涂了。。。。
。。。。。
那么探索性測試到底是啥玩意啊?
我們先來看一個例子吧。很多人都玩過猜數字的游戲吧。我心里想一個數字,你來猜。你可以問任何問題,我回答“是”還是“不是”。然后你通過不斷問問題和 我的回答來最終猜到我心想的數字。在猜對的情況下問的問題越少得分越高。比如,我心里想了一個數字。你可以問“大于零?”,我說“是”。你現在知道是正數 了,你然后問“小于100?”,我說“是”。你現在知道是小于100的正數,你然后問“小于50?”,我說“不是”。你現在知道是介于50和100間的 數。你繼續再問幾次后因該就能猜對了。
在這個簡單的游戲中有兩個策略至關重要:
1、你要根據前面問題的答案來分析和設計下一個問題。第一個問題可能不著邊,但是第二個問題會讓你跟接近你想要的答案。第三個會更加靠近,以此類推。
2、僅僅根據前面問題的答案來設計下一個問題可以最終幫你猜對數字,但是要想用最少的問題來猜對數字不僅要根據前面問題的答案,而且需要對問題本身其它 知識加以綜合運用使用其它策略和技術。比如在知道是小于100的正數后,你可以使用binary search,最多猜6次就可以猜對;如果你不知道binary search,你可以猜是否小??90?小于80?小于70?… 猜上十幾次也可以猜對;或者猜是否小于99?小于98?小于97?… 猜上幾十次也可以猜對。所以采用不同策略直接決定你猜對的速度。
所以兩個關鍵因素:前面問題的答案+有效的策略。
探索性測試和猜數字游戲完全一樣。在這里要猜的數字就是你要找的bug。你問的問題就是你做的測試,每個問題的答案就是你測試過程中產品的輸出。第一輪 你只有一個非常模糊的范圍比如測試某個模塊的某個功能。在你測試的時候通過觀察產品的反應和輸出來判斷分析下一步做什么會發現bug。當然實際測試中不會 像猜數字那樣直接和簡單。
下面我們來看一下一個真實的測試例子。有一次我在測試一個用戶界面的錄入頁面。用戶可以輸入比如姓名,年齡,等等很多信息,最后系統根據輸入的內容處理保存到數據庫中。 當然我對每一個輸入框都會嘗試不同的數據比如空值,很長的字符串,空格等等,系統都沒有問題。但是我注意到每次保存的時候系統都會生成一個本地文件,該文 件的名字是其中一個輸入框的我的輸入。該輸入框的唯一限制就是不可以為空不可以超過255個字符。我想到文件名字中不可以有斜杠“\”,于是我就在該輸入 框中如入“ab\cd”,它通過了輸入校驗,但是保存的時候系統就崩潰了。這就是探索性測試一個非常典型的例子,通過觀察分析上一次測試的產品反應和輸出 來判斷系統會有問題的地方,然后設計調整步驟和測試數據反復嘗試直到完全驗證模塊沒有問題或找到bug.
探索性測試和手工測試的區別: 手工測試通常是指完全按照預先設計好的步驟一步一步人工測試直到驗證了所要驗證的功能。如果結果和預期結果一致,則驗證通過;如果不一致,則是bug.可 以看出手工測試過程單調沒有思考沒有變通。在上面的猜數字的游戲中你明明已經知道是正數,你還在按照游戲開始前設計的步驟問大于-100? 大于-90?。。。。當然現實生活中 沒有這樣的傻子,在你“手工”測試的時候你或多或少已經使用“探索性”了,只不過你沒有意識到罷了。所以很多人誤認為探索性測試是個時髦新測試技術,研究 了半天又不知道到底新在那里和自己一致做的有什么不同。或者恍然大悟原來自己已經探索了很多年了。但是探索性測試有效率高和效率低之分,所以有人干脆就把 效率高ET的才叫ET, 效率低的ET叫手工測試。這也是讓人糊涂的原因之一吧。
測試自動化就是把手工測試的每個步驟有測試自動化工具來完成。好處是不用人做了,缺點是測試過程中仍然沒有思考沒有變通。
Ad-hoc測試(隨機測試):沒有預先設計好的步驟,也沒有明確目標,也沒有策略。在上面猜數字的游戲中你明明知道是正數,你還在東一榔頭,西一棒槌的亂猜等于100?等于-100?等于0?。。。當然也有可能被你一不小心蒙對了。
探索性測試和測試自動化各有各的優缺點。至于什么時候開始測試自動化,什么時候開始ET,先測試自動化后ET,還是先ET后測試自動化需要看項目產品具體情況了。沒有絕對對錯,以盡早發現bug,發現更多的的bug為宗旨。另外既然ET和測試自動化的各自優缺點,微軟有 些組最近兩年在嘗試“探索性測試自動化”的方式來把探索性測試和測試自動化相結合,充分發揮各自的優點。看到這里你可能要恨我了,我剛學會測試自動化,你 又提倡ET了;我剛搞清楚ET,你又開始提倡探索性測試自動化了。。。 呵呵,人類發展過程就是通過社會分工,揚長避短。專注于做自己擅長的事情,把自己不擅長做的事情交給擅長的人去做。社會發展是如此,云計算是 如此,測試也是如此。有人說過:“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。”
其實我們可以看到探索性測試入門容易或者你已經在做了多年了,難得是有效地探索性測試,或者做效率高的 ET(否則被別人不屑為手工測試了J)。那么如何根據前面的測試結果來分析和思考,如何才能敏銳地嗅覺到通向bug的種種線索?當然有多種方式來訓練自己 這方面的能力。還有如何衡量考核ET的效率,投入和產出比率?欲知詳情,請聽下回分解。。。。