探索性測試

探索性測試（英語：），是一種軟體測試方法。特點為在進行測試時，同時探索開發更多不同型態的測試方式，以便改善測試流程。當軟體開始測試流程後，一般測試者會使用預先設立好的測試案例來進行程式測試，而探索性測試就是為了彌補傳統的案例測試的缺點而產生。

1983年，Cem Kaner提出探索性測試，定義「探索性測試」為「一種強調個人自由與責任的測試方法，讓獨立的測試者可以藉由不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時的改善專案達到相輔相成的效果」^[1]。

歷史

探索性測試常被許多富有經驗的測試者所使用。

適用時機

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

使用時機

• 專案初期
  • 在專案的初期，測試案例的建立並不完整，可以藉由探索性測試來協助測試案例的建立以及修正。
• 專案中後期
  • 當專案接近中後期時花點時間利用探索性測試可以探索更多軟體的可能性與找出潛藏的程式缺陷，也可以對原本的測試腳本進行改善與評估。

優點與缺點

• 優點
  • 鼓勵創造性。
  • 可增加機會找到新的、未知的程式缺陷。
  • 允許測試者花較多的時間去測試一些有趣或複雜的狀況。
  • 可較快速的對受測的系統做出快速的評量。
  • 可讓你知道系統是否容易使用。
  • 可變通的，有彈性的。
  • 它比腳本測試有趣，因為它不會一成不變。
• 缺點
  • 不容易被協調及調整。
  • 無法對系統作全面性的測試。
  • 提供有限的測試可信度。
  • 非常的依靠測試者的領域知識（domain knowledge （页面存档备份，存于））以及技術。
  • 無法保證最重要的程序錯誤一定被發現。
  • 並不適用要執行很久的測試（例如執行一整個晚上的測試）。

差異

探索性測試常與即興測試混淆，基本上探索性測試使用即興測試的觀念，而將測試的結果用於提升測試人員的水準與改善腳本測試流程，即興測試未必會將測試結果用來改善腳本測試的流程。

註腳

參見

• 軟體測試
• 軟件測試模型
• 敏捷軟體開發