探索式測試的祕密 http://www.infoq.com/cn/articles/exploratory-testing-secret
先拋一個問題出來：爲什麼產品提交到測試這邊，我們的測試工程師可以發現很多開發或用戶都發現不能的Bug呢？大家可能覺得這個原因肯定有很多，比如有這些：
- 我們是測試工程師，我們是專門幹這個的
- 我們很好地理解了需求，我們使用了很多且很好的測試設計技術
- 我們有較多時間進行測試執行
- 開發人員或用戶沒有時間去進行測試
- 開發人員或用戶沒有時間不知道怎麼去進行測試
- 我們的運氣好，突然發現了這些好的Bug
(當然還有很多其他的因素，這裏就不列出所有的了)
那麼再有一個問題出來：爲什麼有些測試人員能發現其他測試人員不能發現的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的地方，提出注意事項)
模型解釋：
- 多線程創建，更新，刪除某類數據, 多線程方式包括同時打開多個頁面或瀏覽器；使用工具多線程併發操作來校驗數據操作的原子性
- 多瀏覽器或一個瀏覽器裏多個Tab進行測試，考慮cookie裏面的值的變化是否影響後續的操作；或使用場景探索模型去多角度校驗頁面信息和數據庫數據的正確性
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到底要考慮什麼：
- 打印，頁設置，打印預覽
- 打印range，打印複製，zoom
- 打印所有的，當前頁，或指定的range
可以看到這個時候我們關注的是產品的功能或特性。
第三個就是Data，也是產品的一個因素，對於這個Data Coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品能夠對數據方面有什麼考慮？我們要cover的就是這個產品能夠處理什麼樣的數據。同樣以打印機產品爲例，看看Data Coverage到底要考慮什麼：
- 打印文檔的類型
- 文檔裏面的元素，文檔的大小和結構
- 關於怎麼打印的數據(比如zoom factor; no. of copies)
可以看到這個時候我們關注的是產品使用過程中不同的數據處理。
第四個就是Platform，也是產品的一個因素，對於這個Platform Coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品依賴什麼才能使用？我們要cover的就是這個產品怎麼處理不同的依賴的。同樣以打印機產品爲例，看看Platform Coverage到底要考慮什麼：
- 打印機，Spoolers，network behavior
- 計算機
- 操作系統
- 打印機驅動程序/設備
可以看到這個時候我們關注的是產品使用過程中不同的環境和依賴。
第五個就是Operation，也是產品的一個因素，對於這個Operations Coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品怎麼使用的？我們要cover的就是這個產品使用的步驟是否合理/正確。同樣以打印機產品爲例，看看Operations Coverage到底要考慮什麼：
- 默認情況下使用
- 真實環境下使用
- 真實的場景下使用
- 複雜的流程下使用
可以看到這個時候我們關注的是產品使用的場景(包括穩定性，可用性，安全性，可擴展性，性能，可安裝性，兼容性，可測性，維護性，本地性等)。
第六個就是Time，也是產品的一個因素，對於這個Time Coverage，我們到底是測試什麼呢？我們到底要cover什麼呢？我們要測試的就是這個產品在什麼時間情況下會受影響？我們要cover的就是這個產品在不同的時間下會表現什麼樣。同樣以打印機產品爲例，看看Time Coverage到底要考慮什麼：
- 嘗試在不同的網絡或端口的速度使用
- 一個文檔打印完，緊接着打印另一個文檔，或隔很長時間再打印
- 嘗試與時間相關的限制，比如使用spooling, buffering, timeouts
- 嘗試hourly，daily，月底，或年底打印報告
- 嘗試從不同的2個工作站同時打印
可以看到這個時候我們關注的是產品使用的時候是否受時間影響。
上面我們可以看到ET在考慮覆蓋率上還是有一點自己獨特的角度，但感覺不是很具體，無細節，對於某一個類型的Coverage需要做出全面的分析，還有一個就是這些不同類型的coverage會經常組合在一起來使用的。至於組合的策略，需要在實際項目過程才能體會。