現代軟體測試與 AI 實戰 (2)：測試金字塔的崩塌與冰淇淋筒反模式

上一篇文章我們提到了 TDD（測試驅動開發）的核心精神，但在真實世界的專案中，許多團隊明明引入了自動化測試，卻還是每天救火、上線前心驚膽戰。

這往往是因為測試的「結構」出了問題。今天我們來聊聊業界最著名的架構隱憂——冰淇淋筒反模式 (The Ice Cream Cone Anti-Pattern)。

什麼是「健康的測試金字塔」？

在談反模式之前，我們先複習一下 Mike Cohn 提出的 測試金字塔 (Testing Pyramid) 概念：

健康的專案應該像一座穩固的金字塔：

1. 單元測試 (Unit Tests)：位在最底層，數量最多。因為它們執行速度極快（幾毫秒），且成本極低。如果你改壞了一個條件判斷式，單元測試會在 1 秒內立刻告訴你。
2. 整合測試 (Integration Tests)：位在中間，數量適中。用來驗證資料庫連線、API 請求等跨元件行為。
3. UI / 端到端測試 (E2E Tests)：位在頂端，數量最少。因為 UI 測試需要啟動瀏覽器，執行極慢，且一旦 UI 稍微改版，測試就容易壞掉 (Flaky)。

現實的骨感：冰淇淋筒反模式 (Ice Cream Cone)

理想很豐滿，現實很骨感。走進大多數缺乏嚴謹工程文化的辦公室，你會發現他們的測試結構是一支倒過來的冰淇淋筒。

為什麼會融化成冰淇淋？

通常有以下幾個場景：

1. 「工程師沒時間寫測試啦！」：公司要求快速推進功能 (Feature Factory)，工程師把 code 寫完就丟過牆給 QA 測試。結果底層的「單元測試」幾乎是 0。
2. 「我們來導入自動化吧！」：管理層決定要自動化，於是要求 QA 去寫 Selenium 或 Playwright 的 UI 自動化腳本。這導致中間那層 UI 自動化變得超級肥大。
3. 「自動化又壞了，還是手動測比較安心。」：UI 測試極度脆弱 (Flaky)，只要工程師改了一個 div 的 ID，自動化腳本就會報大錯。久而久之沒人想修，最後大家還是只能回到「頂層最大陀的冰淇淋」——純人工點擊驗收。

冰淇淋筒帶來的災難

• 回饋迴圈極長：工程師寫錯了邏輯，無法在 1 秒內知道。必須等好幾天，QA 甚至客戶在畫面上點擊時才發現。那時工程師早就忘記當初寫這段 code 的邏輯了。 (就像 debug 時，從畫面一路 tracing 到底層函數，這是一個 Shrinking 縮小範圍的痛苦過程)。
• 部署恐懼症：沒有底層單元測試的保護，每次 refactor (重構) 就像在玩踩地雷，根本不敢去動前人留下來的 Legacy Code。

該如何把冰淇淋融化，找回金字塔？

要把冰淇淋翻轉回金字塔，絕對不是「叫 QA 少測一點」這麼簡單，而是必須推動測試左移 (Shift-Left) 的文化：

了解了反模式之後，下一篇我們將繼續挖掘團隊管理與基礎建設的隱形殺手：組織與環境的隱形殺手：測試孤島與環境迷思。