我們知道，傳統(tǒng)的測試一般是先根據(jù)需求文檔編寫出測試用例，而后由測試人員本人或他人再根據(jù)測試用例的具體描述步驟（腳本）進(jìn)行執(zhí)行與驗(yàn)證。這種已經(jīng)持續(xù)了幾十年的測試方法我們又稱之為腳本測試（Scripted Test，簡稱ST）。但是這幾年隨著敏捷開發(fā)的流行以及業(yè)務(wù)本身快速發(fā)展的需要，在開發(fā)速度不斷得到提升的同時(shí)測試卻慢慢變成了瓶頸，主要體現(xiàn)在下面兩點(diǎn)：


1. 傳統(tǒng)腳本測試的速度應(yīng)對敏捷快速交付的要求有些吃力。當(dāng)前大部分敏捷項(xiàng)目的迭代周期是1至2周，除掉需求和開發(fā)所需工時(shí)，留給測試的時(shí)間少之又少。而在這么短的時(shí)間內(nèi)還需要經(jīng)?；ㄙM(fèi)大量的時(shí)間來編寫詳細(xì)的測試用例文檔，使得測試人員不得不用加班來解決時(shí)間不足的問題；


2. 除此之外，頻繁變更的需求也導(dǎo)致測試人員需要大量的時(shí)間來更新和維護(hù)測試用例。而在上線時(shí)間的壓力下，測試人員經(jīng)常感到疲于奔命，壓力巨大。


那么測試人員在這種敏捷開發(fā)的環(huán)境下到底如何應(yīng)對才能更加從容呢？敏捷測試專家Lisa Crispin在她的著作《敏捷軟件測試：測試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南》一書中提到了解決思路，那就是大家所熟知的測試金字塔：

測試金字塔最初的原型分三層，底層是單元測試，中間層是API測試，上層GUI自動化測試。后來Lisa在金字塔的塔尖再補(bǔ)上了一片“云”，這片“云”就是探索式測試（Exploratory Test，簡稱ET）。



什么是探索式測試？


那么究竟什么是探索式測試？不同的測試專家都曾經(jīng)對其下過定義，但最新的一種定義如下：
探索式測試是一種強(qiáng)調(diào)測試人員的自由和責(zé)任以不斷優(yōu)化其工作價(jià)值的測試方法，它通過將學(xué)習(xí)、測試設(shè)計(jì)和測試執(zhí)行作為互相支持的活動在整個項(xiàng)目過程中并行執(zhí)行。



如何解讀這個定義呢？筆者建議抓住三個重點(diǎn)：
首先，它不是新的測試技術(shù)而更像是新的測試模式或風(fēng)格。正如Scrum其本質(zhì)是把工作按批次來完成但具體的開發(fā)方法沒有變化一樣，探索式測試本身也是會使用到我們熟悉的如等價(jià)類、邊界值等測試技術(shù)，同時(shí)探索式測試也可以被應(yīng)用到不同的測試階段中；



其次，和敏捷宣言更強(qiáng)調(diào)個體一樣，探索式測試同樣強(qiáng)調(diào)測試人員個人的主觀能動性，在這點(diǎn)上探索式測試的觀點(diǎn)與敏捷不謀而合，盡管探索式測試概念的提出比敏捷還要早（探索式測試由CemKaner博士在1983年提出）；


最后，探索式測試把測試學(xué)習(xí)、測試設(shè)計(jì)和測試執(zhí)行這些在傳統(tǒng)腳本測試中需要分開不同階段來完成的任務(wù)并行的執(zhí)行。當(dāng)然，這里說的并行其實(shí)就是一個小的循環(huán)迭代，以此可以最快的得到反饋，并且指導(dǎo)優(yōu)化下一輪的迭代。在這里大家是不是覺得有點(diǎn)熟悉的味道？和Scrum的核心思想是否一致？


其實(shí)探索式測試還有其它一些體現(xiàn)敏捷思想的地方，比如和敏捷輕文檔一樣，探索式測試不再要求詳細(xì)的測試用例文檔；再比如和Sprint有固定的時(shí)間盒一樣，后面介紹的Session-Based Test Management（簡稱SBTM）也是基于固定時(shí)間盒來完成等等，這里就不一一展開討論了。


探索式測試和腳本測試有什么不同？


腳本測試一般會分為兩個階段：第一階段根據(jù)需求、標(biāo)準(zhǔn)、測試規(guī)范等文檔先輸出測試計(jì)劃、測試用例等測試交付件；第二階段則根據(jù)之前準(zhǔn)備好的測試用例由本人或者他人對被測系統(tǒng)進(jìn)行操作來執(zhí)行測試，最終輸出測試報(bào)告、缺陷報(bào)告等。如下圖：

而探索式測試只有一個階段，測試人員根據(jù)一切可能掌握的信息和資料，針對被測系統(tǒng)進(jìn)行學(xué)習(xí)，在學(xué)習(xí)的同時(shí)一邊設(shè)計(jì)測試要點(diǎn)一邊進(jìn)行測試，最終得到相關(guān)測試結(jié)果。如下圖：

那么對于這兩種不同測試的效果如何呢？我們來看一個掃雷的例子，如下圖所示：黑色四邊形框框代表是雷區(qū)，而紅色小方塊則代表地雷。

如果按照腳本測試的方法，如下圖所示，會看到測試按步就班，雖然能發(fā)現(xiàn)一部分地雷，但仍然還存在很多的地雷沒有被發(fā)現(xiàn)。

而如果按照探索式測試的方法，會看到更加發(fā)散，覆蓋度更大，所以其效率更高，發(fā)現(xiàn)的地雷的也更多，如下圖：

探索式測試是隨機(jī)測試嗎？


很多人覺得，既然測試前不再需要提前準(zhǔn)備測試用例了，同時(shí)測試又要依靠個人的自由發(fā)揮，那不就變成隨機(jī)測試（Ad-Hoc Testing）了嗎？ 為了解釋這個問題，我想給大家舉一個猜數(shù)字游戲的例子：


你預(yù)先在心里想好一個1到100之間的數(shù)字（假如是66），讓我來猜。我可以問任何問題，而你只有兩種回答：是或者不是。然后你我之間通過不斷的問答，最后猜中那個數(shù)字，而問的問題次數(shù)越少得分越高。


我可能會天馬行空，想到什么數(shù)字就問什么數(shù)字，比如問是不是80？是不是2？是不是60等等，這種沒有規(guī)律隨機(jī)猜測的方式就像隨機(jī)測試一樣，相對來說是比較難快速找到答案的。



另外一種方式我會有策略，比如先問是否比50??？這里得到的回答應(yīng)該是“否”。那么我就會根據(jù)之前這個回答來判斷答案一定在50-100之間，而在下一個問題的時(shí)候我就會根據(jù)二分法原則問是否比75小，從而層層縮小范圍。這種通過對前一個結(jié)果的反饋進(jìn)行分析然后指導(dǎo)和優(yōu)化重新設(shè)計(jì)問題的方式其實(shí)就是探索式測試的核心理念所在，它和沒有策略完全依靠隨機(jī)的方式是截然不同的。

如何開展探索式測試？


這里談的開展包括兩個層次：首先，我們需要知道什么時(shí)候采用探索式測試。筆者認(rèn)為無論是腳本測試還是探索式測試，都有其優(yōu)勢和劣勢。最好的方式是兩者能結(jié)合在一起。但是至于哪個為主哪個為輔則取決于不同的項(xiàng)目情況和環(huán)境。甚至有時(shí)在時(shí)間很短的情況下直接只使用探索式也是可行的。具體的分類如下：

類別

時(shí)間緊迫

時(shí)間充裕

需求不明確/變更頻繁

探索式測試

探索式測試為主、腳本測試為輔

需求明確/變更少

探索式測試為主、腳本測試為輔

腳本測試為主、探索式測試為輔



另外，對于具體執(zhí)行層面，我們會采用一種稱之為Session-Based Testing management（簡稱SBTM）的方法來進(jìn)行測試。關(guān)于SBTM術(shù)語的中文翻譯，史亮、高翔兩位老師在他們的著作《探索式測試實(shí)踐之路》中把它翻譯成“基于測程的測試管理”，有興趣的朋友可以去查閱。



SBTM把整個測試工作分成了多個Session來完成，每個Session包含了下面幾個要點(diǎn)：

Charter：一個session所要完成的使命；

Time Box：一段固定的不被打擾的時(shí)間段，一般為60-90分鐘；

Reviewable Results：匯總的關(guān)于Session的結(jié)果測試報(bào)告，常見的是Session Sheet；

Debriefing：測試人員與測試主管的匯報(bào)交流，就本次測試的發(fā)現(xiàn)進(jìn)行檢查，并且看看優(yōu)化改進(jìn)的地方。



下面是埃森哲關(guān)于SBTM的一個簡單的測試流程，僅供各位讀者參考：

總結(jié)


探索式測試本身具備的敏捷特性，使得其非常契合應(yīng)用在敏捷開發(fā)項(xiàng)目中，可以看做是敏捷開發(fā)的最佳拍檔。當(dāng)然，探索式測試也不是能包治百病的靈丹妙藥，最關(guān)鍵還是需要測試人員了解學(xué)習(xí)探索式測試，同時(shí)愿意努力去嘗試和實(shí)踐，并且不斷去改進(jìn)和優(yōu)化它，因?yàn)檫@個世上不會有銀彈。


參考：
《探索式測試實(shí)踐之路》，史亮，高翔
《埃森哲探索式測試方案》