首先需要聲明的是，目前我對探索式測試理論和實踐的了解還停留在1到2年前的水準，很多内容都在《探索式測試實踐之路》可以了解到的，但是需要告訴大家的是，雖然國内對et的理論和實踐進步不大，但是國外一些測試大師對et的理論和實踐都有很大的提高，包括工具、流程和總體解決方案。由于最近兩年的主要精力不在這個上面，是以對國外這兩年et的發展了解不多，如果有說的不對的地方，歡迎指出來，也讓我多學習和了解下。
雖然很多人都看了《探索式測試實踐之路》這本書，但是并不是所有人都能了解這裡面的來龍去脈，我也在很多場合說明了自己的看法，但是還是會存在一些誤讀，加上崔老師提的關于et的4個問題，我覺得非常好，很多看過拿本書的人都會或多或少有自己的看法，我趁這個機會，說下自己的看法，不一定正确。
（1）如何選擇探索的深度？
大家都應該知道，探索式測試的探索的涵義吧，基本上就是根據自己所得到的資訊去挖掘更多的新的資訊，進而判斷系統出來是否正确和合理。但是時間是有限，我們到底要挖潛到什麼時候呢？我們做測試也是一樣的道理，測試不可能很全面，什麼都想測試到，代碼覆寫率100%等。但是我們應該要測試到什麼程度呢，有哪些判斷依據呢，很多時候就是平衡，我們需要抓住一些平衡，在一定的context範圍内。
我個人是這樣了解的，首先我們必須非常清楚我們的任務具體是什麼，了解我們現在做的charter和session到底是什麼。然後，大家都知道session有自己的一些特點吧，很關鍵的一個就是 timebox，就是區間，在有限的時間區間内對被測系統就行測試設計和執行層面的探索，當然，這時候又涉及到之前劃分session的原則和合理性，這個不在這裡細說。
a. 在timebox内，測試人員對具體的任務進行探索，隻要思維不枯竭，應該不存在是否需要繼續探索的疑問。但如果不知道要測試什麼了，該怎麼辦呢？首先：靜下來，梳理之前得到的資訊，整合系統處理邏輯和所有異常流程，再次check是否覆寫到所有的測試點；第二，使用通用的測試tips提醒，check自己是否考慮到類似的測試場景，比如session tester工具就有這樣的tips；第三，正對被測子產品的分析，check相應的探索式測試方法，進行場景方法層面的思維提醒；最後，和相關人進行交流和溝通，在交流的過程中，會得到别人的啟發，進而看是否存在遺漏的測試場景。一旦存在，立即執行。
b. 假設在測試人員挖掘的資訊比較多，測試的非常high，時間過得也快，也發現了一些問題，進而無形中增加送出bug的時間，減少了真正測試的時間，這個時候，測試人員該怎麼辦呢。我個人的看法是，首先減少送出bug的時間，采用關鍵字加截圖的方式，快速記錄bug；第二，測試人員會使用工具來進行時間提醒，原來确定的時間到了後，測試人員應該停下來，仔細思考我挖掘的是否足夠，check前幾次異常測試場景是否發現bug，思考開發實作代碼邏輯和被測子產品的整體品質，綜合判斷是否需要繼續探索更新的資訊和測試執行； 第三，如果确定了繼續探索，需要考慮是否調配其他的session的測試時間，或者是否加班完成它；第四，如果能判斷覆寫80%以上的代碼覆寫率，且認可開發的品質，建議測試人員plugin out，去測試其他計劃内的session。最後，對于整合資訊并作出分析和判斷，這個過程需要非常快速和高效的，這個可能就是一些經驗的積累，建議大家多去嘗試，然後看看結果，給自己增加信心或者教訓。
（2）如何衡量探索式測試的有效性？
這個問題其實有點大，個人覺得這個和你實踐et的方式有關，目前來說，大部分人認為et就是st的補充，但是補充的效果到底怎麼樣呢，很多人可能都沒有去實踐和分析具體的細節。
對于如何衡量et的效率，我前幾年一直在思考這個問題，但是我真的沒有得出很好的答案，我目前的看法是這樣的：客觀資料 + 主觀感受。 客觀資料，主要包括發現bug的數量和認可的測試思路。主觀感受就是個人在et執行或設計過程中，對于sut的探索的過程中的主觀感受，是否真正擴充了你的思維，讓你思考更多你之前沒有思考過的角度。這裡說到的bug數量不一定能說服人，因為你不可能一個人針對同一個項目使用et 或 st來進行測試，進而比較兩個結果，這個隻能是單次元的，是 誰用誰知道啊。說et能提高效率，我采用的是機關時間内發現bug率，大家是否還記得我之前的很多分享都會說這些資料。freestyle et的方式是2.45bug/hour、et主導&st輔助的方式是1.5bug/hour、st主導&et輔助的方式是1.0bug/hour、普通st方式是0.46bug/hour。資料僅供參考。
我之前也說過，如果僅僅把et當做st的補充，實踐的政策不好的話，會造成一個問題，那就是et的很多測試執行思路和之前st做過的很多是重複的，這樣不利于et的發揮，同時在成本上是劃不來的。我們這邊是允許重複的，不可能做到完完全全的不重複，怎麼減少這個重複度，是我們大家需要思考的一個問題，我的看法是，首先從意識上就要差別我們做的et和st是不一樣的，測試思路和方法政策都不一樣，但是結果（測試思路清單）可能會存在重複的，但不影響我們的思考的重點是什麼，我們會分析和收集et和st在測試思維上的差別和測試集合，這些也許會幫助你找到et設計和執行的重點；最後，多去分析傳統測試設計方法和et測試方法的差別和背景，了解到深層次的使用方法，做一些基礎的積累，這個也會幫助大家減少這個重複度。
（3）如何避免與标準的測試流程沖突？
這個問題就是标準的流程問題了，對于et在項目中如何實踐，如何和标準的st流程融合，書中都有非常詳細的流程說明和注意點。這裡個人就說幾個看法，敢于去嘗試新的想法和東西，有時候不是壞事，也許就可能看到不一樣的天空呢，再有，我們可以選擇一些不太重要的項目進行實踐，減低風險。
這裡我需要強調的是，無論你使用什麼方式去實踐et，流程中的一些細節需要做到位，比如交叉測試的測試思路和方法，需要充分考慮自己的測試思維以及測試tips的作用。主要流程也許不會有大的差別，都需要做測試設計和測試執行，但是如何去做，會有一些細節的差别，請把這些細節做到位，再說實踐後的效果，否則，很容易做到表面，沒做到本質。
（4）如何避免隻有測試精英才能執行探索式測試？
這個問題，其實是那本書裡面，史亮也說了自己的看法，建議大家再看一遍。et執行，一方面是需要參考et設計時的測試思路，另一方面就是現場發揮，也就是執行現場整合資訊來建立更新的測試場景。
其實我個人不太同意隻有測試精英才能執行探索式測試，怎麼去做探索式測試，這邊會有一些基礎流程和規則，不管你是精英還是菜鳥，隻要掌握這些方法和政策，給一個産品的測試任務，大體上能有80%的重複程度。這裡面簡單說下這些基礎規則包含的内容：
a. et的基礎測試方法以及應用
b. 執行現場測試的敏銳性
c. 現場整合資訊的能力
d. 分析産品和評估風險的能力
另外需要說明的是，et沒有最佳實踐，et做的好與不好，不僅僅看測試工程師是否是精英，而要看很多相關的其他因素，這些情況都會或多或少影響着et實踐的資料産出，下面列出了比較重要的制約因素：
這個項目的測試的具體任務（一般和測試類型和産品本來的特點）
這個測試人員的角色（lead或sdet或ste）
具體的測試人員（技能，天賦，擅長點）
可用的測試工具和測試機器
可用的時間
可用的測試資料和文檔
從其他的人員獲得的幫助
目前的測試政策
同一個産品已經經過測試後的狀态
其實我們可以總結影響et的基本因素為：時間，測試人員，産品，任務。我們還可以分析下et過程中的幾個關鍵的因素，其實也就是一個優秀的et測試人員所具備的基本能力：
測試設計：一個優秀的測試設計師，一般有如下幾個能力：首先是分析這個産品；評估産品的所有的風險；使用現有的工具去分析或記錄；測試設計技術的熟練使用。
細心觀察：一個優秀的et測試人員必須比一般的人甚至是做st的測試人員更具有細心觀察細節的能力。et測試人員必須去觀察一切看似不正常或有疑問的地方，他還要能仔細的在推論和其他一些的假設中辨識出真理何在。
批判性思考：一個優秀的et測試人員能夠快速的評審和解釋他們的思考邏輯，并能在獨立思考中需找錯誤。這在重制bug的時候非常重要。
豐富的想法：一個優秀的et測試人員能夠比一般人産生更多且更好的想法。但通過什麼來産生這麼多且好的idea呢？這個也是et的核心了，目前et的牛人們創立了一個叫heuristics的方法，這個方法比較抽象且實踐過程在國内幾乎空白，後續讨論下。
豐富的資源：一個優秀的et測試人員能夠建構一個集測試工具，資訊資源，測試資料，同仁的一個儲存室。這樣在測試的時候，可以很快的應用這些資源
這些能力的教育訓練和培養，隻要方法和政策得當，可以在1-2個月内達到一定的水準，是以這個時候，和所謂的測試精英一起來對某個産品進行et，不會有大的差別，至少80%以上是沒問題的。
轉載自：http://blog.sina.com.cn/s/blog_6cf812be0101f0wf.html
![Winrunner的一些技巧[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)