常被人問到各種探索測試的問題， 我總是不斷在重復。因此借一次回答10個問題的機會，把自己的答復都固化下來， 積累在自己的技術博客中， 希望能減少重復回答的次數。
1、探索性測試能解決什么樣的問題？不能解決什么類型的問題？
——解決快速發現功能級bug的問題；不能系統的解決性能測試、穩定性測試的問題。
2、一個產品線如何確定是否適合這種方法？如何將探索性測試方法與具體的產品結合起來？
――所有產品都適合應用，只是ET所在投入比例不同（我在硬件驅動軟件測試、Linux文件系統測試、windows客戶端、web應用都應用過）；
――方法與產品結合的辦法是：關注我的ET TOPN方法，這是測試界的數據分析與數據挖掘
3、探索性測試方法的落實？如何培訓并運用到項目中？如何讓測試人員在項目中將這些方法運行起來，或者說將方法與具體的case（涉及到業務及功能點）對應起來？
――借助腦圖工具把此次測試任務的測試對象畫于中心位置，然后把ET的方法作為第一層節點，在每個ET方法后面延伸第二層節點（由ET方法啟發出來的測試場景）
4、case是怎樣的管理粒度？如何維護？
――探索測試的用例大多不適合回歸（成本很大），只有部分最有價值的用例適合抽取回歸。
――探索測試用例繼承性的問題通過腦圖積累，每次探索測試都是在前一次腦圖的基礎上疊加增長（所有測試場景的維護管理：最高層是測試對象、然后是測試方法、最后是測試場景）
5、怎樣衡量探索性測試方法的成果？包括階段性的結果？
――初期學習衡量的方式就是：單位時間內投入測試人時發現的bug數（提升測試效率）；在測試用例設計階段用探索測試方法補充的測試用例發現的bug數占總用例發現bug（提升用例數）； 在用例執行后補充進行探索測試發現的bug數（提升測試質量）
――后期熟練后：達到代碼覆蓋率目標的測試時間（測試效率）；用戶發現bug數（測試質量）；支持項目的測試周期（測試設計時間＋測試執行時間）縮短。
6、探索性測試有哪些工具支持？有沒有可能自動化回歸？
――大部分探索測試場景不需要回歸。探索測試更多是測試設計的武器。
――腦圖工具是目前最好的工具。
7、探索性測試的測試方法是否必需通過bug分析選取，這些方法一般多久更新一次，更新的變化很大怎么辦？有通過的或者好用的必選方法嗎？
―――必須要通過bug分析選取；如果沒有bug，可以參考我所推薦的測試方法分類；
――變化很大沒有影響，說明要么產品形態和實現發生很大變化、要么團隊的人員資源發生了變化。這正是探索測試可以快速適配變化的優勢所在。
8、做ET測試時如何做到覆蓋所有的用戶場景？通過方法來到達的嗎？那選擇方法是否很關鍵？
――所有的用戶場景無法做到，這是共產主義社會。但能先做到盡可能先覆蓋到大部分的用戶行為模式（很多ET方法就是用戶行為模式的抽象與集成）。
―――選擇方法非常關鍵，決定影響你ET的效率和質量（能否覆蓋到你產品當前的主要風險方向）。
9、流程上的問題：補充性探索性測試是否可以不做漫游測試，補充性探索性測試測試設計是否不是必需用腦圖，那還是否能達到ET的目標？
――漫游測試 是ET在預測試和功能基本測試時的方法。
――所有探索測試 都必須事先進行計劃（探索測試設計腦圖就是計劃），沒有計劃就可能倒退回自由測試，無法積累、無法技術管理、方向錯誤、降低效率。
10、探索性測試一般占項目測試人力的多少比例？如何平衡投入產出比？
――初期部分同事掌握和實施探索測試、熟練后成為團隊內部教練、然后逐步全民掌握和應用探索測試。
版權聲明：本文出自 架構師Jack 的51Testing軟件測試博客：http://www.51testing.com/?293557
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。