Cache 測試：快取讓 bug 更難找，也讓 bug 更難修

Cache 測試：快取讓 bug 更難找，也讓 bug 更難修 目錄 1. 那個「你在測舊的版本」的 bug 2. Cache 讓測試複雜的幾種方式 3. Cache 相關的測試策略 4. Cache 失效的邊界情境 5. 結尾 那個「你在測舊的版本」的 bug 我們的 App 的樹種商店，我測試了「購買新樹種」的流程，顯示購買成功，但回到商店頁面，那棵樹還是顯示「未解鎖」。 我截圖，開 bug，說「購買後樹種狀態沒有更新」。 RD 看了之後說：「這個可能是 cache 問題，你試試看強制重整或者重開 App 看看。」 我試了，重開 App 之後，樹種正確顯示為「已解鎖」。 RD 說：「我們的商店頁面有 5 分鐘的 cache，購買後沒有 invalidate 這個 cache，所以顯示舊的狀態。是個 bug，但原因是 cache 沒有失效，不是購買邏輯有問題。」 如果我不知道 cache 的存在，我的 bug report 描述的問題方向就不對——「購買後樹種狀態沒有更新」和「購買後 cache 沒有失效」是兩件事，後者讓 RD 能更快定位。 Phil Karlton 有句名言在工程師圈廣泛流傳：「電腦科學只有兩個難題：快取失效（cache invalidation），和命名。」快取失效不只是實作難，測試起來也難——它的 bug 不會讓功能直接壞掉，而是讓系統在「對」和「錯」之間以時間差的方式搖擺。這種搖擺讓 QA 很容易誤判：「剛剛還好好的，為什麼現在壞了？」 Cache 讓測試複雜的幾種方式 1. 你在測 cache，不是功能 API 改了，但測試環境的 cache 還是舊的。你測到的是 cache 裡的舊資料，以為功能有問題，但其實是 cache 還沒有失效。 測試前要知道：這個功能有哪些 cache？cache 的 TTL（存活時間）是多少？怎麼手動清除 cache？ 2. Cache 導致跨裝置不一致 用戶在裝置 A 種了一棵樹，在裝置 B 上看，森林主頁顯示的是 cache 的舊版本，新種的樹沒有出現。幾分鐘後 cache 過期，才顯示正確。 這個問題在單一裝置上測試發現不了，需要多裝置測試。 3. Cache key 設計問題 不同用戶的 cache 如果用的 key 有 bug（比如 cache key 沒有包含 user ID），可能發生「用戶 A 看到用戶 B 的 cache 資料」。 這是一個安全問題，也是一個 cache 設計問題。測試方法：用兩個不同帳號在同一台裝置上交替使用，確認 cache 不會混淆。 4. Cache 讓 bug 的修復更複雜 修了一個 bug，但用戶的 cache 裡還是舊的行為。用戶反映「bug 還在」，但實際上 App 的邏輯已經修好了，只是 cache 裡還是舊版本。 這種情況，hotfix 可能需要同時清除對應的 cache，否則用戶需要等 TTL 過期才能看到修復。 Cache 相關的測試策略 測試前弄清楚 cache 的邊界 對每個功能，我會問 RD 這幾個問題： 1. 「這個頁面/API 有 cache 嗎？」 2. 「Cache 的 TTL 是多少？」 3. 「什麼操作會使 cache 失效（invalidate）？」 4. 「我怎麼在測試環境手動清 cache？」 有了這些資訊，我才能判斷測試時看到的結果是「功能的行為」還是「cache 的行為」。 測試 cache 失效的觸發 每個「應該讓 cache 失效」的操作，要驗證 cache 真的失效了： 購買新樹種 → 商店頁面的 cache 應該立刻失效 更新帳號資料 → 個人頁面的 cache 應該失效 訂閱到期 → Pro 功能的 cache 應該失效 測試方法：執行操作後， 立刻 （不等待）刷新頁面，確認顯示的是最新狀態，而不是 cache 的舊狀態。 多裝置的 cache 一致性 高風險情境： Cache 失效的邊界情境 Cache 失效中途 Cache 正在失效的瞬間（舊 cache 已過期，新資料還沒有載入），用戶看到的是什麼？ 可能的狀態： 空白/空資料（最差） Loading spinner（可接受） Stale data with loading indicator（最好） Cache 和實時更新的衝突 好友功能：好友 A 正在計時，你的首頁顯示好友的計時狀態，這個狀態有 10 秒的 cache。好友 A 突然結束計時，你的頁面應該在幾秒內更新，還是要等 10 秒？ 這需要 PM 定義預期行為，QA 確認實作符合預期。 大量資料的 cache 如果用戶有 100 棵樹，樹種資料的 cache 很大，cache 失效後需要重新載入的時間很長，用戶體驗怎麼樣？ 結尾 Cache 是效能優化的工具，但它讓系統的行為變得不那麼直觀：同一個操作，根據 cache 的狀態，可能有不同的結果。 作為 QA，了解 cache 的存在和邊界，能讓你的 bug report 更精確（「cache 沒有失效」比「資料沒有更新」更有用），也能讓你的測試覆蓋更真實（不是每次都等 cache 過期再測，也要測「操作完立刻查看」的情境）。 那個樹種商店的 bug，修法是：購買成功後，server side 主動 invalidate 那個用戶的商店頁面 cache，而不是讓用戶等 5 分鐘。簡單，但需要有人先找到這個問題。 參考資料 Caching Best Practices AWS Architecture Blog TwoHardThings (Cache Invalidation and Naming) Martin Fowler HTTP Caching MDN Web Docs Redis Documentation: Key Expiration Google Cloud CDN: Testing Cache Behavior