概念地圖・測試自動化金字塔
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
測試自動化金字塔：把定位成本往下層搬
一套監理所線上預約系統，工程師每改一行程式，自動測試要跑三小時四十分鐘才給答案。早上十點按下去，下午一點半才知道有沒有壞。中間那三個半小時，人不會停在原地——他繼續改下一段，於是紅燈亮起來的時候，已經沒人分得清是哪一段害的。測試自動化金字塔畫的就是這件事：同一套系統的驗證，要分幾層、每層放幾個。底層又多又快，往上愈少愈慢。它排的是兩件很實際的事——回饋速度，與定位成本。
三層各幾個測試，各跑多久
把一套系統的自動測試照層數一次，會得到三組數字：個數、跑完要多久、壞了以後平均多久才定位到那一行。
| 層 | 測試個數 | 全層跑完 | 壞了平均多久定位到那一行 |
|---|---|---|---|
| 單元層 | 1840 | 3 分鐘 | 4 分鐘 |
| 服務層（API） | 260 | 11 分鐘 | 25 分鐘 |
| 介面層（端對端） | 48 | 42 分鐘 | 95 分鐘 |
三層加起來 2148 個測試，一輪 56 分鐘。上班八小時是 480 分鐘，這個形狀一天跑得完八輪。表格右邊那一欄才是這張圖真正的重點——同樣一顆紅燈，在最底層是四分鐘的小事，在最上層是一個半小時的偵探工作。
一個測試案例該寫在單元還是介面
有些測試搬得下去，有些只能留在上層。底下四個自問，是決定一個案例落在哪一層的實際判準。
一、這件事非得走完整條路才驗得到嗎。兩個預約時段有沒有重疊，是一條規則——餵它兩筆時間，它該說重疊。這種判斷不需要開瀏覽器、不需要登入、不需要一台測試機。監理站那套系統裡，規費怎麼算、車齡到期沒、身分證字號格式對不對，全都屬於這一類。它們被寫在介面層的時候，一個要跑五十幾秒；搬到單元層，一千八百多個一起跑才 3 分鐘。自問：這件事非得把整條路走完，才驗得出來嗎？
二、紅燈亮的時候，訊息會指到哪裡。介面層的失敗訊息長這樣：找不到指定的按鈕。它告訴你畫面上少了一顆按鈕，沒告訴你為什麼少。工程師得自己回頭猜——是排程模組、是權限判斷，還是前端改了樣式名稱。監理站那套系統改版前，這種猜測平均要花 95 分鐘。單元層的失敗訊息會直接寫「預期 450，實得 400」，那一行在哪，訊息自己說了。自問：它壞掉的時候，錯誤訊息會不會直接指到我要改的那一行？
三、它多久會無故變紅一次。驗車排程那組介面測試，跑一輪紅三個，重跑一次就綠了——網路慢、動畫還沒播完、資料庫剛好在做備份。改版前 310 個介面測試裡，約 68 個屬於這種偶發失敗，比例 22%。這個數字一過某條線，紅燈就不再是訊息，值班的人第一個動作會變成「先重跑一次看看」。那一刻起，整層測試變成裝飾。自問：這個測試上週紅了幾次，其中幾次是真的壞了？
四、加進去以後，今天還按得動幾次。一個測試的價值要看它一天能給你幾次答案。監理站改版前一輪 220 分鐘，上班時間按得動兩輪；改版後一輪 56 分鐘，同樣八小時按得動八輪。同樣一批人、同樣一套系統，回饋從一天兩次變成一天八次——中間沒有任何一個人變聰明，只是把驗證換了位置。自問：把它加進這一層以後，我今天還按得動幾次？
一套監理所預約系統的測試清單，三層各數一次
底下這套台灣中部某監理站的線上預約與驗車排程系統，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實機關。
- 先數改版前那一套：單元 120 個、服務 90 個、介面 310 個，合計 520 個，全套跑 220 分鐘。形狀是上寬下窄的倒三角。一天兩輪
- 看介面層的紅燈品質：那 310 個裡約 68 個是偶發失敗，重跑一次才過。值班表上寫的第一條處理程序，是「重跑」。紅燈失去意義
- 把規則往下搬：時段重疊、車齡到期、規費級距、證號格式——這些在單一模組裡就驗得完的判斷，改寫成單元測試，長成 1840 個，全層 3 分鐘跑完。4 分鐘就定位
- 接縫留在服務層：預約系統與監理資料庫之間的合約、排程服務回傳的欄位格式，留在 API 層驗，260 個，11 分鐘。接縫有人守
- 介面層只留非走不可的路：預約成功、改期、取消、繳費，加上各自的關鍵分支，收斂成 48 個，42 分鐘。42 分鐘的等待
改完之後測試總數從 520 個長到 2148 個，跑一輪的時間卻從 220 分鐘掉到 56 分鐘。多出來的一千六百多個測試沒有讓誰更辛苦——它們幾乎全在最底層，三分鐘一次全部跑完。真正值得記住的接縫在最後一段：介面層從 310 個砍到 48 個，被砍掉的那 262 個大多換了個位置繼續驗，省下來的全是等待。留下來的那四條路有一個共同點——走不完，明天監理站的櫃檯就要多排一條人龍。這個形狀讓團隊一天拿到八次答案，而不是兩次；而每一次答案，都指得到那一行。以上為說明結構用的示意情境，僅供理解框架之用。
這個形狀什麼時候會騙你
- 個數湊得出形狀，湊不出信心。要把倒三角翻成金字塔，最快的做法是替每個屬性讀寫各寫一個單元測試。數字漂亮了、形狀對了，但那 1840 個裡如果有一半在驗「存進去 A、讀出來 A」，它們一個真正的錯誤都攔不住。看形狀之前先問一件事：最近三個月被測試攔下來的問題，是哪一層攔的？答案要是「幾乎都靠人工測試發現」，那座金字塔只是張畫。
- 底層全綠，不代表使用者按得下去。單元層驗的是每個零件自己對不對，服務層驗零件之間講不講得通。兩層都綠，畫面上那顆「確認預約」按鈕還是可能沒接上事件——民眾點下去，什麼都沒發生。介面層那 48 個留著就是為了這件事。它們慢、它們貴，但它們是整套測試裡唯一會替真實使用者按一次的角色。砍到零的那一天，客服電話就變成你的測試環境。
- 形狀對了，時間不一定對。金字塔畫的是個數的分佈，時間要另外量。1840 個單元測試如果每一個都連一次資料庫、每一個都起一次完整的應用程式框架，3 分鐘會變成 30 分鐘——形狀還是金字塔，回饋一樣慢。所以真正該盯的數字是碼表：每一層跑完各幾分鐘，寫在牆上，每週看一次。形狀是結果，時間才是你要管的東西。
那 42 分鐘，是誰在等
那 42 分鐘，帳掛在機器身上。
按下去的人不會盯著進度條看 42 分鐘。他去改下一段程式、回一封信、開一場會。等紅燈亮起來，他腦子裡那份「我剛剛動了什麼」已經散了——接下來的 95 分鐘，是把它重新拼回來的時間。所以介面層那 48 個測試，貴的地方在人：注意力被切斷兩次，第一次在等，第二次在猜。《痛點》那把尺問的是誰在痛、痛得夠不夠深。搬到這裡，痛的人有名有姓——值班的工程師、等著上線的產品經理，還有明天早上要改期卻按不動按鈕的民眾。這張圖畫得出每一層要跑多久，畫不出這三個人裡誰最等不起。個數可以數，形狀可以畫，等的人只能去問。今晚打開最近十次的 CI 紀錄，只抄一個數字：跑完各花了幾分鐘。
關於測試金字塔，常被問到的幾件事
測試一定要排成金字塔嗎？聽說也有人主張獎盃形狀。
獎盃形狀（testing trophy）把最寬的一層放在服務層，理由是現代系統的多數錯誤出在整合處。兩種形狀爭的其實是同一題：哪一層的回饋最快、定位最省。如果你的服務層跑 11 分鐘、定位 25 分鐘，把它加寬很划算；如果那一層要開三個容器、跑 40 分鐘，它就不該當主力。先量出自己那三個數字，形狀會自己浮出來。
介面層到底該留幾個？
沒有通用數字，但有一個可操作的起點：列出「這條路壞了，明天就會有人打電話進來」的路徑。監理站那套系統列出四條——預約成功、改期、取消、繳費——每條再展開幾個關鍵分支，收斂成 48 個。判準是一句話：這條路走不完，業務就停擺。列不進這句話的，往下搬一層。數量要等列完才知道——先訂一個目標數，只會逼人湊。
舊系統已經是倒三角，要怎麼翻過來？
不要停下來重寫。監理站那次的做法是三步：介面層先只處理偶發失敗那一批，把 68 個裡最常紅的挑出來修或刪；空出來的時間拿去補單元層；接著訂一條規矩，每修一個線上問題，就在最底層補一個能攔住它的測試。形狀是一季一季長出來的，用每一次修錯誤換一個底層測試——三個月以後回頭數，比例自己就變了。
單元測試寫太多，之後重構會不會綁手綁腳？
會，前提是它們測的是實作細節。單元測試該綁的是行為：餵這兩個時段，回傳重疊。一旦它開始檢查某個內部方法被呼叫幾次，你改寫內部寫法就會弄紅一整片，測試從防護網變成水泥。判斷方法很簡單——做一次不改變任何行為的重構，如果測試紅了，紅的那些就是綁在實作上的，那才是該重寫的對象。
量一次全套跑完要多久，再決定要不要把案例往下搬。同一套系統的另一種驗證問題——要收多少資料才看得出差異——可以接著看A/B 測試的樣本數估算。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。