探索式測試的秘密
我們是測試工程師，我們是專門幹這個的
我們很好地理解了需求，我們使用了很多且很好的測試設計技術
我們有較多時間進行測試執行
開發人員或使用者沒有時間去進行測試
開發人員或使用者沒有時間不知道怎麼去進行測試
我們的運氣好，突然發現了這些好的bug
(當然還有很多其他的因素，這裡就不列出所有的了)
其他測試人員對於業務需求不熟悉，該測試人員對於業務非常精
其他測試人員沒有很好的狀態，注意力不夠集中
其他測試人員的測試經驗較少，該測試人員測試經驗非常豐富
其他測試人員的運氣不怎麼好，該測試人員是突然靈感出來發現的
其他測試人員的測試環境和測試資料不一樣
(當然還有很多其他的因素，這裡就不列出所有的了)
同樣的問題還有很多，比如：為什麼我們很多好的bug都不是通過我們已經寫好的測試用例發現的呢？其實這裡面我並不是想去搞清楚很多不同的原因，根據80/20原則，我只想關注乙個主要的，那就是經驗豐富的測試工程師是如何進行測試的，是如何進行探索式測試的，他們的思維過程到底是什麼樣的，和我們通常的測試有什麼不一樣的。
很多人都會問到底什麼是探索式測試，也有很多人知道很多時候我們就是在做探索式測試(只是我們自己不知道而已)，不管怎樣，我們都期望把很好的測試方法或手段傳承下去，讓新加入測試行業的同學都可以吸收這個武林秘籍。根據看erik的ppt，我這邊大概抽象了下探索式測試的思維過程：
這個思維模型簡稱為cpie
簡要說明：collation，這個action注意就是我們需要收集所有關於sut的所有資訊，去了解和理解。
prioritization，我們要對所有需要測試的任務或模組或特性進行優先順序的劃分，這裡不說劃分原則。
investigation，劃分好後，就需要對應確定即將測試的任務進行仔細的分析並**其可能輸出的結果。
experimentation，這個action就是需要我們實際的去進行測試，看看我們的**是否正確，我們的資訊是否正確，就會變化到去影響collation階段。
這裡面部分人看的出來，還是有點站在整個專案或產品測試的角度去進行測試，那實際上對於某個小的需求和功能，是如何進行探索式測試的呢？
這裡面還需要強調的是探索式測試是乙個測試方法，不是測試技術，大家都知道有很多測試技術，特別是測試設計技術，這樣的話，就意味著進行著探索式測試，就可以完全使用這些測試技術，可以融合這些測試技術。
下面來看下et的大師 james bach是怎麼來看待et的思維過程的：
這裡面可以看到和erik的觀點還是有很多類似的地方的，都強調experiment，也就是說之前我們做的再好的測試設計和用例，只要在測試執行的時候才知道好還是不好，還有沒有更好的測試思路。同樣可以發現這些都是乙個迴圈的過程，et過程中，測試設計和測試執行是互相驅動和完善的過程，這也是和我們平時的sbt(script based testing)的最大區別。
個人認為之所以優秀的測試人員能發現一些隱含比較深的bug，主要有以下幾個關鍵的因素：
對於基本的測試設計技術的使用達到爐火純青的地步
對於錯誤猜測測試方法有一定的理解和應用
對於開發思維習慣和異常的使用者使用思路有一定的了解
這裡面談到了錯誤猜測方法，erik也提到了，這個方法在et過程中使用得非常普遍，也許很多人會認為該方法很大程度上依賴於個人的測試經驗積累，不錯，但不意味著新的測試人員不能很好地使用該方法去進行et。這是又回到了模型的概念了，個人理解的模型有三個層面，如下：
功能測試模型：一些常用功能的測試思路的大集合(增刪改查，web頁面測試等)
2. 線下bug模型：基於線下測試發現的優秀bug抽象的模型(主要針對於常出現bug的地方，提出注意事項)
模型解釋：
3. 線上故障模型：基於線上事故產生的原因進行抽象的模型(環境較複雜和特殊，完善我們的測試設計思路和創新出新的測試方法)
目前**也在做這三方面的測試模型，以應用於et的培訓資料，使測試經驗不豐富的同學也能夠快速掌握錯誤猜測方法去進行et測試，把這些模型完全掌握且能夠應用得好，那我們還怕我們的功能覆蓋率不夠全嗎。
說到覆蓋率，接下來說下et在coverage上是怎麼考慮的。我們說的coverage一般就是product coverage，同樣也是這個被測產品的一部分。那麼對於product coverage又包括哪些方面的coverage呢？
第乙個就是structure，也就是產品的乙個因素，對於這個structural coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品是怎麼構成的，我們要cover的就是構成這個產品的部分。下面以印表機產品為例，看看structural coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品的內部結構。
第二個就是function，也是產品的乙個因素，對於這個functional coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品能夠做什麼？我們要cover的就是這個產品做得什麼樣。同樣以印表機產品為例，看看functional coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品的功能或特性。
第三個就是data，也是產品的乙個因素，對於這個data coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品能夠對資料方面有什麼考慮？我們要cover的就是這個產品能夠處理什麼樣的資料。同樣以印表機產品為例，看看data coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品使用過程中不同的資料處理。
第四個就是platform，也是產品的乙個因素，對於這個platform coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品依賴什麼才能使用？我們要cover的就是這個產品怎麼處理不同的依賴的。同樣以印表機產品為例，看看platform coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品使用過程中不同的環境和依賴。
第五個就是operation，也是產品的乙個因素，對於這個operations coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品怎麼使用的？我們要cover的就是這個產品使用的步驟是否合理/正確。同樣以印表機產品為例，看看operations coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品使用的場景(包括穩定性，可用性，安全性，可擴充套件性，效能，可安裝性，相容性，可測性，維護性，本地性等)。
第六個就是time，也是產品的乙個因素，對於這個time coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品在什麼時間情況下會受影響？我們要cover的就是這個產品在不同的時間下會表現什麼樣。同樣以印表機產品為例，看看time coverage到底要考慮什麼：
可以看到這個時候我們關注的是產品使用的時候是否受時間影響。
上面我們可以看到et在考慮覆蓋率上還是有一點自己獨特的角度，但感覺不是很具體，無細節，對於某乙個型別的coverage需要做出全面的分析，還有乙個就是這些不同型別的coverage會經常組合在一起來使用的。至於組合的策略，需要在實際專案過程才能體會。
探索式測試的秘密
我們是測試工程師，我們是專門幹這個的 我們很好地理解了需求，我們使用了很多且很好的測試設計技術 我們有較多時間進行測試執行 開發人員或使用者沒有時間去進行測試 開發人員或使用者沒有時間不知道怎麼去進行測試 我們的運氣好，突然發現了這些好的bug 當然還有很多其他的因素，這裡就不列出所有的了 其他測試...
讀書筆記 探索式測試 混合探索式測試
1.講述使用者故事 2.描述需求 3.演示產品功能 4.演示整合場景 5.描述設定和安裝 6.描述警告和出錯情況 1.通過場景操作引入變化 操作後得到的新場景稱為衍生場景。刪除步驟 替換步驟 重複步驟 替換資料 替換環境 替換硬體 替換容器 瀏覽器相容性 替換版本 修改本地設定 cookie 登錄檔...
探索式測試的問與答
本節用對話的形式討論探索式測試的概念與實踐。提問者是本書的一位虛擬讀者，回答者是本書的作者們。問 探索式測試中的 探索 該如何理解？答 所謂探索是指有目的的漫遊，即帶著使命在某個空間中漫遊，但沒有預先確定的路線 kaner01 探索包括對產品與技術的深入研究和基於研究成果的實踐應用。問 如何實施探索...