如果你是一名測試人員，那么不管你對探索性測試的了解是多是少，我肯定你一定用過探索性測試的方法。想想看，你是否曾經這樣測試過？不僅僅按照測試案例或者腳本上寫什么，就完全使用那一套相同的數據、一模一樣的流程，而是根據你執行時的所見，臨時有所想和所動，進行一定程度的自由發揮？我想你肯定有過，這就是探索性測試，它將你的測試與純基于腳本的測試（script. based testing）區分開來。而這種自由發揮，因為是有大致方向和范圍的，所以也與完全盲目亂點的猴子測試（monkey testing）不同。
換言之，因為你是人，所以你比猴子和機器人都聰明，你懂得在學習中不斷完善自己，而不是漫無目的或者按圖索驥。因為你是測試人員，所以探索性測試是你必備的職業技能。而如果不經過一定的理論指導和系統實踐，我想憑著那點探索的本能，你還不足以成為一名高效的測試人員。如果想快速提高探索測試的技能，我認為最好的方法是和你測試組的伙伴一起來實踐和提高，而不是一個人練習。如果你所在的團隊還沒有過這方面的實踐，那么你可以從本文當中了解到我們團隊中基于session的探索性測試的實踐和感悟。
為什么我們選擇基于session的探索性測試？
基于session的探索性測試在2000年由James Bach和Jonathan Bach兄弟倆創建。這里的Session其實就是一段指定的時間，比如從8：30到10：00的一個半小時。探索性測試可以不基于session。至少在讀完J Whitter的“探索性測試”一書后我完全沒有覺得session是探索性測試中的一個關鍵詞。但是查閱探索性測試資料，你會發現實踐中的探索性測試很多都是基于session展開的。我們實踐了以下三個基于session的探索性測試的要點，并感受到了它的益處。
1、因為session，更專注
因為每個session都有確定的開始和結束時間，一般長度為一小時、一個半小時或者兩小時，所以在這有限的且不算太長的時間里，測試人員會更專注，從而效率更高。
我清楚地記得，有一天下午我們小組（4個測試人員）計劃了兩個各一個半小時的session。第一個session結束，當我們做debrief（下面會介紹debrief）的時候，有兩個人明確提出下面即將開始的新的session能否改成一個小時，因為過去的一個半小時太累了，“大腦都要缺氧了！”當然，剛收獲了近40個缺陷和近30個疑問的這個session，無疑大家都是很辛苦的。但是，從另一個方面，我們也看到，平時如果沒有session，大家的專注程度是否還可以提高一點呢？對我而言，雖然感到這次和我平時個人做探索性測試的專注程度類似，但在一個集體做探索性測試的氛圍下，似乎也更有時間的緊迫感了。我想這就象自己在家做模擬卷和在學校里和同學一起模擬考一樣，總有那么點不同的壓力。
2、因為charter，強迫思考
在一個既定的方向或者說章程（Charter）上一定要發現缺陷，這其實是強迫你思考和挑戰自己的思維局限。
我喜歡看釣魚比賽的節目，也感到它和測試的相通之處很有意思。例如，釣魚的挑戰在于：如何在你已經非常熟悉、覺得無魚可釣的水域找到魚；如何在一個你不熟悉的水域，快速釣到大魚；如果你可以自由選擇，你將換到哪個水域（因為根據經驗你猜想那里可能有大家伙）？精明的垂釣者不單有專業的釣竿（測試輔助工具），對天氣、水域（軟件工作環境）和魚生活習性（被測系統的功能）的了解，還要有一些很重要的臨場判斷（根據前面幾條魚的大小和難易程度判斷今天在這個地方釣上大家伙的概率，以決定下一步是繼續在這里守株待兔還是馬上轉移）和一點點的運氣。關于運氣，我覺得測試中也一定是有的，但是我更相信機遇或者運氣是比較垂青有準備的頭腦的。所以，我總是愿意花時間去多測測，花心思去少測測。
想想測試中，我們是否也面臨和釣魚類似的挑戰？如何在你已經測試了一段時間，覺得比較穩定的功能上找到新的缺陷？如何在你不熟悉的模塊，快速找到缺陷？如果一種方法找不到缺陷，接下來該換種什么樣的思路？
突破自己思維的局限，我們團隊中每個人都在實踐多種不同的方法。比如，探索性測試一書中的各種方法（遍歷法、強迫癥法、取消法、超模法。。。），自創或者借鑒的各種測試的常用方法（web測試要點、安全測試常用方法。。。）以及Test Explorer工具的小提示等等。
當我們設定所有測試人員都采用同一種方法來測試的時候，報出的不同的缺陷往往非常令人印象深刻。我們也在一起分享、總結、積極尋找測試某個軟件的最管用的探索性測試方法是哪一兩個。強迫自我突破，學習他人突破，三個臭皮匠頂個諸葛亮！
3、因為匯報（debrief），團隊力量勝于個人
我個人覺得，個人的探索性測試和團隊的探索性測試在流程上最大的差別就是匯報（debrief）。這是一個session結束后的短暫討論環節。我們采用的是Jon Bach提出的PROOF模式。PROOF即Past， Results， Obstacles， Outlook， Feelings的首字母縮寫。按照這個形式，我們會逐個分享過去這個session自己完成的工作、得到的結果、碰到的困難、接下來需要進行的工作（可以作為下一個session的目標）、自己的感覺。在這個環節里，我們會對一些公共的問題或者大的障礙進行一些溝通，但不會太長時間討論，而主要是讓團隊成員知曉一些我們認為重要的信息。這里，我們經常能夠發現共鳴或者別人輕易就解釋了我們的疑惑。如果我們做的charter是同一性質的，如易用性，那么我們會在每個人都以PROOF模式做簡要匯報后，按照session報告中缺陷和問題的記錄，快速過一遍每個缺陷和問題。這對于我們能夠及時學習和借鑒別人的測試思路，馬上運用到自己接下來的測試過程有一定的幫助。我感到：通過debrief環節的及時溝通和互相學習，我們將探索測試的精髓也擴展到了我們的團隊學習和實踐中，即在一個很短的周期內，學習和執行是融為一體的，而不是順序的、隔離的。
用ET測試自己的模塊和別人的模塊
1、測試自己的模塊
當用探索性測試方法測試自己的模塊時，在功能方面能更為有效地發現缺陷，尤其是那些復雜功能。另外，我們覺得有些探索性測試的方法應該被本模塊負責的測試人員優先采用而保證其質量，不應該由別的測試人員來嘗試。比如，確保所有按鈕都可以工作，所有報錯信息都正常顯示，所有字段最大長度檢查都通過等。因為如果一個別的測試人員隨機地去檢查字段長度，而結果是被測的正好沒問題，漏測的地方正好有問題，這就可能給團隊一個錯誤的信息。這種情況屬于基于腳本的測試沒有到位。或者別的測試人員逐個檢查每個字段長度而發現全部都沒有問題，最后才知道這是因為已經被本模塊測試人員測試過并且缺陷被修復過了，這就是一種資源的浪費。
2、測試別人的模塊
（1）為什么要測試別人的模塊？
有人也許會問：“如果每個測試人員都可以熟練有效地運用探索性測試方法來測試自己的模塊，那為什么要互相交換，去測試別人的模塊呢？”這是個很好的問題。帶著這個疑問，我們嘗試了測試別人的模塊，并發現了以下的必要性和好處。
● 避免自己難以發現的問題被遺漏
人無完人，測試人員也不例外。每個人每次測試中的盲點并不都能被自己及時發現。而換個人，這樣的問題容易很快被發現。對于團隊來說，這是一種高效的做法。
● 利于知識傳遞和儲備
測試別人的模塊，利于及時深入了解被測對象的詳細復雜邏輯。當你被要求去探索性測試一個不熟悉的復雜功能時，如果事先不做一些功課，相信你甚至都很難訂出一個自己覺得合理的charter。硬著頭皮上的后果是在一個明明有大貝殼的沙灘，花了時間卻只撿到一些零零碎碎的小貝殼。這對組織是危險的，對自己也是令人沮喪的。
● 有很多好的問題（issue）被提出，或者再次被提出
不難理解，因為視角不同，交換測試的時候會有很多好的問題被提出。再次被提出是指原來測試的人員也有類似的感覺，但不那么強烈；或者曾被諸如“用戶不會這么做或者這樣想”而遭到過開發人員的拒絕。這種問題一旦被再次提出，往往就更具有說服力，值得舊話重提。
（2）測試別人的模塊時如何選擇charter？
經過實踐，我們發現利用探索性測試測試別人的模塊時，在易用性、用戶界面顯示、模塊交互、類似功能的一致性等方面能夠高效地發現有價值的缺陷。
（3）測試別人的模塊時應避免的情況
為了避免資源的浪費，我建議在測試別人的模塊的時候先告知原來負責測試這個模塊的人員你接下來的session里測試的范圍和方向。盡量不要去測試那些已經做過大量測試的非主要功能，而主要功能則可以運用以前沒有運用過的探索性方法再深入測試。比如，原來的測試人員在主要功能的數據多樣性方面已經進行過大量測試，而按照操作順序這種探索性測試方法相對運用得比較少，這就將是你的更好的方向。
另外，測試時報告的缺陷數量固然重要，但我們的目標不是報告更多的缺陷，而是報告更多有商業價值的缺陷，所以應該避免在一些很邊緣的或者細小的地方報很多類似的缺陷，同一類型的小缺陷算一個缺陷就夠了。
（4）如何看待別人在你的模塊報告的缺陷？
正如在你的一畝三分地上，當你自己已經覺得收割完畢，而看到別人仍然收獲頗豐的時候，除了不敢相信，我很難想像你會有更開心的第一反應。而我覺得人與人的差別往往在于第二反應，在于不敢相信之后你會做什么。當別人在你的模塊報告較多的缺陷時，大多數人會仔細看一下，確認到底是什么問題，接著以“了解了”結束。有一部分人會想“如果也給我一個同樣charter的session，我能報出這個缺陷么？為什么？”還有人會去匯總背后的原因，分享這些心得，以后測試的時候能提醒自己和團隊朝這些方面改進。
經過初步嘗試團隊的基于session的探索性測試，我感到了其與個人的基于session的探索性測試的互為補充之處，也實踐了如debrief這樣的團隊實踐。下一步，我們將對測試的結果進行分析，持續探索利用探索性測試提高測試有效性和效率的有效方法。