問題驅動測試（PDT）：致命 Bug 藏在你沒問過的問題裡

前言：一個讓人難受的場景

想像一個畫面：迭代尾聲，你加班把上百條測試案例全部跑完，報告漂漂亮亮、綠燈整片，信心滿滿地說「可以上線了」。結果上線不到一小時，客服群組跳出第一個 ticket——某個你從來沒想過的操作組合，讓後端噴出 500。

你心裡浮出那個很難面對的問題：

我到底測了什麼？我測的是「案例」，還是「問題」？

這篇文章想認真回答這件事。因為這正是我開這個部落格想寫的第一個核心命題——測試的靈魂不在於執行腳本，而在於提問。 而把這份提問變成一種紀律的做法，我稱為 問題驅動測試（Problem-Driven Testing, PDT）。

一、先看清楚「腳本化測試」的優點與盲點

在談 PDT 之前，我必須先幫「腳本化測試（Scripted Testing）」講句公道話——它不是錯的，只是不夠。

它的優點是真實存在的

可重複：同一份案例給不同人跑，結果可以對得起來
易交接：新人來了，照著跑就能上工
覆蓋率可量化：向上報告時有數字可以給
建立流程紀律：尤其在合規嚴格的產業（金融、醫療），腳本化幾乎是必要條件

所以請不要誤會：我不是要你把腳本燒掉。

但它有三個結構性盲點

盲點一：只驗證「預期情況」，處理不了「未預期情況」。

腳本案例的寫法是「Given X, When Y, Then Z」。問題是，真實世界的 bug 常常發生在「有人做了 W」——那個你寫案例時根本沒想到的 W。

這不只是理論——測試圈流傳一個段子梗圖完美詮釋了這件事：

一位 QA 工程師走進酒吧，點了 1 杯啤酒、點了 0 杯啤酒、點了 99999 杯啤酒、點了 -1 杯啤酒、點了一條蜥蜴——系統都正常處理。真正的使用者走進來之後，問了一句「廁所在哪？」酒吧當場爆炸。

盲點二：腳本本身就是一種假設，而 bug 常常躲在假設之外。

每一條測試案例，都是你對「系統應該怎麼用」的一個猜測。但致命的 bug 很少出現在你猜對的地方——它們藏在你沒想到要猜的地方。

盲點三：複雜系統中，排列組合爆炸，腳本永遠寫不完。

一個中等規模的 App，把所有使用者狀態 × 網路狀態 × 裝置狀態 × 帳號權限組合起來，輕易就是上萬種情境。你不可能寫完。那你寫的那 300 條，憑什麼相信它涵蓋了最危險的那幾種？

小結

腳本化測試解決的是「可重複的驗證」問題，解決不了「未知風險的發現」問題。而致命 bug，幾乎全都屬於後者。

二、那什麼是問題驅動測試（PDT）？

一句話定義

問題驅動測試，是以「尚未回答的問題」為測試的起點，而不是以「預先寫好的案例」為起點。

這個差異聽起來很小，其實整個工作流程會翻過來。

三個核心前提

前提一：每個軟體都藏著我們還不知道的風險。

測試員的工作不是「證明系統沒問題」，而是「找出我們原本以為沒問題、但其實有問題的地方」。如果你相信系統是完美的，你根本不需要測試。

前提二：測試的目的，是降低「對品質的不確定性」。

不是產出通過數，不是覆蓋率報表，不是「我跑完了」——是讓團隊更清楚產品目前站在什麼位置。一個找到關鍵風險的測試員，比一個跑完五百條案例但什麼都沒問的測試員更有價值。

前提三：腳本是工具，不是目的。

腳本存在是為了幫你記得「底線要守住」，不是為了定義「你只能做這些」。

它不是我發明的，它有血統

為了誠實交代，PDT 不是我發明的詞彙，它深受幾個思想流派的影響：

探索式測試（Exploratory Testing）：Cem Kaner、James Bach、Michael Bolton 發展的流派，強調「學習、設計、執行」同步進行。Bach 對測試本質下過一個我很喜歡的定義——

“Testing is questioning a product in order to evaluate it.”

一字不差，這就是 PDT。想深入的讀者可以去翻三人合著的《Lessons Learned in Software Testing》，那本書是 Context-Driven School 的入門經典，也是 PDT 背後學理的主要源頭。
Context-Driven School：主張沒有最佳實務，只有「脈絡下的合適做法」。
風險導向測試（Risk-Based Testing）：共享「以風險優先」的資源分配邏輯。

我之所以還是特別用「問題驅動」這個名字，是因為我想把提問的動作本身，放到方法論的正中央。

一個跨領域的印證：連閱讀都是這樣

這個「帶著問題進場」的做法，其實不只在測試圈成立。

Mortimer Adler 在《如何閱讀一本書》裡，給讀者的核心建議之一就是：

閱讀一本書之前，先在心裡帶著一兩個想問作者的問題進場，你吸收到的會比什麼都沒帶進去的人多出好幾倍。

這跟 PDT 是完全同一件事。不帶問題進場，測試和閱讀一樣，都只是讓內容流過你。

換句話說，PDT 不是什麼 QA 的獨門絕學——它只是把人類在閱讀、研究、訪談、做判斷時早就在用的求知姿態，系統化到測試工作裡。如果你是那種讀書會先翻目錄、畫重點、邊讀邊提問的人，恭喜，你其實天生就有 PDT 的腦袋。

三、PDT vs. 腳本化測試：本質差異對照表

維度	腳本化測試	問題驅動測試（PDT）
起點	預先寫好的案例	一個尚未回答的問題
產出	Pass / Fail	新的資訊、新的風險、下一個問題
測試員角色	執行者	研究者
評估標準	案例通過率、覆蓋率	風險揭露程度、不確定性下降
失敗的定義	案例不通過	跑完什麼都沒學到
最適場景	穩定流程、回歸守門、合規驗證	複雜系統、新功能、高風險變更、陌生模組

如果你只能從這篇文章帶走一件事，我希望是這張表裡的這一行：

腳本化測試的失敗是「案例沒過」；問題驅動測試的失敗是「跑完什麼都沒學到」。

四、為什麼在複雜系統中，PDT 才是抓出致命 Bug 的關鍵？

複雜系統的三個特徵

多狀態：使用者、訂單、裝置、連線⋯⋯每個物件都有自己的狀態機
多依賴：前端依賴 API、API 依賴 DB、DB 依賴網路、網路依賴⋯⋯你知道的
非線性行為：兩個小問題加在一起，不等於兩個小問題——可能是一個大 crash

致命 bug 的分布

我自己踩過坑、看過事故報告後，有一個很鮮明的觀察：致命 bug 幾乎從不出現在「主流程」上。它們出現在：

邊界：時間剛好到 00:00、剛好滿 100 筆、字串長度剛好 256
互動：A 功能跟 B 功能同時進行時
時序：請求比預期晚到 3 秒、事件觸發順序顛倒
異常路徑：使用者按了「返回」、網路中斷、權限剛好被撤銷

這四類情境的共通點是什麼？它們都很難被腳本預先列舉。因為能預先列舉的，都是設計者已經想到的；而這些 bug 的本質，就是「設計者沒想到」。

PDT 的武器：一個不斷循環的思考節奏

PDT 處理這類 bug 的方式，不是多寫幾條案例，而是換一種思考節奏：

提問：針對眼前這個模組，冒出一個還沒被回答的問題
假設：猜一個答案——「如果我這樣操作，系統應該會這樣反應」
反證：動手試試看，驗證假設是不是真的成立
擴散：不論結果對錯，都讓它生出下一個該問的問題

這是「怎麼想」的節奏，會持續循環跑，直到你對模組的不確定性下降到可接受程度。至於想什麼——也就是具體該問哪些問題——留到第五節再給你可直接帶走的提問模板。

一個小例子（我自己踩過的坑）

我之前寫 Selenium 自動化的時候，有一段測試一直穩定通過。我按照腳本化的邏輯，當然就繼續跑下去。某天我隨手問了一個問題：

「如果頁面裡有兩個相同 ID 的元素，我的 By.ID 到底抓到了誰？」

這個問題不在我的腳本裡。但我決定花 10 分鐘去追。結果我發現——我半年來以為在測的按鈕，根本不是實際使用者會看到的那一顆。（完整故事寫在 Selenium踩到的坑。）

那一刻我第一次真正懂了 PDT 的價值：腳本守護的是我已經知道的東西，提問揭露的是我不知道自己不知道的東西。

五、怎麼開始做 PDT？（讓你明天上班就能用）

講到這裡，如果你只收到「要有提問精神」這種雞湯，我覺得我欠你一個退費。所以這節給你可以直接帶走的東西。

從「問一個好問題」開始——四個提問模板

第四節講的是「怎麼想」的節奏（提問 → 假設 → 反證 → 擴散）。這一節給你「想什麼」——面對任何一個功能、一個模組、一個新需求，先強迫自己回答這四個問題再動手：

最糟情境題：這個功能如果壞掉，對使用者/公司最糟會怎樣？
誤用情境題：什麼情況下，使用者會做出設計者沒想到的事？
假設揭露題：這個功能「之所以能運作」，背後倚賴了哪些沒被寫出來的假設？
半途情境題：這個流程如果「只發生一半」，系統會處在什麼狀態？

這四個問題只要認真問，你會發現每一題都能衍生出十幾個測試點，而且全部都是腳本裡沒有的。

搭配工具

心智圖：把提問過程畫出來，問題會自己長問題
啟發式清單（Heuristics）：像 James Bach 的 SFDPOT、CRUSSPIC STMPL，當作「提問的提詞卡」
測試筆記（Session-Based Test Management）：記下你「問了什麼、試了什麼、學到什麼、還剩什麼沒問」，這是 PDT 最重要的交付物

最關鍵的觀念：PDT 不取代腳本化測試

請務必把這句話收好：

腳本化測試守底線，問題驅動測試追風險。兩者是疊加關係，不是替換關係。

你仍然需要腳本來做回歸、做合規、做可重複驗證。你只是在腳本之外，額外留出時間與精力，讓自己以研究者的姿態去追問那些腳本永遠追不到的風險。

六、「可是我哪有時間做 PDT？」——PDT 的四個實務階段

講到這裡，我猜你心裡已經冒出這句話了：

「聽起來很棒啦，但我手上一個 App 的 UI 手動回歸測試就要兩天——一天半跑案例、半天寫報告。你要我在哪裡擠出 PDT 的時間？」

這是最真實的問題。我自己就卡在這個預算裡。所以這節不談理想，只談現實可操作的版本。

先講一件讓你放心的事：你很可能已經在做 PDT 了，只是沒意識到。 而且 PDT 不是一個開關，是一個光譜。

你可能已經在做 PDT 了——三個徵兆

跑案例跑到一半突然停下來：「奇怪，這個按鈕剛剛為什麼會這樣反應？」於是多點了幾下
測試報告裡除了 pass/fail，還多寫了一段「順便觀察到⋯⋯」
對某個 feature 有「總覺得哪裡怪怪的」的直覺，決定在時間之外多測一輪

這些都是 PDT 的雛形。 如果你有過這些動作，你不是 0 分，你已經在 Level 1 了。

PDT 的四個階段

我把實務上看到的 PDT 強度，分成四個階段。對照看看你在哪一層：

階段	時間配置	行為特徵	典型產出
Level 1：偶發式	95% 跑腳本 + 5% 隨機追問	遇到「怪怪的」才停下來，不規劃	案例結果 + 零星觀察
Level 2：保留式	80% 跑腳本 + 20% 刻意探索	測前列「想問的問題清單」，刻意留時間	結構化觀察 + 風險提示
Level 3：策略式	50% 跑腳本 + 30% 探索 + 20% 風險規劃	開始前做風險分析，依風險分配時間	測試策略 + 風險清單
Level 4：文化級	團隊一起提問、一起探索	PDT notes 成為團隊交付物	跨角色共識的品質地圖

這張表有一個重要訊息：階段之間不是「做得好 / 做得差」的差別，而是「個人 / 團隊 / 組織」的差別。

Level 1–2：個人努力就能做到
Level 3：需要你對專案有一定話語權
Level 4：超出個人範圍，牽涉到團隊與組織文化

所以請不要期待自己從 Level 1 直接跳到 Level 3——會很累，硬推通常也會被主管打回來。一次升一階就好。

回到你那個「1.5 天執行 + 0.5 天報告」的預算

給你三個階梯，從最低門檻開始爬：

最低門檻（往 Level 1.5 爬）

把 1.5 天執行的最後 2 小時，刻意關掉腳本、自由探索
帶著一個問題進去：「這個版本我最擔心的三件事是什麼？」
不一定要找到 bug——只要讓自己的不確定性下降，就算成功

中等門檻（到 Level 2）

1.5 天拆成「1 天跑腳本 + 0.5 天探索」
探索前花 15 分鐘寫下 5 個想問的問題（用第五節那四題當模板）
把探索發現寫進 0.5 天的報告裡，當成附加風險提示交付
這會讓你的報告比同事的報告多一層價值，而且肉眼可見

進階門檻（到 Level 3）

在開始測試之前，先花 30 分鐘做風險分析：這個版本改了什麼、改動影響什麼、哪裡最脆弱
依風險動態調整：高風險模組多探索、低風險模組用腳本或自動化帶過
這一層需要你跟 PM 或開發要到「這個版本改了什麼」的清單——要清單這個動作本身，就已經在累積影響力

一個心態上的翻轉

很多人卡在 Level 1 上不去，不是因為沒時間，是因為覺得「探索時間 = 沒產出時間」。

這個心態必須翻轉：

探索產出的不是案例結果，是「降低不確定性」這個成果。

當你的報告能告訴團隊「這個版本我最擔心的是 X、因為 Y」，你就已經不是「跑腳本的人」，而是「提供判斷依據的人」。

在複雜系統的時代，這兩種角色的價值正在快速拉開。

結語：測試工程師的價值，藏在「你問了什麼問題」

回到開台宣言那句話：測試的靈魂在於提問。

PDT 其實不是一個工具、不是一套 SOP、甚至不是一個流派——它是一種職業姿態。它區分的不是資深與資淺，而是**「執行者」與「研究者」**。

兩種角色的市場價值，會隨著系統複雜度的提升，差得越來越遠。

Cem Kaner 在《Lessons Learned in Software Testing》裡寫過一句話，我覺得最適合當這篇的句點：

“You are not paid to write test cases, you are paid to test.”

你不是因為「把案例寫完、跑完」才拿到薪水的——你是因為能為團隊判斷品質才拿到薪水的。這兩件事的差別，就是 PDT 存在的理由。

一個我還沒想清楚的問題

光知道 PDT 還不夠。真正難的是下面這題：

在一個只看腳本通過率的主管、只看交付時程的 PM、只看 bug 數字的團隊裡，你要怎麼把 PDT 真的推動起來？

說實話，這題我自己目前也還沒有完整答案。我正在自己的工作裡慢慢實驗——哪些說法主管聽得進去、哪些情境同事會自然買單、哪些場合硬推反而會讓人反感。等我踩過更多牆、累積更多實際的觀察之後，會再把心得整理成一篇獨立的文章。

如果你剛好也在嘗試，或是已經有自己的心得，歡迎留言交流——這條路可能結伴走比較遠。

如果這篇對你有幫助，歡迎把那張對照表截圖分享給身邊還在摸索測試價值定位的朋友。