一、把 30 天摺成一張地圖

先把走過的路攤開。這 30 天不是三十個獨立的主題，是一棟四層的房子，每一層都踩在下一層上：

圖 1：30 天知識地圖——四個階段疊成一棟房子，判讀與溝通是測試人員住的那一層

第一階段（Day 1–7）：觀念與第一次小勝利。三個核心問題（撐得住多少人、多快回應、撐得了多久）、工具選擇、百分位數、壓測禮儀，到 Day 7 的第一個有裁判的 smoke test。這一層的關鍵字是紅綠燈：讓 thresholds 當裁判，你從第一週就有了可以自動判定的測試。

第二階段（Day 8–15）：腳本實作與真實系統的麻煩。真實系統會要登入、要 token、會產生髒資料、腳本會壞——參數化、關聯、除錯、負載模型、scenarios、腳本整理,最後用一次 AI 審查收尾。這一層的關鍵字是除錯工作流程：腳本第一次幾乎不會動是常態，帶著 AI 修好它是能力。

第三階段（Day 16–23）：判讀、溝通與報告。這是系列的重心，也是測試人員的核心價值所在：從業務推門檻、在半規格環境做相對比較、三條線索找瓶頸、可信度四問、視覺化、報告、開單、進 CI。這一層的關鍵字是證據：每個結論都有數據撐、每個數據都先驗過可信度、每張單都讓 RD 十分鐘能重現。

第四階段（Day 24–30）：進階場景與收尾。Soak、雲端、瀏覽器層、混合場景、跨協定——每一個都是「本機的 HTTP 一來一回」之外的世界；然後是 AI 協作的總帳與今天的地圖。這一層的關鍵字是場景：知道每種武器存在、知道何時該用，需要時回來翻。

注意這棟房子的比例：工具與語法只占前兩層，而且是最薄的兩層。這是刻意的——Day 29 講過原因：生成的成本歸零了，判讀與溝通才是會升值的部分。如果三個月後你只記得住一層，記第三層。

二、自我檢核：每週結束時，你能做出什麼

學習地圖回答「學了什麼」，但工作上真正的問題是「能做出什麼」。下面這份清單把 30 天換算成四個星期的產出——每一條都是可以交付的東西，不是知識點。逐條打勾，缺的那條就是回去重讀的那幾天：

這張表還有一個用法：拿去和主管談。「效能測試我學到哪了」很難談,「我現在可以幫團隊把 smoke 掛進 CI、下個版本交效能報告」很好談——這就是 Day 22 說的,把立場問題變成可交付的問題。四週的產出全部打勾的人，
你已經不是「會一點效能測試」，你是團隊裡有能力對效能說話的人——多數團隊一個都沒有。

三、三條往前的路

30 天走完，前面有三條路。不是三選一，是先後問題——看你的團隊現在最痛哪裡。

圖 2：三條後續路線——從你已經站的位置出發，各自通往不同的縱深

路線一：可觀測性（Observability）——往「因」的方向走。這 30 天你一直站在系統外面看「果」：k6 端的數據、曲線的形狀、Day 24 那張只能請 RD 幫忙截圖的伺服器監控。可觀測性就是把那道牆拆掉——學會看 metrics、logs、traces 三件套，看懂 Grafana 的儀表板，甚至自己下 PromQL 查詢。走這條路之後，Day 18 的「三條線索縮小範圍」會升級成「直接看見哪個服務、哪條 SQL 慢」。適合誰：常常測出問題、卻總卡在「然後只能等 RD 查」的人。第一步：請 RD 給你看一次你們家 Grafana 上「壓測時段」的儀表板，把 Day 24 第四節那張清單逐項對到真實的面板上。

路線二：自動化深化——往「常態」的方向走。Day 23 掛上的只是 smoke。這條路把效能測試從「事件」變成「日常」：load test 排程化、歷次結果自動比較（回歸偵測——這次比上次慢 15% 就示警）、效能預算寫進 pipeline、Day 26 的 Web Vitals 也進 CI 追蹤。走到後來，你維護的不是測試，是一套效能的雷達系統。適合誰：團隊發版頻繁、Day 22 說的「量尺」角色已經開始成形的人。第一步：把 Day 23 的 workflow 加上「與上一次結果比較」——請 Claude Code 幫你把兩次 summary.json 的 p95 相減，超過閾值就讓 job 變紅。

路線三：領域深化——往「底層」的方向走。曲線告訴你「資料庫可能有問題」，這條路讓你看得懂問題本身：SQL 執行計畫、索引為什麼有效、連線池怎麼調、快取策略、負載平衡與水平擴展——Day 18 的推測會變成有把握的診斷，Day 21 的建議會從「候選清單」變成「可行方案」。這條路最長，但走進去的測試人員最稀有,通常也走向效能工程師（Performance Engineer）的職涯。適合誰：對「為什麼慢」比「有多慢」更好奇的人。第一步：挑一條你測出來最慢的 API，請 RD 帶你看一次它的 SQL 與執行計畫，用 Claude Code 當翻譯——你會發現 Day 11 的除錯工作流程在這裡一樣好用。

三條路共用同一個起點：你已經會量、會判讀、會溝通。這三件事不會因為往任何方向深化而作廢——它們是三條路共同的地基。

四、資源清單：接下來讀什麼、跟誰學

工具會改版，所以這份清單以「去哪裡找」為主，不背版本細節（Day 29 的老規矩：讓它查，不要背）。

官方資源。k6 官方文件（grafana.com/docs/k6）是第一站，這 30 天每次「請先查現行文件」查的都是它;官方的 k6-learn workshop 教材（GitHub 上的 grafana/k6-learn）是一套完整的教學投影片與講義，拿來複習或在公司內部開分享會都很合適；QuickPizza 的 repo（grafana/quickpizza）可以整套拉到自己機器上跑——練習站搬回家，Day 6 的流量禮儀就再也不是限制，stress 與 breakpoint 想怎麼壓就怎麼壓。

社群與延伸。Grafana 官方部落格的 k6 分類會發布新功能與實戰案例；效能測試的經典書籍值得挑一本啃（請 Claude Code 依你的路線推薦並摘要）；台灣的測試社群（如各測試相關年會與讀書會）裡，效能測試的分享正在變多——你現在有能力聽懂了，下一步是站上去講：把這 30 天的某一段做成 20 分鐘的內部分享，是最好的複習。

最重要的資源：你自己的 repo。這 30 天留下的東西——journey 腳本、共用模組、報告範本、缺陷單範本、perf-smoke.yml、六個協作習慣——比任何教材都值錢，因為它們已經長成你的工作流程。維護它,像 Day 14 說的那樣：下一次不用重寫，是所有效率的起點。

五、結語：從排隊的比喻，到有能力對效能說話的人

回到 Day 1。那天的你可能連 JavaScript 都沒寫過，對效能測試的全部印象是「好像很難、要會寫程式」。三十天後盤點一下口袋：你跑過 smoke、load、soak、混合場景；你在半規格的環境裡做過誠實的相對比較；你寫過 RD 十分鐘能重現的缺陷單；你的 smoke test 此刻可能正掛在 CI 上替團隊把關;你知道 AI 哪裡快、哪裡會失手、怎麼讓它自己標出弱點。

「不會寫程式」這件事,最後被證明從來不是重點。效能測試的核心從來不是語法，是判斷：多少人算尖峰、多慢算太慢、這個數字能不能信、該不該擋上線——這些問題 30 天前就存在，30 天後依然由人回答，只是現在,回答的人可以是你。

產出會越來越快，會判讀的人只會越來越稀缺。這是驗證瓶頸的時代——對願意花 30 天練判讀的人來說,是最好的時代。

去吧。下一次有人在會議室裡問「這個系統撐得住嗎」，你知道該怎麼做：先問撐得住是指什麼、多少人、多快——然後打開終端，讓數據說話。

給 RD 的一句話：這個系列結束了，但你團隊裡多了一個會量、會判讀、會開好單的夥伴。他的門檻歡迎你挑戰、他的推論標好了記號、他的單子十分鐘能重現——請用對待專業的方式回應這些專業。效能是團隊的事，現在終於有人專門盯著它了。

六、觀念驗證：最後三個問題

• 四個階段的關鍵字各是什麼？為什麼判讀與溝通那一層是「測試人員住的那一層」？（第一節）
• 自我檢核清單為什麼寫成「能做出什麼」而不是「學過什麼」？它和主管的對話有什麼關係？（第二節）
• 三條後續路線各自往哪個方向走、適合誰？你打算先走哪一條，第一步是什麼？（第三節）

七、三十天,全劇終

這是本系列的最後一篇。三十天,一個不會寫程式的測試人員,和一個很會寫程式的 AI，把效能測試從「別人的專業」變成了「自己的能力」。地圖給你了，檢核表給你了,三條路也給你了——剩下的部分，在你的終端裡。k6 run,開始吧。