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