探索式測試的若干問題
探索式測試的范圍
探索式測試是不是就是一種黑盒的測試?顯然探索式測試不區分黑盒還是白盒，可以用在任何一個測試里面，但是它需要我們更加理解產品，去產品內部理解產品的設計細節，才能發現一些更深層次的、隱蔽的問題。
探索式測試能不能用于硬件上?理論上來說，純硬件是很難做探索式測試的，腳本測試都很難，硬件一般我們關注的是行數驗證，硬件的老化測試，但是硬件上的軟件是可以用探索式測試的。對純硬件進行某一領域的探索式測試，如果造成了損壞，結果往往是不可逆的。
探索式測試怎么融入用戶體驗測試?探索式測試是一種 Test Style，不會局限于哪一種測試，把用戶體驗測試融入探索式測試就可以。
ET(探索式測試)主導和ST(基于測試用例的測試方法)輔助的探索式測試方法適合什么類型的項目?我們牢牢抓住探索式測試更靈活、適應性強、不需要編制繁雜的測試用例、鼓勵測試人員探索出難以發現的問題等特點，所以就能得出ET主導和ST輔助的探索式測試方法適用于：
- 采用MVP模式的敏捷項目。
- 在Bug優先級定義中，出現的Bug不會是很高優先級且項目本身是中等類型的項目(因為特別高優先級的Bug往往是需要記錄在規范的測試用例中以便審查的)。
- 離核心模塊比較邊緣的項目。
探索式測試的價值
探索式測試能夠提供給團隊什么幫助?探索式測試最大的特點就是機動性，通過探索式測試得出的結果，分析探索出來的缺陷密度，可以幫助調整團隊的測試計劃、測試策略以及測試設計，并且探索式測試可以分配到整個軟件生命周期中。
做探索式測試的價值高嗎，目前很多公司沒有推行?有很多時候，在做了探索式測試之后，才會得到一些額外的測試用例，想要得到價值高的時候，那么它的價值就是很高的。為什么公司沒有實行，因為有些公司對軟件質量的要求不高，當一個軟件的質量關乎重大利益的時候，對質量要求也很高的時候，那么探索式測試就很有價值，公司自然也會推行。
怎么在合理的時間內，進行有效的探索性測試，并且度量探索性測試的結果是合理并且是足夠的?不管是敏捷模型還是瀑布模型，會有測試輪次的概念，第一輪會跑全鏈路的 Case，第二輪做 Bug 驗證，第三輪會做全鏈路 Case 的回歸;第一輪測試往往會用交叉測試的思路，這就是探索式測試的思路，在計劃內、時間內去做探索性測試，做到什么樣的程度是可控的;還有一個判斷標準是，有沒有在一個獨立的 Session 內，到底有沒有關注到很多探索式測試的執行，你關注到在探索式測試執行中后，你在這個 Session 內測了很多東西，即使沒有發現 Bug 也沒有關系，因為你知道自己測了什么，哪部分是沒有問題的，然后根據自己的計劃想停止就停止，不停止也可以，所以進行到哪種程度是和我們的測試模式是有關系的。
度量探索式測試做得好還是不好，Bug 和問題的產出可以來度量，但很難證明探索式測試的價值，從 Bug 產出的角度來看，不同實踐方式做的探索式測試產出的 Bug 數量是不一樣的，例如用ET主導、ST主導、Free Style的 ET，還是結對測試 BugBash 得出的 Bug 產出是不一樣的;一個 Session 做完了，綜合起來看 Bug 的數量、Issue 的數量，Test Note，Test Data 可以反映出一個價值。
探索式測試的前提條件
探索式測試對測試工程師的能力有什么特別的要求?探索式測試也要分階段，這里的階段包括對軟件系統業務流以及數據流熟悉程度的不同階段，還有測試設計能力的不同階段，所以不要想到自己要做多么完美，把自己當前能力能做的探索式測試做好就行，每個階段都可以做探索式測試。
探索式測試方法論比較依賴經驗，是不是不適合新人?除了ET主導和ST輔助不適合新人以外，其它的方式新人都可以嘗試學習，只要不把自己當新人，這些方法都可以去實踐。
探索式測試怎么做
項目安排緊張，怎么保障足夠的探索式測試?瀑布模型內做探索性測試，60-120分鐘的時間都抽不出來，那就沒辦法做了，肯定是要抽一定時間來做探索式測試的，一個功能至少要進行兩到三次探索式測試，還要進行功能與功能間結合式的探索;敏捷模式基本在敏捷開發中每個 Stage 都會做，在一張卡的各個階段也會進行實施。
如何在大量回歸測試過程中，進行探索式測試?第一是先用交叉方式，第二用 PI Testing(突變測試)，可以縮小測試的范圍，精確的測試該測的地方，第三實在沒有時間，那就用 Bug Bash 借助更多人的力量，不僅能 cover回歸測試的范圍，還可以找到一些測試范圍以外的場景 case。
探索式測試的區別和優勢
探索式測試和傳統測試的區別是什么?依書中所言，從結果來看的話，傳統測試流程和方法每小時發現 Bug 的數大概在0.2-0.3個，ET輔助和ST主導每小時大概在1.0左右，ST輔助和ET主導大概在1.5左右，Feel Style大概3個 Bug，其次探索式測試為了看系統是否能做超出既定期望的事，以及做了超出期望的事之后系統所做出的反應。
探索式測試和隨機測試的區別以及探索式測試有什么優勢?adhoc測試可以理解為錯誤猜測方法的升級版，隨機測試沒有那么聚焦的目的，探索式測試有明確的聚焦，發現 Bug 核心的影響力要比 adhoc 更大，探索式測試是抱著發現 Bug 的目的去做的，更重視UT。
探索式測試和混沌工程之間有什么聯系和差異?沒有關聯，思路不同;混沌工程的核心就是故障注入，故障注入分系統層面、應用層面、中間鍵層面，斷網，超時等一些破壞性測試，有日志級別的和代碼級別的故障注入;做故障注入已經是知道這一塊會出現故障，已經知道這里會設計怎樣場景，探索式測試是不清楚情況，不斷去探索，才會知道哪里可能有問題。
探索式測試的內容延伸
探索式測試跟我們的測試覆蓋率是不是矛盾的?根本不矛盾，算測試覆蓋率的時候我們要有明確的分母才能算出，如果探索式測試是保證每個功能都測試到了，那么我們的測試覆蓋率就是100%;如果探索式測試的分母是整個測試用例集，是無法統計出測試覆蓋率的。
活文檔會花費 QA 較多時間來記錄和管理嗎?這個“活”字看大家怎么去理解，開發們的單元測試和 swagger 文檔就是典型的例子，對于 QA 來說活文檔是自動化測試代碼的更改，要改其實和修改傳統的測試用例一樣的，花時間維護活文檔帶來的好處是會使活文檔與產品代碼保持一致性，并且及時提醒哪些文檔錯了需要修改，所以花時間去管理是很有意義的。
如何提高測試設計能力?首先要了解測試的基本理論，還要加深了解被測對象，然后去熟悉相關的測試類型所需要的測試知識和工具。
探索式測試的發展
探索式測試會越來越重要嗎，它以后發展的趨勢是怎么樣的?國外是一種穩中求勝的趨勢，在 Facebook 上都經常能看到很多探索式測試一些新奇的討論;國內逐漸被自動化測試的聲浪蓋過去了，這個趨勢跟大環境有關，其實有很多公司雖然說在做敏捷，其實并不是真正的敏捷，探索式測試做得很差，甚至不知道如何實施探索式測試，真正意義上在做敏捷的公司和項目，就會覺得探索式測試是真的很重要的，得到的回報往往在敏捷項目上反映得最明顯(感覺作者也很認可敏捷)。
在我把這些問題總結出來然后去和前輩們交流的時候，有一些感悟，其實測試的本質就是對軟件系統各個變量的單變量驗證以及各種變量的組合驗證，假設整個軟件系統所有變量的組合結果為如圖所示的空間幾何體，已知的變量組合結果空間為S(可理解為我們期望軟件系統能做和不能做的事，往往是故事卡上寫的 AC)，那么未知的變量空間區域為 S’(可理解為軟件系統能不能做更多期望之外的事，以及做了更多不能做的事的反應)，那么 S’就是我們要探索的一個領域。
在我們平常測試過程中，頁面上的一個按鈕、一個選擇框其實就是一個變量，我們會去驗證按鈕和選擇框各自的功能，也會去驗證選擇框加上按鈕一起的組合功能，然后在這些變量上我們可能會去產生探索其他場景的想法;API的各個參數驗證也是相同的道理。
最后大家對探索式測試想要有更深入了解的話，可以去閱讀《探索式測試實踐之路》和《Explore It!: Reduce Risk and Increase》這兩本書。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
