探索性測試找 bug 的效果如何?

很多人問我: 探索性測試 (Exploratory Testing, ET) 真的很會找 bug 嗎? 有沒有資料可以佐證?

這個問題很合理。ET 的支持者常常講得很有感覺, 但「感覺」不是證據。所以我把手邊看過的資料整理一下, 從最早的兩篇, 一路到近幾年的學術研究, 讓你自己判斷。

先講結論, 再看資料:

找到的 bug 數量: ET 不比 ST (Scripted Testing, 有寫測試案例的測試) 少, 有些實驗還明顯更多
花的功夫: ET 明顯少很多, 因為省掉了設計和撰寫測試案例的時間
誤報: ST 誤報的比例通常比較高, 或是至少不比 ET 低
關鍵變數: 測試人員的知識與經驗, 對 ET 效果的影響很大

一、兩篇早期的比較

(1) Defect Detection Efficiency: Test Case Based vs. Exploratory Testing

這是 Juha Itkonen 等人在 2007 年 ESEM 研討會發表的研究 (當時任職於 Helsinki University of Technology, 也就是現在的 Aalto 大學), 算是 ET 領域最早的對照實驗之一。實驗設計是這樣的:

受試者是 79 位軟體工程進階學生
測試對象是開源文字編輯器 jEdit 4.2, 研究者在裡面植入了人工缺陷
每位學生參加兩場各 90 分鐘的測試 session, 一場用 ST (論文稱為 TCT, Test Case based Testing), 一場用 ET
ST 的測試案例在 session 之前就要設計好, 這段設計時間平均花了 7 小時

結論如下:

(a) ST 和 ET 找到的 bug 數量沒有顯著差異, 種類分佈也大致相同

每人平均找到的 bug 數, ET 是 7.04 個, ST 是 6.37 個, ET 略多但未達統計顯著 (p=0.088)。也就是說, 有沒有事先寫測試案例, 對「找到多少 bug」這件事沒有顯著影響。這件事本身就很值得想一想: 我們花那麼多時間寫 test case, 到底換到了什麼?

細看分類的話, ET 找到的 usability 和 minor 等級的 bug 顯著較多, ST 找到的 severe / critical 略多一點點但不顯著。作者自己也提醒, 這些分類上的差異統計力道不強, 不要過度解讀。

(b) ST 的總投入時間約是 ET 的 6 倍

論文的數字是: ST 平均花 8.5 小時 (7 小時設計測試案例 + 1.5 小時執行), ET 只花 1.5 小時, 大約 5.7 倍。ET 省掉的就是設計和撰寫測試案例的那一段。換句話說, 在「每小時找到幾個 bug」這個指標上, ET 遠勝。

(c) ST 的誤報數量約是 ET 的兩倍

誤報 (false defect report) 在這篇的定義是: 看不懂的報告、重複的報告、或是回報了不存在的 bug。數字是每人平均 ST 2.08 個, ET 1.03 個, 差異統計顯著。

論文本身沒有解釋為什麼會這樣, 以下是我的猜測: 照著腳本走的人, 遇到跟腳本不一樣的結果就直接報, 比較少去思考「這真的是問題嗎?」。而 ET 的人一直在動腦, 反而比較會判斷。

資料來源: https://wiki.aalto.fi/display/~jitkonen@aalto.fi/Defect+Detection+Efficiency+-+Test+Case+Based+vs.+Exploratory+Testing

(2) Exploratory Testing Vs Scripted Testing: Who Wins?

這是一篇來自業界的經驗分享, 不是嚴謹的學術研究, 但因為是真實專案的數字, 很有參考價值。他們分兩個階段, 分別用 ST 和 ET 測同一個產品。(註: 這篇原始網頁目前已經打不開了, 以下數字是我當年看到時記錄下來的。)

階段 1:

ST: 6 個 major bugs
ET: 10 個 major bugs, 5 個 minor bugs
註: ST 找到的 bugs 全部都被包含在 ET 找到的裡面

階段 2:

ST: 10 個 major bugs, 8 個 minor bugs
ET: 14 個 major bugs, 5 個 minor bugs
註: ST 報告了 ET 未發現的 2 個 major bugs 和 1 個 minor bug, 但 ET 報告了 ST 未報告的 3 個 major bugs 和 1 個 minor bug

這篇有兩個值得注意的地方:

第一, ET 在 major bug 的數量上都領先。這跟很多人的直覺相反, 大家以為 ET 是隨便亂點, 只能找到表面的小問題, 但實際上嚴重的 bug 反而 ET 抓得比較多。

第二, 階段 2 顯示兩邊各有對方沒找到的 bug。這代表 ST 和 ET 不是完全互相取代的關係, 它們看問題的角度不一樣, 找到的 bug 也會有部分不重疊。

資料來源: https://www.softwaretestinghelp.com/exploratory-testing-vs-scripted-testing/

二、近幾年的學術研究怎麼說?

上面兩篇分別是 2007 年和業界經驗談, 有人會問: 有沒有更新、更嚴謹的研究? 有的, 而且結論大致一致。

(3) Are Test Cases Needed? (Itkonen & Mäntylä, 2014)

發表在 Empirical Software Engineering 期刊, 是對 2007 年那篇研究的重複實驗 (replication)。這次用 51 位學生, 一樣測 jEdit, 一樣比較 ET 和 TCT (Test-Case-based Testing, 也就是 ST)。

結果完全確認了原始研究的三個發現:

ET 和 TCT 在缺陷偵測效果上沒有差異
ET 效率較高, 因為需要的設計工作量較少
TCT 產生的誤報比 ET 多

在科學研究裡, 一個結果能被重複實驗驗證, 可信度會高很多。這篇的價值就在這裡。

資料來源: https://link.springer.com/article/10.1007/s10664-013-9266-8

(4) An Experiment on the Effectiveness and Efficiency of Exploratory Testing (Afzal et al., 2015)

同樣發表在 Empirical Software Engineering, 這篇的規模更大: 四個對照實驗, 總共 24 位業界從業人員和 46 位學生, 每場測試 session 固定 90 分鐘 (這也是 Session-Based Test Management 建議的長度)。

他們不只算 bug 數量, 還把 bug 依照偵測難度、嚴重程度、類型分類來看。結果:

ET 找到的 bug 數量顯著較多
不管是依難度、類型還是嚴重程度來看, ET 找到的都比較多
兩種方法的誤報數量沒有顯著差異

這篇跟 Itkonen 的研究有一個差別: Itkonen 說「數量差不多, 但 ET 比較省力」, Afzal 這篇直接說「在固定時間內, ET 找得比較多」。方向一致, 只是 Afzal 的結果更強。至於為什麼會更強, 摘要沒有說明, 可能跟受試者組成、測試對象、實驗安排都有關, 有興趣的人可以去讀全文。

另外值得一提, 這篇的受試者有三分之一是業界人士, 不完全是學生, 讓結果更貼近真實情況。

資料來源: https://link.springer.com/article/10.1007/s10664-014-9301-4

(5) The Role of the Tester’s Knowledge in Exploratory Software Testing (Itkonen, Mäntylä & Lassenius, 2013)

發表在 IEEE Transactions on Software Engineering。這篇不是比較 ET 和 ST, 而是回答一個更深的問題: ET 到底是靠什麼找到 bug 的?

他們觀察測試人員做 ET 的過程, 發現測試人員會運用不同類型的知識 (領域知識、系統知識、一般軟體工程知識) 來設計測試和辨識失敗。換句話說, ET 不是「隨便亂試」, 而是把測試人員腦中的知識即時轉換成測試行為。

這篇的意義在於: 它解釋了為什麼 ET 有效, 同時也暗示了 ET 的限制: 測試人員懂多少, ET 就能發揮多少。

資料來源: https://doi.org/10.1109/TSE.2012.55

(6) 經驗與訓練對 ET 效果的影響 (Gebizli & Sözer, 2017)

發表在 ICSTW 2017。這是一篇在業界做的案例研究: 19 位教育背景和經驗不同的從業人員, 用 ET 測試一套數位電視系統, 研究者統計他們找到的失效數量和嚴重程度。

結論分兩半: ET 的效率 (單位時間找到的失效數) 顯著受到教育背景和經驗的影響; 但在找到的 critical 失效數量上, 看不出教育背景的影響。

前半段跟 (5) 是同一個方向。也就是說, 當有人跟你說「我們試過 ET, 效果不好」, 你可以先問: 做 ET 的人受過什麼訓練? 對系統和領域熟不熟?

(7) Efficient and Effective Exploratory Testing of Large-Scale Software Systems (Mårtensson et al., 2021)

發表在 Journal of Systems and Software。這篇的角度不同, 是從組織層面問: 什麼條件下 ET 才會有效?

他們先回顧了 129 篇 ET 相關文獻, 再訪談六家員工超過 2,000 人的跨國公司, 整理出九個讓 ET 有效率、有效果的關鍵因素, 分成四大類:

測試人員的知識、經驗與人格特質
測試的目的與範圍 (purpose and scope)
工作方式 (ways of working)
記錄與回報 (recording and reporting)

他們據此提出 ExET (Excellence in Exploratory Testing) 模型, 讓公司可以自我評估 ET 的強項和待改善之處。

這篇的啟示是: ET 不是一個人的事, 也不是「給你自由你就會找到 bug」。要有明確的目的 (charter)、要有記錄的方式、要有支援除錯的測試環境, 效果才出得來。這也是為什麼我在教 ET 的時候, 一直強調 SBTM、charter 和 Low-Tech Dashboard。

資料來源: https://doi.org/10.1016/j.jss.2020.110890

(8) 補充: ET 在研究圈依然是活躍的主題

近幾年還有不少研究不是直接比較 ET 和 ST, 而是在 ET 的基礎上往前走, 例如:

Coppola 等人 2024 年在 IEEE Transactions on Software Engineering 探討遊戲化 (gamification) 對探索性 GUI 測試效果與效率的影響
Leveau 等人 2022 年在 Software Testing, Verification and Reliability 探討如何提升網頁應用探索性測試的多樣性
Martino 等人 2023 年在 Journal of Systems and Software 探討團隊組成對 GUI 應用探索性測試的影響

這些研究的共同前提都是: ET 有效, 問題是怎麼讓它更有效。

三、看這些資料時, 要小心的地方

我不希望大家看完就變成 ET 的無腦信徒, 所以幾個限制要講清楚:

受試者多半是學生。 雖然 Afzal 那篇有 24 位業界人士, 但整體來說學術實驗的受試者以學生為主。學生寫 test case 的能力可能比資深測試人員差, 這會讓 ST 看起來比較弱。

測試對象單一。 好幾篇研究都是測 jEdit 這個文字編輯器。在需要嚴格追溯性的領域 (例如醫療、航太), ST 的價值不只是找 bug, 還有合規證據, 這些研究沒有涵蓋。

時間是固定的。 90 分鐘的 session 對 ET 有利, 因為 ST 要先花時間設計。但如果 test case 可以重複使用很多次 (例如回歸測試), 攤提下來的成本就不一樣了。這也是為什麼我一直說: 回歸測試交給自動化, 探索性測試留給人。

ET 的效果高度依賴人。 這一點所有研究都同意。一個不懂系統的人做 ET, 結果可能比照著腳本跑還差。

四、所以, 該怎麼選?

把上面的資料綜合起來, 我的看法是:

如果目標是在有限時間內找到最多 bug, 特別是嚴重的 bug, 證據明顯偏向 ET
ST 和 ET 找到的 bug 有部分不重疊, 所以不是二選一, 而是怎麼搭配
ET 要有效, 前提是測試人員的知識 + 適當的結構 (charter、時間盒、記錄)
在 AI coding 的時代, 產出程式碼的速度變快, 驗證變成瓶頸, ET 這種「每小時找到最多問題」的方法只會更重要

回到最開始的問題: 如果你時間有限, 想要找更多 bugs, 你會怎麼選擇呢?

參考文獻

Itkonen, J., Mäntylä, M. V., & Lassenius, C. (2007). Defect Detection Efficiency: Test Case Based vs. Exploratory Testing. ESEM 2007, pp. 61–70.
Software Testing Help. Exploratory Testing Vs Scripted Testing: Who Wins? https://www.softwaretestinghelp.com/exploratory-testing-vs-scripted-testing/
Itkonen, J., & Mäntylä, M. V. (2014). Are test cases needed? Replicated comparison between exploratory and test-case-based software testing. Empirical Software Engineering, 19(2), 303–342. https://doi.org/10.1007/s10664-013-9266-8
Afzal, W., Ghazi, A. N., Itkonen, J., Torkar, R., Andrews, A., & Bhatti, K. (2015). An experiment on the effectiveness and efficiency of exploratory testing. Empirical Software Engineering, 20(3), 844–878. https://doi.org/10.1007/s10664-014-9301-4
Itkonen, J., Mäntylä, M. V., & Lassenius, C. (2013). The role of the tester’s knowledge in exploratory software testing. IEEE Transactions on Software Engineering, 39(5), 707–724. https://doi.org/10.1109/TSE.2012.55
Gebizli, C. S., & Sözer, H. (2017). Impact of education and experience level on the effectiveness of exploratory testing: An industrial case study. ICSTW 2017, pp. 23–28. https://doi.org/10.1109/ICSTW.2017.8
Pfahl, D., Yin, H., Mäntylä, M. V., & Münch, J. (2014). How is exploratory testing used? A state-of-the-practice survey. ESEM 2014. https://doi.org/10.1145/2652524.2652531
Mårtensson, T., Ståhl, D., Martini, A., & Bosch, J. (2021). Efficient and effective exploratory testing of large-scale software systems. Journal of Systems and Software, 174, 110890. https://doi.org/10.1016/j.jss.2020.110890
Coppola, R., Fulcini, T., Ardito, L., Torchiano, M., & Alégroth, E. (2024). On effectiveness and efficiency of gamified exploratory GUI testing. IEEE Transactions on Software Engineering. https://doi.org/10.1109/TSE.2023.3348036