探索性測試

探索性測試可以說是一種測試思維技術。它沒有很多實際的測試方法、技術和工具，但是卻是所有測試人員都應該掌握的一種測試思維方式。探索性強調測試人員的主觀能動性，拋棄繁雜的測試計畫和測試用例設計過程，強調在碰到問題時及時改變測試策略。

基本介紹

• 中文名：探索性測試
• 外文名：Exploratory Testing
• 定義：同時設計測試和執行測試
• 分類：基於場景 策略 反饋， 自由式
• 途徑：綜合的整理和分析

定義

對探索性測試最直白的定義是：同時設計測試和執行測試。探索性測試有時候會與即興測試（ad hoc testing）混淆。即興測試通常是指臨時準備的、即興的Bug搜尋測試過程。從定義可以看出，誰都可以做即興測試。由Cem Kaner提出的探索性測試，相比即興測試是一種精緻的、有思想的過程。

在對測試對象進行測試的同時學習測試對象並設計測試，在測試過程中運用獲得的關於測試對象的信息設計新的更好的測試。這個有趣的過程如下圖所示。

探索性測試強調測試設計和測試執行的同時性，這是相對於傳統軟體測試過程中嚴格的“先設計，後執行”來說的。測試人員通過測試來不斷學習被測系統，同時把學習到的關於軟體系統的更多信息通過綜合的整理和分析，創造出更多的關於測試的主意。

圖1 探索性測試

基本過程

識別軟體系統的目的；

識別軟體系統提供的功能；

識別軟體系統潛在的不穩定的區域；

在探索軟體系統的過程中記錄關於軟體的信息和問題；

類型

探索式軟體測試一共分為自由式探索式測試、基於場景的探索式測試、基於策略的探索式測試和基於反饋的探索式測試。下面將詳細介紹4種類型的套用場景。

一：自由式探索式測試

自由式探索式測試指的是對一個應用程式的所有功能，以任意次序、使用任何如數進行隨機探測，而不考慮哪些功能是否必須包括在內。自由式測試沒有任何規則和模式、只是不停的去做。很不幸，很多人認為所有的探索式測試都是自由式的，從長遠的觀點來看，這種看法低估了探索式測試技術的能力，我們在隨後將看到這類測試的一些變種。

一個自由測試用例可能會被選中成為一個快速的冒煙測試，用它來檢查是否會找到重大的崩潰或者嚴重的軟體缺陷，或是在採用先進的技術之前通過它來熟悉一個應用程式。顯然，自由式探索式測試無需也不應該進行大量的準備規則。事實上，它更像是“探索”而不是“測試”，所以我們應當相應的調整對它的期望值。

自由式測試不需要多少經驗或者信息。但是，同以下提到的探索式技術相結合後，它將成為一個非常強大的測試工具。

二：基於場景的探索式測試

基於場景的探索式測試和傳統的基於場景的測試有類似之處。兩者都涉及到一個開始點，就是用戶故事或者是文檔化的端到端場景的開始之處，那也是我們所期望的最終用戶開始執行應用程式的地方。這些場景可以來自用戶研究、應用程式、以前版本的數據等，並作為腳本用於測試軟體。探索式測試是對傳統場景測試的補充，把腳本的套用範圍擴大到了更改、調整和改變用戶執行路徑的範疇。

使用場景作為指導的探索式測試人員經常會修改他感興趣的輸入或者是追尋一些並沒有包括在腳本中的潛在副作用。不過，由於最終的目標是完成給出的場景，這些測試上的彎路、最終總是會回到腳本檔案記載的用戶主要執行路徑。

三：基於策略的探索式測試

將自由式測試探索式與具有測試老手的經驗、技能和感知融合在一起，就成為基於策略的探索式測試。它屬於自由式的探索，只是他是在現有的錯誤搜尋技術下引導完成的。基於策略的探索式測試套用所有的已知技術(如邊界值分析或組合測試)和未知的本能(如異常處理往往容易出現軟體缺陷)，來指導測試人員進行測試。

這些已知的策略是基於策略的探索式測試成功的關鍵，存儲的測試知識越豐富，測試就會更有效率。這些策略緣於積累下來的知識，它們指導軟體缺陷隱藏在哪裡，如何綜合人工輸入數據，那些代碼路徑常常出現故障。

基於策略的探索式測試結合了測試老手的經驗和探索型測試人員的隨機性。

四：基於反饋的探索式測試

基於反饋的探索式測試緣於自由式測試，但是隨著測試歷史的形成，測試人員們就會利用反饋來指導今後的探索。“覆蓋”就是典型的例子。一名測試人員通過諮詢那些覆蓋指標(代碼覆蓋、用戶界面覆蓋、特性覆蓋、輸入覆蓋或者其中的某一些組合)來選中新的測試用例，以使這些覆蓋指標得以提高。覆蓋指標只是收錄反饋信息的標誌之一。我們也會看其他標誌，如代碼改動數量和軟體缺陷密集程度等。

基於反饋的探索式測試時一種“上一次測試”：在上一次我根據應用程式的最後狀態選了每某一個輸入之後、下一次我就會選中另外一個輸入。或者是，在上一次遇到這個界面時我用A屬性，這一次我就會用B屬性。

基於反饋的探索式測試工具是非常有價值的，它可以是測試人員保存、搜尋測試歷史並據此採取實時行動。不幸的是這樣的工具很少。

適用時機

1. 當測試者是新手，可以一邊訓練一邊測試
   
2. 需要快速的對程式進行評估
   
3. 在傳統的測試腳本（Test Script）中發現新的問題需要快速驗證
   
4. 當有需要去確認另一位測試者的工作狀況
   
5. 當團隊內有熟悉相關領域知識（Domain Knowledge）的測試者
   
6. 當需要做煙霧測試
   
7. 當程式設計完後並沒有預先規劃並準備好測試腳本
   
8. 當專案使用敏捷軟體開發
   
9. 專案很複雜並且難以了解
   
10. 當測試者並沒有許可權去創建測試案例
    
11. 當想要針對某個程式錯誤進行深入調查
    
12. 當專案尚未穩定到可以執行腳本測試（Script Test）
    
13. 當想要擴大腳本測試的多樣性時
    

優點與缺點

• 優點
  
• 鼓勵創造性。
  
• 可增加機會找到新的、未知的程式缺陷。
  
• 允許測試者花較多的時間去測試一些有趣或複雜的狀況。
  
• 可較快速的對受測的系統做出快速的評量。
  
• 可讓你知道系統是否容易使用。
  
• 可變通的，有彈性的。
  
• 它比腳本測試有趣，因為它不會一成不變。
  

缺點

• 不容易被協調及調整。
  
• 無法對系統作全面性的測試。
  
• 提供有限的測試可信度。
  
• 非常的依靠測試者的領域知識（domain knowledge）以及技術。
  
• 無法保證最重要的程式錯誤一定被發現。
  
• 並不適用要執行很久的測試（例如執行一整個晚上的測試）。