傳統腳本測試的侷限
我們知道，傳統的測試一般是先根據需求文檔編寫出測試用例，而後由測試人員本人或他人再根據測試用例的具體描述步驟（腳本）進行執行與驗證。這種已經持續了幾十年的測試方法我們又稱之為腳本測試（Scripted Test，簡稱ST）。但是這幾年隨著敏捷開發的流行以及業務本身快速發展的需要，在開發速度不斷得到提升的同時測試卻慢慢變成了瓶頸，主要體現在下面兩點：
- 傳統腳本測試的速度應對敏捷快速交付的要求有些吃力。當前大部分敏捷項目的迭代週期是1至2周，除掉需求和開發所需工時，留給測試的時間少之又少。而在這麼短的時間內還需要經常花費大量的時間來編寫詳細的測試用例文檔，使得測試人員不得不用加班來解決時間不足的問題；
- 除此之外，頻繁變更的需求也導致測試人員需要大量的時間來更新和維護測試用例。而在上線時間的壓力下，測試人員經常感到疲於奔命，壓力巨大。
那麼測試人員在這種敏捷開發的環境下到底如何應對才能更加從容呢？敏捷測試專家Lisa Crispin在她的著作《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》一書中提到了解決思路，那就是大家所熟知的測試金字塔：
測試金字塔最初的原型分三層，底層是單元測試，中間層是API測試，上層GUI自動化測試。後來Lisa在金字塔的塔尖再補上了一片“雲”，這片“雲”就是探索式測試（Exploratory Test，簡稱ET）。
什麼是探索式測試？
那麼究竟什麼是探索式測試？不同的測試專家都曾經對其下過定義，但最新的一種定義如下：
探索式測試是一種強調測試人員的自由和責任以不斷優化其工作價值的測試方法，它通過將學習、測試設計和測試執行作為互相支持的活動在整個項目過程中並行執行。
如何解讀這個定義呢？筆者建議抓住三個重點：
- 首先，它不是新的測試技術而更像是新的測試模式或風格。正如Scrum其本質是把工作按批次來完成但具體的開發方法沒有變化一樣，探索式測試本身也是會使用到我們熟悉的如等價類、邊界值等測試技術，同時探索式測試也可以被應用到不同的測試階段中；
- 其次，和敏捷宣言更強調個體一樣，探索式測試同樣強調測試人員個人的主觀能動性，在這點上探索式測試的觀點與敏捷不謀而合，儘管探索式測試概念的提出比敏捷還要早（探索式測試由CemKaner博士在1983年提出）；
- 最後，探索式測試把測試學習、測試設計和測試執行這些在傳統腳本測試中需要分開不同階段來完成的任務並行的執行。當然，這裡說的並行其實就是一個小的循環迭代，以此可以最快的得到反饋，並且指導優化下一輪的迭代。在這裡大家是不是覺得有點熟悉的味道？和Scrum的核心思想是否一致？
其實探索式測試還有其它一些體現敏捷思想的地方，比如和敏捷輕文檔一樣，探索式測試不再要求詳細的測試用例文檔；再比如和Sprint有固定的時間盒一樣，後面介紹的Session-Based Test Management（簡稱SBTM）也是基於固定時間盒來完成等等，這裡就不一一展開討論了。
探索式測試和腳本測試有什麼不同？
腳本測試一般會分為兩個階段：第一階段根據需求、標準、測試規範等文檔先輸出測試計劃、測試用例等測試交付件；第二階段則根據之前準備好的測試用例由本人或者他人對被測系統進行操作來執行測試，最終輸出測試報告、缺陷報告等。如下圖：
而探索式測試只有一個階段，測試人員根據一切可能掌握的信息和資料，針對被測系統進行學習，在學習的同時一邊設計測試要點一邊進行測試，最終得到相關測試結果。如下圖：
那麼對於這兩種不同測試的效果如何呢？我們來看一個掃雷的例子，如下圖所示：黑色四邊形框框代表是雷區，而紅色小方塊則代表地雷。
如果按照腳本測試的方法，如下圖所示，會看到測試按步就班，雖然能發現一部分地雷，但仍然還存在很多的地雷沒有被發現。
而如果按照探索式測試的方法，會看到更加發散，覆蓋度更大，所以其效率更高，發現的地雷的也更多，如下圖：
探索式測試是隨機測試嗎？
很多人覺得，既然測試前不再需要提前準備測試用例了，同時測試又要依靠個人的自由發揮，那不就變成隨機測試（Ad-Hoc Testing）了嗎？為了解釋這個問題，我想給大家舉一個猜數字遊戲的例子：
你預先在心裡想好一個1到100之間的數字（假如是66），讓我來猜。我可以問任何問題，而你只有兩種回答：是或者不是。然後你我之間通過不斷的問答，最後猜中那個數字，而問的問題次數越少得分越高。
我可能會天馬行空，想到什麼數字就問什麼數字，比如問是不是80？是不是2？是不是60等等，這種沒有規律隨機猜測的方式就像隨機測試一樣，相對來說是比較難快速找到答案的。
另外一種方式我會有策略，比如先問是否比50小？這裡得到的回答應該是“否”。那麼我就會根據之前這個回答來判斷答案一定在50-100之間，而在下一個問題的時候我就會根據二分法原則問是否比75小，從而層層縮小範圍。這種通過對前一個結果的反饋進行分析然後指導和優化重新設計問題的方式其實就是探索式測試的核心理念所在，它和沒有策略完全依靠隨機的方式是截然不同的。
如何開展探索式測試？
這裡談的開展包括兩個層次：首先，我們需要知道什麼時候採用探索式測試。筆者認為無論是腳本測試還是探索式測試，都有其優勢和劣勢。最好的方式是兩者能結合在一起。但是至於哪個為主哪個為輔則取決於不同的項目情況和環境。甚至有時在時間很短的情況下直接只使用探索式也是可行的。具體的分類如下：
類別時間緊迫時間充裕需求不明確/變更頻繁探索式測試探索式測試為主、腳本測試為輔需求明確/變更少探索式測試為主、腳本測試為輔腳本測試為主、探索式測試為輔
另外，對於具體執行層面，我們會採用一種稱之為Session-Based Testing management（簡稱SBTM）的方法來進行測試。關於SBTM術語的中文翻譯，史亮、高翔兩位老師在他們的著作《探索式測試實踐之路》中把它翻譯成“基於測程的測試管理”，有興趣的朋友可以去查閱。
SBTM把整個測試工作分成了多個Session來完成，每個Session包含了下面幾個要點：
- Charter：一個session所要完成的使命；
- Time Box：一段固定的不被打擾的時間段，一般為60-90分鐘；
- Reviewable Results：彙總的關於Session的結果測試報告，常見的是Session Sheet；
- Debriefing：測試人員與測試主管的彙報交流，就本次測試的發現進行檢查，並且看看優化改進的地方。
下面是埃森哲關於SBTM的一個簡單的測試流程，僅供各位讀者參考：
總結
探索式測試本身具備的敏捷特性，使得其非常契合應用在敏捷開發項目中，可以看做是敏捷開發的最佳拍檔。當然，探索式測試也不是能包治百病的靈丹妙藥，最關鍵還是需要測試人員瞭解學習探索式測試，同時願意努力去嘗試和實踐，並且不斷去改進和優化它，因為這個世上不會有銀彈。
參考：
- 《探索式測試實踐之路》，史亮，高翔
- 《埃森哲探索式測試方案》
原埃森哲中國卓越測試中心負責人，測試、敏捷及DevOps專家。
ISO29119軟件測試國際標準評審組專家，埃森哲金牌講師。
本文作者陳曉鵬老師主講的【IDCF訓練營|敏捷測試方法與實踐】，【+ID：CH050791】
閱讀更多 國際DevOps教練聯合會 的文章
